This was left as NULL on the initial merge due to debate on the mailing list on
how to handle DMA contexts for sysbus devices. Patch
9e11908f12 was later merged to fix OHCI. This is the,
equivalent fix for sysbus EHCI.
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Report an error instead of segfaulting when attaching a USB device to a
machine with no USB busses:
$ qemu-system-arm -machine vexpress-a9 \
-sd Fedora-17-armhfp-vexpress-mmcblk0.img \
-kernel vmlinuz-3.4.2-3.fc17.armv7hl \
-initrd initramfs-3.4.2-3.fc17.armv7hl.img \
-usbdevice disk:format=raw:test.img
Note that the vexpress-a9 machine does not have a USB host controller.
Reported-by: David Abdurachmanov <David.Abdurachmanov@cern.ch>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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=879096
Signed-off-by: Gerd Hoffmann <kraxel@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>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When we've no data to return from the interrupt endpoint, return NAK rather
then a 0 length packet.
CC: Alon Levy <alevy@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
I noticed this while making all devices with interrupt endpoints properly
do wakeup. While at it also add wakeup support.
Note that I've not tested this, but returning STALL for an interrupt ep
which has no data is cleary the wrong thing to do.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
uhci_async_cancel() already does a uhci_async_unlink().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Now that we have separate status and length fields in USBPacket
update the completion tracepoint to log both.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The previous default of 0 means that even errors and warnings would not
get printed, which is really not a good default.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Packets which are queued up, but not yet handed over to the device, are
*not* in flight.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Starting with commit 1c380f9460 dma
transfers can actually fail. This patch makes ehci keep track
of the busmaster bit in pci config space, by setting/clearing the
dma_context pointer. Attempts to dma without context will result
in raising HSE (Host System Error) interrupt and stopping the host
controller.
This patch fixes WinXP not booting with a usb stick attached to ehci.
Root cause is seabios activating ehci so you can boot from the stick,
and WinXP clearing the busmaster bit before resetting the host
controller, leading to ehci actually trying dma while it is disabled.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
While testing the move to async packet handling for interrupt endpoints I
noticed that Windows-XP likes to play tricks with the next pointer for
periodic qh-s, so we should not fail qh / qtd verification when it changes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Windows links interrupt qtd-s in circles, which means that when interrupt
endpoints return USB_RET_ASYNC, combined with the recent
"ehci: Retry to fill the queue while waiting for td completion" patch,
we keep adding the tds to the queue over and over again, as we detect the
circle from fill_queue, but we call it over and over again ...
This patch fixes this by changing the circle detection to also detect
circling into tds already queued up previously.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This avoids the q->qtdaddr == p->qtdaddr asserts we have triggering, when
a queue contains multiple completed packages when we cancel the queue.
I triggered this with windows7 + async interrupt endpoint handling (*)
+ not detecting circles in ehci_fill_queue() properly, which makes the qtd
validation in ehci_fill_queue fail, causing cancellation of the queue on every
mouse event ...
*) Which is not going upstream as it will cause loss of interrupt events on
migration.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ehci_state_writeback() will free the packet, so we should not access
the packet after calling ehci_state_writeback().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The Linux is more tolerant here as well: Just stop parsing the device
descriptors when an error is detected but do not reset what was found
so far. This allows to run buggy devices with partially invalid
descriptors.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commit a844ed842d leads to usb-host
detecting devices not right after qemu startup because the guest
isn't running yet. Instead they are found on the first of the
regular usb device poll runs. Which is too late for seabios to see
them, so booting from usb sticks fails.
Fix this by adding a vm state change handler which triggers a device
scan when the vm is started.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Elements in qemu SGLists can cross IOMMU page boundaries. So, in commit
39c138c842 "usb: Fix usb_packet_map() in the
presence of IOMMUs", I changed usb_packet_map() to split up each SGList
element on IOMMU page boundaries and each resulting piece of qemu's memory
space separately to the iovec the usb code uses internally.
That was correct in concept, but the patch has a bug. The 'base' variable
correctly steps through the dma address of each piece, but then we call
the dma_memory_map() function on the base address of the whole SGList
element every time.
This patch fixes at least one problem using XHCI on the pseries guest
machine. It didn't affect OHCI because that doesn't use usb_packet_map().
In theory it also affects EHCI, but we haven't observed that in practice.
I think the transfers were small enough on EHCI that they never crossed an
IOMMU page boundary in practice.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* bonzini/scsi-next:
virtio-scsi: use dma_context_memory
dma: Define dma_context_memory and use in sysbus-ohci
megasas: Correct target/lun mapping
scsi-disk: flush cache after disabling it
megasas: do not include block_int.h
scsi: remove superfluous call to scsi_device_set_ua
virtio-scsi: factor checks for VIRTIO_SCSI_S_DRIVER_OK when reporting events
scsi: do not return short responses for emulated commands
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Define a new global dma_context_memory which is a DMAContext corresponding
to the global address_space_memory AddressSpace. This can be used by
sysbus peripherals like sysbus-ohci which need to do DMA.
In particular, use it in the sysbus-ohci device, which fixes a
segfault when attempting to use that device.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
The xhci device does correct endian switches on the results of some DMAs
but not all. In particular, there are many DMAs of what are essentially
arrays of 32-bit integers which never get byteswapped. This causes them
to be interpreted incorrectly on big-endian hosts, since (as per the xhci
spec) these arrays are always little-endian in guest memory.
This patch adds some helper functions to fix these bugs. This may not be
all the endian bugs in the xhci code, but it's certainly some of them and
the Linux guest xhci driver certainly gets further with these fixes.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Instead make ehci_execute and ehci_fill_queue return the again value.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This follows the logic of host-linux: If a 2.0 device has no ISO
endpoint and no interrupt endpoint with a packet size > 64, we can
attach it also to an 1.1 host controller. In case the redir server does
not report endpoint sizes, play safe and remove the 1.1 compatibility as
well. Moreover, if we detect a conflicting change in the configuration
after the device was already attached, it will be disconnected
immediately.
HdG: Several small cleanups and fixes
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
So that the client gets a notification about us disconnecting the device.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Older versions (anything but the latest) of Linux usbfs + libusb(x),
will submit larger (bulk) transfers split into multiple 16k submissions,
which means that rather then all tds getting linked into the queue in
one atomic operarion they get linked in a bunch at a time, which could
cause problems if:
1) We scan the queue while libusb is in the middle of submitting a split
bulk transfer
2) While this bulk transfer is pending we migrate to another host.
The problem is that after 2, the new host will rescan the queue and
combine the packets in one large transfer, where as 1) has caused the
original host to see them as 2 transfers. This patch fixes this by stopping
combinging if we detect a 16k transfer with its int_req flag set.
This should not adversely effect performance for other cases as:
1) Linux never sets the interrupt flag on packets other then the last
2) Windows does set the in_req flag on each td, but will submit large
transfers in 20k tds thus never triggering the check
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently we only do pipelining for output endpoints, since to properly
support short-not-ok semantics we can only have one outstanding input
packet. Since the ehci and uhci controllers have a limited per td packet
size guests will split large input transfers to into multiple packets,
and since we don't pipeline these, this comes with a serious performance
penalty.
This patch adds helper functions to (re-)combine packets which belong to 1
transfer at the guest device-driver level into 1 large transger. This can be
used by (redirection) usb-devices to enable pipelining for input endpoints.
This patch will combine packets together until a transfer terminating packet
is encountered. A terminating packet is a packet which meets one or more of
the following conditions:
1) The packet size is *not* a multiple of the endpoint max packet size
2) The packet does *not* have its short-not-ok flag set
3) The packet has its interrupt-on-complete flag set
The short-not-ok flag of the combined packet is that of the terminating packet.
Multiple combined packets may be submitted to the device, if the combined
packets do not have their short-not-ok flag set, enabling true pipelining.
If a combined packet does have its short-not-ok flag set the queue will
wait with submitting further packets to the device until that packet has
completed.
Once enabled in the usb-redir and ehci code, this improves the speed (MB/s)
of a Linux guest reading from a USB mass storage device by a factor of
1.2 - 1.5.
And the main reason why I started working on this, when reading from a pl2303
USB<->serial converter, it combines the previous 4 packets submitted per
device-driver level read into 1 big read, reducing the number of packets / sec
by a factor 4, and it allows to have multiple reads outstanding. This allows
for much better latency tolerance without the pl2303's internal buffer
overflowing (which was happening at 115200 bps, without serial flow control).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Gerd Hoffmann <kraxel@redhat.com>
