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

Re: [Xen-devel] [PATCH v8 00/15] execute hotplug scripts from libxl



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?

Ian


_______________________________________________
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®.