From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShEM1-0002Oq-2j for qemu-devel@nongnu.org; Wed, 20 Jun 2012 02:25:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ShELt-00036f-Nu for qemu-devel@nongnu.org; Wed, 20 Jun 2012 02:25:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:21224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ShELt-00036P-FY for qemu-devel@nongnu.org; Wed, 20 Jun 2012 02:25:17 -0400 Message-ID: <4FE16CC6.6090007@redhat.com> Date: Wed, 20 Jun 2012 08:25:10 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1340087992-2399-1-git-send-email-benh@kernel.crashing.org> <1340087992-2399-8-git-send-email-benh@kernel.crashing.org> <4FE081CE.1060001@redhat.com> <1340137438.28143.28.camel@pasglop> <20120620031421.GB9144@truffala.fritz.box> In-Reply-To: <20120620031421.GB9144@truffala.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 07/13] usb: Convert usb_packet_{map, unmap} to universal DMA helpers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt , qemu-devel@nongnu.org, anthony@codemonkey.ws Hi, >> Like with any other device, it's hard ... what would happen on real >> hardware is that the USB controller will get a target abort, which will >> result in the controller reporting an error (typically in the PCI status >> register) and stopping. Not that hard, code to cancel in-flight transactions is in place already as this can happen for other reasons too. > handle this. However, the USB case should be ok - it may not be > theoretically guaranteed that the calls are close, but it's certainly > the case at the moment. Depends on the device. For the usb hid devices (which is the most important use case for power I think) packets will be processed synchronously, so there is no problem here. usb-storage can keep packets in flight without holding the qemu lock (waiting for async block I/O finish). Shouldn't be too long though. usb-host keeps pretty much every packet in flight without holding the qemu lock as it passes on the requests to the hosts usbfs, then waits asynchronously for the request finish before returning the result to the guest. Depending on the kind of device you are passing though this can be *very* long (minutes). cheers, Gerd