search for: __add_memory

...-memory.c index 5d545b78111f9..54a888ea7f751 100644 --- a/arch/powerpc/platforms/pseries/hotplug-memory.c +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c @@ -606,7 +606,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb) block_sz = memory_block_size_bytes(); /* Add the memory */ - rc = __add_memory(lmb->nid, lmb->base_addr, block_sz); + rc = __add_memory(lmb->nid, lmb->base_addr, block_sz, 0); if (rc) { invalidate_lmb_associativity_index(lmb); return rc; diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c index e294f44a78504..d91b3584d4b2b 100644 -...

...0ea976d1cac47..e1c9fa0d730f5 100644 --- a/arch/powerpc/platforms/pseries/hotplug-memory.c +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c @@ -615,7 +615,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb) nid = memory_add_physaddr_to_nid(lmb->base_addr); /* Add the memory */ - rc = __add_memory(nid, lmb->base_addr, block_sz); + rc = __add_memory(nid, lmb->base_addr, block_sz, MHP_NONE); if (rc) { invalidate_lmb_associativity_index(lmb); return rc; diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c index e294f44a78504..2067c3bc55763 100644 --- a/driv...

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

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

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

...file included from include/linux/crypto.h:20: In file included from include/linux/slab.h:15: In file included from include/linux/gfp.h:6: In file included from include/linux/mmzone.h:853: >> include/linux/memory_hotplug.h:354:55: error: unknown type name 'mhp_t' extern int __add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags); ^ include/linux/memory_hotplug.h:355:53: error: unknown type name 'mhp_t' extern int add_memory(int nid, u64 start, u64 size, mhp_t mhp_flags); ^ include/linux/memory_hotplug.h:357:11: error: unknown type name 'mhp_t'...

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

...about a real S3 suspend. Do we > care about that here? Yes, because as I know S3 state is supported by Xen guests. > 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 >...

...tem RAM"); > > /* device_online() will take the lock when calling online_pages() */ > mem_hotplug_done(); > @@ -1081,10 +1082,21 @@ int __ref add_memory_resource(int nid, struct resource *res, > /* requires device_hotplug_lock, see add_memory_resource() */ > int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags) > { > + const char *resource_name = "System RAM"; > struct resource *res; > int ret; > > - res = register_memory_resource(start, size); > + /* > + * Indicate that memory managed by a driver is special. It...

...tem RAM"); > > /* device_online() will take the lock when calling online_pages() */ > mem_hotplug_done(); > @@ -1081,10 +1082,21 @@ int __ref add_memory_resource(int nid, struct resource *res, > /* requires device_hotplug_lock, see add_memory_resource() */ > int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags) > { > + const char *resource_name = "System RAM"; > struct resource *res; > int ret; > > - res = register_memory_resource(start, size); > + /* > + * Indicate that memory managed by a driver is special. It...

...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_memory_resource(int nid, struct resource *res, /* requires device_hotplug_lock, see add_memory_resource() */ int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags) { + const char *resource_name = "System RAM"; struct resource *res; int ret; - res = register_memory_resource(start, size); + /* + * Indicate that memory managed by a driver is special. It's always + * detected and added via...

.../* device_online() will take the lock when calling online_pages() */ > > mem_hotplug_done(); > > @@ -1081,10 +1082,21 @@ int __ref add_memory_resource(int nid, struct resource *res, > > /* requires device_hotplug_lock, see add_memory_resource() */ > > int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags) > > { > > + const char *resource_name = "System RAM"; > > struct resource *res; > > int ret; > > > > - res = register_memory_resource(start, size); > > + /* > > +...

...ice_online() will take the lock when calling online_pages() */ >>> mem_hotplug_done(); >>> @@ -1081,10 +1082,21 @@ int __ref add_memory_resource(int nid, struct resource *res, >>> /* requires device_hotplug_lock, see add_memory_resource() */ >>> int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags) >>> { >>> + const char *resource_name = "System RAM"; >>> struct resource *res; >>> int ret; >>> >>> - res = register_memory_resource(start, size); >>> +...

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;