search for: firmware_map_add_hotplug

...h 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 that reason into account. The justification can not be it is hotplugged therefore it should not belong in the firmware memory map. Unless you can show that firmware_map...

...h 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 that reason into account. The justification can not be it is hotplugged therefore it should not belong in the firmware memory map. Unless you can show that firmware_map...

...*resource_name = "System RAM"; > > /* > * Make sure value parsed from 'mem=' only restricts memory adding > @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resource *res, > BUG_ON(ret); > > /* create new memmap entry */ > - firmware_map_add_hotplug(start, start + size, "System RAM"); > + if (!(flags & MHP_DRIVER_MANAGED)) > + firmware_map_add_hotplug(start, start + size, "System RAM"); > > /* device_online() will take the lock when calling online_pages() */ > mem_hotplug_done(); > @@ -1081,10 +...

...*resource_name = "System RAM"; > > /* > * Make sure value parsed from 'mem=' only restricts memory adding > @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resource *res, > BUG_ON(ret); > > /* create new memmap entry */ > - firmware_map_add_hotplug(start, start + size, "System RAM"); > + if (!(flags & MHP_DRIVER_MANAGED)) > + firmware_map_add_hotplug(start, start + size, "System RAM"); > > /* device_online() will take the lock when calling online_pages() */ > mem_hotplug_done(); > @@ -1081,10 +...

...zing 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 new memmap entry */ - firmware_map_add_hotplug(start, start + size, "System RAM"); + if (!(flags & MHP_NO_FIRMWARE_MEMMAP)) + firmware_map_add_hotplug(start, start + size, "System RAM"); /* device_online() will take the lock when calling online_pages() */ mem_hotplug_done(); -- 2.25.3

...n 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 that reason into account. The > justification can not be it is hotplugged therefore it should not belong > in the firmware memory map. Unless you c...

...RCE_SYSTEM_RAM | IORESOURCE_BUSY; - char *resource_name = "System RAM"; /* * Make sure value parsed from 'mem=' only restricts memory adding @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resource *res, BUG_ON(ret); /* create new memmap entry */ - firmware_map_add_hotplug(start, start + size, "System RAM"); + if (!(flags & MHP_DRIVER_MANAGED)) + firmware_map_add_hotplug(start, start + size, "System RAM"); /* device_online() will take the lock when calling online_pages() */ mem_hotplug_done(); @@ -1081,10 +1082,21 @@ int __ref add_memor...

...> /* > > * Make sure value parsed from 'mem=' only restricts memory adding > > @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resource *res, > > BUG_ON(ret); > > > > /* create new memmap entry */ > > - firmware_map_add_hotplug(start, start + size, "System RAM"); > > + if (!(flags & MHP_DRIVER_MANAGED)) > > + firmware_map_add_hotplug(start, start + size, "System RAM"); > > > > /* device_online() will take the lock when calling online_pages() */ > &gt...

This is the follow up of [1]: [PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools I realized that this is not only helpful for virtio-mem, but also for dax/kmem - it's a fix for that use case (see patch #3) of persistent memory. Also, while testing, I discovered that kexec-tools will *not* add dax/kmem memory (anything not directly under the root when parsing

This series is based on [1]: [PATCH v2 00/10] virtio-mem: paravirtualized memory That will hopefull get picked up soon, rebased to -next. The following patches were reverted from -next [2]: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use As discussed in that thread, they should be reverted from -next already. In theory, if people agree, we could take the first two patches

...;>> * Make sure value parsed from 'mem=' only restricts memory adding >>> @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resource *res, >>> BUG_ON(ret); >>> >>> /* create new memmap entry */ >>> - firmware_map_add_hotplug(start, start + size, "System RAM"); >>> + if (!(flags & MHP_DRIVER_MANAGED)) >>> + firmware_map_add_hotplug(start, start + size, "System RAM"); >>> >>> /* device_online() will take the lock when calling online_pages()...

...y_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 new memmap entry */ > - firmware_map_add_hotplug(start, start + size, "System RAM"); > + if (!(flags & MHP_NO_FIRMWARE_MEMMAP)) > + firmware_map_add_hotplug(start, start + size, "System RAM"); > > /* device_online() will take the lock when calling online_pages() */ > mem_hotplug_done();

...y_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 new memmap entry */ > - firmware_map_add_hotplug(start, start + size, "System RAM"); > + if (!(flags & MHP_NO_FIRMWARE_MEMMAP)) > + firmware_map_add_hotplug(start, start + size, "System RAM"); > > /* device_online() will take the lock when calling online_pages() */ > mem_hotplug_done();

David Hildenbrand <david at redhat.com> writes: > 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/ -

David Hildenbrand <david at redhat.com> writes: > 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/ -

...ts. > Actually, this is nearly identical to mm/memory_hotplug.c:add_memory(). > It looks to me like you should: > > * pull the common core out into mm/memory_hotplug.c:__add_memory() > (or a better name) > * make add_memory() do its > register_memory_resource()/firmware_map_add_hotplug() around that > (assuming they''re definitely unwanted in the Xen case) > * make xen_add_memory() just call __add_memory() along with whatever > else it needs (which is nothing?) > > That way you can export a high-level __add_memory function from > memory_hotp...

Hi, I am sending this e-mail once again because it probably has been lost in abyss of Xen-devel/LKLM list. Here is the second version of memory hotplug support for Xen guests patch. This one cleanly applies to git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git repository, xen/memory-hotplug head. Changes: - /sys/devices/system/memory/probe interface has been removed;