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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 04/02/2014 04:02 PM, Jan Beulich wrote:
> > > > On 02.04.14 at 16:24, <george.dunlap@xxxxxxxxxxxxx> 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

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