Re: [libvirt] ARM KVM GICv3 Support
Hello!
Nobody ever CCed me, so i saw this topic only occasionally... Sorry for the late reply.
The challenge is that QEMU's virt machine model defaults to GICv2
unless
you specify an additional "-machine gic-version=host" parameter to QEMU,
in which case your VM gets the same GIC version as your host.
Or you can specify gic-version=3, and get v3.
The idea behind this was to be backwards-compatible. In old qemu versions you don't
specify anything, and get v2. With new qemu
it's the same.
The only problem here is that on some GICv3 hosts you can run only GICv3 KVM guests,
because vGICv2 support is optional. With TCG
(once GICv3 software emulation is implemented) you wouldn't have this limitation at
all. Actually, i am also proposing kernel
patches which enable to use software-emulated GIC with KVM
(http://www.spinics.net/lists/kvm/msg124539.html,
http://www.spinics.net/lists/kvm/msg124545.html), but got no review so far. I also have
support in qemu for this. With these patches
you would actually be able to run GICv2 guest on GICv3-only host, but with some
performance penalty, just by adding
kernel_irqchip=off machine option.
Now, I'm told that this is inconvenient for libvirt, because it
typically does not pass any -machine options, is that correct?
It's incorrect:
http://www.redhat.com/archives/libvir-list/2015-September/msg01067.html
Second, some hardware platforms only support GICv2 guests, some only
support GICv3 guests, and some support both GICv2 and GICv3 guests
(those hosts with a GICv3 with the backwards compatibility support).
It is unclear to me how libvirt users will relate to these constraints.
Actually, i see GICv3 and GICv2 "virt" actually as different machine types.
Because in real world these would be different
motherboards, even if we imagine that CPUs are the same. Actually, initially i proposed to
simply add "virt-v3" (or "virt-gicv3", if
you want) machine type. I believe this would resolve many things automatically (obviously
in order to run a machine you need an OS
new enough to support it, and all applications would just see the new machine choice). But
Peter strongly disagreed with that and
asked me to add an option to existing virt machine instead.
The end goal here is to determine if we need to add any functionality
to
QEMU to better support libvirt, and what kind of features/glue need to
be added to libvirt for this to work.
I'd say that it's not libvirt's work now. We have support in the XML for this
option, so now it's up to application to be able to
specify this. For example, applications, once "virt" type is chosen, should be
able to present one more control to choose between
GIC versions. Just think of it as "machine sub-type".
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia