Hi Marc,

On 28/05/2020 13:38, Marc Zyngier wrote:

On 2020-05-28 13:36, Marc Zyngier wrote:

quoted

On 2020-05-26 17:18, James Morse wrote:

quoted

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.

quoted

quoted

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

quoted

quoted

@@ -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.

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel