Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: kvmarm@lists.cs.columbia.edu
Cc: 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>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH 10/14] KVM: arm64/sve: Explain validity checks in set_sve_vls()
Date: Fri, 12 Apr 2019 17:28:14 +0100	[thread overview]
Message-ID: <1555086498-26691-11-git-send-email-Dave.Martin@arm.com> (raw)
In-Reply-To: <1555086498-26691-1-git-send-email-Dave.Martin@arm.com>

Correct virtualization of SVE relies for correctness on code in
set_sve_vls() that verifies consistency between the set of vector
lengths requested by userspace and the set of vector lengths
available on the host.

However, the purpose of this code is not obvious, and not likely to
be apparent at all to people who do not have detailed knowledge of
the SVE system-level architecture.

This patch adds a suitable comment to explain what these checks are
for.

No functional change.

Suggested-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 arch/arm64/kvm/guest.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index f025a2f..7f10d6d 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -266,6 +266,13 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	if (max_vq > sve_vq_from_vl(kvm_sve_max_vl))
 		return -EINVAL;
 
+	/*
+	 * Vector lengths supported by the host can't currently be
+	 * hidden from the guest individually: instead we can only set a
+	 * maxmium via ZCR_EL2.LEN.  So, make sure the available vector
+	 * lengths match the set requested exactly up to the requested
+	 * maximum:
+	 */
 	for (vq = SVE_VQ_MIN; vq <= max_vq; ++vq)
 		if (vq_present(&vqs, vq) != sve_vq_available(vq))
 			return -EINVAL;
-- 
2.1.4

WARNING: multiple messages have this Message-ID (diff)
From: Dave Martin <Dave.Martin@arm.com>
To: kvmarm@lists.cs.columbia.edu
Cc: 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>,
	linux-arm-kernel@lists.infradead.org
Subject: [PATCH 10/14] KVM: arm64/sve: Explain validity checks in set_sve_vls()
Date: Fri, 12 Apr 2019 17:28:14 +0100	[thread overview]
Message-ID: <1555086498-26691-11-git-send-email-Dave.Martin@arm.com> (raw)
Message-ID: <20190412162814.iATshjwyb2W2FNpw_7wENK82wF8qSf_Pk3ElaSq5L2I@z> (raw)
In-Reply-To: <1555086498-26691-1-git-send-email-Dave.Martin@arm.com>

Correct virtualization of SVE relies for correctness on code in
set_sve_vls() that verifies consistency between the set of vector
lengths requested by userspace and the set of vector lengths
available on the host.

However, the purpose of this code is not obvious, and not likely to
be apparent at all to people who do not have detailed knowledge of
the SVE system-level architecture.

This patch adds a suitable comment to explain what these checks are
for.

No functional change.

Suggested-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
---
 arch/arm64/kvm/guest.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/kvm/guest.c b/arch/arm64/kvm/guest.c
index f025a2f..7f10d6d 100644
--- a/arch/arm64/kvm/guest.c
+++ b/arch/arm64/kvm/guest.c
@@ -266,6 +266,13 @@ static int set_sve_vls(struct kvm_vcpu *vcpu, const struct kvm_one_reg *reg)
 	if (max_vq > sve_vq_from_vl(kvm_sve_max_vl))
 		return -EINVAL;
 
+	/*
+	 * Vector lengths supported by the host can't currently be
+	 * hidden from the guest individually: instead we can only set a
+	 * maxmium via ZCR_EL2.LEN.  So, make sure the available vector
+	 * lengths match the set requested exactly up to the requested
+	 * maximum:
+	 */
 	for (vq = SVE_VQ_MIN; vq <= max_vq; ++vq)
 		if (vq_present(&vqs, vq) != sve_vq_available(vq))
 			return -EINVAL;
-- 
2.1.4

_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  parent reply	other threads:[~2019-04-12 16:29 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-12 16:28 [PATCH 00/14] KVM: arm64: SVE cleanups Dave Martin
2019-04-12 16:28 ` Dave Martin
2019-04-12 16:28 ` [PATCH 01/14] arm64/sve: Clarify vq map semantics Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-12 16:28 ` [PATCH 02/14] KVM: arm/arm64: Demote kvm_arm_init_arch_resources() to just set up SVE Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-12 16:28 ` [PATCH 03/14] KVM: arm: Make vcpu finalization stubs into inline functions Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-12 16:28 ` [PATCH 04/14] KVM: arm64/sve: sys_regs: Demote redundant vcpu_has_sve() checks to WARNs Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-12 16:28 ` [PATCH 05/14] KVM: arm64/sve: Clean up UAPI register ID definitions Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-15 15:17   ` Andrew Jones
2019-04-15 15:17     ` Andrew Jones
2019-04-16 12:37     ` Dave Martin
2019-04-16 12:37       ` Dave Martin
2019-04-12 16:28 ` [PATCH 06/14] KVM: arm64/sve: Miscellaneous tidyups in guest.c Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-12 16:28 ` [PATCH 07/14] KVM: arm64/sve: Make register ioctl access errors more consistent Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-12 16:28 ` [PATCH 08/14] KVM: arm64/sve: WARN when avoiding divide-by-zero in sve_reg_to_region() Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-12 16:28 ` [PATCH 09/14] KVM: arm64/sve: Simplify KVM_REG_ARM64_SVE_VLS array sizing Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-15 15:20   ` Andrew Jones
2019-04-15 15:20     ` Andrew Jones
2019-04-16 12:41     ` Dave Martin
2019-04-16 12:41       ` Dave Martin
2019-04-16 13:00       ` Andrew Jones
2019-04-16 13:00         ` Andrew Jones
2019-04-16 14:10         ` Dave Martin
2019-04-16 14:10           ` Dave Martin
2019-04-16 14:28           ` Andrew Jones
2019-04-16 14:28             ` Andrew Jones
2019-04-16 15:36             ` Dave Martin
2019-04-16 15:36               ` Dave Martin
2019-04-16 15:52             ` Dave Martin
2019-04-16 15:52               ` Dave Martin
2019-04-17  4:16               ` Andrew Jones
2019-04-17  4:16                 ` Andrew Jones
2019-04-17 14:01                 ` Dave Martin
2019-04-17 14:01                   ` Dave Martin
2019-04-12 16:28 ` Dave Martin [this message]
2019-04-12 16:28   ` [PATCH 10/14] KVM: arm64/sve: Explain validity checks in set_sve_vls() Dave Martin
2019-04-12 16:28 ` [PATCH 11/14] KVM: arm/arm64: Clean up vcpu finalization function parameter naming Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-12 16:28 ` [PATCH 12/14] KVM: Clarify capability requirements for KVM_ARM_VCPU_FINALIZE Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-12 16:28 ` [PATCH 13/14] KVM: Clarify KVM_{SET, GET}_ONE_REG error code documentation Dave Martin
2019-04-15 15:21   ` [PATCH 13/14] KVM: Clarify KVM_{SET,GET}_ONE_REG " Andrew Jones
2019-04-15 15:21     ` Andrew Jones
2019-04-16 12:42     ` Dave Martin
2019-04-16 12:42       ` Dave Martin
2019-04-12 16:28 ` [PATCH 14/14] KVM: arm64: Clarify access behaviour for out-of-range SVE register slice IDs Dave Martin
2019-04-12 16:28   ` Dave Martin
2019-04-15 15:22 ` [PATCH 00/14] KVM: arm64: SVE cleanups Andrew Jones
2019-04-15 15:22   ` Andrew Jones
2019-04-16 12:46   ` Dave Martin
2019-04-16 12:46     ` 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=1555086498-26691-11-git-send-email-Dave.Martin@arm.com \
    --to=dave.martin@arm.com \
    --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=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