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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-11-15 at 12:12 +0000, Keir Fraser wrote:
> On 15/11/2012 11:23, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
> >>>> On 15.11.12 at 11:47, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> >> On Tue, 2012-11-13 at 22:23 +0000, Dan Magenheimer wrote:
> >>> This is a first cut of the hypervisor patch of the proposed
> >>> XENMEM_claim_pages hypercall/subop.
> >> 
> >> Who is expected to be able to call this? I think a XENMEM subop implies
> >> that the guest itself, plus perhaps any controlling stubdom (e.g. qemu)
> >> could call
> >> it, which I don't think is desirable.
> >> 
> >> Should this be limited to the toolstack only and therefore be a subop of
> >> domctl or some other hypercall?
> > 
> > Oh, yes, absolutely. Whether making it a domctl (where it doesn't
> > belong except for that aspect) I'm not that sure, though.
> 
> It can stay as a XENMEM_ subop, but it should be in the
> __XEN__||__XEN_TOOLS__ section of public/memory.h indicating that it is
> toolstack only (regardless of whether we actually enforce that), and that
> the interface is not 100% guaranteed to remain compatible (since it is not
> part of the general guest ABI).

We need to be mindful of what a guest who calls this anyway can achieve.
Is it limited by d->max_pages, IOW similar in principal to
XENMEM_populate_physmap? If so then it is probably acceptable.

Ian.


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