usb-redir: Don't handle interrupt output packets async
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> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This commit is contained in:
parent
234e810cce
commit
723aedd532
@ -662,21 +662,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;
|
||||
|
||||
@ -685,7 +686,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,
|
||||
@ -1647,11 +1647,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);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
Loading…
Reference in New Issue
Block a user