Re: [Xen-devel] Guest knowledge of own domid [was: docs: initial documentation for xenstore paths]

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2012-08-09 at 22:26 +0100, Jean Guyader wrote:
> On 9 August 2012 22:02, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
> > On 07/30/2012 10:03 AM, Ian Campbell wrote:
> >> This is based upon my inspection of a system with a single PV domain 
> >> running
> >> and is therefore very incomplete.
> >>
> >> There are several things I'm not sure of here, mostly marked with XXX in 
> >> the
> >> text.
> >>
> >> In particular:
> >>
> >>  - We seem to expose various things to the guest which really it has no 
> >> need to
> >>    know (at least not via xenstore). e.g. its own domid, its device model 
> >> pid,
> >>    the size of the video ram, store port and gref.
> >
> > If the domid key is unneeded/removed, is there a recommended method for
> > a guest to query its own domid? I don't see a hypercall that returns it
> > directly, although there is one to return the guest's UUID - which seems
> > much less useful for a guest to know about itself.
> >
> > While hypercalls are fairly consistent about accepting DOMID_SELF, a
> > domain does occasionally need to know its own ID: xenstore permission
> > changes do not accept DOMID_SELF, 

I wonder if that would be a worthwhile protocol extension.

> and if two domains are attempting to
> > set up communication such as V4V or vchan, they need to be able to tell
> > their peer what domain ID to use.

That's trickier.

I suppose they could rendezvous via /vm/$UUID? Although there has been
talk of removing that path in the future.

> >
> 
> That is one way for doing it another way would be to use a name
> resolution system
> a bit like a DNS. A system like that would need to live where the VM
> are created and destroyed
> (probably dom0 or a domain builder VM).
> The server could be using vchan, v4v or even a shared XenStore node,
> but I think we
> need something like that.
> 
> In the long run it's much better to rely on a name instead of a domid
> because domids can
> change throughout the VM life cycle (reboot, hibernate, save/restore,
> migration, ...).

Right, this is the main reason to avoid building a reliance on domid
into a protocol.

> 
> Jean
> 
> > It is possible for a domain to query its own domain ID indirectly, so it
> > would be difficult to argue that a domain should not be able to obtain
> > its own ID. One method for a domain to query its own ID is to create an
> > unbound event channel with remote_domid = DOMID_SELF, and then execute
> > evtchn_status on the event channel in order to see the resolved domain
> > id. Querying Xenstore permissions on a newly-created key will show the
> > local domain as the first entry. Less reliably, the backend paths for
> > all xenbus devices contain the local and remote domain IDs.
> >



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