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 16:40:36 +0200 Message-ID: <51924CE4.5090600@citrix.com> References: <4B45B535F7F6BE4CB1C044ED5115CDDE01541F4E95B2@LONPMAILBOX01.citrite.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4B45B535F7F6BE4CB1C044ED5115CDDE01541F4E95B2@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 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.