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

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 08/16/2012 07:28 AM, Ian Campbell wrote:
> 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.

It might be, although it's never required. After checking where this would
be useful, it looks like the caller could just call a get-permissions on
the node before set-permissions, and just avoid modification to the owner.
Since non-privileged xenstore clients cannot modify the owner of a xenstore
key, and cannot change permissions on keys they do not own, this change
would just end up saving one call to xenstore. Privileged domains already
take advantage of their override capabilities and usually do not add domain
0 to the node permissions list, so it's not useful there.

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

The /vm/$UUID path isn't currently useful for this, since it doesn't maintain
domain IDs (just names) and doesn't contain writable sub-keys for a domain
to use. I also don't think such a sub-key should be added; it makes more
sense to keep all of a domain's modifiable keys under its home path.

Perhaps this could be changed to another identifier-to-domid mapping, like
the proposed addition of a location to map name to domid? 

The toolstack would maintain something like:
  /local/by-name/$name == domid
  /local/by-uuid/$uuid == domid
  /local/domain/$domid/name - same as existing
  /local/domain/$domid/uuid - ? maybe unneeded, as it's available from Xen.

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

Both ends of any xen-based communication need to handle each of these events
in order to re-establish grants/events or v4v rings/ports. The domid does
need to be treated as a short-term identifier of a domain in a protocol that
expects to continue to work across such events.

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