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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On 14/05/13 18:17, Thanos Makatos wrote:
>>> 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?

local_device_attach_cb (in libxl.c) already does wait for the device to
reach state 4 (connected), in libxl__wait_device_connection you should
just skip the wait for state 2.

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