Re: [Xen-devel] Xen ballooning interface

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Mon, Aug 13, 2018 at 03:06:10PM +0200, Juergen Gross wrote:
> Today's interface of Xen for memory ballooning is quite a mess. There
> are some shortcomings which should be addressed somehow. After a
> discussion on IRC there was consensus we should try to design a new
> interface addressing the current and probably future needs.

Thanks for doing this! Memory accounting is quite messy at the moment
:(.

[...]
> Open questions
> --------------
> Should we add memory size information to the memory/vnode<n> nodes?
> 
> Should the guest add information about its current balloon sizes to the
> memory/vnode<n> nodes (i.e. after ballooning, or every x seconds while
> ballooning)?
> 
> Should we specify whether the guest is free to balloon another vnode
> than specified?

What if the guest simply doesn't support NUMA and doesn't know
anything about nodes?

> Should memory hotplug (at least for PV domains) use the vnode specific
> Xenstore paths, too, if supported by the guest?

Is extra memory hotplug going to set:

memory/vnode<n>/target-balloon-size = -1000

In order to tell the guest it can hotplug past the boot time amount of
memory?

> Any further thoughts on this?

Isn't this just moving the memory accounting problem to another piece
of software?

Currently as you say there's a difference between the xenstore target
and the guest memory map, because some memory is used by the firmware.
In order to solve this the toolstack won't provide an absolute memory
target but instead a relative one to the guest that contains the
balloon size.

But the toolstack interface (xl) still uses mem-set which is an
absolute value. How is the toolstack going to accurately calculate the
balloon size without knowing the extra memory used by the firmware?

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel