[Xen-devel] RE: [PATCH 02 of 23] libxl: add a comment describing the device interfaces

[Dave Scott <Dave.Scott@xxxxxxxxxxxxx>]

Hi Ian,

I think the shape of this interface looks sensible.

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

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.

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.

Cheers,
Dave


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