[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] x86: expose XENMEM_get_pod_target to subject domain
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |