Re: [libvirt] [PATCH v2 0/3] Add support for gic-version machine option
Hello!
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