qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] "usb: uhci: Look up queue by address, not token"
Date: Thu, 15 Nov 2012 16:19:34 +0100	[thread overview]
Message-ID: <50A50806.5020309@redhat.com> (raw)

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.

So I'm wondering if you can give a (short) description of exactly what you
were seeing which is fixed by this patch ? And were you seeing this with
1.2, or with master ?

The reason why I want to know, is that identifying the queue by qh has a
disadvantage, to be precise I believe the following can then happen:

1) The guest queues up multiple requests for a queue
2) We execute one, go async
3) The guest changes it mind an unlinks the qh
4) The guest will think the queue is cancelled after frindex has
changed by 1, but we keep it around for 64 frames (which sucks,
and I want to improve on this, but we need to for various reasons)
5) The guests submits some new requests to the queue, using a
new qh (which possibly has a different address).
6) We see the new qh, and execute a request from there
7) The 1st request on the old qh completes, and we execute the next
8) Now things are a mess as we're executing requests from the old
(cancelled from the guest pov) and new queue intermixed...

Using the token to identify the queue fixes this, cause we will
find the same queue for the old and new qh, and uhci_queue_verify()
will then fail because of the qh addr change, and then we cancel
the old queue. IOW then we do the right thing.

So I'm wondering if there is another, potentially better fix for
what you are seeing?

Regards,

Hans

p.s.

Did you send this directly to Gerd, without CC-ing qemu-devel, or
did I just miss it on qemu-devel ? If the former, please add qemu-devel
to the CC next time.

             reply	other threads:[~2012-11-15 15:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-15 15:19 Hans de Goede [this message]
2012-11-15 15:40 ` [Qemu-devel] "usb: uhci: Look up queue by address, not token" Jan Kiszka
2012-11-16 10:25   ` Gerd Hoffmann
2012-11-16 11:24     ` Jan Kiszka
2012-11-16 13:43       ` Gerd Hoffmann
2012-11-17 10:22         ` Hans de Goede
2012-11-16 13:29   ` Hans de Goede
2012-11-16 15:06     ` Jan Kiszka
2012-11-17 10:20       ` Hans de Goede

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50A50806.5020309@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).