Re: [PATCH 06/11] KVM: arm64: nv: Acceletate EL0 counter accesses from hypervisor context

Marc Zyngier
2024-12-05T13:31:19Z

On Thu, 05 Dec 2024 12:07:07 +0000,
Joey Gouly <joey.gouly@arm.com> wrote:
>
> On Mon, Dec 02, 2024 at 05:21:29PM +0000, Marc Zyngier wrote:
> > Similarly to handling the physical timer accesses early when FEAT_ECV
> > causes a trap, we try to handle the physical counter without returning
> > to the general sysreg handling.
> >
> > More surprisingly, we introduce something similar for the virtual
> > counter. Although this isn't necessary yet, it will prove useful on
> > systems that have a broken CNTVOFF_EL2 implementation. Yes, they exist.
> >
>
> > Special care is taken to offset reads of the counter with the host's
> > CNTPOFF_EL2, as we perform this with TGE clear.
>
> Can you explain this part a bit more? I'm assuming it's somehow related to the
> arch_timer_read_cntpct_el0() call.
>
> However I think we're at EL2 inside kvm_hyp_handle_timer(), so reading
> CNTPCT_EL0 won't involve CNTPOFF_EL2.
>
> What am I missing/misunderstanding?

I think the wording above is particularly misleading, and leads to
some bad confusion.

Let's go back to basics: we're at host EL2, and handling a trap from
guest EL2. Although you are right that CNTPOFF_EL2 doesn't affect a
direct read of CNTPCT_EL0 from EL2, we are emulating it as if it was
executed from EL1 (guest EL2 being EL1).

So any offsetting that would be applied if we were not trapping
CNTPCT_EL0 must still be applied. In the case of a read from
hypervisor context, this is the VM-wide offset.

But this makes me realise that...

>
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kvm/hyp/include/hyp/switch.h | 5 +++++
> > arch/arm64/kvm/hyp/vhe/switch.c | 13 +++++++++++++
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > index 34f53707892df..30e572de28749 100644
> > --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> > +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > @@ -501,6 +501,11 @@ static inline bool handle_tx2_tvm(struct kvm_vcpu *vcpu)
> > return true;
> > }
> >
> > +static inline u64 compute_counter_value(struct arch_timer_context *ctxt)
> > +{
> > + return arch_timer_read_cntpct_el0() - timer_get_offset(ctxt);
> > +}
> > +
> > static bool kvm_hyp_handle_cntpct(struct kvm_vcpu *vcpu)
> > {
> > struct arch_timer_context *ctxt;
> > diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> > index b014b0b10bf5d..49815a8a4c9bc 100644
> > --- a/arch/arm64/kvm/hyp/vhe/switch.c
> > +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> > @@ -296,6 +296,13 @@ static bool kvm_hyp_handle_timer(struct kvm_vcpu *vcpu, u64 *exit_code)
> > val = __vcpu_sys_reg(vcpu, CNTP_CVAL_EL0);
> > }
> > break;
> > + case SYS_CNTPCT_EL0:
> > + case SYS_CNTPCTSS_EL0:
> > + /* If !ELIsInHost(EL0), the guest's CNTPOFF_EL2 applies */
> > + val = compute_counter_value(!(vcpu_el2_e2h_is_set(vcpu) &&
> > + vcpu_el2_tge_is_set(vcpu)) ?
> > + vcpu_ptimer(vcpu) : vcpu_hptimer(vcpu));

... this should be simplified, because there is no case where we can
be in HYP context *and* not be using the hptimer() context (everything
else would be handled by kvm_handle_cntxct()).

I'm minded to change this to:

diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index a8b1a23712329..5a79ed0aac613 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -305,10 +305,7 @@ static bool kvm_hyp_handle_timer(struct kvm_vcpu *vcpu, u64 *exit_code)
break;
case SYS_CNTPCT_EL0:
case SYS_CNTPCTSS_EL0:
- /* If !ELIsInHost(EL0), the guest's CNTPOFF_EL2 applies */
- val = compute_counter_value(!(vcpu_el2_e2h_is_set(vcpu) &&
- vcpu_el2_tge_is_set(vcpu)) ?
- vcpu_ptimer(vcpu) : vcpu_hptimer(vcpu));
+ val = compute_counter_value(vcpu_hptimer(vcpu));
break;
case SYS_CNTV_CTL_EL02:
val = __vcpu_sys_reg(vcpu, CNTV_CTL_EL0);

Thanks,

M.

--
Without deviation from the norm, progress is not possible.