From: Hans de Goede <hdegoede@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Hans de Goede <hdegoede@redhat.com>, qemu-devel@nongnu.org
Subject: [Qemu-devel] [PATCH 2/2] usb-redir: Don't handle interrupt output packets async
Date: Sat, 17 Nov 2012 12:26:57 +0100 [thread overview]
Message-ID: <1353151617-25804-3-git-send-email-hdegoede@redhat.com> (raw)
In-Reply-To: <1353151617-25804-1-git-send-email-hdegoede@redhat.com>
Instead report them as successfully completed directly on submission, this
has 2 advantages:
1) This matches the timing of interrupt output packets on real hardware,
with the previous async handling, if an ep has an interval of say 500 ms,
then there would be 500+ ms between the submission and the guest seeing the
completion, as we wont do the write back until the qh gets polled again. And
in the mean time the guest may very well have timed out, as the guest can
reasonable expect a much quicker completion.
2) This fixes interrupt output packets potentially getting send twice
surrounding a migration. As we delay the writeback to guest memory until
the qh gets polled again, there is a window between completion and writeback
where migration can happen, in this case the destination will not know
about the completion, and it will execute the packet *again*
But it does also come with a disadvantage:
1) If the actual interrupt out to the real usb device fails, there is no
way to report this back to the guest.
This patch assumes however that interrupt outs in practice never fail, as
they are only used by specialized drivers, which are unlikely to issue illegal
requests (unlike general class drivers which often issue requests which some
devices don't implement). And that thus the advantages outway the disadvantage.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
hw/usb/redirect.c | 26 ++++++++++++++------------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/hw/usb/redirect.c b/hw/usb/redirect.c
index 9658bda..15f394c 100644
--- a/hw/usb/redirect.c
+++ b/hw/usb/redirect.c
@@ -672,21 +672,22 @@ static void usbredir_handle_interrupt_in_data(USBRedirDevice *dev,
usbredir_handle_status(dev, p, status);
}
+/*
+ * Handle interrupt out data, the usbredir protocol expects us to do this
+ * async, so that it can report back a completion status. But guests will
+ * expect immediate completion for an interrupt endpoint, and handling this
+ * async causes migration issues. So we report success directly, counting
+ * on the fact that output interrupt packets normally always succeed.
+ */
static void usbredir_handle_interrupt_out_data(USBRedirDevice *dev,
USBPacket *p, uint8_t ep)
{
- /* Output interrupt endpoint, normal async operation */
struct usb_redir_interrupt_packet_header interrupt_packet;
uint8_t buf[p->iov.size];
DPRINTF("interrupt-out ep %02X len %zd id %"PRIu64"\n", ep,
p->iov.size, p->id);
- if (usbredir_already_in_flight(dev, p->id)) {
- p->status = USB_RET_ASYNC;
- return;
- }
-
interrupt_packet.endpoint = ep;
interrupt_packet.length = p->iov.size;
@@ -695,7 +696,6 @@ static void usbredir_handle_interrupt_out_data(USBRedirDevice *dev,
usbredirparser_send_interrupt_packet(dev->parser, p->id,
&interrupt_packet, buf, p->iov.size);
usbredirparser_do_write(dev->parser);
- p->status = USB_RET_ASYNC;
}
static void usbredir_stop_interrupt_receiving(USBRedirDevice *dev,
@@ -1670,11 +1670,13 @@ static void usbredir_interrupt_packet(void *priv, uint64_t id,
/* bufp_alloc also adds the packet to the ep queue */
bufp_alloc(dev, data, data_len, interrupt_packet->status, ep);
} else {
- USBPacket *p = usbredir_find_packet_by_id(dev, ep, id);
- if (p) {
- usbredir_handle_status(dev, p, interrupt_packet->status);
- p->actual_length = interrupt_packet->length;
- usb_packet_complete(&dev->dev, p);
+ /*
+ * We report output interrupt packets as completed directly upon
+ * submission, so all we can do here if one failed is warn.
+ */
+ if (interrupt_packet->status) {
+ WARNING("interrupt output failed status %d ep %02X id %"PRIu64"\n",
+ interrupt_packet->status, ep, id);
}
}
}
--
1.8.0
prev parent reply other threads:[~2012-11-17 11:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-17 11:26 [Qemu-devel] [USB fixes for 1.3] usb-redir: Fix migration race with output int eps Hans de Goede
2012-11-17 11:26 ` [Qemu-devel] [PATCH 1/2] usb-redir: Split usb_handle_interrupt_data into separate in/out functions Hans de Goede
2012-11-17 11:26 ` Hans de Goede [this message]
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=1353151617-25804-3-git-send-email-hdegoede@redhat.com \
--to=hdegoede@redhat.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).