[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 5/6] tools/libxl: Allow dom0 to be destroyed



On 03/13/2014 01:17 PM, Ian Jackson wrote:
Daniel De Graaf writes ("Re: [PATCH 5/6] tools/libxl: Allow dom0 to be 
destroyed"):
A domain can't destroy itself anyway (the hypervisor prevents this), so
if there was a simple way for xl to check if the domain ID was its own
ID, this would work.  I am not aware of a good, simple way to make this
check, so leaving it at preventing dom0's destruction will at least not
regress in usability.

What does XEN_DOMCTL_getdomaininfo do when passed DOMID_SELF ?

Ian.



It returns -ESRCH. The domain passed in is a lower bound for the domain
ID, and is not resolved using the usual domid resolution function.

One possible method for a domain to determine its own domain ID is to
create an unbound inter-domain event channel to DOMID_SELF and then use
EVTCHNOP_status to read the now-resolved endpoint.  This seems rather
cumbersome to implement: the toolstack only exposes this as far as
xc_evtchn_status, so libxl would need modification in addition to xl.

Reading the "domid" key from xenstore is another alternative, but it
also requires adding a function to libxl and needs some fall-back if
the key does not exist.

The constant LIBXL_TOOLSTACK_DOMID is defined inlibxl_internal.h, but
I'm not sure it is best to expose this: I would prefer to eventually
remove the uses of this #define to support toolstack domains with a
dynamic domain ID.  For now, that #define is not used in any location
that impedes functionality if it is incorrect (it only makes errors
a bit less user-friendly).

--
Daniel De Graaf
National Security Agency

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.