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

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

On 08/16/2012 10:36 AM, Ian Campbell wrote:
> On Thu, 2012-08-16 at 15:33 +0100, Daniel De Graaf wrote:
> 
>>>> 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
> 
> This second one is a bit like the existing /vm/$uuid/domid.

That key isn't being populated by xl on my system, so I didn't know it existed.

> 
> I think I would go with:
> 
>   /local/by-name/$name == /local/domain/$domid
>   /local/by-uuid/$uuid == /local/domain/$domid
> 
> though, So that you can just read it and use it without interpreting it.

In that case, you would need to parse the domid out of the string in order
to use it in hypercalls (grant, event, v4v). The frontend/backend paths use
a distinct frontend-id/backend-id key for the domain ID, but we are trying
to avoid this since populating this key would mean the domain populating it
needs to know its own domain ID.

>>   /local/domain/$domid/name - same as existing
>>   /local/domain/$domid/uuid - ? maybe unneeded, as it's available from Xen.
> 
> Is it available for other domains via xen, or just yourself?
> 

Yourself and anyone who can call getdomaininfo (which is usually just dom0).
This is actually the same as the xenstore permissions on keys such as
/local/domain/$id/name. Changing these may need consideration, because on
public hosting servers, you might not want to allow domains to be enumerated
by name.

-- 
Daniel De Graaf
National Security Agency