From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:55008)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1TZK2L-0004w0-7q
	for qemu-devel@nongnu.org; Fri, 16 Nov 2012 06:24:44 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1TZK2I-0003eS-1j
	for qemu-devel@nongnu.org; Fri, 16 Nov 2012 06:24:41 -0500
Received: from thoth.sbs.de ([192.35.17.2]:23044)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jan.kiszka@siemens.com>) id 1TZK2H-0003a4-Nw
	for qemu-devel@nongnu.org; Fri, 16 Nov 2012 06:24:37 -0500
Message-ID: <50A62273.5000404@siemens.com>
Date: Fri, 16 Nov 2012 12:24:35 +0100
From: Jan Kiszka <jan.kiszka@siemens.com>
MIME-Version: 1.0
References: <50A50806.5020309@redhat.com> <50A50CD7.4070104@siemens.com>
	<50A61497.90003@redhat.com>
In-Reply-To: <50A61497.90003@redhat.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] "usb: uhci: Look up queue by address, not token"
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>, "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

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.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux