public inbox for linux-arm-kernel@lists.infradead.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: Tue, 11 Feb 2025 19:08:15 +0000	[thread overview]
Message-ID: <Z6ugHxri_XlOMKWD@J2N7QTR9R3> (raw)
In-Reply-To: <Z6owjEPNaJ55e9LM@J2N7QTR9R3>

On Mon, Feb 10, 2025 at 05:00:04PM +0000, Mark Rutland wrote:
> | 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.

I had a quick go at this, and there are a few things that I spotted that
got in the way, so I'm not going to spin that immediately, but I'd be
happy to in a short while. Notes below:

(1) I looked at using __activate_cptr_traps() and
    __deactivate_cptr_traps() rather than poking CPACR/CPTR directly,
    to ensure that this is kept in-sync with the regular guest<->host
    transitions, but that requires a bit of refactoring (e.g. moving
    those *back* into the common header), and potentially requires doing
    a bit of redundant work here, so I'm not sure whether that's
    actually preferable or not.

    If you have a strong preference either way as to doing that or
    poking CPACR/CPTR directly, knowing that would be helfpul.

(2) The cpacr_clear_set() function doesn't behave the same as
    sysreg_clear_set(), and doesn't handle the case where a field is in
    both the 'clr' and 'set' masks as is the case above. For example, if
    one writes the following to clear THEN set the FPEN field, disabling
    traps:

    | cpacr_clear_set(CPACR_EL1_FPEN, CPACR_EL1_FPEN);

    ... the VHE code looks good:

    | mrs     x0, cpacr_el1
    | orr     x1, x0, #0x300000		// set both FPEN bits
    | cmp     x0, x1
    | b.eq    <<skip_write>>
    | msr     cpacr_el1, x1

    ... but the nVHE code does the opposite:

    | mrs     x0, cptr_el2
    | orr     x1, x0, #0x400		// set TFP
    | tbnz    w0, #10, <<skip_write>>
    | msr     cptr_el2, x1

    Luckily this does the right thing for all existing users, but that'd
    need to be cleaned up.

(3) We should be able to get rid of the ISB when writing to FPEXC32_EL2.
    That register has no effect while in AArch64 state, and the ERET
    will synchronize it before AArch32 guest code can be executed.

    That should probably be factored out into save/restore functions
    that are used consistently.

Mark.


  parent reply	other threads:[~2025-02-11 19:10 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
2025-02-10 18:06       ` Will Deacon
2025-02-10 20:03         ` Mark Rutland
2025-02-11 19:08       ` Mark Rutland [this message]
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=Z6ugHxri_XlOMKWD@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox