[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 4/9] xen: introduce XEN_DOMCTL_devour
On Thu, 2014-12-18 at 13:57 +0000, Jan Beulich wrote: > >>> On 11.12.14 at 14:45, <vkuznets@xxxxxxxxxx> wrote: > > --- a/xen/common/domctl.c > > +++ b/xen/common/domctl.c > > @@ -1177,6 +1177,39 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) > > u_domctl) > > } > > break; > > > > + case XEN_DOMCTL_devour: > > + { > > + struct domain *recipient_dom; > > + > > + if ( !d->recipient ) > > + { > > + recipient_dom = get_domain_by_id(op->u.devour.recipient); > > + if ( recipient_dom == NULL ) > > + { > > + ret = -ESRCH; > > + break; > > + } > > + > > + if ( recipient_dom->tot_pages != 0 ) > > + { > > + put_domain(recipient_dom); > > + ret = -EINVAL; > > + break; > > + } > > + /* > > + * Make sure no allocation/remapping is ongoing and set > > is_dying > > + * flag to prevent such actions in future. > > + */ > > + spin_lock(&d->page_alloc_lock); > > + d->is_dying = DOMDYING_locked; > > + d->recipient = recipient_dom; > > Is d == recipient_dom a valid case (not leading to any issues)? I suspect not, due to the restriction that the recipient not have any domheap pages, if d didn't have any domheap pages this whole dance is a bit unnecessary. In any case it doesn't seem very useful, so it's much easier to just avoid the issue by outlawing it. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |