[libvirt] [PATCH 1/2] qemu: aarch64: Don't add PCIe controller by default

[Andrea Bolognani]

On Wed, 2016-02-17 at 12:40 -0500, Laine Stump wrote:
> On 01/28/2016 04:14 PM, Cole Robinson wrote:
> > 
> > This was discussed here:
> > 
> > https://www.redhat.com/archives/libvir-list/2015-December/msg00217.html
> > 
> > The summary is that apps/users are in a tough spot WRT aarch64 -M virt
> > and PCIe support: qemu has all the plumbing, but most distros don't
> > support it yet. Presently libvirt adds a PCIe controller to the XML for
> > new enough qemu, but this patch drops that behavior.
> I read back through all of these messages and am more thoroughly 
> undecided than ever about the proper thing to do.

Same here :)

> I guess the end of that thread was that the best thing to do was (as 
> you're doing in this patch) to temporarily (?) not add a pcie-root 
> controller to a domain's XML for aarch64 -M virt, and if there is no PCI 
> controller, then use virtio-mmio for the address of all devices; but if 
> a pcie-root is manually added, to instead use pci addresses.
> 
> My main issue with that is that the XML is then not reflecting the 
> hardware exactly in cases where the binary is creating a pcie-root 
> automatically (but we're not using it). The alternative would be to 
> force specifying the address type of each device though, and since that 
> is impractical for management apps to deal with, I guess keying off the 
> presence/absence of a manually-created pcie-root is the less evil of the 
> options :-P.

This is my concern as well.

Not adding automatically the dmi-to-pci-bridge and pci-bridge sounds
like a step in the right direction as QEMU will happily work without
them, but the PCIe root controller is always added (if my reading of
the output of 'info qtree' and poking around the guest is correct)
and the domain XML should reflect this fact.

Deviating from the actual (virtual) hardware is something that's
bound to come back and bite us at some point, I'm afraid, and we
should avoid it.

Cheers.

-- 
Andrea Bolognani
Software Engineer - Virtualization Team