Bug 1527860

Summary: [RFE] Q35: change piix3-usb controller (USB1) to qemu-xhci controller (USB3)
Product: Red Hat Enterprise Virtualization Manager Reporter: Marcel Apfelbaum <marcel>
Component: ovirt-engineAssignee: Steven Rosenberg <srosenbe>
Status: CLOSED ERRATA QA Contact: Nisim Simsolo <nsimsolo>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: dblechte, hhan, jcoscia, lsurette, mavital, michal.skrivanek, mtessun, nsimsolo, rduda, Rhev-m-bugs, sgoodman, srevivo, srosenbe, trichard, ybendito
Target Milestone: ovirt-4.3.0Keywords: FutureFeature
Target Release: ---Flags: nsimsolo: testing_plan_complete+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-08 12:36:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1411297    
Bug Blocks: 1527843    

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