On Fri, May 1, 2020 at 2:11 PM David Hildenbrand <david@xxxxxxxxxx> wrote: > > On 01.05.20 22:12, Dan Williams wrote: [..] > >>> Consider the case of EFI Special Purpose (SP) Memory that is > >>> marked EFI Conventional Memory with the SP attribute. In that case the > >>> firmware memory map marked it as conventional RAM, but the kernel > >>> optionally marks it as System RAM vs Soft Reserved. The 2008 patch > >>> simply does not consider that case. I'm not sure strict textualism > >>> works for coding decisions. > >> > >> I am no expert on that matter (esp EFI). But looking at the users of > >> firmware_map_add_early(), the single user is in arch/x86/kernel/e820.c > >> . So the single source of /sys/firmware/memmap is (besides hotplug) e820. > >> > >> "'e820_table_firmware': the original firmware version passed to us by > >> the bootloader - not modified by the kernel. ... inform the user about > >> the firmware's notion of memory layout via /sys/firmware/memmap" > >> (arch/x86/kernel/e820.c) > >> > >> How is the EFI Special Purpose (SP) Memory represented in e820? > >> /sys/firmware/memmap is really simple: just dump in e820. No policies IIUC. > > > > e820 now has a Soft Reserved translation for this which means "try to > > reserve, but treat as System RAM is ok too". It seems generically > > useful to me that the toggle for determining whether Soft Reserved or > > System RAM shows up /sys/firmware/memmap is a determination that > > policy can make. The kernel need not preemptively block it. > > So, I think I have to clarify something here. We do have two ways to kexec > > 1. kexec_load(): User space (kexec-tools) crafts the memmap (e.g., using > /sys/firmware/memmap on x86-64) and selects memory where to place the > kexec images (e.g., using /proc/iomem) > > 2. kexec_file_load(): The kernel reuses the (basically) raw firmware > memmap and selects memory where to place kexec images. > > We are talking about changing 1, to behave like 2 in regards to > dax/kmem. 2. does currently not add any hotplugged memory to the > fixed-up e820, and it should be fixed regarding hotplugged DIMMs that > would appear in e820 after a reboot. > > Now, all these policy discussions are nice and fun, but I don't really > see a good reason to (ab)use /sys/firmware/memmap for that (e.g., parent > properties). If you want to be able to make this configurable, then > e.g., add a way to configure this in the kernel (for example along with > kmem) to make 1. and 2. behave the same way. Otherwise, you really only > can change 1. That's clearer. > > > Now, let's clarify what I want regarding virtio-mem: > > 1. kexec should not add virtio-mem memory to the initial firmware > memmap. The driver has to be in charge as discussed. > 2. kexec should not place kexec images onto virtio-mem memory. That > would end badly. > 3. kexec should still dump virtio-mem memory via kdump. Ok, but then seems to say to me that dax/kmem is a different type of (driver managed) than virtio-mem and it's confusing to try to apply the same meaning. Why not just call your type for the distinct type it is "System RAM (virtio-mem)" and let any other driver managed memory follow the same "System RAM ($driver)" format if it wants?
