On Thu, Apr 27, 2017 at 04:13:43PM +0200, Andrea Bolognani wrote:
On Thu, 2017-04-27 at 10:24 +0200, Pavel Hrdina wrote:
> > You're technically correct[1]. However, piix3-uhci is
> > another piece of Intel-derived hardware so in practice
> > qemu-system-aarch64 is very unlikely to have it compiled
> > in and most users will end up getting the error instead.
>
> Isn't the nec-xhci also Intel hardware, so the same would apply to that
> controller as well.
Not quite:
Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] [8086:7020]
NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194]
The vendor for piix3-uhci is Intel Corporation, the vendor
for nec-xhci is NEC Corporation.
I guess both are unlikely to show up in actual aarch64
hardware, but the former is clearly x86-specific while the
latter is somewhat more architecture-agnostic.
> Moreover, this probably happens only for downstream
> builds of QEMU (most likely only RHEL/CentOS) as there is no configure
> option for that. QEMU has some default configs for different architectures
> but in upstream QEMU the set of UHCI usb controllers is enabled by default
> for aarch64.
The upstream QEMU configuration takes the kitchen sink
approach, eg. qemu-system-ppc64 will include allwinner-ahci
and other devices that clearly have no place in a ppc64
guest, so I don't think we should take that as an indication
that piix-uhci is something anyone will want to reasonably
use on aarch64 :)
My point was that we should not make any decisions based on downstream
configurations :).
Like I said, I'll send v2 with nec-xhci enabled for aarch64.
Pavel
--
Andrea Bolognani / Red Hat / Virtualization
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list