[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.