On 01.05.20 00:24, Andrew Morton wrote:
On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand [off-list ref] wrote:
quoted
quoted
Why does the firmware map support hotplug entries?
I assume:
The firmware memmap was added primarily for x86-64 kexec (and still, is
mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs
get hotplugged on real HW, they get added to e820. Same applies to
memory added via HyperV balloon (unless memory is unplugged via
ballooning and you reboot ... the the e820 is changed as well). I assume
we wanted to be able to reflect that, to make kexec look like a real reboot.
This worked for a while. Then came dax/kmem. Now comes virtio-mem.
But I assume only Andrew can enlighten us.
@Andrew, any guidance here? Should we really add all memory to the
firmware memmap, even if this contradicts with the existing
documentation? (especially, if the actual firmware memmap will *not*
contain that memory after a reboot)
For some reason that patch is misattributed - it was authored by
Shaohui Zheng [off-list ref], who hasn't been heard from in
a decade. I looked through the email discussion from that time and I'm
not seeing anything useful. But I wasn't able to locate Dave Hansen's
review comments.
Okay, thanks for checking. I think the documentation from 2008 is pretty
clear what has to be done here. I will add some of these details to the
patch description.
Also, now that I know that esp. kexec-tools already don't consider
dax/kmem memory properly (memory will not get dumped via kdump) and
won't really suffer from a name change in /proc/iomem, I will go back to
the MHP_DRIVER_MANAGED approach and
1. Don't create firmware memmap entries
2. Name the resource "System RAM (driver managed)"
3. Flag the resource via something like IORESOURCE_MEM_DRIVER_MANAGED.
This way, kernel users and user space can figure out that this memory
has different semantics and handle it accordingly - I think that was
what Eric was asking for.
Of course, open for suggestions.
--
Thanks,
David / dhildenb