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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list