All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org, "Oliver Upton" <oupton@kernel.org>,
	kvmarm@lists.linux.dev
Subject: Re: [PATCH 10/28] KVM: arm64: Relax CNTHCTL_EL2 handling when FEAT_NV2p1 is present
Date: Thu, 02 Jul 2026 18:46:52 +0100	[thread overview]
Message-ID: <871pdl8esz.wl-maz@kernel.org> (raw)
In-Reply-To: <20260702162132.091A51F000E9@smtp.kernel.org>

On Thu, 02 Jul 2026 17:21:31 +0100,
sashiko-bot@kernel.org wrote:
> 
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> 
> New issues:
> - [High] Unconditional use of the CNTKCTL_EL1 hardware alias under FEAT_NV2p1 clobbers the CNTHCTL_EL2.ECV bit for both the host and the guest.
> 
> Pre-existing issues:
> - [High] Writes to the control-plane system registers CNTHCTL_EL2 and CNTKCTL_EL1 are missing a mandatory ISB instruction.
> --
> 
> commit 71cc9698fb316a6dc28bed5d5465cd03b6074925
> Author: Marc Zyngier <maz@kernel.org>
> 
> KVM: arm64: Relax CNTHCTL_EL2 handling when FEAT_NV2p1 is present
> 
> This patch optimizes CNTHCTL_EL2 accesses when FEAT_NV2p1 is present by
> treating the CNTKCTL_EL1 accessor as normal. It replaces the split approach
> with direct use of the CNTKCTL_EL1 hardware alias.
> 
> > diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
> > index 4155fe89b58a1..db60facad9f3c 100644
> > --- a/arch/arm64/kvm/arch_timer.c
> > +++ b/arch/arm64/kvm/arch_timer.c
> 
> [ ... ]
> 
> > @@ -876,8 +876,14 @@ static void timer_set_traps(struct kvm_vcpu *vcpu, struct timer_map *map)
> >  	assign_clear_set_bit(tvt02, CNTHCTL_EL1NVVCT, clr, set);
> >  	assign_clear_set_bit(tpt02, CNTHCTL_EL1NVPCT, clr, set);
> >  
> > -	/* This only happens on VHE, so use the CNTHCTL_EL2 accessor. */
> > -	sysreg_clear_set(cnthctl_el2, clr, set);
> > +	/*
> > +	 * This only happens on VHE, so use the CNTHCTL_EL2 accessor, unless
> > +	 * we are sure CNTKCTL_EL1 is completely stateful with FEAT_NV2p1.
> > +	 */
> > +	if (!cpus_have_final_cap(ARM64_HAS_NV2P1))
> > +		sysreg_clear_set(cnthctl_el2, clr, set);
> > +	else
> > +		sysreg_clear_set(cntkctl_el1, clr, set);
> 
> [Severity: High]
> Does this read-modify-write on the host's physical state using the
> cntkctl_el1 alias inadvertently clear KVM's own physical CNTHCTL_EL2.ECV bit?
> 
> Since the alias drops or mishandles the ECV bit, reading it might return ECV
> as 0 and write it back as 0. This could silently disable the host's ECV
> functionality, such as CNTPOFF initialization from kvm_timer_init_vhe().

No, and that's the whole point of NV2p1: the CNTKCTL_EL1 bits are
guaranteed to be stateful, and we don't need to do anything else

> [Severity: High]
> This is a pre-existing issue, but shouldn't there be an isb() instruction
> immediately following these control-plane system register writes?

"control-plane"? WTF???

And no. These bits only need to take effect when entering the guest,
for which we already have a context synchronisation event.

> Writing to CNTHCTL_EL2 or CNTKCTL_EL1 without an explicit context
> synchronization event can cause the CPU to operate under a stale timer trap
> configuration for several cycles before returning.

Bollocks.

	M.

-- 
Jazz isn't dead. It just smells funny.

  reply	other threads:[~2026-07-02 17:45 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 16:02 [PATCH 00/28] KVM: arm64: Add support for FEAT_NV2p1 and FEAT_NV3 Marc Zyngier
2026-07-02 16:02 ` [PATCH 01/28] arm64: sysreg: Emit RESx/UNKN values for Mapping definitions Marc Zyngier
2026-07-02 16:19   ` sashiko-bot
2026-07-02 17:41     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 02/28] arm64: Update ID_AA64MMFR4_EL1 description to 2026-03 JSON release Marc Zyngier
2026-07-02 16:02 ` [PATCH 03/28] KVM: arm64: Merge guest's HCRX_EL2 using NV_HCRX_GUEST_EXCLUDE Marc Zyngier
2026-07-02 16:34   ` sashiko-bot
2026-07-02 18:29     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 04/28] KVM: arm64: Drop __HCRX_EL2_* masks Marc Zyngier
2026-07-02 18:34   ` sashiko-bot
2026-07-02 21:10     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 05/28] KVM: arm64: Plumb HCRX_EL2.SRMASKEn in HCRX_EL2 sanitisation Marc Zyngier
2026-07-02 16:28   ` sashiko-bot
2026-07-02 18:18     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 06/28] KVM: arm64: Classify CPTR_EL2 as a SR_LOC_SPECIAL register Marc Zyngier
2026-07-07 11:33   ` Joey Gouly
2026-07-02 16:02 ` [PATCH 07/28] KVM: arm64: Don't evaluate HCR_EL2.NV on ERET fast path Marc Zyngier
2026-07-02 16:24   ` sashiko-bot
2026-07-02 17:57     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 08/28] arm64: Add ARM64_HAS_NV2P1 capability Marc Zyngier
2026-07-02 16:02 ` [PATCH 09/28] KVM: arm64: Relax CPTR_EL2 handling when FEAT_NV2p1 is present Marc Zyngier
2026-07-02 16:02 ` [PATCH 10/28] KVM: arm64: Relax CNTHCTL_EL2 " Marc Zyngier
2026-07-02 16:21   ` sashiko-bot
2026-07-02 17:46     ` Marc Zyngier [this message]
2026-07-02 16:02 ` [PATCH 11/28] KVM: arm64: Expose FEAT_NV2p1 to NV guests Marc Zyngier
2026-07-02 16:28   ` sashiko-bot
2026-07-02 18:23     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 12/28] arm64: Add FEAT_NV2p1 detection Marc Zyngier
2026-07-02 16:02 ` [PATCH 13/28] arm64: sysreg: Add NVHCR_EL2 description as a mirror of HCR_EL2 Marc Zyngier
2026-07-02 16:02 ` [PATCH 14/28] arm64: sysreg: Add HCRX_EL2 bits related to FEAT_NV3 Marc Zyngier
2026-07-02 16:02 ` [PATCH 15/28] arm64: Add ARM64_HAS_NV3 capability Marc Zyngier
2026-07-02 16:02 ` [PATCH 16/28] KVM: arm64: Split NV-specific exit fixups from the non-NV handling Marc Zyngier
2026-07-02 16:02 ` [PATCH 17/28] KVM: arm64: Add NV3 control bits to HCRX_EL2 sanitisation Marc Zyngier
2026-07-02 16:02 ` [PATCH 18/28] KVM: arm64: Add kvm_has_nv{2,3}() predicates Marc Zyngier
2026-07-02 16:25   ` sashiko-bot
2026-07-02 18:01     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 19/28] KVM: arm64: Make HCR_EL2 a non-VNCR register Marc Zyngier
2026-07-02 16:02 ` [PATCH 20/28] KVM: arm64: Add sanitisation for NVHCR_EL2 Marc Zyngier
2026-07-02 16:02 ` [PATCH 21/28] KVM: arm64: Add NVHCR_EL2 handling to the sysreg array Marc Zyngier
2026-07-02 16:02 ` [PATCH 22/28] KVM: arm64: Add routing for NVHCR_EL2 trap Marc Zyngier
2026-07-02 16:26   ` sashiko-bot
2026-07-02 18:14     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 23/28] KVM: arm64: Add NVHCR_EL2 context switching Marc Zyngier
2026-07-02 16:43   ` sashiko-bot
2026-07-02 20:28     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 24/28] KVM: arm64: Engage NV3 ERET trap elision Marc Zyngier
2026-07-02 16:02 ` [PATCH 25/28] KVM: arm64: Engage NV3 TLBI " Marc Zyngier
2026-07-02 16:45   ` sashiko-bot
2026-07-02 21:04     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 26/28] KVM: arm64: Add FEAT_NV3 detection Marc Zyngier
2026-07-02 16:39   ` sashiko-bot
2026-07-02 20:03     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 27/28] KVM: arm64: Expose FEAT_NV3 to guests Marc Zyngier
2026-07-02 16:39   ` sashiko-bot
2026-07-02 20:01     ` Marc Zyngier
2026-07-02 16:02 ` [PATCH 28/28] arm64: Add override for ID_AA64MMFR4_EL1.NV_frac 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=871pdl8esz.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=oupton@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.