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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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.

 -George

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