[libvirt] ARM KVM GICv3 Support

[Pavel Fedin]

 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