search for: mem_hotplug_don

...gt; + */ > +#define MHP_DRIVER_MANAGED 1 > + > /* > * Zone resizing functions > * > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index ebdf6541d074..cfa0721280aa 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -98,11 +98,11 @@ void mem_hotplug_done(void) > u64 max_mem_size = U64_MAX; > > /* add this memory to iomem resource */ > -static struct resource *register_memory_resource(u64 start, u64 size) > +static struct resource *register_memory_resource(u64 start, u64 size, > + const char *resource_name) > { >...

...gt; + */ > +#define MHP_DRIVER_MANAGED 1 > + > /* > * Zone resizing functions > * > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index ebdf6541d074..cfa0721280aa 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -98,11 +98,11 @@ void mem_hotplug_done(void) > u64 max_mem_size = U64_MAX; > > /* add this memory to iomem resource */ > -static struct resource *register_memory_resource(u64 start, u64 size) > +static struct resource *register_memory_resource(u64 start, u64 size, > + const char *resource_name) > { >...

...ystem RAM (driver managed)" in e.g., /proc/iomem + */ +#define MHP_DRIVER_MANAGED 1 + /* * Zone resizing functions * diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index ebdf6541d074..cfa0721280aa 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -98,11 +98,11 @@ void mem_hotplug_done(void) u64 max_mem_size = U64_MAX; /* add this memory to iomem resource */ -static struct resource *register_memory_resource(u64 start, u64 size) +static struct resource *register_memory_resource(u64 start, u64 size, + const char *resource_name) { struct resource *res; unsigned long...

...> > + > > /* > > * Zone resizing functions > > * > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > > index ebdf6541d074..cfa0721280aa 100644 > > --- a/mm/memory_hotplug.c > > +++ b/mm/memory_hotplug.c > > @@ -98,11 +98,11 @@ void mem_hotplug_done(void) > > u64 max_mem_size = U64_MAX; > > > > /* add this memory to iomem resource */ > > -static struct resource *register_memory_resource(u64 start, u64 size) > > +static struct resource *register_memory_resource(u64 start, u64 size, > > +...

...evm_memremap_pages_release(void *data) align_size >> PAGE_SHIFT, NULL); } else { arch_remove_memory(nid, align_start, align_size, - pgmap->altmap_valid ? &pgmap->altmap : NULL); + pgmap_altmap(pgmap)); kasan_remove_zero_shadow(__va(align_start), align_size); } mem_hotplug_done(); @@ -129,8 +123,8 @@ static void devm_memremap_pages_release(void *data) * 1/ At a minimum the res, ref and type and ops members of @pgmap must be * initialized by the caller before passing it to this function * - * 2/ The altmap field may optionally be initialized, in which case altmap...

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

.../* >>> * Zone resizing functions >>> * >>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >>> index ebdf6541d074..cfa0721280aa 100644 >>> --- a/mm/memory_hotplug.c >>> +++ b/mm/memory_hotplug.c >>> @@ -98,11 +98,11 @@ void mem_hotplug_done(void) >>> u64 max_mem_size = U64_MAX; >>> >>> /* add this memory to iomem resource */ >>> -static struct resource *register_memory_resource(u64 start, u64 size) >>> +static struct resource *register_memory_resource(u64 start, u64 size, >>> +...

.../* 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

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

...*/ > - 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();

...*/ > - 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();

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of Linux 5.2-rc5 and has some minor conflicts with the hmm tree that are easy to resolve. Diffstat summary: 32 files changed, 361 insertions(+), 1012 deletions(-) Git

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Hi Dan, Jérôme and Jason, below is a series that cleans up the dev_pagemap interface so that it is more easily usable, which removes the need to wrap it in hmm and thus allowing to kill a lot of code Note: this series is on top of the rdma/hmm branch + the dev_pagemap releas fix series from Dan that went into 5.2-rc5. Git tree: git://git.infradead.org/users/hch/misc.git

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where