| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: [PATCH 02 of 23] libxl: add a comment describing the dev
On Tue, 2011-10-04 at 09:53 +0100, Dave Scott wrote:
> Hi Ian,
>
> I think the shape of this interface looks sensible.
Thanks for taking a look.
> [ snip ]
> > + * libxl_device_<type>_add(ctx, domid, device):
> > + *
> > + * Adds the given device to the specified domain. This can be called
> > + * while the guest is running (hotplug) or before boot (coldplug).
> > + *
> > + * This function only sets up the device but does not wait for the
> > + * domain to connect to the device and therefore cannot block on the
> > + * guest.
> > + *
> > + * XXX do we need a way to wait? e.g. wait_for_connect function?
>
> I don't know about other users but xapi doesn't currently care whether a
> domain
> has actually connected to the device (in the sense of xenstore state = 4).
> Xapi only cares about whether the device has been connected to the domain
> from the host's PoV; i.e. the "virtual cable" has been plugged in and the
> domain
> can use the device if it chooses to.
That's what I was thinking too but I expressed it badly, i.e.
wait_for_backend_setup() might be a better name / concept.
> BTW Xapi's disk hotplug command will block until it gets a completion signal
> from a backend udev script. While the command is in progress it holds a lock
> which prevents an old xenstore watch being processed which might cause xapi
> to think a async unplug has just occurred (more below)
>
> > + * XXX perhaps an optional way to generate an event on connect?
> > + * needs event system overhaul.
> > + *
> > + * libxl_device_<type>_remove(ctx, domid, device):
> > + *
> > + * Removes the given device from the specified domain by performing
> > + * an orderly unplug with guest co-operation. This requires that the
> > + * guest is running.
> > + *
> > + * This method is currently synchronous and therefore can block
> > + * while interacting with the guest.
> > + *
> > + * XXX should provide an async version. needs event system overhaul.
>
> Xapi normally performs a synchronous unplug, waiting for completion signaled
> via a backend udev script. However if the disk is mounted inside the domain
> and the blkfront signals an error ("02 - refusing to close" ISTR) then xapi
> stops waiting and the synchronous unplug fails. Later when the admin inside
> the
> guest unmounts the disk and the unplug completes, xapi's xenstore watch fires,
> it grabs a lock, checks the state of xenstore and if necessary marks the disk
> as unplugged.
Is this roughly the same as doing an async unplug followed by an event
triggered by the udev script? The only difference is whether the event
happens sooner or much later? Possibly we could have a separate "unplug
deferred" style event which triggers when we notice that the guest is
refusing to unplug, so the toolstack can at least report that fact?
>
> BTW I've always thought this behaviour a little weird and I'm not attached to
> it :) IMHO it would be nice to have a failed unplug request cause the whole
> operation to be aborted, and not to have the device unplug later by itself.
We may find our hands tied by the existing backend/frontend
implementations here, but we can see what we can do.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home