All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Will Deacon <will@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org, broonie@kernel.org,
	catalin.marinas@arm.com, eauger@redhat.com,
	eric.auger@redhat.com, fweimer@redhat.com, jeremy.linton@arm.com,
	maz@kernel.org, oliver.upton@linux.dev, pbonzini@redhat.com,
	stable@vger.kernel.org, tabba@google.com, wilco.dijkstra@arm.com
Subject: Re: [PATCH v2 2/8] KVM: arm64: Remove host FPSIMD saving for non-protected KVM
Date: Mon, 10 Feb 2025 16:59:56 +0000	[thread overview]
Message-ID: <Z6owjEPNaJ55e9LM@J2N7QTR9R3> (raw)
In-Reply-To: <20250210161242.GC7568@willie-the-truck>

On Mon, Feb 10, 2025 at 04:12:43PM +0000, Will Deacon wrote:
> On Thu, Feb 06, 2025 at 02:10:56PM +0000, Mark Rutland wrote:
> > Now that the host eagerly saves its own FPSIMD/SVE/SME state,
> > non-protected KVM never needs to save the host FPSIMD/SVE/SME state,
> > and the code to do this is never used. Protected KVM still needs to
> > save/restore the host FPSIMD/SVE state to avoid leaking guest state to
> > the host (and to avoid revealing to the host whether the guest used
> > FPSIMD/SVE/SME), and that code needs to be retained.
> > 
> > Remove the unused code and data structures.
> > 
> > To avoid the need for a stub copy of kvm_hyp_save_fpsimd_host() in the
> > VHE hyp code, the nVHE/hVHE version is moved into the shared switch
> > header, where it is only invoked when KVM is in protected mode.
> > 
> > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > Reviewed-by: Mark Brown <broonie@kernel.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Fuad Tabba <tabba@google.com>
> > Cc: Marc Zyngier <maz@kernel.org>
> > Cc: Mark Brown <broonie@kernel.org>
> > Cc: Oliver Upton <oliver.upton@linux.dev>
> > Cc: Will Deacon <will@kernel.org>
> > ---
> >  arch/arm64/include/asm/kvm_host.h       | 20 +++++-------------
> >  arch/arm64/kvm/arm.c                    |  8 -------
> >  arch/arm64/kvm/fpsimd.c                 |  2 --
> >  arch/arm64/kvm/hyp/include/hyp/switch.h | 25 ++++++++++++++++++++--
> >  arch/arm64/kvm/hyp/nvhe/hyp-main.c      |  2 +-
> >  arch/arm64/kvm/hyp/nvhe/switch.c        | 28 -------------------------
> >  arch/arm64/kvm/hyp/vhe/switch.c         |  8 -------
> >  7 files changed, 29 insertions(+), 64 deletions(-)
> 
> [...]
> 
> > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > index f838a45665f26..c5b8a11ac4f50 100644
> > --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> > +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > @@ -375,7 +375,28 @@ static inline void __hyp_sve_save_host(void)
> >  			 true);
> >  }
> >  
> > -static void kvm_hyp_save_fpsimd_host(struct kvm_vcpu *vcpu);
> > +static void kvm_hyp_save_fpsimd_host(struct kvm_vcpu *vcpu)
> > +{
> > +	/*
> > +	 * Non-protected kvm relies on the host restoring its sve state.
> > +	 * Protected kvm restores the host's sve state as not to reveal that
> > +	 * fpsimd was used by a guest nor leak upper sve bits.
> > +	 */
> > +	if (system_supports_sve()) {
> > +		__hyp_sve_save_host();
> > +
> > +		/* Re-enable SVE traps if not supported for the guest vcpu. */
> > +		if (!vcpu_has_sve(vcpu))
> > +			cpacr_clear_set(CPACR_EL1_ZEN, 0);
> > +
> > +	} else {
> > +		__fpsimd_save_state(host_data_ptr(host_ctxt.fp_regs));
> > +	}
> > +
> > +	if (kvm_has_fpmr(kern_hyp_va(vcpu->kvm)))
> > +		*host_data_ptr(fpmr) = read_sysreg_s(SYS_FPMR);
> > +}
> > +
> >  
> >  /*
> >   * We trap the first access to the FP/SIMD to save the host context and
> > @@ -425,7 +446,7 @@ static bool kvm_hyp_handle_fpsimd(struct kvm_vcpu *vcpu, u64 *exit_code)
> >  	isb();
> >  
> >  	/* Write out the host state if it's in the registers */
> > -	if (host_owns_fp_regs())
> > +	if (is_protected_kvm_enabled() && host_owns_fp_regs())
> >  		kvm_hyp_save_fpsimd_host(vcpu);
> 
> I wondered briefly whether this would allow us to clean up the CPACR
> handling a little and avoid the conditional SVE trap re-enabling inside
> kvm_hyp_save_fpsimd_host() but I couldn't come up with a clean way to
> do it without an additional ISB. Hrm.
> 
> Anyway, as far as the patch goes:
> 
> Acked-by: Will Deacon <will@kernel.org>

Thanks!

FWIW, I'd also considered that, and I'd concluded that if anything we
could do a subsequent simplification by pulling that out of
kvm_hyp_save_fpsimd_host() and have kvm_hyp_handle_fpsimd() do something
like:

| static inline bool kvm_hyp_handle_fpsimd(struct kvm_vcpu *vcpu, u64 *exit_code)
| {
| 	...
| 
| 	/* Valid trap */
| 
| 	/*
| 	 * Enable everything EL2 might need to save/restore state.
| 	 * Maybe each of the bits should depend on system_has_xxx()
| 	 */
| 	cpacr_clear_set(0, CPACR_EL1_FPEN | CPACR_EL1_ZEN | CPACR_EL1_SMEN */
| 	isb();
| 
| 	...
| 
| 	/* Write out the host state if it's in the registers */
| 	if (is_protected_kvm_enabled() && host_owns_fp_regs())
| 		kvm_hyp_save_fpsimd_host(vcpu);
| 	
| 	/* Restore guest state */
| 
| 	...
| 
| 	/*
| 	 * Enable traps for the VCPU. The ERET will cause the traps to
| 	 * take effect in the guest, so no ISB is necessary.
| 	 */
| 	cpacr_guest = CPACR_EL1_FPEN;
| 	if (vcpu_has_sve(vcpu))
| 		cpacr_guest |= CPACR_EL1_ZEN;
| 	if (vcpu_has_sme(vcpu))			// whenever we add this
| 		cpacr_guest |= CPACR_EL1_SMEN;
| 	cpacr_clear_set(CPACR_EL1_FPEN | CPACR_EL1_ZEN | CPACR_EL1_SMEN,
| 			cpacr_guest);
| 
| 	return true;
| }

... where we'd still have the CPACR write to re-enable traps, but it'd
be unconditional, and wouldn't need an extra ISB.

If that makes sense to you, I can go spin that as a subsequent cleanup
atop this series.

Mark.


  reply	other threads:[~2025-02-10 17:20 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-06 14:10 [PATCH v2 0/8] KVM: arm64: FPSIMD/SVE/SME fixes Mark Rutland
2025-02-06 14:10 ` [PATCH v2 1/8] KVM: arm64: Unconditionally save+flush host FPSIMD/SVE/SME state Mark Rutland
2025-02-07 12:27   ` Will Deacon
2025-02-07 13:21     ` Mark Rutland
2025-02-10 10:53       ` Marc Zyngier
2025-02-10 15:05       ` Will Deacon
2025-02-06 14:10 ` [PATCH v2 2/8] KVM: arm64: Remove host FPSIMD saving for non-protected KVM Mark Rutland
2025-02-10 16:12   ` Will Deacon
2025-02-10 16:59     ` Mark Rutland [this message]
2025-02-10 18:06       ` Will Deacon
2025-02-10 20:03         ` Mark Rutland
2025-02-11 19:08       ` Mark Rutland
2025-02-06 14:10 ` [PATCH v2 3/8] KVM: arm64: Remove VHE host restore of CPACR_EL1.ZEN Mark Rutland
2025-02-10 16:14   ` Will Deacon
2025-02-06 14:10 ` [PATCH v2 4/8] KVM: arm64: Remove VHE host restore of CPACR_EL1.SMEN Mark Rutland
2025-02-10 16:16   ` Will Deacon
2025-02-06 14:10 ` [PATCH v2 5/8] KVM: arm64: Refactor CPTR trap deactivation Mark Rutland
2025-02-10 16:34   ` Will Deacon
2025-02-06 14:11 ` [PATCH v2 6/8] KVM: arm64: Refactor exit handlers Mark Rutland
2025-02-10 16:37   ` Will Deacon
2025-02-06 14:11 ` [PATCH v2 7/8] KVM: arm64: Mark some header functions as inline Mark Rutland
2025-02-10 16:39   ` Will Deacon
2025-02-06 14:11 ` [PATCH v2 8/8] KVM: arm64: Eagerly switch ZCR_EL{1,2} Mark Rutland
2025-02-06 19:12   ` Mark Brown
2025-02-07  9:34     ` Mark Rutland
2025-02-10 16:53   ` Will Deacon
2025-02-10 17:21     ` Mark Rutland
2025-02-10 18:20       ` Will Deacon
2025-02-10 18:56         ` Mark Rutland
2025-02-11 10:29           ` Will Deacon
2025-02-08  0:27 ` [PATCH v2 0/8] KVM: arm64: FPSIMD/SVE/SME fixes Mark Brown

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=Z6owjEPNaJ55e9LM@J2N7QTR9R3 \
    --to=mark.rutland@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=eauger@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=jeremy.linton@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=pbonzini@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tabba@google.com \
    --cc=wilco.dijkstra@arm.com \
    --cc=will@kernel.org \
    /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.