qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/2] hw/usb-ohci: Honour endpoint maximum packet


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]