[libvirt] [PATCH v2 0/3] Add support for gic-version machine option

Pavel Fedin p.fedin at samsung.com
Thu Oct 1 11:31:03 UTC 2015


> I think Cole wanted to know more like how it can be useful for end
> users.  Since I see GIC as something similar to APIC, I'm guessing the
> usefulness won't be directly visible, but should help.  About what
> exactly it does or what are the differences between, that I cannot
> help with, unfortunately.

 Ah, i assumed you know ARM architecture, sorry.
 So, GIC for ARM is really what is APIC for x86. It's an interrupt controller. There are several
generations of this controller, up to 3 as of now (there is spec for v4, but i don't know any
real-life implementation, additionally it's fully compatible with v3). v1 is really obsolete, and
AFAIK v2 is fully compatible with it, so for us the only important ones are v2 and v3.
 v2 is what was included into the majority of ARM32 systems. Some ARM64 systems use it too, but it
has a number of limitations. The largest one is that it cannot support more than 16 CPUs. In order
to overcome this, GICv3 was developed. GICv3 is significantly different from GICv2, so it requires
own implementation, and own kernel driver.
 The next thing concerns virtualization, and here comes our qemu support. GICv3 can include
backwards v2 compatibility, but only as an option. And, for example, on my board there's no such
option. Therefore, in order to be able to use KVM GIC acceleration, you have to emulate GICv3 guest
on such a host. You simply will be unable to run GICv2 guest under KVM in this case.
 So, "GIC type" setting should be thought of like a "board subtype". This is different hardware,
with different software support.

> > When choosing 'virt' machine type for ARM architecture.
> >
> Unconditionally?  Doesn't that pose a problem, e.g. for requesting
> version that is not supported

 It shouldn't. If you specify version unsupported by qemu, qemu will complain. I guess, the same
with any other option.

> or breaking something that expects lower version?

 qemu's policy is to default to 2. libvirt's policy is NOT to specify gic-version property unless
value different from 2 is explicitly specified in the XML. I guess, virt-manager could also default
to '2' (or 'Hypervisor's default', which would be the same).

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia

More information about the libvir-list mailing list