[RFC PATCH] Documentation/arm64: describe the kernel's expectations of 'memory'

[James Morse]

Hi Jonathan, Ard,

On 17/05/2021 13:25, Ard Biesheuvel wrote:
> On Mon, 17 May 2021 at 14:19, Jonathan Cameron <Jonathan.Cameron at huawei.com> wrote:
>> On Mon, 17 May 2021 13:55:16 +0200 Ard Biesheuvel <ardb at kernel.org> wrote:
>>> On Mon, 17 May 2021 at 13:30, Jonathan Cameron <Jonathan.Cameron at huawei.com> wrote:
>>>> On Mon, 17 May 2021 11:33:19 +0100 James Morse <james.morse at arm.com> wrote:>>>>> Document linux's expectations around the behaviour of memory as the

>>>>> +On arm64, the kernel does not rewrite the UEFI memory map when memory is added
>>>>> +or removed. On device memory that is present at boot, but must be removed later
>>>>
>>>> Might be worth giving an example of why memory 'must be removed'?  I'm not sure
>>>> what you are getting at there.

[...]

>> Two separate issues here. The 'broken' one where _SP or indeed
>> hotplug flag is no use, and the one where it is 'must be removed later'
>> and we just don't want to put unmovable allocations in it.

> I am not sure I follow the 'must be removed' thing. Why is that needed?

This phrase was to cover people who want to remove memory that was present at boot... but
they didn't want it to be. I think dedicating it to VMs is the popular use case, (and, er,
bypassing all the OSes memory management...).

If its in the UEFI memory map, the kernel expects it can't be removed. It might be in use
by something, and even if its not - we don't want to rewrite the UEFI
tables/tree/lists/maps to remove it, and we certainly can't do that in a future proof manner.

It might not be relevant to CXL, but its one of the pain points of hotplug memory.

I'm not sure I can come up with a terse example:
| e.g. a memory carve-out that must be also be respected by a future OS loaded via kexec()
?


Thanks,

James