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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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