Re: [PATCH] x86: expose XENMEM_get_pod_target to subject domain

[George Dunlap <george.dunlap@eu.citrix.com>]

On 04/02/2014 04:02 PM, Jan Beulich wrote:
>>>> On 02.04.14 at 16:24, <george.dunlap@eu.citrix.com> wrote:
>> I understand the sentiment; but as I said, the real problem is a lack of
>> clarity about what exactly the toolstack is asking the VM to do.  This
>> is obviously a particular problem in the case of PoD, but it's still a
>> problem even for non-PoD guests; it's just that the outcomes are less
>> severe.  If we solve the general problem, we'll solve the PoD problem.
>>
>> The other thing is that the whole point of PoD is to be transparent to
>> the guest.  Xen is already careful in how it handles post-creation
>> adjustments to the PoD size -- always increasing the PoD cache, never
>> decreasing it -- specifically so that the guest doesn't need to know.
>>
>> What should really happen at some point is for PoD to just become a
>> special case of swapping.  In a sense, that's almost the same issue: you
>> could have a situation where the toolstack asks a guest to balloon down,
>> and the guest does so; but not as low as the toolstack expected, so the
>> toolstack labels the guest as "misbehaving" and tells Xen to swap out
>> pages until it reaches what the toolstack thinks is the correct value.
>> The guest won't crash, but performance will be impacted.
>>
>> The target in xenstore could be made tightly coupled: if the toolstack
>> always wrote into xenstore exactly what it reported to Xen, then it
>> would be the same.
>>
>> Alternately, since now Xen is involved with ballooning targets --
>> whether you're doing PoD or swapping -- maybe we should consider moving
>> the "target" into Xen entirely.  Then there would be no chance for
>> "drift", as Xen and the balloon driver would be working from the same
>> data.  This would be basically repurposing the get/set pod_target
>> hypercall to something specifically for ballooning.
> This all reads like something that won't happen soon, and wouldn't
> likely to be reasonably backportable. Yet we have the problem in
> shipping code, and hence alongside a proper long term solution we
> should also (and perhaps first) try to find a simple and sufficiently
> correct short term one. (But yes, the present "balloon down much
> further than needed" model might be perceived as that short term
> one, albeit personally I don't like it.)

There are three things I mentioned:

1. Make the static-max / target something rational and useable by the 
balloon driver
2. Move "target" from xenstore into the hypervisor, and make a proper 
interface for it there.
3. Re-implement PoD as a special case of hypervisor swap

#3 is unlikely to happen soon; but it's not a solution to your problem 
anyway.  It just changes the failure mode from "guest crashes" to "guest 
experiences performance degradation".

Either #1 or #2  should be straightforward to implement and backport; #1 
would probably be the easiest to backport.  (Yet another reason to 
prefer it over #2.)

  -George