HCR_EL2.E2H is nasty, as a flip of this bit completely changes the way
we deal with a lot of the state. So when the guest flips this bit
(sysregs are live), do the put/load dance so that we have a consistent
state.

Yes, this is slow. Don't do it.

Suggested-by: Alexandru Elisei <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
---
 arch/arm64/kvm/sys_regs.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 2c1ab8cd58b4..0d29d9d59c3f 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -187,9 +187,24 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, 
int reg)
                goto memory_write;
 
        if (unlikely(get_el2_mapping(reg, &el1r, &xlate))) {
+               bool need_put_load;
+
                if (!is_hyp_ctxt(vcpu))
                        goto memory_write;
 
+               /*
+                * HCR_EL2.E2H is nasty: it changes the way we interpret a
+                * lot of the EL2 state, so treat is as a full state
+                * transition.
+                */
+               need_put_load = ((reg == HCR_EL2) &&
+                                vcpu_el2_e2h_is_set(vcpu) != !!(val & 
HCR_E2H));
+
+               if (need_put_load) {
+                       preempt_disable();
+                       kvm_arch_vcpu_put(vcpu);
+               }
+
                /*
                 * Always store a copy of the write to memory to avoid having
                 * to reverse-translate virtual EL2 system registers for a
@@ -197,6 +212,11 @@ void vcpu_write_sys_reg(struct kvm_vcpu *vcpu, u64 val, 
int reg)
                 */
                __vcpu_sys_reg(vcpu, reg) = val;
 
+               if (need_put_load) {
+                       kvm_arch_vcpu_load(vcpu, smp_processor_id());
+                       preempt_enable();
+               }
+
                switch (reg) {
                case ELR_EL2:
                        write_sysreg_el1(val, SYS_ELR);
-- 
2.29.2

_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Reply via email to