Re: [Xen-devel] [PATCH v3 1/3] libxl: xl mem-max et consortes must update static-max in xenstore too [and 1 more messages]

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-04-11 at 13:24 +0100, Daniel Kiper wrote:
> On Wed, Apr 10, 2013 at 04:56:09PM +0100, Ian Jackson wrote:
> > Daniel Kiper writes ("Re: [Xen-devel] [PATCH v3 1/3] libxl: xl mem-max et 
> > consortes must update static-max in xenstore too"):
> > > On Tue, Apr 09, 2013 at 03:18:10PM +0100, Ian Jackson wrote:
> > > > Daniel Kiper writes ("Re: [Xen-devel] [PATCH v3 1/3] libxl: xl mem-max 
> > > > et consortes must update static-max in xenstore too"):
> > > > > That is why I think that static-max should be unconditionally
> > > > > changed or the guest should write something in xenstore to inform
> > > > > that it supports memory hotplug and relevant check should be waived.
> > > >
> > > > Right.  I don't see what any of that has to do with "xl mem-max"
> > > > though.  The purpose of xl mem-max is to update the guest's
> > > > enforcement limit.
> > >
> > > ...and static-max if you would like to use memory hotplug in real.
> > > If not, then xl mem-set does not allow you to allocate more memory
> > > to a guest than static-max.
> >
> > You seem to be losing sight of the purpose of the static-max key in
> > xenstore.  It is for the benefit of the toolstack - and, indirectly,
> > the user - so that we know the maximum amount of memory we can ask the
> > guest to us.
> 
> OK, I understand that. However, static-max equal to maxmem makes sens
> for a guest without memory hotplug. If you have memory hotplug and you
> could not change static-max then this is an obstacle to use memory
> hotplug in real. You could not raise target above static-max using
> xl mem-set and you could not change target from guest because
> of "xen maximum" too.
> 
> Now we have two options:
>   - we could allow user to change static-max for a given guest by calling
>     xl mem-max (my current solution); this way we change a bit meaning
>     of static-max from "maximum amount of memory allowed for the guest
>     (usualy all guest OS structures were prepared for this amount of memory
>     but they do not need to be filled at boot time)" to "maximum amount
>     of memory allowed for the guest at a given moment",
>   - we could leave static-max as is and use "xen maximum" as "maximum
>     amount of memory allowed for the guest at a given moment"; However,
>     in this case comparison with static-max in libxl_set_memory_target()
>     should be changed to comparison with "xen maximum".

How does this stuff work for physical memory hotplug? Understanding that
might help us decide what admins expect (and is also directly relevant
to HVM memory hotplug).

In the e820 of a physical system memory which is actually present at
boot is obviously represented as E820_MEMORY, but how are the holes in
the memory map where DIMMs could subsequently be physically inserted
represented? Are they just "reserved" or is there a special "unpopulated
memory" type?

And on the PV kernel side how does this appear to the guest? If you boot
a "massively ballooned" guest (e.g. 1G out of max 1TB) does it
automatically switch to making the bulk of the difference a hotpluggable
region rather than a balloon region? What does "pre-ballooned" even mean
to a guest which supports memory hotplug?

Do the kernels support memory unplug?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel