Re: [Xen-devel] [RFC/PATCH v2] XENMEM_claim_pages (subop of existing) hypercall

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-11-14 at 23:55 +0000, Dan Magenheimer wrote:
> 
> Note 1: Tim: I'm thinking this may resolve your concern that
> the claim mechanism must be more complicated to handle
> restricted memory allocations and order>0 allocations.
> The proposed claim mechanism only guarantees a quantity of
> order==0 pages; if restricted allocations are required, these
> are done first by the toolstack, and followed by the claim.
> Order>0 allocations still work if memory is not fragmented,
> but the claim mechanism doesn't guarantee anything but
> a quantity of order==0 pages.

How does this interact with the feature which lets you create PV guests
using only superpages? I believe is something Oracle added and still
maintains (Dave added to the CC).

Also doesn't this fail to make any sort of guarantee if you are building
a 32 bit PV guest, since they require memory under a certain host
address limit (160GB IIRC)?

Basically neither of those cases benefit from this hypercall at all? I
don't know what the usecase for the superpage PV guests is (but I
suppose it is important to Oracle, at least). The 32 bit PV guest use
case is still a pretty significant one which I think ought to be
handled, otherwise any system built on top of this functionality will
only work reliably in a subset of cases.

Ian.


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