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