Re: [Qemu-devel] "usb: uhci: Look up queue by address, not token"

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 11/16/2012 02:43 PM, Gerd Hoffmann wrote:
> On 11/16/12 12:24, Jan Kiszka wrote:
>> On 2012-11-16 11:25, Gerd Hoffmann wrote:
>>> On 11/15/12 16:40, Jan Kiszka wrote:
>>>> Hi Hans,
>>>>
>>>> On 2012-11-15 16:19, Hans de Goede wrote:
>>>>> Hi Jan,
>>>>>
>>>>> I just saw your $subject patch in Gerd's usb-next tree, and I've a question
>>>>> about it. The token should be enough to uniquely identify a device + ep,
>>>>> and unless a guest uses multiple qhs for a singe ep, that _should_ be enough.
>>>>
>>>> But what disallows that the guest issues multiple requests (QH + series
>>>> of TDs) for a single endpoint? I'm not finding any trace in the spec
>>>> that disallows this. And my special guest is stumbling over that
>>>> limitation in QEMU.
>>>
>>> The order which the TDs from the two QHs are filled is undefined I
>>> think, so why a guest would do that?
>>
>> If short packets are ok, the next one queued would already be ready to
>> take the next chunk of data.
>
> I don't think you need two queues to model that.  IIRC the alt_next is
> taken on short tansfers, so you can line up all your TDs in one queue
> and let uhci jump forward to the next buffer start on short transfers
> using alt_next.
>

(Un)fortunately alt_next is an ehci only thing, uhci does not have this,
which may be a good thing as it has its own set of issues.

> The problem with two queues is that you simply don't know in which queue
> your transfers will end up and thus in which order your buffers are
> filled.  I don't think you want that.  If the device happens to NAK a
> transfer because it isn't ready yet uhci will go on to the next queue,
> so you can see the second queue being filled before the first is full.
> Wouldn't happen with qemu's uhci emulation, but I'm pretty sure on real
> hardware it can happen.

Ah good one, yes even with depth-first traversal if the device sends a nak
because it is not ready to send/receive, the controller will go horizontal
(so to the next qh), so even with depth first traversal using multiple qhs
per ep can go wrong. So that special legacy guest really is just broken by
design, even if it manages to get away with it on real hardware most of the
time.

Regards,

Hans