search for: mhp_no_firmware_memmap

...kernel. > > We should let the kexec kernel decide how to use that memory - just as > we do during an ordinary reboot. ... > - rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0); > + rc = add_memory(numa_node, new_res->start, resource_size(new_res), > + MHP_NO_FIRMWARE_MEMMAP); Looks fine. But, if you send another revision, could you add a comment about the actual goal of MHP_NO_FIRMWARE_MEMMAP? Maybe: /* * MHP_NO_FIRMWARE_MEMMAP ensures that future * kexec'd kernels will not treat this as RAM. */ Not a biggie, though. Acked-by: Dave Hansen <dave.han...

...emory_hotplug.h @@ -68,6 +68,14 @@ struct mhp_params { pgprot_t pgprot; }; +/* Flags used for add_memory() and friends. */ + +/* + * Don't create entries in /sys/firmware/memmap/. The memory is detected and + * added via a device driver, not via the initial (firmware) memmap. + */ +#define MHP_NO_FIRMWARE_MEMMAP 1 + /* * Zone resizing functions * diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index c01be92693e3..e94ede9cad00 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resource *res, BUG_ON(ret); /* create...

...m.c @@ -65,7 +65,8 @@ int dev_dax_kmem_probe(struct device *dev) new_res->flags = IORESOURCE_SYSTEM_RAM; new_res->name = dev_name(dev); - rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0); + rc = add_memory(numa_node, new_res->start, resource_size(new_res), + MHP_NO_FIRMWARE_MEMMAP); if (rc) { release_resource(new_res); kfree(new_res); -- 2.25.3

...ating that >> this is not to be used for ordinary hotplugged DIMMs - only when the >> device driver is under control to decide what to do with that memory - >> especially when kexec'ing. >> >> (previously, I called this flag MHP_DRIVER_MANAGED, but I think >> MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description) >> >> Would that make it clearer? > > I am not certain, but Andrew Morton deliberately added that > firmware_map_add_hotplug call. Which means that there is a reason > for putting hotplugged memory in the firmware map. > &...

On 01.05.20 00:24, Andrew Morton wrote: > On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com> wrote: > >>> >>> 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

On 30.04.20 17:38, Eric W. Biederman wrote: > David Hildenbrand <david at redhat.com> writes: > >> Some devices/drivers that add memory via add_memory() and friends (e.g., >> dax/kmem, but also virtio-mem in the future) don't want to create entries >> in /sys/firmware/memmap/ - primarily to hinder kexec from adding this >> memory to the boot memmap of the

...ertainly rephrase the subject/description/comment, stating that this is not to be used for ordinary hotplugged DIMMs - only when the device driver is under control to decide what to do with that memory - especially when kexec'ing. (previously, I called this flag MHP_DRIVER_MANAGED, but I think MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description) Would that make it clearer? Thanks! -- Thanks, David / dhildenb

On Fri, May 1, 2020 at 2:11 PM David Hildenbrand <david at redhat.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 >

On 01.05.20 18:56, Dan Williams wrote: > On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 00:24, Andrew Morton wrote: >>> On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com> wrote: >>> >>>>> >>>>> Why does the firmware map support hotplug entries?

>> 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,

On 01.05.20 19:39, Dan Williams wrote: > On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 18:56, Dan Williams wrote: >>> On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david at redhat.com> wrote: >>>> >>>> On 01.05.20 00:24, Andrew Morton wrote: >>>>> On Thu, 30 Apr 2020

...ms { > pgprot_t pgprot; > }; > > +/* Flags used for add_memory() and friends. */ > + > +/* > + * Don't create entries in /sys/firmware/memmap/. The memory is detected and > + * added via a device driver, not via the initial (firmware) memmap. > + */ > +#define MHP_NO_FIRMWARE_MEMMAP 1 > + > /* > * Zone resizing functions > * > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index c01be92693e3..e94ede9cad00 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struc...

...ms { > pgprot_t pgprot; > }; > > +/* Flags used for add_memory() and friends. */ > + > +/* > + * Don't create entries in /sys/firmware/memmap/. The memory is detected and > + * added via a device driver, not via the initial (firmware) memmap. > + */ > +#define MHP_NO_FIRMWARE_MEMMAP 1 > + > /* > * Zone resizing functions > * > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index c01be92693e3..e94ede9cad00 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struc...

On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: > > On 01.05.20 19:45, David Hildenbrand wrote: > > On 01.05.20 19:39, Dan Williams wrote: > >> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: > >>> > >>> On 01.05.20 18:56, Dan Williams wrote: > >>>> On Fri, May 1,

...em memory (anything not directly under the root when parsing /proc/iomem) to the elfcorehdr, so this memory will never get included in a dump. This probably has to be fixed in kexec-tools - virtio-mem will require this as well. v1 -> v2: - Don't change the resource name - Rename the flag to MHP_NO_FIRMWARE_MEMMAP to reflect what it is doing - Rephrase subjects/descriptions - Use the flag for dax/kmem I'll have to rebase virtio-mem on these changes, there will be a resend. [1] https://lkml.kernel.org/r/20200429160803.109056-1-david at redhat.com David Hildenbrand (3): mm/memory_hotplug: Prepare pass...

On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com> wrote: > > > > 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.

On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david at redhat.com> wrote: > > > > 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.

On Fri, May 1, 2020 at 11:14 AM David Hildenbrand <david at redhat.com> wrote: > > On 01.05.20 20:03, Dan Williams wrote: > > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: > >> > >> On 01.05.20 19:45, David Hildenbrand wrote: > >>> On 01.05.20 19:39, Dan Williams wrote: > >>>> On Fri, May 1, 2020

.../description/comment, stating that > this is not to be used for ordinary hotplugged DIMMs - only when the > device driver is under control to decide what to do with that memory - > especially when kexec'ing. > > (previously, I called this flag MHP_DRIVER_MANAGED, but I think > MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description) > > Would that make it clearer? I am not certain, but Andrew Morton deliberately added that firmware_map_add_hotplug call. Which means that there is a reason for putting hotplugged memory in the firmware map. So the justification needs to take...

.../description/comment, stating that > this is not to be used for ordinary hotplugged DIMMs - only when the > device driver is under control to decide what to do with that memory - > especially when kexec'ing. > > (previously, I called this flag MHP_DRIVER_MANAGED, but I think > MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description) > > Would that make it clearer? I am not certain, but Andrew Morton deliberately added that firmware_map_add_hotplug call. Which means that there is a reason for putting hotplugged memory in the firmware map. So the justification needs to take...