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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Apr 1, 2014 at 5:55 PM, George Dunlap
<George.Dunlap@xxxxxxxxxxxxx> wrote:
> On Wed, Feb 26, 2014 at 10:28 AM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 
> wrote:
>> On Wed, 2014-02-26 at 09:46 +0000, Jan Beulich wrote:
>>> >>> On 26.02.14 at 10:25, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>>> > On Tue, 2014-02-25 at 08:03 +0000, Jan Beulich wrote:
>>> >> Anyway, I also consider it odd to complain about this now when
>>> >> the referenced discussion has happened weeks ago, with no
>>> >> useful result.
>>> >
>>> > IIRC George was on vacation and/or travelling for a conference back then
>>> > (or maybe he was just back in town and buried in email, with the same
>>> > affect)
>>> >
>>> > Anyway, since George knows PoD better than any of us I think it is worth
>>> > revisiting things with his input.
>>> >
>>> > I would certainly prefer a solution which exposed some more semantically
>>> > meaningful information (from the guest's PoV) which lets it do the right
>>> > thing rather than just exposing the PoD internal accounting directly,
>>> > since that seems like rather an implementation detail to me. e.g. what
>>> > if we decide to make the PoD cache shared between a bunch of related
>>> > guests (totally hypothetical) or back it with the normal page sharing or
>>> > paging mechanisms? We don't want those sorts of changes to create a
>>> > visible guest ABI difference.
>>>
>>> So what's the counter proposal then?
>>
>> My expectation was that was why George is asking questions... Since he
>> knows PoD I'm hoping he will have some ideas.
>
> Sorry, this thread managed to fall out of my normal mechanism to mark
> a thread as important to come back to.
>
> 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.

 -George

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