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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.)

Jan


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