On Sun, 2017-02-19 at 18:54 +0100, Auger Eric wrote:
We should find a way to detect whether the interrupt controller will support PCIe, and fall back to using virtio-mmio when it doesn't. Eric, any ideas about how we could achieve that? Actually, we will probably want to do the opposite, eg. pick GICv2 over GICv3 if the latter doesn't allow us to use PCIe. Yes I think the easiest solution is to select the GICv2 + v2m combo to
Not sure how the "combo" part works... I noticed that, if I start a guest with -machine virt,gic-version=3 I only get one GIC-related device: dev: arm-gicv3, id "" gpio-out "sysbus-irq" 4 gpio-in "" 288 num-cpu = 1 (0x1) num-irq = 288 (0x120) revision = 3 (0x3) has-security-extensions = false mmio 0000000008000000/0000000000010000 mmio 00000000080a0000/0000000000020000 However, if I use gic-version=2, I get: dev: arm-gicv2m, id "" gpio-out "sysbus-irq" 64 base-spi = 48 (0x30) num-spi = 64 (0x40) mmio 0000000008020000/0000000000001000 dev: arm_gic, id "" gpio-out "sysbus-irq" 4 gpio-in "" 288 num-cpu = 1 (0x1) num-irq = 288 (0x120) revision = 2 (0x2) has-security-extensions = false mmio 0000000008000000/0000000000001000 mmio 0000000008010000/0000000000002000 mmio ffffffffffffffff/0000000000000100 Is that what you're referring to? Do we need to care about the fact that it's two devices rather than one?
get the MSI support. This depends on whether the limitations linked to GICv2 usage are acceptable in your case (max 8 cpus for instance).
I think the advantages of using virtio-pci instead of virtio-mmio offset the limitations of GICv2, at least in the default case. Aside from not being able to have more than 8 vCPUs, what other limitations are we looking at? Anyway, my question was really: how can we tell whether a certain gic-version will support PCIe? Is there a way to ask QEMU for the information, or would we have to hardcode this knowledge in libvirt? The latter sounds like it would backfire quite easily, as I assume the emulated GICv3 not having PCIe support is only a matter of the relevant code not having been implemented *yet*, not something that's always going to be true. -- Andrea Bolognani / Red Hat / Virtualization