linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Joey Gouly <joey.gouly@arm.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	kvm@vger.kernel.org, Suzuki K Poulose <suzuki.poulose@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Christoffer Dall <christoffer.dall@arm.com>
Subject: Re: [PATCH 06/11] KVM: arm64: nv: Acceletate EL0 counter accesses from hypervisor context
Date: Thu, 05 Dec 2024 13:31:16 +0000	[thread overview]
Message-ID: <86h67itfx7.wl-maz@kernel.org> (raw)
In-Reply-To: <20241205120707.GA102570@e124191.cambridge.arm.com>

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.


  reply	other threads:[~2024-12-05 13:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-02 17:21 [PATCH 00/11] KVM: arm64: Add NV timer support Marc Zyngier
2024-12-02 17:21 ` [PATCH 01/11] KVM: arm64: nv: Add handling of EL2-specific timer registers Marc Zyngier
2024-12-02 17:21 ` [PATCH 02/11] KVM: arm64: nv: Sync nested timer state with FEAT_NV2 Marc Zyngier
2024-12-05  0:26   ` Oliver Upton
2024-12-02 17:21 ` [PATCH 03/11] KVM: arm64: nv: Publish emulated timer interrupt state in the in-memory state Marc Zyngier
2024-12-02 17:21 ` [PATCH 04/11] KVM: arm64: nv: Use FEAT_ECV to trap access to EL0 timers Marc Zyngier
2024-12-02 17:21 ` [PATCH 05/11] KVM: arm64: nv: Accelerate EL0 timer read accesses when FEAT_ECV in use Marc Zyngier
2024-12-02 17:21 ` [PATCH 06/11] KVM: arm64: nv: Acceletate EL0 counter accesses from hypervisor context Marc Zyngier
2024-12-05  0:37   ` Oliver Upton
2024-12-05 11:03     ` Marc Zyngier
2024-12-05 17:07       ` Oliver Upton
2024-12-05 12:07   ` Joey Gouly
2024-12-05 13:31     ` Marc Zyngier [this message]
2024-12-02 17:21 ` [PATCH 07/11] KVM: arm64: Handle counter access early in non-HYP context Marc Zyngier
2024-12-02 17:21 ` [PATCH 08/11] KVM: arm64: nv: Add trap routing for CNTHCTL_EL2.EL1{NVPCT,NVVCT,TVT,TVCT} Marc Zyngier
2024-12-02 17:21 ` [PATCH 09/11] KVM: arm64: nv: Propagate CNTHCTL_EL2.EL1NV{P,V}CT bits Marc Zyngier
2024-12-02 17:21 ` [PATCH 10/11] KVM: arm64: nv: Sanitise CNTHCTL_EL2 Marc Zyngier
2024-12-02 17:21 ` [PATCH 11/11] KVM: arm64: Work around x1e's CNTVOFF_EL2 bogosity Marc Zyngier
2024-12-05  0:40 ` [PATCH 00/11] KVM: arm64: Add NV timer support Oliver Upton
2024-12-09 14:24 ` Chase Conklin
2024-12-09 15:15   ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86h67itfx7.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=andersson@kernel.org \
    --cc=christoffer.dall@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oliver.upton@linux.dev \
    --cc=suzuki.poulose@arm.com \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).