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.
next prev 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