Guest knowledge of own domid [was: docs: initial documentation for xenstore paths]

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

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, 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.

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.

-- 
Daniel De Graaf
National Security Agency