qemu-devel
[Top][All Lists]
Advanced

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

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


From: Hans de Goede
Subject: Re: [Qemu-devel] "usb: uhci: Look up queue by address, not token"
Date: Sat, 17 Nov 2012 11:22:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121016 Thunderbird/16.0.1

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



reply via email to

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