It appears that there is firmware out there that advertises GICv2
compatibility on GICv3, despite the CPUs not being able to actually do
it. That's a bummer, and at best creates unexpected behaviours for the
users. At worse, it will crash the machine. Awesome!
In order to mitigate this issue, try and validate whether we can
actually flip the CPU into supporting MMIO accesses instead of system
registers. If we can't, ignore the compatibility information and
shout. It's not completely foolproof, but it should cover the existing
broken platforms...
The workaround is much more invasive than Shameer's initial proposal,
as I wanted to keep it localised to KVM instead of spreading the
horror at every level (after all, only KVM is concerned with v2
compatibility).
Tested on a deliberately misconfigured FVP (DT advertising the MMIO
regions with cluster*.gicv3.cpuintf-mmap-access-level=2).
* From v1:
- Fixed silly thinko when computing the configuration state
Marc Zyngier (2):
KVM: arm64: Rename __vgic_v3_get_ich_vtr_el2() to
__vgic_v3_get_gic_config()
KVM: arm64: Workaround firmware wrongly advertising GICv2-on-v3
compatibility
arch/arm64/include/asm/kvm_asm.h | 4 +--
arch/arm64/kvm/hyp/nvhe/hyp-main.c | 6 ++---
arch/arm64/kvm/hyp/vgic-v3-sr.c | 40 ++++++++++++++++++++++++++++--
arch/arm64/kvm/vgic/vgic-v3.c | 12 ++++++---
4 files changed, 52 insertions(+), 10 deletions(-)
--
2.29.2
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
