[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC XEN PATCH 04/16] xen/x86: add XENMEM_populate_pmemmap to map host pmem pages to guest
>>> On 10.10.16 at 02:32, <haozhong.zhang@xxxxxxxxx> wrote: > +static int pmem_assign_pages(struct domain *d, > + struct page_info *pg, unsigned int order) What is the order parameter good for here, when the only caller passes zero? > +{ > + int rc = 0; > + unsigned long i; > + > + spin_lock(&d->pmem_lock); > + > + if ( unlikely(d->is_dying) ) > + { > + rc = -EINVAL; > + goto out; > + } > + > + for ( i = 0; i < (1 << order); i++ ) > + { > + ASSERT(page_get_owner(&pg[i]) == NULL); > + ASSERT((pg[i].count_info & ~(PGC_allocated | 1)) == 0); Why is PGC_allocated | 1 allowed to be set here? > @@ -1329,6 +1330,36 @@ long do_memory_op(unsigned long cmd, > XEN_GUEST_HANDLE_PARAM(void) arg) > } > #endif > > + case XENMEM_populate_pmemmap: > + { > + struct xen_pmemmap pmemmap; > + struct xen_pmemmap_args args; > + > + if ( copy_from_guest(&pmemmap, arg, 1) ) > + return -EFAULT; > + > + d = rcu_lock_domain_by_any_id(pmemmap.domid); > + if ( !d ) > + return -EINVAL; I don't think you mean DOMID_SELF to be used here. And you're lacking an XSM check in any event. > + args.domain = d; > + args.mfn = pmemmap.mfn; > + args.gpfn = pmemmap.gpfn; > + args.nr_mfns = pmemmap.nr_mfns; > + args.nr_done = start_extent; > + args.preempted = 0; > + > + rc = pmem_populate(&args); Please make sure you don't break the ARM build here. > --- a/xen/include/public/memory.h > +++ b/xen/include/public/memory.h > @@ -646,7 +646,19 @@ struct xen_vnuma_topology_info { > typedef struct xen_vnuma_topology_info xen_vnuma_topology_info_t; > DEFINE_XEN_GUEST_HANDLE(xen_vnuma_topology_info_t); > > -/* Next available subop number is 28 */ > +#define XENMEM_populate_pmemmap 28 > + > +struct xen_pmemmap { > + /* IN */ > + domid_t domid; > + xen_pfn_t mfn; > + xen_pfn_t gpfn; > + unsigned int nr_mfns; > +}; You'll clearly need to add compat mode argument translation code. Also, may I suggest xen_pmem_map (and similarly elsewhere), to avoid mistaking this for "physical memory map" or some such (i.e. keeping pmem and map sufficiently separated)? Also I think patch 5 needs to be merged here, or be moved ahead of this one, to avoid the intermediate broken state (leaking all the pmem pages assigned to a domain). Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |