- 08 1月, 2013 1 次提交
-
-
由 Gerd Hoffmann 提交于
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 07 1月, 2013 6 次提交
-
-
由 Hans de Goede 提交于
Some usb devices (host or network redirection) can benefit from knowing when the guest stops using an endpoint. Redirection may involve submitting packets independently from the guest (in combination with a fifo buffer between the redirection code and the guest), to ensure that buffers of the real usb device are timely emptied. This is done for example for isoc traffic and for interrupt input endpoints. But when the (re)submission of packets is done by the device code, then how does it know when to stop this? For isoc endpoints this is handled by detecting a set interface (change alt setting) command, which works well for isoc endpoints. But for interrupt endpoints currently the redirection code never stops receiving data from the device, which is less then ideal. However the controller emulation is aware when a guest looses interest, as then the qh for the endpoint gets unlinked (ehci, ohci, uhci) or the endpoint is explicitly stopped (xhci). This patch adds a new ep_stopped USBDevice method and modifies the hcd code to call this on queue unlink / ep stop. This makes it possible for the redirection code to properly stop receiving interrupt input (*) data when the guest no longer has interest in it. *) And in the future also buffered bulk input. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
If somehow we've gotten behind a lot, simply skip ahead, like the ehci code does. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Before this patch uhci would process an unlimited amount of frames when behind on schedule, by setting the timer to a time already past, causing the timer subsys to immediately recall the frame_timer function gain. This would cause invalid cancellations of bulk queues when the catching up processed more then 32 frames at a moment when the bulk qh was temporarily unlinked (which the Linux uhci driver does). This patch fixes this by processing maximum 16 frames in one go, and always setting the timer one ms later, making the code behave more like the ehci code. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Rather then using the magic 32 value in various places. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Re-arrange how we process frames / increase frnum / report pending interrupts, to avoid a 1 ms delay in interrupt reporting to the guest. This increases the packet throughput for cases where the guest submits a single packet, then waits for its completion then re-submits from 500 pkts / sec to 1000 pkts / sec. This impacts for example the use of redirected / virtual usb to serial convertors. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 19 12月, 2012 2 次提交
-
-
由 Paolo Bonzini 提交于
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Paolo Bonzini 提交于
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 17 12月, 2012 1 次提交
-
-
由 Michael S. Tsirkin 提交于
update all users so we can remove the makefile hack. Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
-
- 29 11月, 2012 1 次提交
-
-
由 Gerd Hoffmann 提交于
Hotplugging them simply doesn't work, so tag them accordingly to avoid users trying and then crashing qemu. For xhci there is nothing fundamental which prevents hotplug from working, we'll "only" need a exit() function which cleans up everything properly. That isn't for 1.3 though. For ehci+uhci+ohci hotplug can't be supported until qemu gains the capability to hotplug multifunction pci devices. https://bugzilla.redhat.com/show_bug.cgi?id=879096Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 21 11月, 2012 3 次提交
-
-
由 Hans de Goede 提交于
uhci_async_cancel() already does a uhci_async_unlink(). Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
It is possible for device disconnect and the guest trying to reset the port (because of USB xact errors prior to the disconnect getting signaled) to race, when we hit this race, the guest will write the port-control register with its pre-disconnect value + the reset bit set, after which we have a disconnected device with its port-enabled bit set in its port-control register, which is no good :) Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Add a completions_only flag, and set this when running process_frame for async completion handling, this fixes 2 issues in a single patch: 1) It makes sure async completed packets get written to guest mem immediately, even if all the bandwidth for the frame was consumed from the timer run process_frame. This is necessary as delaying their writeback to the next frame can cause the completion to get lost on migration. 2) The calling of process_frame from a bh on async completion causes iso tds to get server more often they should, messing up usb sound class device timing. By only processing completed packets, the iso tds get skipped fixing this. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 09 11月, 2012 1 次提交
-
-
由 Hans de Goede 提交于
Since with the ehci and xhci controllers a single packet can be larger then maxpacketsize, it is possible for the result of a single packet to be both having transferred some data as well as the transfer to have an error. An example would be an input transfer from a bulk endpoint successfully receiving 1 or more maxpacketsize packets from the device, followed by a packet signalling halt. While already touching all the devices and controllers handle_packet / handle_data / handle_control code, also change the return type of these functions to void, solely storing the status in the packet. To make the code paths for regular versus async packet handling more uniform. This patch unfortunately is somewhat invasive, since makeing the qemu usb core deal with this requires changes everywhere. This patch only prepares the usb core for this, all the hcd / device changes are done in such a way that there are no functional changes. This patch has been tested with uhci and ehci hcds, together with usb-audio, usb-hid and usb-storage devices, as well as with usb-redir redirection with a wide variety of real devices. Note that there is usually no need to directly set packet->actual_length form devices handle_data callback, as that is done by usb_packet_copy() Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 01 11月, 2012 5 次提交
-
-
由 Hans de Goede 提交于
My recent uhci cleanup series has introduced a regression, where qemu sometimes crashes on a device disconnect. The problem is that the uhci code never checked for a device not / no longer existing, instead it was relying on usb_handle_packet accepting a NULL device. But since we now pass usb_handle_packet q->ep->dev, rather then just a local dev variable, we crash as q->ep == NULL due to the device no longer existing. This patch fixes this. Note that this patch also improves over the old behavior were we would: 1) create a queue for the device 2) create an async for the packet 3) have usb_handle_packet fail 4) destroy the async 5) wait for the queue to be idle for 32 frames 6) destroy the queue Which was rather sub-optimal. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Kills the ugly "switch (device_id) { ... }" struct and makes it easier to figure what the differences between the uhci variants are. Need our own DeviceClass struct for that so we can allocate some space to store UHCIInfo. Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Gerd Hoffmann 提交于
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
- 25 10月, 2012 20 次提交
-
-
由 Hans de Goede 提交于
ctrl endpoints use different pids for different phases of a control transfer, this patch makes us use only one queue for a ctrl ep, rather then 3. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
If the guest is using multiple transfers to try and keep the usb bus busy / used at maximum efficiency, currently we would see / do the following: 1) submit transfer 1 to the device 2) submit transfer 2 to the device 3) report transfer 1 completion to guest 4) report transfer 2 completion to guest 5) submit transfer 1 to the device 6) report transfer 1 completion to guest 7) submit transfer 2 to the device 8) report transfer 2 completion to guest etc. So after the initial submission we would effectively only have 1 transfer in flight, rather then 2. This is caused by us not checking the queue for addition of new transfers by the guest (ie the resubmission of a recently finished transfer), while waiting for a pending transfer to complete. This patch does add a check for this, changing the sequence to: 1) submit transfer 1 to the device 2) submit transfer 2 to the device 3) report transfer 1 completion to guest 4) submit transfer 1 to the device 5) report transfer 2 completion to guest 6) submit transfer 2 to the device etc. Thus keeping 2 transfers in flight (most of the time, and always 1), as intended by the guest. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Before this patch we would not mark a queue valid when its head was a non-active td. This causes us to misbehave in the following scenario: 1) queue with multiple input transfers queued 2) We hit some latency issue, causing qemu to get behind processing frames 3) When qemu gets to run again, it notices the first transfer ends short, marking the head td non-active 4) It now processes 32+ frames in a row without giving the guest a chance to run since it is behind 5) valid is decreased to 0, causing the queue to get cancelled also cancelling already queued up further input transfers 6) guest gets to run, notices the inactive td, cleanups up further tds from the short transfer, and lets the queue continue at the first td of the next input transfer 7) we re-start the queue, issuing the second input transfer for the *second* time, and any data read by the first time we issued it has been lost Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
A td can be reused by the guest in a different queue, before we notice the original queue has been unlinked. So search for tds by addr only, detect guest td reuse, and cancel the original queue, this is necessary to keep our packet ids unique. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
According to the spec a guest can unlink a qh, and then as soon as frindex has changed by 1 since the unlink, assume it is idle and re-use it. However for various reasons, we cannot simply consider a qh as unlinked if we've not seen it for 1 frame. This means that it is possible for a guest to re-use / restart the queue while we still see its old state. This patch adds a safety check for this, and "early" retires queues when they were changed by the guest. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
There is no need to just cancel any in-flight packets, and then wait for validate-end to clean things up, we can simply clean things up immediately on device removal. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
This avoids the need to repeatedly lookup the device, and ep. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
And move its calling point to handle_td, this removes the ep_ret ugliness, and prepates the way for further cleanups in the follow-up patches in this patch-set. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
We use the name td both to refer to a UHCI_TD read from guest memory as well as to refer to the guest address where a td is stored, switch over to always use td_addr in the second case for consistency. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Cleanup: all callers of uhci_queue_free first unconditionally cancel all remaining asyncs in the queue, so lets move this to uhci_queue_free(). Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Since we are either dealing with emulated devices, where retrying is not going to help, or with redirected devices where the host OS will have already retried, don't bother retrying on failed transfers. Also move some common/indentical code out of all the error cases into the generic error path. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
All callers of uhci_async_cancel() call uhci_async_unlink() first, so lets move the unlink call to uhci_async_cancel() Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
No devices ever return async for isoc endpoints and the core already enforces this. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
After a short-not-ok packet ending short, we should not advance the queue. Move enforcing this to the core, rather then handling it in the hcd code. This may result in the queue now actually containing multiple input packets (which would not happen before), and this requires special handling in combination with pipelining, so disable pipleining for input endpoints (for now). Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
hcds which queue up more then one packet at once (uhci, ehci and xhci), must clear the queue after an error which has caused the queue to halt. Currently this is handled as a special case inside the hcd code, this patch instead adds an USB_RET_REMOVE_FROM_QUEUE packet result code, teaches the 3 hcds about this and moves the clearing of the queue on a halt into the USB core. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-
由 Hans de Goede 提交于
This can be used by usb-device code which wishes to process an entire endpoint queue at once, to do this the usb-device code returns USB_RET_ADD_TO_QUEUE from its handle_data class method and defines a flush_ep_queue class method to call when the hcd is done queuing up packets. Signed-off-by: NHans de Goede <hdegoede@redhat.com> Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
-