Hello! > We are not. Support for GICv2 vs v3 should be dealt with > by suitable machine properties
I don't remember whether i clearly wrote about it... First i added a property, like -machine virt,gicv3=on. But then i decided to stick back to different machine name because libvirt does not have mechanism for passing machine options. > (and by figuring out how > we handle probing for which of the two the host kernel > can provide us). This is tricky. I thought about it. Kernel offers us only KVM_CAP_IRQCHIP Boolean. But it does not tell us which irqchip. Possible variants are: a) Host with GICv2 - this can only be v2. b) Host with GICv3 with backwards compatibility option - this can be both b) Host with GICv3 without compatibility option - this can only be v3. Perhaps we could do a probe in kvm_arch_irqchip_create(), however i'm not sure what happens in the kernel when this is called. This call actually instantiates the device, but drops its fd. I suggest, the device is still created, and next attempt to do it will just return the same fd. And i don't know what happens if we create both GICs (i cannot test because i don't have machine capable of doing it). OTOH, if we don't have in-kernel acceleration, perhaps the good idea is stick to what the user wants, and use emulation. Yes, i know about problems with generic timer in this case, but this if different issue which can also be fixed. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia
