similar to: messages logs flooded with xen_balloon: reserve_additional_memory: add_memory() failed

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

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

The pvops dom0 kernel does not expose the balloon driver via /proc/xen, so use the sysfs interface. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> diff -r 1944c39d0007 tools/python/xen/xend/osdep.py --- a/tools/python/xen/xend/osdep.py Fri Nov 14 09:57:33 2008 -0800 +++ b/tools/python/xen/xend/osdep.py Fri Nov 14 12:26:51 2008 -0800 @@ -38,7 +38,10 @@

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

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;

Hi Konrad, Today i tried linuses tree of today (last commit is 4c4d285ad5665bfbd983b95fde8d7a477d24a361). It boots dom0 fine, but it fails to start any domU with: "Error: Failed to query current memory allocation of dom0." With my previous 3.1.5 kernel everything is fine, nothing else changed in config in between. dmesg and xm dmesg attached -- Sander Dom0 shows: total

We soon want to pass flags, e.g., to mark added System RAM resources. mergeable. Prepare for that. This patch is based on a similar patch by Oscar Salvador: https://lkml.kernel.org/r/20190625075227.15193-3-osalvador at suse.de Acked-by: Wei Liu <wei.liu at kernel.org> Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Dan Williams

We soon want to pass flags, e.g., to mark added System RAM resources. mergeable. Prepare for that. This patch is based on a similar patch by Oscar Salvador: https://lkml.kernel.org/r/20190625075227.15193-3-osalvador at suse.de Acked-by: Wei Liu <wei.liu at kernel.org> Reviewed-by: Juergen Gross <jgross at suse.com> # Xen related part Cc: Andrew Morton <akpm at

On 4/30/20 3:29 AM, David Hildenbrand wrote: > Currently, when adding memory, we create entries in /sys/firmware/memmap/ > as "System RAM". This does not reflect the reality and will lead to > kexec-tools to add that 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.

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

Currently, when adding memory, we create entries in /sys/firmware/memmap/ as "System RAM". This does not reflect the reality and will lead to kexec-tools to add that 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

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 are these random "flags", and how do we know what should be

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 are these random "flags", and how do we know what should be

Hi David, I love your patch! Yet something to improve: [auto build test ERROR on next-20200909] [cannot apply to mmotm/master hnaz-linux-mm/master xen-tip/linux-next powerpc/next linus/master v5.9-rc4 v5.9-rc3 v5.9-rc2 v5.9-rc4] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in

On 21.08.20 12:34, David Hildenbrand wrote: > Let's reuse the new mechanism to merge system ram resources below the > root. We are the only one hotplugging system ram (e.g., DIMMs don't apply), > so this is safe to be used. > > Cc: Andrew Morton <akpm at linux-foundation.org> > Cc: Michal Hocko <mhocko at suse.com> > Cc: Boris Ostrovsky <boris.ostrovsky

Let's reuse the new mechanism to merge system ram resources below the root. We are the only one hotplugging system ram (e.g., DIMMs don't apply), so this is safe to be used. Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Boris Ostrovsky <boris.ostrovsky at oracle.com> Cc: Juergen Gross <jgross at suse.com> Cc: Stefano

Let's try to merge system ram resources we add, to minimize the number of resources in /proc/iomem. We don't care about the boundaries of individual chunks we added. Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Boris Ostrovsky <boris.ostrovsky at oracle.com> Cc: Juergen Gross <jgross at suse.com> Cc: Stefano Stabellini