From: Dave Martin <Dave.Martin@arm.com>
To: kvmarm@lists.cs.columbia.edu
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Okamoto Takayuki" <tokamoto@jp.fujitsu.com>,
"Christoffer Dall" <cdall@kernel.org>,
"Ard Biesheuvel" <ard.biesheuvel@linaro.org>,
"Marc Zyngier" <marc.zyngier@arm.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will.deacon@arm.com>,
"Zhang Lei" <zhang.lei@jp.fujitsu.com>,
"Julien Grall" <julien.grall@arm.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 24/27] KVM: arm64/sve: Allow userspace to enable SVE for vcpus
Date: Tue, 19 Mar 2019 17:52:15 +0000 [thread overview]
Message-ID: <1553017938-710-25-git-send-email-Dave.Martin@arm.com> (raw)
In-Reply-To: <1553017938-710-1-git-send-email-Dave.Martin@arm.com>
Now that all the pieces are in place, this patch offers a new flag
KVM_ARM_VCPU_SVE that userspace can pass to KVM_ARM_VCPU_INIT to
turn on SVE for the guest, on a per-vcpu basis.
As part of this, support for initialisation and reset of the SVE
vector length set and registers is added in the appropriate places,
as well as finally setting the KVM_ARM64_GUEST_HAS_SVE vcpu flag,
to turn on the SVE support code.
Allocation of the SVE register storage in vcpu->arch.sve_state is
deferred until the SVE configuration is finalized, by which time
the size of the registers is known.
Setting the vector lengths supported by the vcpu is considered
configuration of the emulated hardware rather than runtime
configuration, so no support is offered for changing the vector
lengths available to an existing vcpu across reset.
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
Changes since v5:
* Refactored to make the code flow clearer and clarify responsiblity
for the various initialisation phases/checks.
In place of the previous, confusingly dual-purpose kvm_reset_sve(),
enabling and resetting of SVE are split into separate functions and
called as appropriate from kvm_reset_vcpu().
To avoid interactions with preempt_disable(), memory allocation is
done in the kvm_vcpu_first_fun_init() path instead. To achieve
this, the SVE memory allocation is moved to kvm_arm_vcpu_finalize(),
which now takes on the role of actually doing deferred setup instead
of just setting a flag to indicate that the setup was done.
* Add has_vhe() sanity-check into kvm_vcpu_enable_sve(), since it
makes more sense here than when resetting the vcpu.
* When checking for SVE finalization in kvm_reset_vcpu(), call the new
SVE-specific function kvm_arm_vcpu_sve_finalized(). The new generic
check kvm_arm_vcpu_is_finalized() is unnecessarily broad here: using
the appropriate specific check makes the code more self-describing.
* Definition of KVM_ARM_VCPU_SVE moved to KVM: arm64/sve: Add pseudo-
register for the guest's vector lengths (which needs it for the
KVM_ARM_VCPU_FINALIZE ioctl).
---
arch/arm64/include/asm/kvm_host.h | 3 +--
arch/arm64/kvm/reset.c | 45 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 5475cc4..9d57cf8 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -49,8 +49,7 @@
#define KVM_MAX_VCPUS VGIC_V3_MAX_CPUS
-/* Will be incremented when KVM_ARM_VCPU_SVE is fully implemented: */
-#define KVM_VCPU_MAX_FEATURES 4
+#define KVM_VCPU_MAX_FEATURES 5
#define KVM_REQ_SLEEP \
KVM_ARCH_REQ_FLAGS(0, KVM_REQUEST_WAIT | KVM_REQUEST_NO_WAKEUP)
diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index e7f9c06..4f04dbf 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -20,10 +20,12 @@
*/
#include <linux/errno.h>
+#include <linux/kernel.h>
#include <linux/kvm_host.h>
#include <linux/kvm.h>
#include <linux/hw_breakpoint.h>
#include <linux/slab.h>
+#include <linux/string.h>
#include <linux/types.h>
#include <kvm/arm_arch_timer.h>
@@ -37,6 +39,7 @@
#include <asm/kvm_coproc.h>
#include <asm/kvm_emulate.h>
#include <asm/kvm_mmu.h>
+#include <asm/virt.h>
/* Maximum phys_shift supported for any VM on this host */
static u32 kvm_ipa_limit;
@@ -130,6 +133,27 @@ int kvm_arm_init_arch_resources(void)
return 0;
}
+static int kvm_vcpu_enable_sve(struct kvm_vcpu *vcpu)
+{
+ if (!system_supports_sve())
+ return -EINVAL;
+
+ /* Verify that KVM startup enforced this when SVE was detected: */
+ if (WARN_ON(!has_vhe()))
+ return -EINVAL;
+
+ vcpu->arch.sve_max_vl = kvm_sve_max_vl;
+
+ /*
+ * Userspace can still customize the vector lengths by writing
+ * KVM_REG_ARM64_SVE_VLS. Allocation is deferred until
+ * kvm_arm_vcpu_finalize(), which freezes the configuration.
+ */
+ vcpu->arch.flags |= KVM_ARM64_GUEST_HAS_SVE;
+
+ return 0;
+}
+
/*
* Finalize vcpu's maximum SVE vector length, allocating
* vcpu->arch.sve_state as necessary.
@@ -188,13 +212,20 @@ void kvm_arch_vcpu_uninit(struct kvm_vcpu *vcpu)
kfree(vcpu->arch.sve_state);
}
+static void kvm_vcpu_reset_sve(struct kvm_vcpu *vcpu)
+{
+ if (vcpu_has_sve(vcpu))
+ memset(vcpu->arch.sve_state, 0, vcpu_sve_state_size(vcpu));
+}
+
/**
* kvm_reset_vcpu - sets core registers and sys_regs to reset value
* @vcpu: The VCPU pointer
*
* This function finds the right table above and sets the registers on
* the virtual CPU struct to their architecturally defined reset
- * values.
+ * values, except for registers whose reset is deferred until
+ * kvm_arm_vcpu_finalize().
*
* Note: This function can be called from two paths: The KVM_ARM_VCPU_INIT
* ioctl or as part of handling a request issued by another VCPU in the PSCI
@@ -217,6 +248,18 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
if (loaded)
kvm_arch_vcpu_put(vcpu);
+ if (!kvm_arm_vcpu_sve_finalized(vcpu)) {
+ /* KVM_ARM_VCPU_INIT: enable features needing deferred setup */
+ if (test_bit(KVM_ARM_VCPU_SVE, vcpu->arch.features)) {
+ ret = kvm_vcpu_enable_sve(vcpu);
+ if (ret)
+ goto out;
+ }
+ } else {
+ /* KVM_RUN: reset deferred features' state */
+ kvm_vcpu_reset_sve(vcpu);
+ }
+
switch (vcpu->arch.target) {
default:
if (test_bit(KVM_ARM_VCPU_EL1_32BIT, vcpu->arch.features)) {
--
2.1.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-19 18:07 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-19 17:51 [PATCH v5 00/26] KVM: arm64: SVE guest support Dave Martin
2019-03-19 17:51 ` [PATCH v6 01/27] KVM: Documentation: Document arm64 core registers in detail Dave Martin
2019-03-19 17:51 ` [PATCH v6 02/27] arm64: fpsimd: Always set TIF_FOREIGN_FPSTATE on task state flush Dave Martin
2019-03-19 17:51 ` [PATCH v6 03/27] KVM: arm64: Delete orphaned declaration for __fpsimd_enabled() Dave Martin
2019-03-19 17:51 ` [PATCH v6 04/27] KVM: arm64: Refactor kvm_arm_num_regs() for easier maintenance Dave Martin
2019-03-19 17:51 ` [PATCH v6 05/27] KVM: arm64: Add missing #includes to kvm_host.h Dave Martin
2019-03-19 17:51 ` [PATCH v6 06/27] arm64/sve: Clarify role of the VQ map maintenance functions Dave Martin
2019-03-19 17:51 ` [PATCH v6 07/27] arm64/sve: Check SVE virtualisability Dave Martin
2019-03-19 17:51 ` [PATCH v6 08/27] arm64/sve: Enable SVE state tracking for non-task contexts Dave Martin
2019-03-19 17:52 ` [PATCH v6 09/27] KVM: arm64: Add a vcpu flag to control SVE visibility for the guest Dave Martin
2019-03-19 17:52 ` [PATCH v6 10/27] KVM: arm64: Propagate vcpu into read_id_reg() Dave Martin
2019-03-19 17:52 ` [PATCH v6 11/27] KVM: arm64: Support runtime sysreg visibility filtering Dave Martin
2019-04-02 2:49 ` Amit Daniel Kachhap
2019-03-19 17:52 ` [PATCH v6 12/27] KVM: arm64/sve: System register context switch and access support Dave Martin
2019-03-26 13:58 ` Julien Thierry
2019-03-19 17:52 ` [PATCH v6 13/27] KVM: arm64/sve: Context switch the SVE registers Dave Martin
2019-03-27 8:15 ` Julien Thierry
2019-03-19 17:52 ` [PATCH v6 14/27] KVM: Allow 2048-bit register access via ioctl interface Dave Martin
2019-03-19 17:52 ` [PATCH v6 15/27] KVM: arm64: Add missing #include of <linux/string.h> in guest.c Dave Martin
2019-03-19 17:52 ` [PATCH v6 16/27] KVM: arm64: Factor out core register ID enumeration Dave Martin
2019-03-27 8:46 ` Julien Thierry
2019-03-19 17:52 ` [PATCH v6 17/27] KVM: arm64: Reject ioctl access to FPSIMD V-regs on SVE vcpus Dave Martin
2019-03-27 8:46 ` Julien Thierry
2019-03-19 17:52 ` [PATCH v6 18/27] KVM: arm64/sve: Add SVE support to register access ioctl interface Dave Martin
2019-03-27 9:23 ` Julien Thierry
2019-03-19 17:52 ` [PATCH v6 19/27] KVM: arm64: Enumerate SVE register indices for KVM_GET_REG_LIST Dave Martin
2019-03-27 9:47 ` Julien Thierry
2019-03-27 10:33 ` Dave Martin
2019-03-27 15:21 ` Julien Thierry
2019-03-28 12:27 ` Dave Martin
2019-03-28 14:29 ` Julien Thierry
2019-03-28 16:48 ` Dave Martin
2019-03-28 16:59 ` Julien Thierry
2019-03-19 17:52 ` [PATCH v6 20/27] arm64/sve: In-kernel vector length availability query interface Dave Martin
2019-03-19 17:52 ` [PATCH v6 21/27] KVM: arm/arm64: Add hook for arch-specific KVM initialisation Dave Martin
2019-03-27 10:07 ` Julien Thierry
2019-03-27 10:41 ` Dave Martin
2019-03-27 15:23 ` Julien Thierry
2019-03-19 17:52 ` [PATCH v6 22/27] KVM: arm/arm64: Add KVM_ARM_VCPU_FINALIZE ioctl Dave Martin
2019-03-27 14:07 ` Julien Thierry
2019-03-27 17:42 ` Dave Martin
2019-03-19 17:52 ` [PATCH v6 23/27] KVM: arm64/sve: Add pseudo-register for the guest's vector lengths Dave Martin
2019-03-27 14:57 ` Julien Thierry
2019-03-19 17:52 ` Dave Martin [this message]
2019-03-27 15:15 ` [PATCH v6 24/27] KVM: arm64/sve: Allow userspace to enable SVE for vcpus Julien Thierry
2019-03-19 17:52 ` [PATCH v6 25/27] KVM: arm64: Add a capability to advertise SVE support Dave Martin
2019-03-27 15:16 ` Julien Thierry
2019-03-19 17:52 ` [PATCH v6 26/27] KVM: Document errors for KVM_GET_ONE_REG and KVM_SET_ONE_REG Dave Martin
2019-03-19 17:52 ` [PATCH v6 27/27] KVM: arm64/sve: Document KVM API extensions for SVE Dave Martin
2019-03-19 17:58 ` [PATCH v5 00/26] KVM: arm64: SVE guest support Dave Martin
2019-03-27 5:51 ` Zhang, Lei
2019-03-20 12:30 ` Dave Martin
2019-03-25 16:32 ` Andrew Jones
2019-03-25 16:38 ` Peter Maydell
2019-03-25 16:49 ` Andrew Jones
2019-03-26 11:28 ` Dave Martin
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=1553017938-710-25-git-send-email-Dave.Martin@arm.com \
--to=dave.martin@arm.com \
--cc=alex.bennee@linaro.org \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=cdall@kernel.org \
--cc=julien.grall@arm.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=marc.zyngier@arm.com \
--cc=peter.maydell@linaro.org \
--cc=tokamoto@jp.fujitsu.com \
--cc=will.deacon@arm.com \
--cc=zhang.lei@jp.fujitsu.com \
/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;
as well as URLs for NNTP newsgroup(s).