[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC/PATCH] XENMEM_claim_pages (subop of an existing) hypercall
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |