Re: [Qemu-devel] [PATCH RFC] docs: add PCIe devices placement guidelines

[Gerd Hoffmann]

  Hi,

> > Side note for usb: In practice you don't want to use the tons of
> > uhci/ehci controllers present in the original q35 but plug xhci into one
> > of the pcie root ports instead (unless your guest doesn't support xhci).
> 
> I've wondered about that recently. For i440fx machinetypes if you don't 
> specify a USB controller in libvirt's domain config, you will 
> automatically get the PIIX3 USB controller added. In order to maintain 
> consistency on the topic of "auto-adding USB when not specified", if the 
> machinetype is Q35 we will autoadd a set of USB2 (uhci/ehci) controllers 
> (I think I added that based on your comments at the time :-). But 
> recently I've mostly been hearing that people should use xhci instead. 
> So should libvirt add a single xhci (rather than the uhci/ehci set) at 
> the same port when no USB is specified?

Big advantage of xhci is that the hardware design is much more
virtualization friendly, i.e. it needs alot less cpu cycles to emulate
than uhci/ohci/ehci.  Also xhci can handle all usb speeds, so you don't
need the complicated uhci/ehci companion setup with uhci for usb1 and
ehci for usb2 devices.

The problem with xhci is guest support.  Which becomes less and less of
a problem over time of course.  All our firmware (seabios/edk2/slof) has
xhci support meanwhile.  ppc64 switched from ohci to xhci by default in
rhel-7.3.  Finding linux guests without xhci support is pretty hard
meanwhile.  Maybe RHEL-5 qualifies.  Windows 8 + newer ships with xhci
drivers.

So, yea, maybe it's time to switch the default for q35 to xhci,
especially if we keep uhci as default for i440fx and suggest to use that
machine type for oldish guests.  But I'd suggest to place xhci in a pcie
root port then, so maybe wait with that until libvirt can auto-add pcie
root ports as needed ...

cheers,
  Gerd