Re: [Xen-devel] [PATCH] xenbus: Add support for xenbus backend in stub domain

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

On 01/12/2012 10:40 AM, Jan Beulich wrote:
>>>> On 12.01.12 at 16:28, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
>> On 01/12/2012 03:59 AM, Jan Beulich wrote:
>>>>>> On 11.01.12 at 18:22, Daniel De Graaf <dgdegra@xxxxxxxxxxxxx> wrote:
>>>> This adds two ioctls to the /dev/xen/xenbus_backend device allowing the
>>>> xenbus backend to be started after the kernel has booted. This is
>>>> intended to allow dom0 to start another domain to run xenstore.
>>>>
>>>> IOCTL_XENBUS_BACKEND_REMOTE_SETUP requires that the xenstore domain be
>>>> started; the domain ID is passed as the ioctl argument. This sets up a
>>>> listening event channel and grant reference to xenbus, but does not
>>>> start using this interface. It returns the local event channel port.
>>>
>>> Any chance to get at least the setup part matched with the
>>> legacy Linux implementation (defining IOCTL_XENBUS_ALLOC)?
>>>
>>> Jan
>>
>> From what I can tell, the legacy ioctl cannot restore watches because the
>> return value must be used to set up xenstore communication before they can
>> be used.
> 
> Then I must have missed something. But this was the only kernel side
> patch, wasn't it?
> 
> Is the intended behavior then to have a Dom0-based xenstored
> starting first, then do a brain transfer to that running in a stub
> domain? That certainly wasn't the behavior of what the legacy
> Linux implementation was intended for...
> 
>> Or were you just asking if IOCTL_XENBUS_BACKEND_REMOTE_SETUP's parameter
>> can be changed to xenbus_alloc_t?  That structure could be populated in the
>> same way as the legacy implementation, but it wouldn't give any more
>> information than the current ioctl does.
> 
> No, if it functionally differs, then we really should just care that
> the ioctl numbers don't collide.
> 
> Jan
> 

I think this depends on how the xenstore domain is constructed: if it is
started instead of the dom0-based xenstored (not the current method, but
converting init-xenstored to create the domain itself should make this
possible) then the setup/commit split of the ioctl is not needed. In that
case the older ioctl name/interface can be preserved (although the grant
field will always be populated with 1).

-- 
Daniel De Graaf
National Security Agency

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel