linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v3 20/24] KVM: arm: Add support for early vcpu configuration ioctls
Date: Tue, 11 Dec 2018 23:28:57 +0000	[thread overview]
Message-ID: <1544570941-7377-21-git-send-email-Dave.Martin@arm.com> (raw)
In-Reply-To: <1544570941-7377-1-git-send-email-Dave.Martin@arm.com>

SVE will require the KVM_ARM_SVE_CONFIG ioctl to be used early to
configure a vcpu before other arch vcpu ioctls will behave in a
consistent way.

To hide these effects from userspace while minimising mess in the
generic code, this patch splits arch vcpu ioctls into two phases:
early configuration ioctls, and normal ioctls.  A new arch helper
vcpu_needs_configuration() reports whether any arch vcpu ioctls
other than early configuration ioctls are allowed.

This entire behaviour will be need to be opt-in for userspace.

There are currently no early configuration ioctls; one will be
added for SVE in a subsequent patch, along with a suitable opt-in
mechanism.

It is assumed that no core vcpu ioctls are affected by any of the
early configuration we want to do.  In any case, most "generic"
vcpu ioctls are stubbed out for arm/arm64 and return -EINVAL.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>

---

Changes since RFC v2:

 * New patch.

   **Discussion required**

   This patch splits arch vcpu ioctls into two phases.  We will
   almost certainly need to do something like this for SVE, since
   until the vector lengths are configured we will be in some kind
   of half-initialised state where most ioctls (in particular
   KVM_GET_REG_LIST, KVM_RUN etc.) cannot be used.

   This is a bit inelegant, and does not interact nicely with
   the core KVM core: we have to assume that all the core vcpu
   ioctls are "harmless" while a vcpu is half-initialised, or
   stubbed out (which seems to be the case for many of the core
   vcpu ioctls on arm/arm64).

   The choice of error codes here may not be ideal.  We should
   try to avoid picking anything that could be confused with other
   error situations.
---
 arch/arm/include/asm/kvm_host.h   | 3 +++
 arch/arm64/include/asm/kvm_host.h | 3 +++
 virt/kvm/arm/arm.c                | 6 ++++++
 3 files changed, 12 insertions(+)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 8d385ec..d61077c 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -365,4 +365,7 @@ static inline int kvm_arm_setup_stage2(struct kvm *kvm, unsigned long *type)
 	return 0;
 }
 
+/* Forbid "ordinary" vcpu ioctls if this returns true: */
+#define vcpu_needs_configuration(vcpu) false
+
 #endif /* __ARM_KVM_HOST_H__ */
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 9fd8729..7599c70 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -536,4 +536,7 @@ void kvm_arch_free_vm(struct kvm *kvm);
 
 int kvm_arm_setup_stage2(struct kvm *kvm, unsigned long *type);
 
+/* Forbid "ordinary" vcpu ioctls if this returns true: */
+#define vcpu_needs_configuration(vcpu) false
+
 #endif /* __ARM64_KVM_HOST_H__ */
diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
index f7bf43a..7bfc06d 100644
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1090,6 +1090,12 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
 	struct kvm_device_attr attr;
 	long r;
 
+	/* Early configuration ioctls will be handled here */
+
+	/* Other ioctls require configuration to have been done first: */
+	if (vcpu_needs_configuration(vcpu))
+		return -EBADFD;
+
 	switch (ioctl) {
 	case KVM_ARM_VCPU_INIT: {
 		struct kvm_vcpu_init init;
-- 
2.1.4


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2018-12-11 23:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-11 23:28 [RFC PATCH v3 00/24] KVM: arm64: SVE guest support Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 01/24] arm64: fpsimd: Always set TIF_FOREIGN_FPSTATE on task state flush Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 02/24] KVM: arm64: Delete orphaned declaration for __fpsimd_enabled() Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 03/24] KVM: arm64: Refactor kvm_arm_num_regs() for easier maintenance Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 04/24] KVM: arm64: Add missing #include of <linux/bitmap.h> to kvm_host.h Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 05/24] arm64/sve: Check SVE virtualisability Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 06/24] arm64/sve: Clarify role of the VQ map maintenance functions Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 07/24] arm64/sve: Enable SVE state tracking for non-task contexts Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 08/24] KVM: arm64: Add a vcpu flag to control SVE visibility for the guest Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 09/24] KVM: arm64: Propagate vcpu into read_id_reg() Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 10/24] KVM: arm64: Extend reset_unknown() to handle mixed RES0/UNKNOWN registers Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 11/24] KVM: arm64: Support runtime sysreg filtering for KVM_GET_REG_LIST Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 12/24] KVM: arm64/sve: System register context switch and access support Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 13/24] KVM: arm64/sve: Context switch the SVE registers Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 14/24] KVM: Allow 2048-bit register access via ioctl interface Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 15/24] KVM: arm64: Reject ioctl access to FPSIMD V-regs on SVE vcpus Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 16/24] KVM: arm64/sve: Add SVE support to register access ioctl interface Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 17/24] KVM: arm64: Enumerate SVE register indices for KVM_GET_REG_LIST Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 18/24] arm64/sve: In-kernel vector length availability query interface Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 19/24] KVM: arm: Move detection of invalid VM type bits to generic code Dave Martin
2018-12-11 23:28 ` Dave Martin [this message]
2018-12-11 23:28 ` [RFC PATCH v3 21/24] KVM: arm64/sve: Report and enable SVE API extensions for userspace Dave Martin
2018-12-11 23:28 ` [RFC PATCH v3 22/24] KVM: arm64/sve: allow KVM_ARM_SVE_CONFIG_QUERY on vm fd Dave Martin
2018-12-11 23:29 ` [RFC PATCH v3 23/24] KVM: Documentation: Document arm64 core registers in detail Dave Martin
2018-12-11 23:29 ` [RFC PATCH v3 24/24] KVM: arm64/sve: Document KVM API extensions for SVE 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=1544570941-7377-21-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=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 \
    /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).