Re: [Xen-devel] libxl: locally attaching disk

[Thanos Makatos <thanos.makatos@xxxxxxxxxx>]

> > I run into the following problem: blkfront goes directly from state 1
> to state 3, the back-end follows by jumping to state 4, and finally the
> front-end goes to state 4 and everything works fine (this is what is
> done for domU guests using blktap3 without pygrub). However, it seems
> that libxl expects the backend to step through each state (specifically
> it times out waiting for the back-end to go to state 2 but the back-end
> has already gone to state 4). If I correctly understand the protocol
> specification in xen/include/public/io/blkif.h, libxl shouldn't be
> doing that. Here's the output of libxl:
> 
> Hello,
> 
> In libxl we wait for the backend to reach state 2 because for blkback
> backends we have to execute hotplug scripts. If you take a look at
> libxl__wait_device_connection in libx_device.c you will see that if the
> backend is Qemu, we skip the waiting and instead jump to device_hotplug
> directly. Since blktap backend don't use hotplug scripts, and hence
> don't wait in state 2 for device hotplug execution you should implement
> something similar for blktap backends.

So if I get this straight, we shouldn't execute device_hotplug for blktap3 
because we don't use hotplug scripts. Also, in the same function, we do need to 
execute libxl__ev_devstate_wait but setting the XenbusState to 
XenbusStateConnected, because lixbl must wait for blkfront to connect to 
tapdisk in order access the block device. Is this correct?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel