Bug 1527860 - [RFE] Q35: change piix3-usb controller (USB1) to qemu-xhci controller (USB3)
Summary: [RFE] Q35: change piix3-usb controller (USB1) to qemu-xhci controller (USB3)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: unspecified
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-4.3.0
: ---
Assignee: Steven Rosenberg
QA Contact: Nisim Simsolo
URL:
Whiteboard:
: 1689415 (view as bug list)
Depends On: 1411297
Blocks: 1527843
TreeView+ depends on / blocked
 
Reported: 2017-12-20 09:37 UTC by Marcel Apfelbaum
Modified: 2019-05-08 12:37 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
This release adds USB qemu-xhci controller support to SPICE consoles, for Q35 chipset support. Red Hat Virtualization now expects that when a BIOS type using the Q35 chipset is chosen, and USB is enabled, that the USB controller will be qemu-xhci.
Clone Of:
Environment:
Last Closed: 2019-05-08 12:36:59 UTC
oVirt Team: Virt
Target Upstream Version:
nsimsolo: testing_plan_complete+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:1085 0 None None None 2019-05-08 12:37:22 UTC
oVirt gerrit 96611 0 master MERGED engine: Added Q35 USB Controllers support to Spice 2020-09-03 01:40:44 UTC

Description Marcel Apfelbaum 2017-12-20 09:37:29 UTC
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.

Comment 1 Michal Skrivanek 2018-08-15 11:48:34 UTC
need to look into SPICE USB sharing controllers. We still use EHCI+3xUHCI

Comment 2 Steven Rosenberg 2018-12-19 17:25:37 UTC
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.

Comment 3 Michal Skrivanek 2019-01-03 12:27:11 UTC
please address comment #1

Comment 10 Michal Skrivanek 2019-01-09 10:09:32 UTC
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

Comment 12 Nisim Simsolo 2019-01-24 12:16:39 UTC
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.

Comment 13 Steve Goodman 2019-02-28 13:31:59 UTC
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.

Comment 14 Michal Skrivanek 2019-02-28 13:33:31 UTC
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

Comment 15 Ryan Barry 2019-03-16 00:22:04 UTC
*** Bug 1689415 has been marked as a duplicate of this bug. ***

Comment 18 errata-xmlrpc 2019-05-08 12:36:59 UTC
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


Note You need to log in before you can comment on or make changes to this bug.