search for: add_memory

...memory to the fixed-up initial memmap for a > kexec kernel (loaded via kexec_load()). The memory will be considered > initial System RAM by the kexec 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:...

.../platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c index 13b369d2cc454..6828108486f83 100644 --- a/arch/powerpc/platforms/powernv/memtrace.c +++ b/arch/powerpc/platforms/powernv/memtrace.c @@ -224,7 +224,7 @@ static int memtrace_online(void) ent->mem = 0; } - if (add_memory(ent->nid, ent->start, ent->size)) { + if (add_memory(ent->nid, ent->start, ent->size, MHP_NONE)) { pr_err("Failed to add trace memory to node %d\n", ent->nid); ret += 1; diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platform...

.../platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c index 13b369d2cc454..a7475d18c671c 100644 --- a/arch/powerpc/platforms/powernv/memtrace.c +++ b/arch/powerpc/platforms/powernv/memtrace.c @@ -224,7 +224,7 @@ static int memtrace_online(void) ent->mem = 0; } - if (add_memory(ent->nid, ent->start, ent->size)) { + if (add_memory(ent->nid, ent->start, ent->size, 0)) { pr_err("Failed to add trace memory to node %d\n", ent->nid); ret += 1; diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseri...

Hi All Back in August there was a report of these errors popping up in dmesg, and as far as I can tell it's still unresolved even in the latest kernel. System RAM resource [mem 0xc8000000-0xcfffffff] cannot be added xen_balloon: reserve_additional_memory: add_memory() failed: -17 On this example its running 3.10.20-11.el6.centos.alt.x86_64 To replicate this just disable Dom0 memory ballooning in /etc/xen/xend-config.sxp and these errors will over time completely fill up dmesg. This is because the amount of memory within these two sys files is different: /s...

...hat 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 passing flags to add_memory() and friends mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP arch/powerpc/platforms/powernv/memtrace.c | 2 +- arch/powerpc/platforms/pseries/hotplug-memory.c | 2 +- drivers/acpi/acpi_memhotplug.c...

My /var/log/messages log is being flooded with kernel messages showing the following messages Aug 1 11:22:52 host43 kernel: System RAM resource 48000000 - 4fffffff cannot be added Aug 1 11:22:52 host43 kernel: xen_balloon: reserve_additional_memory: add_memory() failed: ?17 Doing a search I found a thread from xen-devel that talks a bit about it. I?m not sure if this is related to the same issue or if that issue was ever fixed. When I cat current_kb and target_kb the values don?t match, they are just barely off. I have not tried setting them to match...

...n(-) diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c index e159184e0ba0..929823a79816 100644 --- a/drivers/dax/kmem.c +++ b/drivers/dax/kmem.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

Hi, > biting this behavior. The specific > error I''m seeing is > > xen_balloon: reserve_additional_memory: add_memory() failed: -17 > System RAM resource 88000000 - 8fffffff cannot be added > > This is a lab system that I''m actively working on so I can give > whatever info you need or run whatever. Below is the xl info and xl > dmesg output [...] Thanks. I am going to work on this about...

...d add them to Linux - just like on a reboot where we still have memory plugged. [1] https://lore.kernel.org/r/20200311171422.10484-1-david at redhat.com/ [2] https://lore.kernel.org/r/20200326180730.4754-1-james.morse at arm.com David Hildenbrand (3): mm/memory_hotplug: Prepare passing flags to add_memory() and friends mm/memory_hotplug: Introduce MHP_DRIVER_MANAGED virtio-mem: Add memory with MHP_DRIVER_MANAGED arch/powerpc/platforms/powernv/memtrace.c | 2 +- .../platforms/pseries/hotplug-memory.c | 2 +- drivers/acpi/acpi_memhotplug.c | 2 +- drivers/base/memory...

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

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

On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: > We soon want to pass flags, e.g., to mark added System RAM resources. > mergeable. Prepare for that. What are these random "flags", and how do we know what should be passed to them? Why not make this an enumerated type so that we know it all works properly, like the GPF_* flags are? Passing around a random

On 09.09.20 09:17, Greg Kroah-Hartman wrote: > On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: >> We soon want to pass flags, e.g., to mark added System RAM resources. >> mergeable. Prepare for that. > > What are these random "flags", and how do we know what should be passed > to them? > > Why not make this an enumerated type so that we

On 09.09.20 13:24, Michael Ellerman wrote: > David Hildenbrand <david at redhat.com> writes: >> On 09.09.20 09:17, Greg Kroah-Hartman wrote: >>> On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: >>>> We soon want to pass flags, e.g., to mark added System RAM resources. >>>> mergeable. Prepare for that. >>> >>> What

On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: > We soon want to pass flags, e.g., to mark added System RAM resources. > mergeable. Prepare for that. What are these random "flags", and how do we know what should be passed to them? Why not make this an enumerated type so that we know it all works properly, like the GPF_* flags are? Passing around a random

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

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

...le 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...

Hi, I have encountered an apparently benign error on two systems where the dom0 kernel log is flooded with messages like: [52482.163855] System RAM resource [mem 0x1b8000000-0x1bfffffff] cannot be added [52482.163860] xen_balloon: reserve_additional_memory: add_memory() failed: -17 The first line is from drivers/xen/xen-balloon.c, the second from mm/memory_hotplug.c The trigger for the messages seems to be the first occasion that a Xen guest is shutdown. I have noted this in a vanilla 3.6.7 and kernel 3.5.0-18 built from Ubuntu sources. Xen version is 4....