From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R49W4-0005gC-0s for qemu-devel@nongnu.org; Thu, 15 Sep 2011 06:50:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R49W2-0000Lv-SX for qemu-devel@nongnu.org; Thu, 15 Sep 2011 06:49:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48537) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R49W2-0000Lr-DG for qemu-devel@nongnu.org; Thu, 15 Sep 2011 06:49:58 -0400 Message-ID: <4E71D851.80501@redhat.com> Date: Thu, 15 Sep 2011 12:49:53 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1316022540-31355-1-git-send-email-peter.maydell@linaro.org> <1316022540-31355-2-git-send-email-peter.maydell@linaro.org> <4E71AA5D.2070400@redhat.com> <4E71C1B0.5070607@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] hw/usb-ohci: Honour endpoint maximum packet size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel@nongnu.org, patches@linaro.org Hi, >> No. What I think is that USBPacket shouldn't be required to be an actual >> USB packet, but a transfer, i.e. do the splitting of larger transfers into >> smaller packets in the usb driver emulation (if needed), not the host >> adapter emulation. > > The OHCI spec still requires us to only process one max-packet-size > worth of data from this TransferDescriptor before we move on to > the next one, though, doesn't it? (cf the flowchart in fig 6-7). [ didn't look at specs ] Yes, EHCI has a simliar rule, on real hardware it is needed to ensure the available USB bandwidth is fairly splitted across all devices by serving them in a robin-round fashion. I don't think this makes much sense for emulation as it behaves very different compared to real hardware. There simply is no bus with limited bandwidth we have to care about. > It seems to me that at least some of that is likely to be > guest-visible, especially in the case where an endpoint returns an > error partway through. So it's not clear to me that you could > validly batch up everything in the TD and do it all at once. I think the only guest-visible effect is that the guest will never ever see an partially filled transfer block, it is either empty or completely filled (except on short transfers). cheers, Gerd