From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTx6e-0004M9-PL for qemu-devel@nongnu.org; Thu, 01 Nov 2012 11:55:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTx6Y-0008CD-QB for qemu-devel@nongnu.org; Thu, 01 Nov 2012 11:54:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63483) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTx6Y-00089j-Fd for qemu-devel@nongnu.org; Thu, 01 Nov 2012 11:54:50 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qA1Fsn2r001939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 1 Nov 2012 11:54:49 -0400 From: Gerd Hoffmann Date: Thu, 1 Nov 2012 16:54:38 +0100 Message-Id: <1351785284-15384-26-git-send-email-kraxel@redhat.com> In-Reply-To: <1351785284-15384-1-git-send-email-kraxel@redhat.com> References: <1351785284-15384-1-git-send-email-kraxel@redhat.com> Subject: [Qemu-devel] [PATCH 25/31] combined-packet: Add a workaround for Linux usbfs + live migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Hans de Goede , Gerd Hoffmann From: Hans de Goede Older versions (anything but the latest) of Linux usbfs + libusb(x), will submit larger (bulk) transfers split into multiple 16k submissions, which means that rather then all tds getting linked into the queue in one atomic operarion they get linked in a bunch at a time, which could cause problems if: 1) We scan the queue while libusb is in the middle of submitting a split bulk transfer 2) While this bulk transfer is pending we migrate to another host. The problem is that after 2, the new host will rescan the queue and combine the packets in one large transfer, where as 1) has caused the original host to see them as 2 transfers. This patch fixes this by stopping combinging if we detect a 16k transfer with its int_req flag set. This should not adversely effect performance for other cases as: 1) Linux never sets the interrupt flag on packets other then the last 2) Windows does set the in_req flag on each td, but will submit large transfers in 20k tds thus never triggering the check Signed-off-by: Hans de Goede Signed-off-by: Gerd Hoffmann --- hw/usb/combined-packet.c | 7 +++++-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/hw/usb/combined-packet.c b/hw/usb/combined-packet.c index 652bf02..3904e71 100644 --- a/hw/usb/combined-packet.c +++ b/hw/usb/combined-packet.c @@ -117,7 +117,7 @@ void usb_ep_combine_input_packets(USBEndpoint *ep) { USBPacket *p, *u, *next, *prev = NULL, *first = NULL; USBPort *port = ep->dev->port; - int ret; + int ret, totalsize; assert(ep->pipeline); assert(ep->pid == USB_TOKEN_IN); @@ -161,8 +161,11 @@ void usb_ep_combine_input_packets(USBEndpoint *ep) } /* Is this packet the last one of a (combined) transfer? */ + totalsize = (p->combined) ? p->combined->iov.size : p->iov.size; if ((p->iov.size % ep->max_packet_size) != 0 || !p->short_not_ok || - next == NULL) { + next == NULL || + /* Work around for Linux usbfs bulk splitting + migration */ + (totalsize == 16348 && p->int_req)) { ret = usb_device_handle_data(ep->dev, first); assert(ret == USB_RET_ASYNC); if (first->combined) { -- 1.7.1