|
From: | Gerd Hoffmann |
Subject: | Re: [Qemu-devel] [PATCH 1/2] hw/usb-ohci: Honour endpoint maximum packet size |
Date: | Thu, 15 Sep 2011 12:49:53 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110904 Red Hat/3.1.14-1.el6_1 Thunderbird/3.1.14 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |