By not advertising USB wakeup support (which we don't).
Signed-off-by: Alon Levy <alevy@redhat.com>
Reviewed-by: Marc-André Lureau <mlureau@redhat.com>
Program received signal SIGSEGV, Segmentation fault.
__strcmp_sse42 () at ../sysdeps/x86_64/multiarch/strcmp-sse42.S:164
164 movdqu (%rsi), %xmm2
(gdb) bt
at /home/elmarco/320g/src/qemu/hw/ccid-card-emulated.c:477
at /home/elmarco/320g/src/qemu/hw/ccid-card-emulated.c:503
Signed-off-by: Marc-André Lureau <mlureau@redhat.com>
Reviewed-by: Alon Levy <alevy@redhat.com>
Allows to remove one FIXME. Makes LIBUSB_LOG_LEVEL_WARNING build errors
go away. And starting with that version libusb has a LIBUSBX_API_VERSION
define which allows to easily #ifdef version dependencies should that
need arrive in the future.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Report the supported speeds for device and port in the error message.
Also add the speeds to the tracepoint. And while being at it drop
the redundant error message in usb_desc_attach, usb_device_attach will
report the error anyway.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
With pipelining it is possible to encounter a finished packet when cleaning
the queue due to a halt. This happens when a non stall error happens while
talking to a real device. In this case the queue on the usb-host side will
continue processing packets, and we can have completed packets waiting in
the queue after an error condition packet causing a halt.
There are 2 reasons to discard the completed packets at this point, rather
then trying to writing them back to the guest:
1) The guest expect to be able to cancel and/or change packets after the
packet with the error without doing an unlink, so writing them back may
confuse the guest.
2) Since the queue does not advance when halted, the writing back of these
packets will fail anyways since p->qtdaddr != q->qtdaddr, so the
ehci_verify_qtd call in ehci_writeback_async_complete_packet will fail.
Note that 2) means that then only functional change this patch introduces
is the printing of a warning when this scenario happens.
Note that discarding these packets means that the guest driver and the device
will get out of sync! This is unfortunate, but should not be a problem since
with a non stall error (iow an io-error) the 2 are out of sync already anyways.
Still this patch adds a warning to signal this happening.
Note that sofar this has only been seen with a DVB-T receiver, which gives
of a MPEG-2 stream, which allows for recovering from lost packets, see:
https://bugzilla.redhat.com/show_bug.cgi?id=890320
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reimplement usb-host on top of libusb.
Reasons to do this:
(1) Largely rewritten from scratch, nice opportunity to kill historical
cruft.
(2) Offload usbfs handling to libusb.
(3) Have a single portable code base instead of bsd + linux variants.
(4) Bring usb-host support to any platform supported by libusbx.
For now this goes side-by-side to the existing code. That is only to
simplify regression testing though, at the end of the day I want remove
the old code and support libusb exclusively. Merge early in 1.5 cycle,
remove the old code after 1.5 release or something like this.
Thanks to qdev the old and new code can coexist nicely on linux. Just
use "-device usb-host-linux" to use the old linux driver instead of the
libusb one (which takes over the "usb-host" name).
The bsd driver isn't qdev'ified so it isn't that easy for bsd.
I didn't bother making it runtime switchable, so you have to rebuild
qemu with --disable-libusb to get back the old code.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Is good enougth for unique device addresses and avoids the need for any
state for device addressing. Makes live migration support easier. Also
makes device->slot lookups trivial.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Check for port reset first and skip everything else then.
Add sanity checks for PLS updates.
Add PLC notification when entering PLS_U0 state.
This gets host-initiated port resume going on win8.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
usb-serial has a qdev chardev property, and hw/qdev-properties-system.c
already contains:
static void release_chr(Object *obj, const char *name, void *opaque)
{
DeviceState *dev = DEVICE(obj);
Property *prop = opaque;
CharDriverState **ptr = qdev_get_prop_ptr(dev, prop);
CharDriverState *chr = *ptr;
if (chr) {
qemu_chr_add_handlers(chr, NULL, NULL, NULL, NULL);
qemu_chr_fe_release(chr);
}
}
So doing the qemu_chr_add_handlers(s->cs, NULL, NULL, NULL, NULL); from
the usb handle_destroy function too will lead to it being done twice.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Headers in include/exec/ are for the deepest innards of QEMU,
they should almost never be included directly.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
# By Paolo Bonzini
# Via Paolo Bonzini
* bonzini/hw-dirs: (35 commits)
hw: move private headers to hw/ subdirectories.
MAINTAINERS: update for source code movement
hw: move last file to hw/arm/
hw: move hw/kvm/ to hw/i386/kvm
hw: move ARM CPU cores to hw/cpu/, configure with default-configs/
hw: move other devices to hw/misc/, configure with default-configs/
hw: move NVRAM interfaces to hw/nvram/, configure with default-configs/
hw: move GPIO interfaces to hw/gpio/, configure with default-configs/
hw: move interrupt controllers to hw/intc/, configure with default-configs/
hw: move DMA controllers to hw/dma/, configure with default-configs/
hw: move VFIO and ivshmem to hw/misc/
hw: move PCI bridges to hw/pci-* or hw/ARCH
hw: move SD/MMC devices to hw/sd/, configure with default-configs/
hw: move timer devices to hw/timer/, configure with default-configs/
hw: move ISA bridges and devices to hw/isa/, configure with default-configs/
hw: move char devices to hw/char/, configure via default-configs/
hw: move more files to hw/xen/
hw: move SCSI controllers to hw/scsi/, configure via default-configs/
hw: move SSI controllers to hw/ssi/, configure via default-configs/
hw: move I2C controllers to hw/i2c/, configure via default-configs/
...
Message-id: 1365442249-18259-1-git-send-email-pbonzini@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Many of these should be cleaned up with proper qdev-/QOM-ification.
Right now there are many catch-all headers in include/hw/ARCH depending
on cpu.h, and this makes it necessary to compile these files per-target.
However, fixing this does not belong in these patches.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
# By Gerd Hoffmann (7) and Hans de Goede (3)
# Via Gerd Hoffmann
* kraxel/usb.79:
usb-tablet: Don't claim wakeup capability for USB-2 version
usb: update docs for bus name change
usb-hub: report status changes only once
usb-hub: limit chain length
xhci: zap unused name field
xhci: remove unimplemented printfs
xhci: remove leftover debug printf
xhci: fix numintrs sanity checks
usb-redir: Add flow control support
usb-redir: Fix crash on migration with no client connected
usb-storage takes care to fetch the USB serial number from -drive
options, but it neglected to pass its own 'serial' property to the
scsi-disk it creates. With this patch, the 'serial' qdev property and
the 'serial' option in -drive behave the same and correctly apply the
serial number on both USB and SCSI level.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Our ehci code does not implement wakeup support, so claiming support for
it with usb-tablet in USB-2 mode causes all tablet events to get lost.
http://bugzilla.redhat.com/show_bug.cgi?id=929068
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
If no client is connected on the src side, then we won't receive a
parser during migrate, in this case usbredir_post_load() should be a nop,
rather then to try to derefefence the NULL dev->parser pointer.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Most frontends can't really determine if the guest actually has the frontend
side open. So lets automatically generate fe_open / fe_close as soon as a
frontend becomes ready (as signalled by calling qemu_chr_add_handlers) /
becomes non ready (as signalled by setting all handlers to NULL).
And allow frontends which can actually determine if the guest is listening to
opt-out of this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-5-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Rename the opened variable to be_open to reflect that it contains the
opened state of the backend.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Message-id: 1364292483-16564-2-git-send-email-hdegoede@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Fix the awkward API of mangling the caller specified PCIe type and
just provide an interface to initialize an endpoint device. This
will pick either a regular endpoint or integrated endpoint based on
the bus and return pcie_cap_init to doing exactly what is asked.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
qdev-monitor.c is the only "core qdev" file that is not used in
user-mode emulation, and it does not define anything that is used
by hardware models. Remove it from the hw/ directory and
remove hw/qdev-monitor.h from hw/qdev.h too; this requires
some files to have some new explicitly includes.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This fixes the following compilation error:
hw/usb/hcd-xhci.c:1156:17: error: format ‘%llx’ expects argument of type
‘long long unsigned int’, but argument 4 has type ‘unsigned int’
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Commit 8550a02d12 added a streams
parameter to usb_wakeup and didn't update redirect.c. Fix it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Add streams support to the xhci emulation. No secondary streams yet,
only linear stream arays are supported for now.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch adds support for usb3 streams to the usb subsystem core.
This is just adding a streams field / parameter in a number of places.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Fix the ordering of the endpoint descriptors for superspeed endpoints:
The superspeed companion must come first, possible additional
descriptors for the endpoint after that.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
usb_packet_copy can handle combined packets now,
so it isn't needed to special-case them any more.
Also use the new usb_packet_size() function.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The code handling the "-usbdevice host:..." legacy command line
syntax is moved to the new hw/usb/host-legacy.c file.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Leave the core usb devices (usb hub, tablet, mouse, keyboard)
enabled unconditionally. Make the other ones configurable.
Exceptions:
- bluetooth: not qdevified yet, has a vl.c dependency because
of that, thus disabling isn't as easy as not linking the
object file.
- smardcard: ccid-card-emulated depends on that one *and*
CONFIG_SMARTCARD_NSS. So it isn't a one-liner and comes
as separate patch because of that.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
To support multiqueue nic, this patch separate the nic destructor from
qemu_del_net_client() to a new helper qemu_del_nic() since the mapping bettween
NiCState and NetClientState were not 1:1 in multiqueue. The following patches
would refactor this function to support multiqueue nic.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
To support multiqueue, this patch introduces a helper qemu_get_nic() to get
NICState from a NetClientState. The following patches would refactor this helper
to support multiqueue.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
To support multiqueue, the patch introduce a helper qemu_get_queue()
which is used to get the NetClientState of a device. The following patches would
refactor this helper to support multiqueue.
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Basically the same as usb-storage, but without automatic scsi
device setup. Also features support for up to 16 LUNs.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This reverts commit a1cbfd554e.
Test isn't useless. scsi_req_enqueue() may finish the request (will
actually happen for requests which don't trigger any I/O such as
INQUIRY), then call usb_msd_command_complete() which in turn will
set s->req to NULL after unref'ing it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
84f2d0ea added an argument to function usb_host_info.
The stub function must match the declaration in usb.h.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
This patch change all info call back function to take
additional QDict * parameter, which allow those command
take parameter. Now it is set to NULL at default case.
Signed-off-by: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
scsi_req_new() never returns null, and scsi_req_enqueue() dereferences
the pointer, so checking for null is useless.
Spotted by Coverity.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* kraxel/usb.76:
usb-host: Initialize dev->port the obviously safe way
usb-host: Drop superfluous null test from usb_host_auto_scan()
ehci: Assert state machine is sane w.r.t. EHCIQueue
xhci: nuke transfe5rs on detach
xhci: call xhci_detach_slot on root port detach too
xhci: create xhci_detach_slot helper function
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Coverity worries the strcpy() could overrun the destination. It
can't, because the source always points to usb_host_scan()'s auto
port[], which has the same size. Use pstrcpy() anyway, to hush the
checker.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Coverity points out that port is later passed to usb_host_open(),
which dereferences it. It actually can't be null: it always points to
usb_host_scan()'s auto port[]. Drop the superfluous port == NULL
test.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Coverity worries the EHCIQueue pointer could be null when we pass it
to functions that reference it. The state machine ensures it can't be
null then. Assert that, to hush the checker.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Since 39bffca203 (qdev: register all
types natively through QEMU Object Model), TypeInfo as used in
the common, non-iterative pattern is no longer amended with information
and should therefore be const.
Fix the documented QOM examples:
sed -i 's/static TypeInfo/static const TypeInfo/g' include/qom/object.h
Since frequently the wrong examples are being copied by contributors of
new devices, fix all types in the tree:
sed -i 's/^static TypeInfo/static const TypeInfo/g' */*.c
sed -i 's/^static TypeInfo/static const TypeInfo/g' */*/*.c
This also avoids to piggy-back these changes onto real functional
changes or other refactorings.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Buffered bulk mode is intended for bulk *input* endpoints, where the data is
of a streaming nature (not part of a command-response protocol). These
endpoints' input buffer may overflow if data is not read quickly enough.
So in buffered bulk mode the usb-host takes care of the submitting and
re-submitting of bulk transfers.
Buffered bulk mode is necessary for reliable operation with the bulk in
endpoints of usb to serial convertors. Unfortunatelty buffered bulk input
mode will only work with certain devices, therefor this patch also adds a
usb-id table to enable it for devices which need it, while leaving the
bulk ep handling for other devices unmodified.
Note that the bumping of the required usbredir from 0.5.3 to 0.6 does
not mean that we will now need a newer usbredir release then qemu-1.3,
.pc files reporting 0.5.3 have only ever existed in usbredir builds directly
from git, so qemu-1.3 needs the 0.6 release too.
Changes in v2:
-Split of quirk handling into quirks.c
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
It uses a different capsbase and opregbase than the Xilinx device.
Signed-off-by: Liming Wang <walimisdev@gmail.com>
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Cc: Igor Mitsyanko <i.mitsyanko@samsung.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This allows specific derived models to use different values.
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
SysBus EHCI was introduced in a hurry before 1.3 Soft Freeze.
To use QOM casts in place of DO_UPCAST() / FROM_SYSBUS(), we need an
identifying type. Introduce generic abstract base types for PCI and
SysBus EHCI to allow multiple types to access the shared fields.
While at it, move the state structs being amended with macros to the
header file so that they can be embedded.
The VMSTATE_PCI_DEVICE() macro does not play nice with the QOM
parent_obj naming convention, so defer that cleanup.
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Due to the way devices are addressed with xhci (done by hardware, not
the guest os) there is no packet when invoking the set-address control
request. Create a dummy packet in that case to avoid null pointer
dereferences.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The xhci-hcd may submit bulk transfers > 65535 bytes even when not using
bulk-in pipeling, so usbredir can only be used in combination with an xhci
hcd if the client has the 32 bits bulk length capability.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
To ensure that interrupt receiving is properly stopped when the guest is
no longer interested in an interrupt endpoint.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
usb_ep_find_packet_by_id mistakenly only checks the first packet and if that
is not a match, keeps trying the first packet! This patch fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This leads to cleaner code in usb-hid, and removes up to a 1000 calls / sec to
qemu_get_clock_ns(vm_clock) if idle-time is set to its default value of 0.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
If somehow we've gotten behind a lot, simply skip ahead, like the ehci code
does.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Rather then using the magic 32 value in various places.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ehci_raise_irq(s, USBSTS_PCD), gets applied immediately so there is no need
to call commit_irq after it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
I tried lowering the time between raising an interrupt and rescanning the
async schedule to see if the guest has queued a new transfer before, but
that did not have any positive effect. I now believe the cause for this is
that lowering this time made it more likely to hit the 1 ms interrupt
threshold penalty for the next packet, as described in my
"ehci: Use uframe precision for interrupt threshold checking" commit.
Now that we do interrupt threshold handling with uframe precision, futher
lowering this time from .5 to .25 ms gives an extra 15% improvement in speed
(MB/s) reading from a simple USB-2.0 thumb-drive.
While at it also properly set the int_req_by_async flag for short packet
completions.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Before this patch, the following could happen:
1) Transfer completes, raises interrupt
2) .5 ms later we check if the guest has queued up any new transfers
3) We find and execute a new transfer
4) .2 ms later the new transfer completes
5) We re-run our frame_timer to write back the completion, but less then
1 ms has passed since our last run, so frindex is not changed, so the
interrupt threshold code delays the interrupt
6) 1 ms from the re-run our frame-timer runs again and finally delivers
the interrupt
This leads to unnecessary large delays of interrupts, this code fixes this
by changing frindex to uframe precision and using that for interrupt threshold
control, making the interrupt fire at step 5 for guest which have low interrupt
threshold settings (like Linux).
Note that the guest still sees the frindex move in steps of 8 for migration
compatibility.
This boosts Linux read speed of a simple cheap USB thumb drive by 6 %.
Changes in v2:
-Make the guest see frindex move in steps of 8 by modifying ehci_opreg_read,
rather then using a shadow variable
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ehci_fill_queue assumes that there is a one on one relationship between an ep
and a qh, this patch adds a check to ensure this.
Note I don't expect this to ever trigger, this is just something I noticed
the guest might do while working on other stuff. The only way this check can
trigger is if a guest mixes in and out qtd-s in a single qh for a non
control ep.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Remove the short-circuiting of fetchqtd in fetchqh, so that the
qtd gets properly verified before completing the transaction.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This is not allowed, except for clearing active on cancellation, so don't
warn when the new token does not have its active bit set.
This unifies the cancellation path for modified qtd-s, and prepares
ehci_verify_qtd to be used ad an extra check inside
ehci_writeback_async_complete_packet().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Also drop the warning printf, which was there mainly because this was an
untested code path (as the previous bug fixes to it show), but that no
longer is the case now :)
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Move public headers to include/net, and leave private headers in net/.
Put the virtio headers in include/net/tap.h, removing the multiple copies
that existed. Leave include/net/tap.h as the interface for NICs, and
net/tap_int.h as the interface for OS-specific parts of the tap backend.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Various header files rely on qemu-char.h including qemu-config.h or
main-loop.h, but they really do not need qemu-char.h at all (particularly
interesting is the case of the block layer!). Clean this up, and also
add missing inclusions of qemu-char.h itself.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Our ehci code has is capable of significantly lowering the wakeup rate
for the hcd emulation while the device is idle. It is possible to add
similar code ot the uhci emulation, but that simply is not there atm,
and there is no reason why a (virtual) usb-tablet can not be a USB-2 device.
Making usb-hid devices connect to the emulated ehci controller instead
of the emulated uhci controller on vms which have both lowers the cpuload
for a fully idle vm from 20% to 2-3% (on my laptop).
An alternative implementation to using a property to select the tablet
type, would be simply making it a new device type, ie usb-tablet2, but the
downside of that is that this will require libvirt changes to be available
through libvirt at all, and then management tools changes to become the
default for new vms, where as using a property will automatically get
any pc-1.3 type vms the lower cpuload.
[ kraxel: adapt compat property for post-1.3 merge ]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
tablet compat fixup
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Lower the timer freq if no iso schedule packets complete for 64 frames in
a row.
We can safely do this, without adding latency, because:
1) If there is isoc traffic this will never trigger
2) For async handled interrupt packets (only usb-host), the completion handler
will immediately schedule the frame_timer from a bh
3) All devices using NAK to signal no data for interrupt endpoints now use
wakeup, which will immediately schedule the frame_timer from a bh
The advantage of this is that when we only have interrupt packets in the
periodic schedule, async_stepdown can do its work and significantly lower
the frequency at which the frame_timer runs.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This allows devices to present a different set of descriptors based on
device properties.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
It is tempting to use USB_RET_ASYNC for interrupt packets, rather then the
current NAK + polling approach, but this causes issues for migration, as
an async completed packet will not getting written back to guest memory until
the next poll time, and if a migration happens in between it will get lost!
Make an exception for host devices, because:
1) host-linux actually uses async completion for interrupt endpoints
2) host devices don't migrate anyways
Ideally we would convert host-linux.c to handle (input) interrupt endpoints in
a buffered manner like it does for isoc endpoints, keeping multiple urbs
submitted to ensure the devices timing requirements are met, as well as making
its interrupt ep handling the same as other usb-devices.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This is necessary for proper interaction with the xhci controller, and it
will allow other hcds to lower there frame timer while waiting for interrupt
data.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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>
Guard against re-definition of EHCI_DEBUG. Allows for turning on of debug info
from configure (using --qemu-extra-cflags="-DEHCI_DEBUG=1") rather than source
code hacking.
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Seperate the PCI stuff from the EHCI components. Extracted the PCIDevice
out into a new wrapper struct to make EHCIState non-PCI-specific. Seperated
tho non PCI init component out into a seperate "common" init function.
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Pull the DMAContext for the PCI DMA out at device init time and put it into
the device state. Use dma_memory_read/write() instead of pci specific versions.
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The capabilities register and operational register offsets can vary from one
EHCI implementation to the next. Parameterise accordingly.
Signed-off-by: Peter Crosthwaite <peter.crosthwaite@xilinx.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Factor out the code which checks whenever a usb device is attached
to the port in question. No functional change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Rename the function for xhci_port_* naming scheme, also drop
the xhci parameter as port carries a pointer to xhci anyway.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add {get,set}_field macros (simliar to ehci) to read and update
some bits of a word. Put them into use for updating pls (port
link state) values. Also add a enum for pls values.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
For secondary interrupters this is explicitly allowed in the specs.
For the primary interrupter behavior is undefined, lets be friendly
and allow disabling too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Not updating the endpoint context in case the state didn't change is
wrong. Other context fields might have changed, for example the
dequeue pointer in response to a CR_SET_TR_DEQUEUE command.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This avoids the need to repeatedly lookup the device, and ep.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
All callers of uhci_async_cancel() call uhci_async_unlink() first, so
lets move the unlink call to uhci_async_cancel()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
No devices ever return async for isoc endpoints and the core
already enforces this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ehci was already testing for this, and we depend in various places
on no devices doing this, so lets move the check for this to the
usb core.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
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: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
For ctrl endpoints Windows (atleast Win7) creates circular td lists, so far
these were not a problem because we would stop filling the queue if altnext
was set. Since further patches in this patchset remove the altnext check this
does become a problem and we need detection for going in circles.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Often the guest will queue up new packets in response to a packet, in the
async schedule with its IOC flag set, completing. By speeding up the
frame-timer, we notice these new packets earlier. This increases the
speed (MB/s) of a Linux guest reading from a USB mass storage device by a
factor of 1.15 on top of the "Improve latency of interrupt delivery"
speed-ups, both with and without input pipelining enabled.
I've not tested the speed-up of this patch without the
"Improve latency of interrupt delivery" patch.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
While doing various performance tests of reading from USB mass storage devices
I noticed the following::
1) When an async handled packet completes, we don't immediately report an
interrupt to the guest, instead we wait for the frame-timer to run and
report it from there
2) If 1) has been fixed and an async handled packet takes a while to complete,
then async_stepdown will become a high value, which means that there
will be a large latency before any new packets queued by the guest in
response to the interrupt get seen
1) was done deliberately as part of commit f0ad01f92:
http://www.kraxel.org/cgit/qemu/commit/?h=usb.57&id=f0ad01f92ca02eee7cadbfd225c5de753ebd5fce
Since setting the interrupt immediately on async packet completion was causing
issues with Linux guests, I believe this recently fixed Linux bug explains
why this is happening:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=361aabf395e4a23cf554cf4ec0c0c6963b8beb01
Note that we can *not* count on this fix being present in all Linux guests!
I was hoping that the recently added support for Interrupt Threshold Control
would fix the issues with Linux guests, but adding a simple ehci_commit_irq()
call to ehci_async_bh() still caused problems with Linux guests.
The problem is, that when doing ehci_commit_irq() from ehci_async_bh(),
the "old" frindex value is used to calculate usbsts_frindex, and when
the frame-timer then runs possibly very shortly after ehci_async_bh(),
it increases the frame-timer, and thus any interrupts raised from that
frame-timer run, will also get reported to the guest immediately, rather
then being delayed to the next frame-timer run.
Luckily the solution for this is simple, this means that we need to
increase frindex before calling ehci_commit_irq() from ehci_async_bh(),
which in the end boils down to simple calling ehci_frame_timer() instead
of ehci_async_bh() from the bh.
This may seem like it causes a lot of extra work to be done, but this
is not true. Any work done from the frame-timer processing the periodic
schedule is work which then does not need to be done the next time the
frame timer runs, also the frame-timer will re-arm itself at (possibly)
a later time then it was armed for saving a vmexit at that time.
As an additional advantage moving to simply calling the frame-timer also
fixes 2) as the packet completion will set async_stepdown to 0, and the
re-arming of the timer with an async_stepdown of 0 ensures that any
newly queued up packets get seen in a reasonable amount of time.
This improves the speed (MB/s) of a Linux guest reading from a USB mass
storage device by a factor of 1.5 - 1.7 with input pipelining disabled,
and by a factor of 1.8 with input pipelining enabled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
According to 4.15.1.2 an interrupt must be raised when a short packet
is received. If we don't do this it may take a significant time for
the guest to notice a short trasnfer has completed, since only the last td
will have its IOC flag set, and a short transfer may complete in an earlier
packet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This field is used in some places to track the tbytes field of the token, but
in other places the field is used directly, use it directly everywhere for
consistency.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Rather then having a special check to start queuing after the first packet,
and then another check for the other packets in uhci_fill_queue(), simply
check the previous packet beforehand in uhci_fill_queue()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Packets with an invalid pid, or which were cancelled have
usb_packet_map() called on them on init, but not usb_packet_unmap()
before being freed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
target_phys_addr_t is unwieldly, violates the C standard (_t suffixes are
reserved) and its purpose doesn't match the name (most target_phys_addr_t
addresses are not target specific). Replace it with a finger-friendly,
standards conformant hwaddr.
Outstanding patchsets can be fixed up with the command
git rebase -i --exec 'find -name "*.[ch]"
| xargs s/target_phys_addr_t/hwaddr/g' origin
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
According to the spec we must raise an interrupt when one is requested
even for non active tds.
Linux depends on this, for bulk transfers it runs an inactivity timer
to work around a bug in early uhci revisions, when we take longer then
200 ms to process a packet, this timer goes of, and as part of the
handling Linux then unlinks the qh, and relinks it after the frindex
has increased by atleast 1, the problem is Linux only checks for the
frindex increases on an interrupt, and we don't send that, causing
the qh to go inactive for more then 32 frames, at which point we
consider the packet cancelled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Instead simple disconnect the device like host redirection does on
migration.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* 'trivial-patches' of git://github.com/stefanha/qemu:
versatilepb: Use symbolic indices for ARM PIC
qdev: kill bogus comment
qemu-barrier: Fix compiler version check for future gcc versions
hw: Add missing 'static' attribute for QEMUMachine
cleanup useless return sentence
qemu-sockets: Fix compiler warning (regression for MinGW)
vnc: Fix spelling (hellmen -> hellman) in comment
slirp: Fix spelling in comment (enought -> enough, insure -> ensure)
tcg/arm: Use tcg_out_mov_reg rather than inline equivalent code
cpu: Add missing 'static' attribute to qemu_global_mutex
configure: Support empty target list (--target-list=)
hw: Fix return value check for bdrv_read, bdrv_write
The entries for libhw* are no longer needed in .gitignore.
There is also no longer a difference between common-obj-y and
hw-obj-y, so one of those two macros is sufficient.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch cleans up return sentences in the end of void functions.
Reported-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@gmail.com>
With the IOMMU infrastructure introduced before 1.2, we need to use
dma_memory_map() to obtain a qemu pointer to memory from an IO bus address.
However, dma_memory_map() alters the given length to reflect the length
over which the used DMA translation is valid - which could be either more
or less than the requested length.
usb_packet_map() does not correctly handle these cases, simply failing if
dma_memory_map() alters the requested length. If dma_memory_map()
increased the length, we just need to use the requested length for the
qemu_iovec_add(). However, if it decreased the length, it means that a
single DMA translation is not valid for the whole sglist element, and so
we need to loop, splitting it up into multiple iovec entries for each
piece with a DMA translation (in practice >2 pieces is unlikely).
This patch implements the correct behaviour
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
There are several issues with our handling of the MULT epcap field
of interrupt qhs, which this patch fixes.
1) When we don't execute a transaction because of the transaction counter
being 0, p->async stays EHCI_ASYNC_NONE, and the next time we process the
same qtd we hit an assert in ehci_state_fetchqtd because of this. Even though
I believe that this is caused by 3 below, this patch still removes the assert,
as that can still happen without 3, when multiple packets are queued for the
same interrupt ep.
2) We only *check* the transaction counter from ehci_state_execute, any
packets queued up by fill_queue bypass this check. This is fixed by not calling
fill_queue for interrupt packets.
3) Some versions of Windows set the MULT field of the qh to 0, which is a
clear violation of the EHCI spec, but still they do it. This means that we
will never execute a qtd for these, making interrupt ep-s on USB-2 devices
not work, and after recent changes, triggering 1).
So far we've stored the transaction counter in our copy of the mult field,
but with this beginnig at 0 already when dealing with these version of windows
this won't work. So this patch adds a transact_ctr field to our qh struct,
and sets this to the MULT field value on fetchqh. When the MULT field value
is 0, we set it to 4. Assuming that windows gets way with setting it to 0,
by the actual hardware going horizontal on a 1 -> 0 transition, which will
give it 4 transactions (MULT goes from 0 - 3).
Note that we cannot stop on detecting the 1 -> 0 transition, as our decrement
of the transaction counter, and checking for it are done in 2 different places.
Reported-by: Shawn Starr <shawn.starr@rogers.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Set maxports to 15. This is what the usb3 route string can handle.
Set maxslots to 64. This is more than the number of root ports we
can have, but with additional hubs you can end up with more devices.
Set maxintrs (aka msi vectors) to 16. Should be enougth, especially
considering that vectors are a limited ressource. Linux guests use
only three at the moment.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* 'usb.65' of git://git.kraxel.org/qemu:
uhci: Don't queue up packets after one with the SPD flag set
usb-redir: Revert usb-redir part of commit 93bfef4c
usb-redir: Add chardev open / close debug logging
usb-redir: Add support for migration
usb-redir: Store max_packet_size in endp_data
usb-redir: Add an already_in_flight packet-id queue
usb-redir: Change cancelled packet code into a generic packet-id queue
ehci: Walk async schedule before and after migration
ehci: Don't set seen to 0 when removing unseen queue-heads
configure: usbredir fixes
ehci: Don't process too much frames in 1 timer tick (v2)
ehci: Fix interrupts stopping when Interrupt Threshold Control is 8
ehci: switch to new-style memory ops
usb-host: allow emulated (non-async) control requests without USBPacket
The USB network interface has a single buffer which the guest reads
from. This patch prevents multiple calls to usbnet_receive() from
clobbering the input buffer. Instead we queue packets until buffer
space becomes available again.
This is inspired by virtio-net and e1000 rxbuf handling.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
The USB network interface has two code paths depending on whether or not
RNDIS mode is enabled. Refactor usbnet_receive() so that there is a
common path throughout the function instead of duplicating everything
across if (is_rndis(s)) ... else ... code paths.
Clean up coding style and 80 character line wrap along the way.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Don't queue up packets after a packet with the SPD (short packet detect)
flag set. Since we won't know if the packet will actually be short until it
has completed, and if it is short we should stop the queue.
This fixes a miniature photoframe emulating a USB cdrom with the windows
software for it not working.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commit 93bfef4c6e makes qemu-devices
which report the qemu version string to the guest in some way use a
qemu_get_version function which reports a machine-specific version string.
However usb-redir does not expose the qemu version to the guest, only to
the usbredir-host as part of the initial handshake. This can then be logged
on the usbredir-host side for debugging purposes and is otherwise completely
unused! For debugging purposes it is important to have the real qemu version
in there, rather then the machine-specific version.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
So that we've a place to migrate it to / from to allow restoring it after
migration.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
After a live migration, the usb-hcd will re-queue all packets by
walking over the schedule in the guest memory again, but requests which
were encountered on the migration source before will already be in flight,
so these should *not* be re-send to the usbredir-host.
This patch adds an already in flight packet ud queue, which will be filled by
the source before migration and then moved over to the migration dest, any
async handled packets are then checked against this queue to avoid sending
the same packet to the usbredir-host twice.
Signed-off-by: Hans de Goede <hdegoede@redhat,com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When removing unseen queue-heads from the async queue list, we should not
set the seen flag to 0, as this may cause them to be removed by
ehci_queues_rip_unused() during the next call to ehci_advance_async_state()
if the timer is late or running at a low frequency.
Note:
1) This *may* have caused the instant unlink / relinks described in commit
9bc3a3a216
2) Rather then putting more if-s inside ehci_queues_rip_unused, this patch
instead introduces a new ehci_queues_rip_unseen function.
3) This patch also makes it save to call ehci_queues_rip_unseen() multiple
times, which gets used in the folluw up patch titled:
"ehci: Walk async schedule before and after migration"
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The Linux ehci isoc scheduling code fills the entire schedule ahead of
time minus 80 frames. If we make a large jump in where we are in the
schedule, ie 40 frames, then the scheduler all of a sudden will only have
40 frames left to work in, causing it to fail packet submissions
with error -27 (-EFBIG).
Changes in v2:
-Don't hardcode a maximum number of frames to process in one tick, instead:
-Process a minimum number of frames to ensure we do eventually catch up
-Stop (after the minimum number) when the guest has requested an irq
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
If Interrupt Threshold Control is 8 or a multiple of 8, then
s->usbsts_frindex can become exactly 0x4000, at which point
(s->usbsts_frindex > s->frindex) will never become true, as
s->usbsts_frindex will not be lowered / reset in this case.
This patch fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Also register different memory regions for capabilities,
operational registers and port status registers. Create
separate tracepoints for operational regs and port status
regs. Ditch a bunch of sanity checks because the memory
core will do this for us now.
Offloading the byte, word and dword access handling to the
memory core also has the side effect of fixing ehci register
access on bigendian hosts.
Cc: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
xhci needs this for USB_REQ_SET_ADDRESS due to the way
usb addressing is handled by the xhci hardware.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
... and register subregions instead, so we offload the dispatching
to the the memory subsystem which is designed to handle it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Move all state belonging to the (single) interrupter into a separate
struct. First step in adding support for multiple interrupters.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Split xhci_irq_update into a function which handles intx updates
(including lowering the irq line once the guests acks the interrupt)
and one which is used for raising an irq only.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Drop custom write_config function which isn't needed any more.
Make the msi property a bit property so it accepts 'on' & 'off'.
Enable MSI by default.
TODO: add compat property to disable on old machine types.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add support for building superspeed endpoint companion descriptors,
create them for superspeed usb devices.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This patch changes the way xhci ports are linked to USBPorts. The fixed
1:1 relationship between xhci ports and USBPorts is gone. Now each
USBPort represents a physical plug which has usually two xhci ports
assigned: one usb2 and ond usb3 port. usb devices show up at one or the
other, depending on whenever they support superspeed or not.
This patch also makes the number of usb2 and usb3 ports runtime
configurable by adding 'p2' and 'p3' properties. It is allowed to
have different numbers of usb2 and usb3 ports. Specifying p2=4,p3=2
will give you an xhci adapter which supports all speeds on physical
ports 1+2 and usb2 only on ports 3+4.
Change the register layout to be a bit more sparse and also not depend
on the number of ports. Useful when for making the number of ports
runtime-configurable.
This patch splits the xhci_xfer_data function into three.
The xhci_xfer_data function used to do does two things:
(1) copy transfer data between guest memory and a temporary buffer.
(2) report transfer results to the guest using events.
Now we three functions to handle this:
(1) xhci_xfer_map creates a scatter list for the transfer and
uses that (instead of the temporary buffer) to build a
USBPacket.
(2) xhci_xfer_unmap undoes the mapping.
(3) xhci_xfer_report sends out events.
The patch also fixes reporting of transaction errors which must be
reported unconditinally, not only in case the guest asks for it
using the ISP flag.
[ v2: fix warning ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
original xhci code (the one which used libusb directly) used to use
'background transfers' for iso streams. In upstream qemu the iso
stream buffering is handled by usb-host & usb-redir, so we will
never ever need this. It has been left in as reference, but is dead
code anyway. Rip it out.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Windows users need to know that they have to use the Baum driver to make
the qemu braille device work.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In order for redirection to work properly when redirecting to an emulated
XHCI controller, the usb-redir-host must support both
usb_redir_cap_ep_info_max_packet_size and usb_redir_cap_64bits_ids,
reject any devices redirected to an XHCI controller when these are not
supported.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This is needed for usb-redir to work properly with the xhci emulation.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This gives us support for 64 bit ids which is needed for using XHCI with
the new hcd generated ids.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Babble is the appropriate error in this case (rather then signalling a stall).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This is a preparation patch for completely getting rid of the async-packet
struct in usb-redir, instead relying on the (new) per ep queues in the
qemu usb core.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The shadow copy only serves as an extra check (besides the packet-id) to
ensure the packet we get back is a reply to the packet we think it is.
This check has never triggered in all the time usb-redir is in use now,
and since the verified data in the returned packet-header is not used
otherwise, removing the check does not open any possibilities for the
usbredirhost to confuse us.
This is a preparation patch for completely getting rid of the async-packet
struct in usb-redir, instead relying on the (new) per ep queues in the
qemu usb core.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This is a preparation patch for completely getting rid of the async-packet
struct in usb-redir, instead relying on the (new) per ep queues in the
qemu usb core.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
There is no need for this, and doing so means that a backend trying to
write immediately after an open event will see qemu_chr_be_can_write
returning 0, which not all backends handle well as there is no wakeup
mechanism to detect when the frontend does become writable.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
USB_RET_NAK is not a valid response for async handled packets (and will
trigger an assert as such).
Also drop the warning when receiving a status of cancelled for packets not
cancelled by qemu itself, this can happen when a device gets unredirected
by the usbredir-host while transfers are pending.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Since my previous comment said "Should never happen", I tried changing the
next line to an assert(0), which did not go well, which as the new comments
explains is logical if you think about it for a moment.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
USB_RET_PROCERR can be triggered by the guest (by for example requesting more
then BUFFSIZE bytes), so don't assert on it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Currently each time we try to execute a NAK-ed packet we redo
ehci_init_transfer, and usb_packet_map, re-allocing (without freeing) the
sg list every time.
This patch fixes this, it does this by introducing another async state, so
that we also properly cleanup a NAK-ed packet on cancel.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
make qemu_queue_{cancel,reset} return the number of packets released,
so the caller can figure whenever there have been active packets even
though there shouldn't have been any. Add tracepoint to log this.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reported packets which have completed before being cancelled as such to the
host. Note that the new code path this patch adds is untested since it I've
been unable to actually trigger the race which needs this code path.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
-combine the qh check with the check for devaddr changes
-also ensure that p gets set to NULL when the queue gets cancelled on
devaddr change, which was not done properly before this patch
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This reverts commit 9bc3a3a216, which got
added to fix an issue where the real, underlying cause was not stopping
the ep queue on an error.
Now that the underlying cause is fixed by the "usb: Halt ep queue and
cancel pending packets on a packet error" patch, the "don't flush" fix
is no longer needed.
Not only is it not needed, it causes us to see cancellations (unlinks)
done by the Linux EHCI driver too late, which in combination with the new
usb-core packet-id generation where qtd addresses are used as ids, causes
duplicate ids for in flight packets.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This can happen with usb-redir live-migration when the packet gets re-queued
after the migration and the original queuing from the migration source side
has already finished.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This way the hcd can re-use the same packet to retry without needing
to re-init it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
If an (emulated) usb-device tries to write more data to a packet then
its iov len, this will trigger an assert in usb_packet_copy(), and if
a driver somehow circumvents that check and writes more data to the
iov then there is space, we have a much bigger problem then not correctly
reporting babble to the guest.
In practice babble will only happen with (real) redirected devices, and there
both the usb-host os and the qemu usb-device code already check for it.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Kick next scsi transfer from request release callback instead of command
completion callback, otherwise we might get stuck in case scsi_req_unref()
doesn't release the request instantly due to someone else holding a
reference too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
One of the recent changes (likely the addition of queuing support) has broken
interrupt endpoints, this patch fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
ehci_state_executing does not need to check for p->usb_status == USB_RET_ASYNC
or USB_RET_PROCERR, since ehci_execute_complete already does a similar check
and will trigger an assert if either value is encountered.
USB_RET_ASYNC should never be the packet status when execute_complete runs
for obvious reasons, and USB_RET_PROCERR is only used by ehci_state_execute /
ehci_execute not by ehci_state_executing / ehci_execute_complete.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ehci_qh_do_overlay() already calls ehci_flush_qh() before it returns, calling
it twice is useless.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
After the "ehci: Print a warning when a queue unexpectedly contains packets
on cancel" commit. Under certain reproducable conditions I was getting the
following message: "EHCI: Warning queue not empty on queue reset".
After aprox. 8 hours of debugging I've finally found the cause. The Linux EHCI
driver has an IAAD watchdog, to work around certain EHCI hardware sometimes
not acknowledging the doorbell at all. This watchdog has a timeout of 10 ms,
which is less then the time between 2 runs through the async schedule when
async_stepdown is at its highest value.
Thus the watchdog can trigger, after which Linux clears the IAAD bit and
re-uses the QH. IOW we were not properly detecting the unlink of the qh, due
to us missing (ignoring for more then 10 ms) the IAAD command, which triggered
the warning.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This patch adds IDs to usb packets. Those IDs are (a) supposed to be
unique for the lifecycle of a packet (from packet setup until the packet
is either completed or canceled) and (b) stable across migration.
uhci, ohci, ehci and xhci use the guest physical address of the transfer
descriptor for this.
musb needs a different approach because there is no transfer descriptor.
But musb also doesn't support pipelining, so we have never more than one
packet per endpoint in flight. So we go create an ID based on endpoint
and device address.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
For controllers which queue up more then 1 packet at a time, we must halt the
ep queue, and inside the controller code cancel all pending packets on an
error.
There are multiple reasons for this:
1) Guests expect the controllers to halt ep queues on error, so that they
get the opportunity to cancel transfers which the scheduled after the failing
one, before processing continues
2) Not cancelling queued up packets after a failed transfer also messes up
the controller state machine, in the case of EHCI causing the following
assert to trigger: "assert(p->qtdaddr == q->qtdaddr)" at hcd-ehci.c:2075
3) For bulk endpoints with pipelining enabled (redirection to a real USB
device), we must cancel all the transfers after this a failed one so that:
a) If they've completed already, they are not processed further causing more
stalls to be reported, originating from the same failed transfer
b) If still in flight, they are cancelled before the guest does
a clear stall, otherwise the guest and device can loose sync!
Note this patch only touches the ehci and uhci controller changes, since AFAIK
no other controllers actually queue up multiple transfer. If I'm wrong on this
other controllers need to be updated too!
Also note that this patch was heavily tested with the ehci code, where I had
a reproducer for a device causing a transfer to fail. The uhci code is not
tested with actually failing transfers and could do with a thorough review!
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This fixes linux guests started without any USB devices not seeing newly
plugged devices until "lsusb" is done inside the guest.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
First, not all interrupts are subject to Interrupt Threshold Control,
some of them must be delivered without delay.
Second, Interrupt Threshold Control state must be part of vmstate,
otherwise we might loose IRQs on migration.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Pick other product id to fix clash with audio.
Current usage list (after applying this patch):
46f4:0001 -- usb-storage
46f4:0002 -- usb-audio
46f4:0003 -- usb-uas
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Need to clear p->result after copying setup data using usb_packet_copy()
because we'll reuse the USBPacket for the data transfer.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commit 5931065907 is incomplete,
we'll arrive in the scsi command complete callback in CSW state
and must handle that case correctly.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Another step in moving the vlan feature out of net core. Users only
deal with NetClientState and therefore qemu_del_vlan_client() should be
named qemu_del_net_client().
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The vlan feature is no longer part of net core. Rename VLANClientState
to NetClientState because net clients are not explicitly associated with
a vlan at all, instead they have a peer net client to which they are
connected.
This patch is a mechanical search-and-replace except for a few
whitespace fixups where changing VLANClientState to NetClientState
misaligned whitespace.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
* kwolf/for-anthony: (41 commits)
fdc-test: Clean up a bit
fdc-test: introduce test_relative_seek
fdc: fix relative seek
qemu-iotests: Valgrind support
coroutine-ucontext: Help valgrind understand coroutines
qemu-io: Fix memory leaks
hw/block-common: Factor out fall back to legacy -drive cyls=...
blockdev: Don't limit DriveInfo serial to 20 characters
hw/block-common: Factor out fall back to legacy -drive serial=...
hw/block-common: Move BlockConf & friends from block.h
Relax IDE CHS limits from 16383,16,63 to 65535,16,255
blockdev: Drop redundant CHS validation for if=ide
hd-geometry: Compute BIOS CHS translation in one place
qtest: Test we don't put hard disk info into CMOS for a CD-ROM
ide pc: Put hard disk info into CMOS only for hard disks
block: Geometry and translation hints are now useless, purge them
qtest: Cover qdev property for BIOS CHS translation
ide: qdev property for BIOS CHS translation
qdev: New property type chs-translation
qdev: Collect private helpers in one place
...
Move down the expire time calculation down in the frame timer, to the
point where the timer is actually reloaded. This way we'll notice any
async_stepdown changes (especially resetting to 0 due to usb activity).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
With the async schedule being kicked from other places than the frame
timer (commit 0f588df8b3) it may happen
that we call ehci_commit_interrupt() more than once per frame.
Move the call from the async schedule handler to the frame timer to
restore old irq behavior, which is more correct. Fixes regressions
with some linux kernel versions.
TODO: implement full Interrupt Threshold Control support.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
$subject says all: when loading old (v1) vmstate which doesn't contain
expire_time initialize it with a reasonable default (current time).
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
$subject says all. First cut.
It's a pure UAS (usb attached scsi) emulation, without BOT (bulk-only
transport) compatibility. If your guest can't handle it use usb-storage
instead.
The emulation works like any other scsi hba emulation (eps, lsi, virtio,
megasas, ...). It provides just the HBA where you can attach scsi
devices as you like using '-device'. A single scsi target with up to
256 luns is supported.
For now only usb 2.0 transport is supported. This will change in the
future though as I plan to use this as playground when codeing up &
testing usb 3.0 transport and streams support in the qemu usb core and
the xhci emulation.
No migration support yet. I'm planning to add usb 3.0 support first as
this probably requires saving additional state.
Special thanks go to Paolo for bringing the qemu scsi emulation into
shape, so this can be added nicely without having to touch a single line
of scsi code.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* mjt/mjt-iov2:
rewrite iov_send_recv() and move it to iov.c
cleanup qemu_co_sendv(), qemu_co_recvv() and friends
export iov_send_recv() and use it in iov_send() and iov_recv()
rename qemu_sendv to iov_send, change proto and move declarations to iov.h
change qemu_iovec_to_buf() to match other to,from_buf functions
consolidate qemu_iovec_copy() and qemu_iovec_concat() and make them consistent
allow qemu_iovec_from_buffer() to specify offset from which to start copying
consolidate qemu_iovec_memset{,_skip}() into single function and use existing iov_memset()
rewrite iov_* functions
change iov_* function prototypes to be more appropriate
virtio-serial-bus: use correct lengths in control_out() message
Conflicts:
tests/Makefile
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Replace iso transfer fprintf's with trace points. Also rename existing
tracepoints so they all match usb_host_iso_*.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Create a new usb_ep_reset() function to reset endpoint state, without
re-initialiting the queues, so we don't unlink in-flight packets just
because usb-host has to re-parse the descriptor tables.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commit 0f588df8b3, added code
to ehci_wakeup to kick the async schedule on wakeup, but the else
was positioned wrong making it trigger for devices which are routed
to the companion rather then to the ehci controller itself.
This patch fixes this. Note that the "programming style" with using the
return at the end of the companion block matches how the companion case
is handled in the other ports ops, and is done this way for consistency.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
hcd-ehci.c is missing an usb_packet_init() call for the ipacket UsbPacket
it uses for isoc transfers, triggering an assert (taking the entire vm down)
in usb_packet_setup as soon as any isoc transfers are done by a high speed
USB device.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commit 4be23939ab makes ehci instantly
zap any unlinked queue heads when the guest rings the doorbell.
While hacking up uas support this turned out to be a problem. The linux
kernel can unlink and instantly relink the very same queue head, thereby
killing any async packets in flight. That alone isn't an issue yet, the
packet will canceled and resubmitted and everything is fine. We'll run
into trouble though in case the async packet is completed already, so we
can't cancel it any more. The transaction is simply lost then.
usb_ehci_qh_ptrs q (nil) - QH @ 39c4f000: next 39c4f122 qtds 00000000,00000001,39c50000
usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0
usb_ehci_qh_ptrs q 0x7f95feba90a0 - QH @ 39c4f000: next 39c4f122 qtds 00000000,00000001,39c50000
usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0
usb_ehci_qh_ptrs q 0x7f95fe515210 - QH @ 39c4f120: next 39c4f0c2 qtds 29dbce40,29dbc4e0,00000009
usb_ehci_qh_fields QH @ 39c4f120 - rl 4, mplen 512, eps 2, ep 1, dev 2
usb_ehci_packet_action q 0x7f95fe515210 p 0x7f95fdec32a0: alloc
usb_packet_state_change bus 0, port 2, ep 1, packet 0x7f95fdec32e0, state undef -> setup
usb_ehci_packet_action q 0x7f95fe515210 p 0x7f95fdec32a0: process
usb_uas_command dev 2, tag 0x2, lun 0, lun64 00000000-00000000
scsi_req_parsed target 0 lun 0 tag 2 command 42 dir 2 length 16384
scsi_req_parsed_lba target 0 lun 0 tag 2 command 42 lba 5933312
scsi_req_alloc target 0 lun 0 tag 2
scsi_req_continue target 0 lun 0 tag 2
scsi_req_data target 0 lun 0 tag 2 len 16384
usb_uas_scsi_data dev 2, tag 0x2, bytes 16384
usb_uas_write_ready dev 2, tag 0x2
usb_packet_state_change bus 0, port 2, ep 1, packet 0x7f95fdec32e0, state setup -> complete
usb_ehci_packet_action q 0x7f95fe515210 p 0x7f95fdec32a0: free
usb_ehci_qh_ptrs q 0x7f95fdec3210 - QH @ 39c4f0c0: next 39c4f002 qtds 29dbce40,00000001,00000009
usb_ehci_qh_fields QH @ 39c4f0c0 - rl 4, mplen 512, eps 2, ep 2, dev 2
usb_ehci_queue_action q 0x7f95fe5152a0: free
usb_packet_state_change bus 0, port 2, ep 2, packet 0x7f95feba9170, state async -> complete
^^^ async packets completes.
usb_ehci_packet_action q 0x7f95fdec3210 p 0x7f95feba9130: wakeup
usb_ehci_qh_ptrs q (nil) - QH @ 39c4f000: next 39c4f122 qtds 00000000,00000001,39c50000
usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0
usb_ehci_qh_ptrs q 0x7f95feba90a0 - QH @ 39c4f000: next 39c4f122 qtds 00000000,00000001,39c50000
usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0
usb_ehci_qh_ptrs q 0x7f95fe515210 - QH @ 39c4f120: next 39c4f002 qtds 29dbc4e0,29dbc8a0,00000009
usb_ehci_qh_fields QH @ 39c4f120 - rl 4, mplen 512, eps 2, ep 1, dev 2
usb_ehci_queue_action q 0x7f95fdec3210: free
usb_ehci_packet_action q 0x7f95fdec3210 p 0x7f95feba9130: free
^^^ endpoint #2 queue head removed from schedule, doorbell makes ehci zap the queue,
the (completed) usb packet is freed too and gets lost.
usb_ehci_qh_ptrs q (nil) - QH @ 39c4f000: next 39c4f0c2 qtds 00000000,00000001,39c50000
usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0
usb_ehci_qh_ptrs q 0x7f95feba90a0 - QH @ 39c4f000: next 39c4f0c2 qtds 00000000,00000001,39c50000
usb_ehci_qh_fields QH @ 39c4f000 - rl 0, mplen 0, eps 0, ep 0, dev 0
usb_ehci_queue_action q 0x7f9600dff570: alloc
usb_ehci_qh_ptrs q 0x7f9600dff570 - QH @ 39c4f0c0: next 39c4f122 qtds 29dbce40,00000001,00000009
usb_ehci_qh_fields QH @ 39c4f0c0 - rl 4, mplen 512, eps 2, ep 2, dev 2
usb_ehci_packet_action q 0x7f9600dff570 p 0x7f95feba9130: alloc
usb_packet_state_change bus 0, port 2, ep 2, packet 0x7f95feba9170, state undef -> setup
usb_ehci_packet_action q 0x7f9600dff570 p 0x7f95feba9130: process
usb_packet_state_change bus 0, port 2, ep 2, packet 0x7f95feba9170, state setup -> async
usb_ehci_packet_action q 0x7f9600dff570 p 0x7f95feba9130: async
^^^ linux kernel relinked the queue head, ehci creates a new usb packet,
but we should have delivered the completed one instead.
usb_ehci_qh_ptrs q 0x7f95fe515210 - QH @ 39c4f120: next 39c4f002 qtds 29dbc4e0,29dbc8a0,00000009
usb_ehci_qh_fields QH @ 39c4f120 - rl 4, mplen 512, eps 2, ep 1, dev 2
So instead of instantly zapping the queue we'll set a flag that the
queue needs revalidation in case we'll see it again in the schedule.
ehci then checks that the queue head fields addressing / describing the
endpoint and the qtd pointer match the cached content before reusing it.
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Only write back the dwords the hc is supposed to update. Should not
make a difference in theory as the guest must not touch the td while
it is active to avoid races. But it is still more correct.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Not a single driver has any possibility of failure on their
exit function, let's keep it that way.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The USB UHCI and EHCI drivers were converted some time ago to use the
pci_dma_*() helper functions. However, this conversion was not complete
because in some places both these drivers do DMA via the usb_packet_map()
function in usb-libhw.c. That function directly used
cpu_physical_memory_map().
Now that the sglist code uses DMA wrappers properly, we can convert the
functions in usb-libhw.c, thus conpleting the conversion of UHCI and EHCI
to use the DMA wrappers.
Note that usb_packet_map() invokes dma_memory_map() with a NULL invalidate
callback function. When IOMMU support is added, this will mean that
usb_packet_map() and the corresponding usb_packet_unmap() must be called in
close proximity without dropping the qemu device lock - otherwise the guest
might invalidate IOMMU mappings while they are still in use by the device
code.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The OHCI device emulation can provide both PCI and SysBus OHCI
implementations. Because of this, it was not previously converted to
use the PCI DMA helper functions.
This patch converts it to use the new universal DMA helper functions.
In the PCI case, it obtains its DMAContext from pci_dma_context(), in
the SysBus case, it uses NULL - i.e. assumes for now that there will
be no IOMMU translation for a SysBus OHCI.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
We update the QTAILQ in the loop, thus we must use the SAFE version
to make sure we don't touch the queue struct after freeing it.
https://bugzilla.novell.com/show_bug.cgi?id=766310
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
QEMU exposes its version to the guest's hardware and in some cases that is wrong
(e.g. Windows prints messages about driver updates when you switch
the QEMU version).
There is a new field now on the struct QEmuMachine, hw_version, which may
contain the version that the specific machine should report. If that field is
set, then that machine will report that version to the guest.
Signed-off-by: Crístian Viana <vianac@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This is far less interesting than it sounds. We simply add an Object to each
BusState and then register the types appropriately. Most of the interesting
refactoring will follow in the next patches.
Since we're changing fundamental type names (BusInfo -> BusClass), it all needs
to convert at once. Fortunately, not a lot of code is affected.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[AF: Made all new bus TypeInfos static const.]
[AF: Made qbus_free() call object_delete(), required {qom,glib}_allocated]
Signed-off-by: Andreas Färber <afaerber@suse.de>
This makes it easier to remove it from BusInfo.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[AF: Drop now unnecessary NULL initialization in scsibus_get_dev_path()]
Signed-off-by: Andreas Färber <afaerber@suse.de>
In qdev, each bus in practice identified an abstract superclass, but
this was mostly hidden. In QOM, instead, these abstract classes are
explicit so we can move bus properties there.
All bus property walks are removed, and all device property walks
are changed to look along the class hierarchy instead.
We would have duplicates if class A defines some properties and its
subclass B does not define any, because class_b->props will be
left equal to class_a->props.
The solution here is to reintroduce the class_base_init TypeInfo
callback, that was present in one of the early QOM versions but
removed (on my request...) before committing.
This breaks global bus properties, an obscure feature when used
with the command-line which is actually useful and used when used by
backwards-compatible machine types. So this patch also adjusts the
global bus properties in hw/pc_piix.c to refer to the abstract class.
Globals and other properties must be modified in the same patch to
avoid complications related to initialization ordering.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Simple code movement in order to simplify future refactoring.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reorder arguments to be more natural, readable and
consistent with other iov_* functions, and change
argument names, from:
iov_from_buf(iov, iov_cnt, buf, iov_off, size)
to
iov_from_buf(iov, iov_cnt, offset, buf, bytes)
The result becomes natural English:
copy data to this `iov' vector with `iov_cnt'
elements starting at byte offset `offset'
from memory buffer `buf', processing `bytes'
bytes max.
(Try to read the original prototype this way).
Also change iov_clear() to more general iov_memset()
(it uses memset() internally anyway).
While at it, add comments to the header file
describing what the routines actually does.
The patch only renames argumens in the header, but
keeps old names in the implementation. The next
patch will touch actual code to match.
Now, it might look wrong to pay so much attention
to so small things. But we've so many badly designed
interfaces already so the whole thing becomes rather
confusing or error prone. One example of this is
previous commit and small discussion which emerged
from it, with an outcome that the utility functions
like these aren't well-understdandable, leading to
strange usage cases. That's why I paid quite some
attention to this set of functions and a few
others in subsequent patches.
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Move the framecount check out of the loop and use the new
ehci_update_frindex function to skip frames if needed.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Adapt the frame timer sleeps according to the actual needs. With the
periodic schedule being active we'll have to wakeup 1000 times per
second and go check for work. In case only the async schedule is active
we can be more lazy though. When idle ehci will increate the sleep time
step by step, so qemu has to wake up less frequently. When we'll see
transactions on the bus or the guest fiddles with the schedule
enable/disable bits we'll return to a 1000 Hz wakeup rate and full
speed. With both schedules disabled we stop wakeups altogether.
This patch also drops the freq property (configures wakeup rate
manually) which is obsoleted by this patch.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When the enable bits for controller / async schedule / periodic schedule
change just make sure we kick the frame timer and let
ehci_advance_periodic_state and ehci_advance_async_state handle the
controller state changes.
This will make ehci set USBSTS_HALT when the controller shutdown is
actually done, once both schedules are in inactive state and the
USBSTS_PSS and USBSTS_ASS bits are clear.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Update the status register in the ehci_set_state function, to make sure
the guest-visible register is in sync with our internal schedule state.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add helper functions to query whenever the async / periodic schedule
is enabled or not. Put them into use too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Check for the reset bit first when processing USBCMD register writes.
Also break out of the switch, there is no need to check the other bits.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
When a packet completes which happens to be part of the async schedule
kick the async bottom half for processing,
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Keep track whenever a EHCIQueue is part of the async or periodic
schedule. This way we don't have to pass around the async flag
everywhere but can look it up from the EHCIQueue struct when needed.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add packet queuing. Follow the qTD chain to see if there are more
packets we can submit. Improves performance on larger transfers,
especially with usb-host, as we don't have to wait for a packet to
finish before sending the next one to the host for processing.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Keep a USBDevice pointer in EHCIQueue so we don't have to lookup the
device on each usb packet submission.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This way it is possible to use ehci_execute to submit others than the
first EHCIPacket of the EHCIQueue.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add a separate EHCIPacket struct and move fields over from EHCIQueue.
Preparing for supporting multiple packets per queue being in flight at
the same time. No functional changes yet.
Fix some codestyle issues along the way.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Properly register reset function via the device class.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Repace the running buffer pointer (scsi_buf) with a buffer offset
field (scsi_off). The later is alot easier to live-migrate.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Factor out packet completion to a separate function which
cares to get the MSDState->packet update right.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
The multifunction ich9 ehci controller with uhci companions uses a
different interrupt pin for each function. The three uhci devices
get pins A, B and C, whereas ehci uses pin D. This way the guest
can assign different IRQ lines to each controller.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Cancel transactions before saving vmstate is pretty pointless and just
causes disruptions. We need to cancel them before *loading* vmstate,
but in that case uhci_reset() handles it already and no special action
is needed.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Add a property for the uhci bandwidth. Can be used to make uhci
emulation run faster than real hardware.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Schedule bottom half on completion of async packets instead of calling
uhci_process_frame directly. This way we run uhci_process_frame only
once in case multiple packets finish in a row. Also check whenever
there is bandwidth left before scheduling uhci_process_frame.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
uhci_process_frame() can be invoked multiple times per frame, so
accounting usb bandwith in a local variable doesn't fly, use a variable
in UHCIState instead. Also check the limit more frequently.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
After this patch, the libhw* directories will have a hierarchy
that mimics the source tree. This is useful because we do have
a couple of files there that are in the top source directory.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This patch starts converting the hw/ directory. Some files in hw/
are compiled once, some twice (32-/64-bit), some once per target.
Each category is moved in a separate patch.
After this patch, the files that are compiled once will show the
same hierarchy in the build tree as they do in the source tree,
for example hw/qdev.o instead of just qdev.o.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Callers are changed to use qerror_report_err() to keep their QError
semantics.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-By: Laszlo Ersek <lersek@redhat.com>
The only backend that really uses it is the socket one, which calls
monitor_get_fd(). But it can use 'cur_mon' instead.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-By: Laszlo Ersek <lersek@redhat.com>
This commit converts qemu_opts_create() from qerror_report() to
error_set().
Currently, most calls to qemu_opts_create() can't fail, so most
callers don't need any changes.
The two cases where code checks for qemu_opts_create() erros are:
1. Initialization code in vl.c. All of them print their own
error messages directly to stderr, no need to pass the Error
object
2. The functions opts_parse(), qemu_opts_from_qdict() and
qemu_chr_parse_compat() make use of the error information and
they can be called from HMP or QMP. In this case, to allow for
incremental conversion, we propagate the error up using
qerror_report_err(), which keeps the QError semantics
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-By: Laszlo Ersek <lersek@redhat.com>
Most important here is to update our internal endpoint state so we know
the endpoint isn't in halted state any more. Without this usb-host
tries to clear halt again with the next data transfer submitted. Doing
this twice is (a) not correct and (b) confuses some usb devices,
rendering them non-functional in the guest.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
