Bug 1451189

fixed upstream
0bbb2f3df1ffd9ccf7135a69a450c6929bc0b915
2da077a881894c0b18032153c709d95ac89492c6

Do test on qemu-kvm-rhev-2.10.0-1.el7.x86_64, following is the test result:

[root@ibm-x3650m3-05 test-results]# /usr/libexec/qemu-kvm -M pc -device nec-usb-xhci,\?
nec-usb-xhci.rombar=uint32
nec-usb-xhci.intrs=uint32
nec-usb-xhci.x-pcie-lnksta-dllla=bool (on/off)
nec-usb-xhci.msix=OnOffAuto (on/off/auto)
nec-usb-xhci.multifunction=bool (on/off)
nec-usb-xhci.msi=OnOffAuto (on/off/auto)
nec-usb-xhci.superspeed-ports-first=bool (on/off)
nec-usb-xhci.streams=bool (on/off)
nec-usb-xhci.romfile=str
nec-usb-xhci.force-pcie-endcap=bool (on/off)
nec-usb-xhci.command_serr_enable=bool (on/off)
nec-usb-xhci.x-pcie-extcap-init=bool (on/off)
nec-usb-xhci.addr=int32 (Slot and optional function number, example: 06.0 or 06)
nec-usb-xhci.p3=uint32
nec-usb-xhci.p2=uint32
nec-usb-xhci.slots=uint32
[root@ibm-x3650m3-05 test-results]# 
[root@ibm-x3650m3-05 test-results]# /usr/libexec/qemu-kvm -M pc -device qemu-xhci,\?
qemu-xhci.rombar=uint32
qemu-xhci.x-pcie-lnksta-dllla=bool (on/off)
qemu-xhci.multifunction=bool (on/off)
qemu-xhci.streams=bool (on/off)
qemu-xhci.romfile=str
qemu-xhci.command_serr_enable=bool (on/off)
qemu-xhci.x-pcie-extcap-init=bool (on/off)
qemu-xhci.addr=int32 (Slot and optional function number, example: 06.0 or 06)
qemu-xhci.p3=uint32
qemu-xhci.p2=uint32
[root@ibm-x3650m3-05 test-results]# 

And do additional test on qemu-kvm-rhev-debuginfo-2.9.0-16.el7_4.9.x86_64, the test result is the same as above.


Gerd,

Could you help to check if above test is enough to verify this bug? If not, could you give some suggestions above the verification?

Thanks!
Nini

Well, the patch just adds a config option to disable nec-usb-xhci.  Whenever option this is used or not depends on the architecture.

x86_64 and ppc64 need nec-usb-xhci for backward compatibility reasons, so both xhci devices are present.

On aarch64 you should find qemu-xhci only.

Gerd,

Got it, thanks!


Xujun,

Could you help to verify the behaviour on qemu-kvm-rhev-2.10.0-1.el7..ppc64le?

Thanks!
Nini

Test it with qemu-kvm-rhev-2.10.0-1.el7.ppc64le.

[root@ibm-p8-rhevm-10 staf-kvm-devel]# /usr/libexec/qemu-kvm -M pseries -device nec-usb-xhci,\?
nec-usb-xhci.rombar=uint32
nec-usb-xhci.intrs=uint32
nec-usb-xhci.x-pcie-lnksta-dllla=bool (on/off)
nec-usb-xhci.msix=OnOffAuto (on/off/auto)
nec-usb-xhci.multifunction=bool (on/off)
nec-usb-xhci.msi=OnOffAuto (on/off/auto)
nec-usb-xhci.superspeed-ports-first=bool (on/off)
nec-usb-xhci.streams=bool (on/off)
nec-usb-xhci.romfile=str
nec-usb-xhci.force-pcie-endcap=bool (on/off)
nec-usb-xhci.command_serr_enable=bool (on/off)
nec-usb-xhci.x-pcie-extcap-init=bool (on/off)
nec-usb-xhci.addr=int32 (Slot and optional function number, example: 06.0 or 06)
nec-usb-xhci.p3=uint32
nec-usb-xhci.p2=uint32
nec-usb-xhci.slots=uint32
[root@ibm-p8-rhevm-10 staf-kvm-devel]# /usr/libexec/qemu-kvm -M pseries -device qemu-xhci,\?
qemu-xhci.rombar=uint32
qemu-xhci.x-pcie-lnksta-dllla=bool (on/off)
qemu-xhci.multifunction=bool (on/off)
qemu-xhci.streams=bool (on/off)
qemu-xhci.romfile=str
qemu-xhci.command_serr_enable=bool (on/off)
qemu-xhci.x-pcie-extcap-init=bool (on/off)
qemu-xhci.addr=int32 (Slot and optional function number, example: 06.0 or 06)
qemu-xhci.p3=uint32
qemu-xhci.p2=uint32

Thanks Xujun.

According to Comment 6 to Comment 8, set the bug as verified.

Gerd,

Is qemu-xhci a new usb controller type on qemu2.9? Or is it just an alias for the nec-usb-xhci one? If it's a new one, what special test should we do for it besides the normal one on usb controllers?

Thanks!
Nini

(In reply to Gu Nini from comment #10)
> Gerd,
> 
> Is qemu-xhci a new usb controller type on qemu2.9? Or is it just an alias
> for the nec-usb-xhci one? If it's a new one, what special test should we do
> for it besides the normal one on usb controllers?
> 
> Thanks!
> Nini

Most if the code is identical.

The qemu-xhci doesn't support some nec-specific vendor commands, which will only be used by the nec (now renesas) drivers.  Neither the xhci drivers from microsoft nor the linux kernel drivers will use these comands.  So it doesn't make any difference, except when installing the renesas drivers on windows 7 to get xhci support there.

Interrupt support is slightly different too.  nec-usb-xhci supports both MSI and MSI-X, qemu-xhci only the (newer) MSI-X interrupts.  Guests typically prefer MSI-X anyway when available, so this should likewise not make a difference.

Bottom line:  A full test is certainly not needed.  A single, simple test (like booting guest with usb-tablet, verify the tablet works) should be done on both nec-usb-xhci and qemu-xhci.  For all other tests testing only one of the two variants is perfectly fine.

(In reply to Gerd Hoffmann from comment #11)
> (In reply to Gu Nini from comment #10)

Thanks Gerd for the detailed explanation.

> 
> The qemu-xhci doesn't support some nec-specific vendor commands, which will
> only be used by the nec (now renesas) drivers.  Neither the xhci drivers
> from microsoft nor the linux kernel drivers will use these comands.  So it
> doesn't make any difference, except when installing the renesas drivers on
> windows 7 to get xhci support there.
> 
> Interrupt support is slightly different too.  nec-usb-xhci supports both MSI
> and MSI-X, qemu-xhci only the (newer) MSI-X interrupts.  Guests typically
> prefer MSI-X anyway when available, so this should likewise not make a
> difference.
>

Do you mean qemu-xhci supports Windows7, when the renesas drivers installed?

> > The qemu-xhci doesn't support some nec-specific vendor commands, which will
> > only be used by the nec (now renesas) drivers.  Neither the xhci drivers

> Do you mean qemu-xhci supports Windows7, when the renesas drivers installed?

Other way around.  Windows7 with the renesas drivers is the only guest configuration which needs nec-usb-xhci (because the renesas drivers work with renesas/nec hardware only).

All other guests have generic xhci drivers should work just fine with both qemu-xhci and nec-usb-xhci and there should be no noticeable difference between the two.

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/RHSA-2018:1104