lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 1 May 2020 14:52:03 -0700 From: Dan Williams <dan.j.williams@...el.com> To: David Hildenbrand <david@...hat.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux MM <linux-mm@...ck.org>, virtio-dev@...ts.oasis-open.org, virtualization@...ts.linux-foundation.org, linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>, Linux ACPI <linux-acpi@...r.kernel.org>, linux-nvdimm <linux-nvdimm@...ts.01.org>, linux-hyperv@...r.kernel.org, linux-s390 <linux-s390@...r.kernel.org>, xen-devel <xen-devel@...ts.xenproject.org>, Michal Hocko <mhocko@...nel.org>, "Michael S . Tsirkin" <mst@...hat.com>, Michal Hocko <mhocko@...e.com>, Pankaj Gupta <pankaj.gupta.linux@...il.com>, Wei Yang <richard.weiyang@...il.com>, Baoquan He <bhe@...hat.com> Subject: Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP On Fri, May 1, 2020 at 2:11 PM David Hildenbrand <david@...hat.com> 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?
Powered by blists - more mailing lists