From: Julien Grall Date: Thu, 19 Oct 2017 17:09:05 +0000 (+0100) Subject: xen/arm: gic-v3: Make sure ICC_SRE_EL1 is restored before ICH_VMCR_EL2 X-Git-Tag: archive/raspbian/4.11.1-1+rpi1~1^2~66^2~1079 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=6ccf25d46c18ff274e68dde8c8da3c656f7699e2;p=xen.git xen/arm: gic-v3: Make sure ICC_SRE_EL1 is restored before ICH_VMCR_EL2 Per 8.4.8 in ARM IHI 0069D, ICH_VMCR_EL2.VFIQEn is RES1 when ICC_SRE_EL1.SRE is 1. This causes a Group 0 interrupt (as generated in GICv2 mode) to be delivered as a FIQ to the guest, with potentially consequence. So we must make sure that ICC_SRE_EL1 has been actually programmed before at ICH_VMCR_EL2. This was discovered when booting EFI in a GICv2 guest on a GICv3 hardware. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index 3c04d4aabc..473e26111f 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -392,7 +392,16 @@ static void gicv3_restore_state(const struct vcpu *v) val |= GICC_SRE_EL2_ENEL1; WRITE_SYSREG32(val, ICC_SRE_EL2); + /* + * VFIQEn is RES1 if ICC_SRE_EL1.SRE is 1. This causes a Group0 + * interrupt (as generated in GICv2 mode) to be delivered as a FIQ + * to the guest, with potentially consequence. So we must make sure + * that ICC_SRE_EL1 has been actually programmed with the value we + * want before starting to mess with the rest of the GIC, and + * VMCR_EL1 in particular. + */ WRITE_SYSREG32(v->arch.gic.v3.sre_el1, ICC_SRE_EL1); + isb(); WRITE_SYSREG32(v->arch.gic.v3.vmcr, ICH_VMCR_EL2); restore_aprn_regs(&v->arch.gic); gicv3_restore_lrs(v);