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

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



On 14/05/13 15:20, Thanos Makatos wrote:
> I want to implement booting from VHD images using pygrub for blktap3. I'm 
> trying to use the existing code for qemu: in 
> libxl__device_disk_local_initiate_attach I tell libxl to do exactly the same 
> thing it does for the LIBXL_DISK_BACKEND_QDISK case in the switch statement 
> (similar for libxl__device_disk_local_initiate_detach).
> 
> 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.

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


 


Rackspace

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