And actually, maybe we can handle that pretty cheaply. If userspace
tries to restore GICD_TYPER2 to a value that isn't what KVM can
offer, we just return an error. Exactly like we do for GICD_IIDR.
Hence the following patch:
diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c b/virt/kvm/arm/vgic/vgic-mmio-v3.c
index 28b639fd1abc..e72dcc454247 100644
--- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
+++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
@@ -156,6 +156,7 @@ static int vgic_mmio_uaccess_write_v3_misc(struct kvm_vcpu *vcpu,
ÂÂÂÂ struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
ÂÂÂÂ switch (addr & 0x0c) {
+ÂÂÂ case GICD_TYPER2:
ÂÂÂÂ case GICD_IIDR:
ÂÂÂÂÂÂÂÂ if (val != vgic_mmio_read_v3_misc(vcpu, addr, len))
ÂÂÂÂÂÂÂÂÂÂÂÂ return -EINVAL;
Being a RO register, writing something that isn't compatible with the
possible behaviour of the hypervisor will just return an error.
This is really a nice point to address my concern! I'm happy to see
this in v6 now.
What do you think?
I agreed with you, with a bit nervous though. Some old guests (which
have no knowledge about GICv4.1 vSGIs and don't care about nASSGIcap
at all) will also fail to migrate from A to B, just because now we
present two different (unused) GICD_TYPER2 registers to them.
Is it a little unfair to them :-) ?