Re: [Xen-devel] [PATCH] x86: expose XENMEM_get_pod_target to subject domain

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 01.04.14 at 19:05, <George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Tue, Apr 1, 2014 at 5:55 PM, George Dunlap
> <George.Dunlap@xxxxxxxxxxxxx> wrote:
>> So the basic issue, regardless of PoD, is that the guest is told to
>> balloon down to X, by handing back (T - X) pages to Xen.  But it
>> doesn't actually know what T is, for a number of reasons; mainly due
>> to having holes in lowmem for vga ram and things like that.  When PoD
>> is enabled, this may cause a guest to end up killed as a result of
>> accidentally not ballooning down enough; but even on non-PoD systems,
>> this would lead to a small mismatch between the toolstack's idea of
>> how much a VM was using (or should be using) and how much the guest is
>> using.
>>
>> It looks like libxl anyway already writes "static-max" into xenstore,
>> right next to the balloon target.  Is there any reason we can't use
>> the toolstack-written static-max to calculate how big a balloon we
>> need to inflate?
>>
>> If it's not accruate or consistent at the moment, we should be able to
>> make it consistent going forward.
> 
> One potential problem I see at the moment is that during domain
> creation, "static-max" is set to maxmem, but "target" is set to
> "memory-video_memkb"; but the actual number of pages will be memory -
> VGA_HOLE, which probably won't match either one.  Then in
> libxl_set_memory_target(), it's just straight-up set to "target".
> This may lead to a rather unexpected situation where after starting
> with memory=2048, setting the target to 1024, and then setting it back
> to 2048, the guest has a different amount of memory than it started
> with.  (Or perhaps the balloon driver will be running up against the
> memory ceiling.)
> 
> It would be ideal if the balloon driver could just release (static-max
> - target) memory and be assured that everything would be OK.

Another problem is that "target" (or in fact anything in xenstore) isn't
tightly coupled with what the hypervisor knows for the domain. Yet
the main goal (preventing to be killed due to ballooning down to much)
depends on only the hypervisor's knowledge, and hence I think that
only the hypervisor should be consulted to find out.

Jan


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