From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roger Pau Monne Subject: Re: [PATCH v8 00/15] execute hotplug scripts from libxl Date: Tue, 10 Jul 2012 17:07:21 +0100 Message-ID: <4FFC5339.4060504@citrix.com> References: <1341403176-50715-1-git-send-email-roger.pau@citrix.com> <1341772363.797.2.camel@hastur.hellion.org.uk> <4FFC1294.9040408@citrix.com> <1341935753.8586.48.camel@hastur.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1341935753.8586.48.camel@hastur.hellion.org.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org Ian Campbell wrote: > On Tue, 2012-07-10 at 07:31 -0400, Roger Pau Monne wrote: >> Ian Campbell wrote: >>> (resending as I don't think I had SMTP setup properly on my laptop -- sorry if you get this twice!) >>> >>> On Wed, 2012-07-04 at 07:59 -0400, Roger Pau Monne wrote: >>>> This new serie (v8) fixes a code refactoring problem that was present >>>> in v7 (06/15 changed code introduced by 05/15). >>> From somewhere in here I'm seeing timeouts waiting for the b/e to go to >>> state 5 when doing cd-insert on an HVM guest. I suspect because this is >>> (or should be) turned into a virtual media change rather than an actual >>> device remove and insert? >>> >>> BTW libxl_cdrom_insert hasn't been async'd up yet -- I was actually just >>> looking into that when I noticed this. >>> > [...] >> Yes, this is due to the fact that Qemu (traditional at least) doesn't >> honour the connection/disconnection protocol, so neither removing the >> frontend or setting the backend to "closing" (5), will make Qemu >> disconnect the device. I used to have a special "dev->backend_type == >> QDISK" to skip the waiting, I've added it to my series again, and it >> should solve the waiting problem. > > Actually I think libxl_cdrom_insert is just broken. For an HVM guest > with an emulated CDROM (i..e the normal case, even if you have PV > drivers) then the media change protocol is not to remove the device and > reinsert it. Instead you are supposed to just change the params key. I > have half a patch to do this (as part of the asyncification of the > interface) and I think it will make this special case unnecessary, at > least or the cdrom case. > > Perhaps you also need it for the disk case though, I don't know. Or > maybe qemu should be taught to honour the protocol? I'm working on making vfb/vkb async, once that is done I can take a look on this, but since the device removal is done after Qemu has been killed I don't have much expectations that this is going to work (at least for the shutdown/destroy case). The block-attach/detach case might work with this approach.