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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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


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