The piix3-usb controller (USB1) is a legacy PCI device and we have no special case to make it an integrated device (because there is a more modern, well supported alternative that is a PCIe device), so it ends up pulling in a dmi-to-pci-bridge and a pci-bridge; we don't want either of those. So instead of piix3-uhci, we should be using an qemu-xhci controller (USB3, and a true PCIe device) instead. I also remember someone saying that it uses much less CPU, so yoou'll get that bonus too.
need to look into SPICE USB sharing controllers. We still use EHCI+3xUHCI
I reviewed this issue and it seems it was already implemented. To set the usb controller for Q35 to be qemu-xhci, please perform the following: 1. On a Version 4.3 Compatible Cluster edit or create a new VM with appropriate settings. 2. Select the System tab and Choose Advanced parameters. 3. Choose a Bios Type of Q35 and save. 4. Click on the VM and and choose the VM Devices tab. 5. The usb device's Spec Params column should have model=qemu-xhci 6. Run the VM 7. In the engine.log one should find the following line within the xml section: <controller type="usb" model="qemu-xhci" index="0"/> Further testing by QE is recommended.
please address comment #1
ok,as per https://www.kraxel.org/blog/2018/08/qemu-usb-tips/ this xml "<controller type='usb' model='qemu-xhci' ports='8'/>" should be what we want for SPICE on q35 Also flagging as a blocker since we need to stabilize guest ABI before 4.3 GA
Verified: ovirt-engine-4.3.0-0.8.master.20190122102235.git7a1ef10.el7 qemu-kvm-ev-2.12.0-18.el7_6.1.1.x86_64 vdsm-4.30.6-19.git754a02d.el7.x86_64 libvirt-client-4.5.0-10.el7_6.3.x86_64 Verification scenario: Polarion test case added to external trackers.
Does the user need to know how to do anything? If I understand correctly, the qemu-xhci (USB3 controller with built-in support for USB2 and USB1.1) is now the default USB controller.
nothing special about it, it's just that now it's going to be a USB3 controller instead of bunch of USB1 and USB2 Note it's for Q35 only. The default for most users stays the same
*** Bug 1689415 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:1085