[virt-tools-list] [virt-manager PATCH 5/5] virt-manager: add a new guest feature GIC for AMR guests

[Pavel Hrdina]

On Sat, Jun 11, 2016 at 12:04:35PM -0400, Cole Robinson wrote:
> Okay, I need to finally truly figure out how all this stuff fits together to
> try and understand if it makes sense to expose in the GUI. My understanding is
> that there's 4 pieces of info at play here:
> 
> - What gic versions can qemu emulate? (available for domain type=qemu)
> - What gic versions does the host support? (available for domain type=kvm)
> - What gic versions does the guest OS support? (eventually tracked by libosinfo)
> 
> As of now there's currently only 3 possible GIC settings: version=2,
> version=3, version=host (kvm only, basically like -cpu host)
> 
> Libvirt will default to the highest gic version that qemu advertises support
> for. That will be gic v2 for type=qemu (the only version qemu presently
> emulates), and whatever the host supports for type=kvm
> 
> That's basically the extent of my knowledge, so I'd like to know:
> 
> - does gic emulation have any impact on type=kvm, or is it only relevant to
> type=qemu? (I assume the latter)

As far as I was able to find GIC emulation is valid only for QEMU and KVM
requires HW support.  However there is an ongoing work to add emulated GICv3 for
QEMU (TCG).

> - do aarch64 hosts only support one gic version, or does say a v3 host also
> support v2?

Backward support is optional so if host supports v3 it can but doesn't have to
support v2.  So there could be hosts only with v3 support but also host with v2
and v3 support.

> - do guest OS support multiple gic versions? like does a guest OS that
> supports v3 also support v2? if a guest OS doesn't support a gic version, does
> that mean it completely fails to boot, or some other failure scenario?

If a OS doesn't support GIC it probably doesn't support ARM at all.

> - what gic versions to common guest OS support? rhelsa, fedora 22, 23, 24 etc.

First support for GIC was introduced in kernel 2.6.14.
GICv2m is supported from 3.19
GICv3 is supported from 3.17

This means that all of that OSes support up to GICv3.

> - besides the OS compat issue, what does gic v3 vs v2 actually provide?
> something super critical for install time?

GICv2 adds a virtualization supports.
GICv2 has some limitations, for example only 8 cpus.
GICv2m adds MSI and MSI-X support.
GICv3 is an update of GICv2 and adds MSI and MSI-X support, and removes the cpu
limitation and adds some other features.

> - is gic setting something that can be changed later without guest impact?

I guess that it's safe to change GIC version for a guest.  But if you would
change GIC from v3 to v2 and the guest has more than 8 cpus KVM wouldn't allow
to start that guest.
 
> I'm trying to answer the question 'when do users want to change that default',
> outside of obvious dev/testing scenarios. If there isn't presently, or planned
> for the near future, a critical case where the user needs to change the
> default just to get a booting/installing VM, then I'd rather not put this in
> the GUI and just save it for virt-install/virt-xml

I understand this point.  The least we should do in GUI is to display the GIC
version.  There is a potential use-case that if you migrate a guest from GICv2
only host to GICv3 host, you would probably like to change the GIC version and
also if you have an OS that supports only GICv2, you would probably want to set
GIC version.  This would be also nice to get from libosinfo.

Pavel