Hi Marc, On 28/05/2020 13:38, Marc Zyngier wrote: > On 2020-05-28 13:36, Marc Zyngier wrote: >> On 2020-05-26 17:18, James Morse wrote: >>> KVM sets HCR_EL2.TACR (which it calls HCR_TAC) via HCR_GUEST_FLAGS. >>> This means ACTLR* accesses from the guest are always trapped, and >>> always return the value in the sys_regs array. >>> >>> The guest can't change the value of these registers, so we are >>> save restoring the reset value, which came from the host. >>> >>> Stop save/restoring this register. >>> >>> This also stops this register being affected by sysregs_loaded_on_cpu, >>> so we can provide 32 bit accessors that always use the in-memory copy. >>> diff --git a/arch/arm64/kvm/hyp/sysreg-sr.c b/arch/arm64/kvm/hyp/sysreg-sr.c >>> index 75b1925763f1..57116cf3a1a5 100644 >>> --- a/arch/arm64/kvm/hyp/sysreg-sr.c >>> +++ b/arch/arm64/kvm/hyp/sysreg-sr.c >>> @@ -133,7 +132,6 @@ static void __hyp_text >>> __sysreg_restore_el1_state(struct kvm_cpu_context *ctxt) >>> isb(); >>> } >>> >>> - write_sysreg(ctxt->sys_regs[ACTLR_EL1], actlr_el1); >> >> If we don't need to save/restore it, we can also drop its presence >> in the sys_regs array. So even user-space accesses read from the hardware register? Fine by me. >> It strikes me that we don't even have a trap handler for this sysreg, >> whether it is 32 or 64bit... That's a bit unfortunate, to say the >> least... > > Ah, no. the sucker is hidden away in "generic_v8"... That thing is A7/A15 (and then user-ABI) legacy right? I was looking at ripping all that out when I ran over these. RFC grade, known not to bisect: http://www.linux-arm.org/git?p=linux-jm.git;a=shortlog;h=refs/heads/kvm_kill_target_table/v0 Thanks, James _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
