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

[Jean Guyader <jean.guyader@xxxxxxxxx>]

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

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