It should return 1 if an error occurs when reading iso td.
This will avoid an infinite loop issue in ohci_service_ed_list.
Signed-off-by: NLi Qiang <liqiang6-s@360.cn>
Message-id: 5899ac3e.1033240a.944d5.9a2d@mx.google.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

In usb_ehci_init function, it initializes 's->ipacket', but there
is no corresponding function to free this. As the ehci can be hotplug
and unplug, this will leak host memory leak. In order to make the
hierarchy clean, we should add a ehci pci finalize function, then call
the clean function in ehci device.
Signed-off-by: NLi Qiang <liqiang6-s@360.cn>
Message-id: 589a85b8.3c2b9d0a.b8e6.1434@mx.google.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The qemu xhci emulation doesn't handle the ERDP_EHB flag correctly.

When the host adapter queues a new event the ERDP_EHB flag is set.  The
flag is cleared (via w1c) by the guest when it updates the ERDP (event
ring dequeue pointer) register to notify the host adapter which events
it has fetched.

An IRQ must be raised in case the ERDP_EHB flag flips from clear to set.
If the flag is set already (which implies there are events queued up
which are not yet processed by the guest) xhci must *not* raise a IRQ.

Qemu got that wrong and raised an IRQ on every event, thereby generating
spurious interrupts in case we've queued events faster than the guest
processed them.  This patch fixes that.

With that change in place we also have to check ERDP updates, to see
whenever the guest has fetched all queued events.  In case there are
still pending events set ERDP_EHB and raise an IRQ again, to make sure
the events don't linger unseen forever.

The linux kernel driver and the microsoft windows driver (shipped with
win8+) can deal with the spurious interrupts without problems.  The
renesas windows driver (v2.1.39) which can be used on older windows
versions is quite upset though.  It does spurious ERDP updates now and
then (not every time, seems we must hit a race window for this to
happen), which in turn makes the qemu xhci emulation think the event
ring is full.  Things go south from here ...

tl;dr: This is the "fix xhci on win7" patch.

Cc: M.Cerveny@computer.org
Cc: 1373228@bugs.launchpad.net
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1486104705-13761-1-git-send-email-kraxel@redhat.com

CCID device emulator uses Application Protocol Data Units(APDU)
to exchange command and responses to and from the host.
The length in these units couldn't be greater than 65536. Add
check to ensure the same. It'd also avoid potential integer
overflow in emulated_apdu_from_guest.
Reported-by: NLi Qiang <liqiang6-s@360.cn>
Signed-off-by: NPrasad J Pandit <pjp@fedoraproject.org>
Message-id: 20170202192228.10847-1-ppandit@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Track xhci_kick_epctx processing being active in a variable.  Check the
variable before calling xhci_kick_epctx from xhci_kick_ep.  Add an
assert to make sure we don't call recursively into xhci_kick_epctx.

Cc: 1653384@bugs.launchpad.net
Fixes: 94b037f2Reported-by: NFabian Lesniak <fabian@lesniak-it.de>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1486035372-3621-1-git-send-email-kraxel@redhat.com
Message-id: 1485790607-31399-5-git-send-email-kraxel@redhat.com

xhci_submit and xhci_fire_ctl_transfer are is called from
xhci_kick_epctx processing loop only, so there is no need to call
xhci_kick_epctx make sure processing continues.  Also eecursive calls
into xhci_kick_epctx can cause trouble.

Drop the xhci_kick_epctx calls.

Cc: 1653384@bugs.launchpad.net
Fixes: 94b037f2Reported-by: NFabian Lesniak <fabian@lesniak-it.de>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1485790607-31399-4-git-send-email-kraxel@redhat.com

Make clear that this isn't guaranteed to actually complete the transfer,
the usb packet can still be in flight after calling that function.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1485790607-31399-3-git-send-email-kraxel@redhat.com

Most callsites check already, one was missed.

Cc: 1653384@bugs.launchpad.net
Fixes: 94b037f2Reported-by: NFabian Lesniak <fabian@lesniak-it.de>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1485790607-31399-2-git-send-email-kraxel@redhat.com

Windows 10 reportedly sends these, so accept them in case
the device in question is a superspeed (usb3) device.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1485870727-21956-2-git-send-email-kraxel@redhat.com

Print some more details in case we get a unknown
control request, to ease trouble-shooting.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Message-id: 1485870727-21956-1-git-send-email-kraxel@redhat.com

 1. Set bInterfaceProtocol to 0x00 for usb-tablet. This should be
    non-zero for boot protocol devices only, which the usb-tablet is not.
 2. Set the usb-tablet's usage to "mouse" in the report descriptor.

The boot protocol of 0x02 specifically confused OS X/macOS' HID driver
stack, causing it to generate additional bogus HID events with relative
motion in addition to the tablet's absolute coordinate events.

Absolute pointing devices with HID Report Descriptor usage of 0x01
(pointing) are treated by the macOS HID driver as analog sticks, and
absolute coordinates are not directly translated to absolute mouse
cursor positions. Changing it to 0x02 (mouse) fixes the problem, and
does not have any adverse effect in other operating systems and
windowing systems. (VMWare does the same thing.)
Signed-off-by: NPhil Dennis-Jordan <phil@philjordan.eu>
Message-id: 1485365075-32702-1-git-send-email-phil@philjordan.eu
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

msix_init() reports errors with error_report(), which is wrong when
it's used in realize().  The same issue was fixed for msi_init() in
commit 1108b2f8. In order to make the API change as small as possible,
leave the return value check to later patch.

For some devices(like e1000e, vmxnet3, nvme) who won't fail because of
msix_init's failure, suppress the error report by passing NULL error
object.

Bonus: add comment for msix_init.

CC: Jiri Pirko <jiri@resnulli.us>
CC: Gerd Hoffmann <kraxel@redhat.com>
CC: Dmitry Fleytman <dmitry@daynix.com>
CC: Jason Wang <jasowang@redhat.com>
CC: Michael S. Tsirkin <mst@redhat.com>
CC: Hannes Reinecke <hare@suse.de>
CC: Paolo Bonzini <pbonzini@redhat.com>
CC: Alex Williamson <alex.williamson@redhat.com>
CC: Markus Armbruster <armbru@redhat.com>
CC: Marcel Apfelbaum <marcel@redhat.com>
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

usb_xhci_realize() corrects invalid values of property "intrs"
automatically, but the uncorrected value is passed to msi_init(),
which chokes on invalid values.  Delay that until after the
correction.

Resources allocated by usb_xhci_init() are leaked when msi_init()
fails.  Fix by calling it after msi_init().

CC: Gerd Hoffmann <kraxel@redhat.com>
CC: Markus Armbruster <armbru@redhat.com>
CC: Marcel Apfelbaum <marcel@redhat.com>
CC: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Acked-by: NMarcel Apfelbaum <marcel@redhat.com>
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>

There are a number of unused trace events that
scripts/cleanup-trace-events.pl finds.  The "hw/vfio/pci-quirks.c"
filename was typoed and "qapi/qapi-visit-core.c" was missing the qapi/
directory prefix.
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 20170126171613.1399-3-stefanha@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>

When passing through an USB storage device to a pseries guest, it
is currently not possible to automatically boot from the device
if the "bootindex" property has been specified, too (e.g. when using
"-device nec-usb-xhci -device usb-host,hostbus=1,hostaddr=2,bootindex=0"
at the command line). The problem is that QEMU builds a device tree path
like "/pci@800000020000000/usb@0/usb-host@1" and passes it to SLOF
in the /chosen/qemu,boot-list property. SLOF, however, probes the
USB device, recognizes that it is a storage device and thus changes
its name to "storage", and additionally adds a child node for the
SCSI LUN, so the correct boot path in SLOF is something like
"/pci@800000020000000/usb@0/storage@1/disk@101000000000000" instead.
So when we detect an USB mass storage device with SCSI interface,
we've got to adjust the firmware boot-device path properly that
SLOF can automatically boot from the device.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1354177Signed-off-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>

Pick a uniform chardev type name.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

It's a storage device, so let's classify it accordingly. And
while we're at it, also add a short description for people who
do not know what MTP means.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NLaurent Vivier <laurent@vivier.eu>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Signed-off-by: NStefan Weil <sw@weilnetz.de>
Acked-by: NAlistair Francis <alistair.francis@xilinx.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

The vmstate_pci_device and vmstate_pcie_devices differ
just in the size of one buffer; combine the two using a _TEST
macro.

I think this is safe as long as everywhere which currently
uses either of these two uses the right type.

One thing that concerns me is that some places use pci_device_load/save
which does some irq mangling, but others just use the VMSTATE_PCI_DEVICE
macro - how are they getting the same irq mangling?

This passes a smoke test migrate of:
./x86_64-softmmu/qemu-system-x86_64 -M pc,accel=kvm -m 1024
./littlefed20.img -device e1000e -device virtio-net -device
e1000 -device virtio-rng -device megasas -device megasas-gen2 -device
ioh3420 -device nec-usb-xhci

to an unmodified qemu.
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20161214195829.18241-1-dgilbert@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>

Introduce checks for the unmigratable flag in the VMStateDescription
structs of respective devices when user attempts to add them. If the
"--only-migratable" was specified, all unmigratable devices will
rightly fail to add. This feature is made compatible for both "-device"
and "-usbdevice" command line options and covers their hmp and qmp
counterparts as well.
Signed-off-by: NAshijeet Acharya <ashijeetacharya@gmail.com>
Message-Id: <1484566314-3987-4-git-send-email-ashijeetacharya@gmail.com>
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>

Current migration code cannot handle some data structures such as
QTAILQ in qemu/queue.h. Here we extend the signatures of put/get
in VMStateInfo so that customized handling is supported. put now
will return int type.
Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: NJianjun Duan <duanj@linux.vnet.ibm.com>
Message-Id: <1484852453-12728-2-git-send-email-duanj@linux.vnet.ibm.com>
Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>

Remove the useless is_external argument.  Since the iohandler
AioContext is never used for block devices, aio_disable_external
is never called on it.  This lets us remove stubs/iohandler.c.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Attach the usb bus of a new pvusb controller to the qdev associated
with the Xen backend. Any device connected to that controller can now
specify the bus and port directly via its properties.
Signed-off-by: NJuergen Gross <jgross@suse.com>
Reviewed-by: NStefano Stabellini <sstabellini@kernel.org>
Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>

In usbredir destroy dispatch function, it doesn't free the vm change
state handler once registered in usbredir_realize function. This will
lead a memory leak issue. This patch avoid this.
Signed-off-by: NLi Qiang <liqiang6-s@360.cn>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-id: 58216976.d0236b0a.77b99.bcd6@mx.google.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

In ehci_init_transfer function, if the 'cpage' is bigger than 4,
it doesn't free the 'p->sgl' once allocated previously thus leading
a memory leak issue. This patch avoid this.
Signed-off-by: NLi Qiang <liqiang6-s@360.cn>
Message-id: 5821c0f4.091c6b0a.e0c92.e811@mx.google.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

Prepare xen_be_send_notify to be shared with frontends:
 * xen_be_send_notify -> xen_pv_send_notify
Signed-off-by: NEmil Condrea <emilcondrea@gmail.com>
Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
Signed-off-by: NQuan Xu <xuquan8@huawei.com>
Acked-by: NAnthony PERARD <anthony.perard@citrix.com>

Prepare xen_be_unbind_evtchn to be shared with frontends:
 * xen_be_unbind_evtchn -> xen_pv_unbind_evtchn
Signed-off-by: NEmil Condrea <emilcondrea@gmail.com>
Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
Signed-off-by: NQuan Xu <xuquan8@huawei.com>
Acked-by: NAnthony PERARD <anthony.perard@citrix.com>

Prepare xen_be_printf to be used by both backend and frontends:
 * xen_be_printf -> xen_pv_printf
Signed-off-by: NEmil Condrea <emilcondrea@gmail.com>
Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
Signed-off-by: NQuan Xu <xuquan8@huawei.com>
Acked-by: NAnthony PERARD <anthony.perard@citrix.com>

Some files contain multiple #includes of the same header file.
Removed most of those unnecessary duplicate entries using
scripts/clean-includes.
Reviewed-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NAnand J <anand.indukala@gmail.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

The *_exitfn functions cannot fail and should not be
returning int.
This also removes the passthru_exitfn since this callback
does nothing as of now.
This was suggested as a Bite-sized task for code cleanup.
Signed-off-by: NAkanksha Srivastava <akanksha.dlf@gmail.com>
Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: NMichael Tokarev <mjt@tls.msk.ru>

Usage has long been removed, since commit f220174d.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022100951.19562-2-marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

No need to keep explicit_fe_open around if it affects only a
qemu_chr_fe_set_handlers(). Use an additional argument instead.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-24-marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Now that all front end use qemu_chr_fe_init(), we can move chardev
claiming in init(), and add a function deinit() to release the chardev
and cleanup handlers.

The qemu_chr_fe_claim_no_fail() for property are gone, since the
property will raise an error instead. In other cases, where there is
already an error path, an error is raised instead. Finally, other cases
are handled by &error_abort in qemu_chr_fe_init().
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-19-marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

This also switches from qemu_chr_add_handlers() to
qemu_chr_fe_set_handlers(). Note that qemu_chr_fe_set_handlers() now
takes the focus when fe_open (qemu_chr_add_handlers() did take the
focus)
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-16-marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Store the property in a CharBackend instead of CharDriverState*.  This
also replace systematically chr by chr.chr to access the
CharDriverState*. The following patches will replace it with calls to
qemu_chr_fe CharBackend functions.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-12-marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

The CharDriverState.init() callback is no longer set since commit
a61ae7f8 and thus unused. The only user, the malta FGPA display has
been converted to use an event "opened" callback instead.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20161022095318.17775-7-marcandre.lureau@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

PAGE_SIZE is undefined on ARM64. Use XC_PAGE_SIZE instead, which is
always 4096 even when page granularity is 64K.

For this to actually work with 64K pages, more changes are required.
Signed-off-by: NStefano Stabellini <sstabellini@kernel.org>
Reviewed-by: NJuergen Gross <jgross@suse.com>
Release-acked-by: NWei Liu <wei.liu2@citrix.com>

Needed to make sure usb redirection is prepared to actually handle the
callback from the usb host adapter.  Without this interrupt endpoints
don't work on xhci.

Note: On ehci the usb_wakeup() call only schedules a BH for the actual
work, which hides this bug because the allocation happens before ehci
calls back even without this patch.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Message-id: 1476096313-7730-1-git-send-email-kraxel@redhat.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

The default DMA offset is set to 3. When the property is not set by
the consumer, the default causes DMA access to be shifted by 3
bytes. In PXA, this results in incorrect DMA access, leading to error
notification in the USB controller driver. A better default would be
0, so that there is no offset, when the consumer does not specify one.
Signed-off-by: NVijay Kumar B. <vijaykumar@zilogic.com>
Reviewed-by: NDeepak S. <deepak@zilogic.com>
Message-id: 1475060958-7760-1-git-send-email-vijaykumar@zilogic.com
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>

snprintf return value is *not* the number of chars written into the
buffer, but the number of chars needed.  So in case the buffer is too
small you can go alloc a bigger one and try again.  But that also means
you can't simply use the return value for the next snprintf call
without checking beforehand that things did actually fit.

Problem is that usb_desc_create_serial didn't perform that check, so a
loooong path string (can happen with deep pci-bridge nesting) results in
the third snprintf call smashing the stack.

Fix this by throwing out all the snpintf calls and use g_strdup_printf
instead.

https://bugzilla.redhat.com/show_bug.cgi?id=1381630Reported-by: NThomas Huth <thuth@redhat.com>
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1475659998-22045-1-git-send-email-kraxel@redhat.com