From: Fuad Tabba <tabba@google.com>
To: kvmarm@lists.linux.dev
Cc: maz@kernel.org, will@kernel.org, qperret@google.com,
tabba@google.com, seanjc@google.com, alexandru.elisei@arm.com,
catalin.marinas@arm.com, philmd@linaro.org, james.morse@arm.com,
suzuki.poulose@arm.com, oliver.upton@linux.dev,
mark.rutland@arm.com, broonie@kernel.org, joey.gouly@arm.com,
rananta@google.com, smostafa@google.com
Subject: [PATCH v3 20/31] KVM: arm64: Clarify rationale for ZCR_EL1 value restored on guest exit
Date: Fri, 19 Apr 2024 08:59:30 +0100 [thread overview]
Message-ID: <20240419075941.4085061-21-tabba@google.com> (raw)
In-Reply-To: <20240419075941.4085061-1-tabba@google.com>
Expand comment clarifying why the host value representing SVE
vector length being restored for ZCR_EL1 on guest exit isn't the
same as it was on guest entry.
Signed-off-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/kvm/fpsimd.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index 63a6f82934a6..1807d3a79a8a 100644
--- a/arch/arm64/kvm/fpsimd.c
+++ b/arch/arm64/kvm/fpsimd.c
@@ -175,12 +175,34 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
if (vcpu_has_sve(vcpu)) {
__vcpu_sys_reg(vcpu, ZCR_EL1) = read_sysreg_el1(SYS_ZCR);
- /* Restore the VL that was saved when bound to the CPU */
+ /*
+ * Restore the VL that was saved when bound to the CPU,
+ * which is the maximum VL for the guest. Because the
+ * layout of the data when saving the sve state depends
+ * on the VL, we need to use a consistent (i.e., the
+ * maximum) VL.
+ * Note that this means that at guest exit ZCR_EL1 is
+ * not necessarily the same as on guest entry.
+ *
+ * Restoring the VL isn't needed in VHE mode since
+ * ZCR_EL2 (accessed via ZCR_EL1) would fulfill the same
+ * role when doing the save from EL2.
+ */
if (!has_vhe())
sve_cond_update_zcr_vq(vcpu_sve_max_vq(vcpu) - 1,
SYS_ZCR_EL1);
}
+ /*
+ * Flush (save and invalidate) the fpsimd/sve state so that if
+ * the host tries to use fpsimd/sve, it's not using stale data
+ * from the guest.
+ *
+ * Flushing the state sets the TIF_FOREIGN_FPSTATE bit for the
+ * context unconditionally, in both nVHE and VHE. This allows
+ * the kernel to restore the fpsimd/sve state, including ZCR_EL1
+ * when needed.
+ */
fpsimd_save_and_flush_cpu_state();
} else if (has_vhe() && system_supports_sve()) {
/*
--
2.44.0.769.g3c40516874-goog
next prev parent reply other threads:[~2024-04-19 8:00 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-19 7:59 [PATCH v3 00/31] KVM: arm64: Preamble for pKVM Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 01/31] KVM: arm64: Initialize the kvm host data's fpsimd_state pointer in pKVM Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 02/31] KVM: arm64: Move guest_owns_fp_regs() to increase its scope Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 03/31] KVM: arm64: Refactor checks for FP state ownership Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 04/31] KVM: arm64: Do not re-initialize the KVM lock Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 05/31] KVM: arm64: Issue CMOs when tearing down guest s2 pages Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 06/31] KVM: arm64: Avoid BUG-ing from the host abort path Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 07/31] KVM: arm64: Check for PTE validity when checking for executable/cacheable Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 08/31] KVM: arm64: Avoid BBM when changing only s/w bits in Stage-2 PTE Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 09/31] KVM: arm64: Support TLB invalidation in guest context Fuad Tabba
2024-04-19 20:54 ` Oliver Upton
2024-04-22 8:11 ` Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 10/31] KVM: arm64: Do not map the host fpsimd state to hyp in pKVM Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 11/31] KVM: arm64: Remove locking from EL2 allocation fast-paths Fuad Tabba
2024-04-19 20:42 ` Oliver Upton
2024-04-22 8:09 ` Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 12/31] KVM: arm64: Prevent kmemleak from accessing .hyp.data Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 13/31] KVM: arm64: Fix comment for __pkvm_vcpu_init_traps() Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 14/31] KVM: arm64: Change kvm_handle_mmio_return() return polarity Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 15/31] KVM: arm64: Move setting the page as dirty out of the critical section Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 16/31] KVM: arm64: Simplify vgic-v3 hypercalls Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 17/31] KVM: arm64: Add is_pkvm_initialized() helper Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 18/31] KVM: arm64: Introduce and use predicates that check for protected VMs Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 19/31] KVM: arm64: Move pstate reset value definitions to kvm_arm.h Fuad Tabba
2024-04-19 7:59 ` Fuad Tabba [this message]
2024-04-19 7:59 ` [PATCH v3 21/31] KVM: arm64: Refactor calculating SVE state size to use helpers Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 22/31] KVM: arm64: Move some kvm_psci functions to a shared header Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 23/31] KVM: arm64: Refactor reset_mpidr() to extract its computation Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 24/31] KVM: arm64: Refactor kvm_vcpu_enable_ptrauth() for hyp use Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 25/31] KVM: arm64: Introduce hyp_rwlock_t Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 26/31] KVM: arm64: Add atomics-based checking refcount implementation at EL2 Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 27/31] KVM: arm64: Use atomic refcount helpers for 'struct hyp_page::refcount' Fuad Tabba
2024-04-19 20:52 ` Oliver Upton
2024-04-22 8:10 ` Fuad Tabba
2024-04-22 13:08 ` Fuad Tabba
2024-04-22 20:46 ` Oliver Upton
2024-04-22 23:44 ` Will Deacon
2024-04-23 1:15 ` Oliver Upton
2024-04-19 7:59 ` [PATCH v3 28/31] KVM: arm64: Reformat/beautify PTP hypercall documentation Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 29/31] KVM: arm64: Rename firmware pseudo-register documentation file Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 30/31] KVM: arm64: Document the KVM/arm64-specific calls in hypercalls.rst Fuad Tabba
2024-04-19 7:59 ` [PATCH v3 31/31] KVM: arm64: Force injection of a data abort on NISV MMIO exit Fuad Tabba
2024-04-19 20:28 ` Oliver Upton
2024-04-22 8:07 ` Fuad Tabba
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=20240419075941.4085061-21-tabba@google.com \
--to=tabba@google.com \
--cc=alexandru.elisei@arm.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=philmd@linaro.org \
--cc=qperret@google.com \
--cc=rananta@google.com \
--cc=seanjc@google.com \
--cc=smostafa@google.com \
--cc=suzuki.poulose@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.