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 12:31:32 +0100 Message-ID: <4FFC1294.9040408@citrix.com> References: <1341403176-50715-1-git-send-email-roger.pau@citrix.com> <1341772363.797.2.camel@hastur.hellion.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1341772363.797.2.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: > (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. > > Ian. > > ~# xl -vvv cd-insert dHVM-1 hdc /scratch/mini.iso,raw > libxl: debug: libxl.c:3074:libxl_device_disk_remove: ao 0x8069c30: create: how=(nil) callback=(nil) poller=0x8069a50 > libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x8069dcc wpath=/local/domain/0/backend/qdisk/43/5632/state token=3/0: register slotnum=3 > libxl: debug: libxl.c:3074:libxl_device_disk_remove: ao 0x8069c30: inprogress: poller=0x8069a50, flags=i > libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x8069dcc wpath=/local/domain/0/backend/qdisk/43/5632/state token=3/0: event epath=/local/domain/0/backend/qdisk/43/5632/state > libxl: debug: libxl_event.c:600:devstate_watch_callback: backend /local/domain/0/backend/qdisk/43/5632/state wanted state 6 still waiting state 5 > > [... long wait ...] > > libxl: debug: libxl_event.c:614:devstate_timeout: backend /local/domain/0/backend/qdisk/43/5632/state wanted state 6 timed out > libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x8069dcc wpath=/local/domain/0/backend/qdisk/43/5632/state token=3/0: deregister slotnum=3 > libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x8069dcc: deregister unregistered > libxl: debug: libxl_event.c:512:libxl__ev_xswatch_register: watch w=0x8069dcc wpath=/local/domain/0/backend/qdisk/43/5632/state token=3/1: register slotnum=3 > libxl: debug: libxl_event.c:457:watchfd_callback: watch w=0x8069dcc wpath=/local/domain/0/backend/qdisk/43/5632/state token=3/1: event epath=/local/domain/0/backend/qdisk/43/5632/state > libxl: debug: libxl_event.c:600:devstate_watch_callback: backend /local/domain/0/backend/qdisk/43/5632/state wanted state 6 still waiting state 5 > > [... long wait ...] > > libxl: debug: libxl_event.c:614:devstate_timeout: backend /local/domain/0/backend/qdisk/43/5632/state wanted state 6 timed out > libxl: debug: libxl_event.c:549:libxl__ev_xswatch_deregister: watch w=0x8069dcc wpath=/local/domain/0/backend/qdisk/43/5632/state token=3/1: deregister slotnum=3 > libxl: debug: libxl_event.c:561:libxl__ev_xswatch_deregister: watch w=0x8069dcc: deregister unregistered > libxl: debug: libxl_device.c:759:device_backend_callback: unable to disconnect device with path /local/domain/0/backend/qdisk/43/5632 > libxl: debug: libxl_event.c:1434:libxl__ao_complete: ao 0x8069c30: complete, rc=0 > libxl: debug: libxl_event.c:1406:libxl__ao__destroy: ao 0x8069c30: destroy > libxl: debug: libxl.c:1958:libxl_device_disk_add: ao 0x8069c30: create: how=(nil) callback=(nil) poller=0x8069a50 > libxl: debug: libxl_device.c:255:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=unknown > libxl: debug: libxl_device.c:258:libxl__device_disk_set_backend: format=raw cdrom=yes > libxl: debug: libxl_device.c:209:disk_try_backend: Disk vdev=hdc, backend phy unsuitable as phys path not a block device > libxl: debug: libxl_device.c:216:disk_try_backend: Disk vdev=hdc, backend tap unsuitable because blktap not available > libxl: debug: libxl_device.c:293:libxl__device_disk_set_backend: Disk vdev=hdc, using backend qdisk > libxl: debug: libxl_event.c:1434:libxl__ao_complete: ao 0x8069c30: complete, rc=0 > libxl: debug: libxl.c:1971:libxl_device_disk_add: ao 0x8069c30: inprogress: poller=0x8069a50, flags=ic > libxl: debug: libxl_event.c:1406:libxl__ao__destroy: ao 0x8069c30: destroy > xc: debug: hypercall buffer: total allocations:2 total releases:2 > xc: debug: hypercall buffer: current allocations:0 maximum allocations:2 > xc: debug: hypercall buffer: cache current size:1 > xc: debug: hypercall buffer: cache hits:0 misses:1 toobig:1 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.