From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Roger_Pau_Monn=E9?= Subject: Re: libxl: locally attaching disk Date: Tue, 14 May 2013 18:30:22 +0200 Message-ID: <5192669E.1080909@citrix.com> References: <4B45B535F7F6BE4CB1C044ED5115CDDE01541F4E95B2@LONPMAILBOX01.citrite.net> <51924CE4.5090600@citrix.com> <4B45B535F7F6BE4CB1C044ED5115CDDE01541F4E9620@LONPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE01541F4E9620@LONPMAILBOX01.citrite.net> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Thanos Makatos Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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.