Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Dave Martin <Dave.Martin@arm.com>
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>,
	kvmarm@lists.cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 06/23] arm64/sve: Check SVE virtualisability
Date: Thu, 15 Nov 2018 15:39:01 +0000	[thread overview]
Message-ID: <87in0ycpuy.fsf@linaro.org> (raw)
In-Reply-To: <1538141967-15375-7-git-send-email-Dave.Martin@arm.com>


Dave Martin <Dave.Martin@arm.com> writes:

> Due to the way the effective SVE vector length is controlled and
> trapped at different exception levels, certain mismatches in the
> sets of vector lengths supported by different physical CPUs in the
> system may prevent straightforward virtualisation of SVE at parity
> with the host.
>
> This patch analyses the extent to which SVE can be virtualised
> safely without interfering with migration of vcpus between physical
> CPUs, and rejects late secondary CPUs that would erode the
> situation further.
>
> It is left up to KVM to decide what to do with this information.
>
> Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> ---
>
> Changes since RFCv1:
>
>  * The analysis done by this patch is the same as in the previous
>    version, but the commit message the printks etc. have been reworded
>    to avoid the suggestion that KVM is expected to work on a system with
>    mismatched SVE implementations.
> ---
>  arch/arm64/include/asm/fpsimd.h |  1 +
>  arch/arm64/kernel/cpufeature.c  |  2 +-
>  arch/arm64/kernel/fpsimd.c      | 87 +++++++++++++++++++++++++++++++++++------
>  3 files changed, 76 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
> index dd1ad39..964adc9 100644
> --- a/arch/arm64/include/asm/fpsimd.h
> +++ b/arch/arm64/include/asm/fpsimd.h
> @@ -87,6 +87,7 @@ extern void sve_kernel_enable(const struct arm64_cpu_capabilities *__unused);
>  extern u64 read_zcr_features(void);
>
>  extern int __ro_after_init sve_max_vl;
> +extern int __ro_after_init sve_max_virtualisable_vl;
>
>  #ifdef CONFIG_ARM64_SVE
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index e238b79..aa1a55b 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1531,7 +1531,7 @@ static void verify_sve_features(void)
>  	unsigned int len = zcr & ZCR_ELx_LEN_MASK;
>
>  	if (len < safe_len || sve_verify_vq_map()) {
> -		pr_crit("CPU%d: SVE: required vector length(s) missing\n",
> +		pr_crit("CPU%d: SVE: vector length support mismatch\n",
>  			smp_processor_id());
>  		cpu_die_early();
>  	}
> diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
> index 42aa154..d28042b 100644
> --- a/arch/arm64/kernel/fpsimd.c
> +++ b/arch/arm64/kernel/fpsimd.c
> @@ -18,6 +18,7 @@
>   */
>
>  #include <linux/bitmap.h>
> +#include <linux/bitops.h>
>  #include <linux/bottom_half.h>
>  #include <linux/bug.h>
>  #include <linux/cache.h>
> @@ -48,6 +49,7 @@
>  #include <asm/sigcontext.h>
>  #include <asm/sysreg.h>
>  #include <asm/traps.h>
> +#include <asm/virt.h>
>
>  #define FPEXC_IOF	(1 << 0)
>  #define FPEXC_DZF	(1 << 1)
> @@ -130,14 +132,18 @@ static int sve_default_vl = -1;
>
>  /* Maximum supported vector length across all CPUs (initially poisoned) */
>  int __ro_after_init sve_max_vl = SVE_VL_MIN;
> +int __ro_after_init sve_max_virtualisable_vl = SVE_VL_MIN;
>  /* Set of available vector lengths, as vq_to_bit(vq): */
>  static __ro_after_init DECLARE_BITMAP(sve_vq_map, SVE_VQ_MAX);
> +/* Set of vector lengths present on at least one cpu: */
> +static __ro_after_init DECLARE_BITMAP(sve_vq_partial_map, SVE_VQ_MAX);
>  static void __percpu *efi_sve_state;
>
>  #else /* ! CONFIG_ARM64_SVE */
>
>  /* Dummy declaration for code that will be optimised out: */
>  extern __ro_after_init DECLARE_BITMAP(sve_vq_map, SVE_VQ_MAX);
> +extern __ro_after_init DECLARE_BITMAP(sve_vq_partial_map, SVE_VQ_MAX);
>  extern void __percpu *efi_sve_state;
>
>  #endif /* ! CONFIG_ARM64_SVE */
> @@ -623,11 +629,8 @@ int sve_get_current_vl(void)
>  	return sve_prctl_status(0);
>  }
>
> -/*
> - * Bitmap for temporary storage of the per-CPU set of supported vector lengths
> - * during secondary boot.
> - */
> -static DECLARE_BITMAP(sve_secondary_vq_map, SVE_VQ_MAX);
> +/* Bitmaps for temporary storage during manipulation of vector length sets */
> +static DECLARE_BITMAP(sve_tmp_vq_map, SVE_VQ_MAX);

This seems odd as a local global, why not declared locally when used?

>
>  static void sve_probe_vqs(DECLARE_BITMAP(map, SVE_VQ_MAX))
>  {
> @@ -650,6 +653,7 @@ static void sve_probe_vqs(DECLARE_BITMAP(map, SVE_VQ_MAX))
>  void __init sve_init_vq_map(void)
>  {
>  	sve_probe_vqs(sve_vq_map);
> +	bitmap_copy(sve_vq_partial_map, sve_vq_map, SVE_VQ_MAX);
>  }
>
>  /*
> @@ -658,24 +662,60 @@ void __init sve_init_vq_map(void)
>   */
>  void sve_update_vq_map(void)
>  {
> -	sve_probe_vqs(sve_secondary_vq_map);
> -	bitmap_and(sve_vq_map, sve_vq_map, sve_secondary_vq_map, SVE_VQ_MAX);
> +	sve_probe_vqs(sve_tmp_vq_map);
> +	bitmap_and(sve_vq_map, sve_vq_map, sve_tmp_vq_map,
> +		   SVE_VQ_MAX);
> +	bitmap_or(sve_vq_partial_map, sve_vq_partial_map, sve_tmp_vq_map,
> +		  SVE_VQ_MAX);
>  }

I'm not quite following what's going on here. This is tracking both the
vector lengths available on all CPUs and the ones available on at least
one CPU? This raises a some questions:

  - do such franken-machines exist or are expected to exit?
  - how do we ensure this is always upto date?
  - what happens when we hotplug a new CPU with less available VQ?

>
>  /* Check whether the current CPU supports all VQs in the committed set */
>  int sve_verify_vq_map(void)
>  {
> -	int ret = 0;
> +	int ret = -EINVAL;
> +	unsigned long b;
>
> -	sve_probe_vqs(sve_secondary_vq_map);
> -	bitmap_andnot(sve_secondary_vq_map, sve_vq_map, sve_secondary_vq_map,
> -		      SVE_VQ_MAX);
> -	if (!bitmap_empty(sve_secondary_vq_map, SVE_VQ_MAX)) {
> +	sve_probe_vqs(sve_tmp_vq_map);
> +
> +	bitmap_complement(sve_tmp_vq_map, sve_tmp_vq_map, SVE_VQ_MAX);
> +	if (bitmap_intersects(sve_tmp_vq_map, sve_vq_map, SVE_VQ_MAX)) {
>  		pr_warn("SVE: cpu%d: Required vector length(s) missing\n",
>  			smp_processor_id());
> -		ret = -EINVAL;
> +		goto error;

The use of goto seems a little premature considering we don't have any
clean-up to do.

> +	}
> +
> +	if (!IS_ENABLED(CONFIG_KVM) || !is_hyp_mode_available())
> +		goto ok;
> +
> +	/*
> +	 * For KVM, it is necessary to ensure that this CPU doesn't
> +	 * support any vector length that guests may have probed as
> +	 * unsupported.
> +	 */
> +
> +	/* Recover the set of supported VQs: */
> +	bitmap_complement(sve_tmp_vq_map, sve_tmp_vq_map, SVE_VQ_MAX);
> +	/* Find VQs supported that are not globally supported: */
> +	bitmap_andnot(sve_tmp_vq_map, sve_tmp_vq_map, sve_vq_map, SVE_VQ_MAX);
> +
> +	/* Find the lowest such VQ, if any: */
> +	b = find_last_bit(sve_tmp_vq_map, SVE_VQ_MAX);
> +	if (b >= SVE_VQ_MAX)
> +		goto ok; /* no mismatches */
> +
> +	/*
> +	 * Mismatches above sve_max_virtualisable_vl are fine, since
> +	 * no guest is allowed to configure ZCR_EL2.LEN to exceed this:
> +	 */
> +	if (sve_vl_from_vq(bit_to_vq(b)) <= sve_max_virtualisable_vl) {
> +		pr_warn("SVE: cpu%d: Unsupported vector length(s) present\n",
> +			smp_processor_id());
> +		goto error;
>  	}
>
> +ok:
> +	ret = 0;
> +error:
>  	return ret;
>  }
>
> @@ -743,6 +783,7 @@ u64 read_zcr_features(void)
>  void __init sve_setup(void)
>  {
>  	u64 zcr;
> +	unsigned long b;
>
>  	if (!system_supports_sve())
>  		return;
> @@ -771,11 +812,31 @@ void __init sve_setup(void)
>  	 */
>  	sve_default_vl = find_supported_vector_length(64);
>
> +	bitmap_andnot(sve_tmp_vq_map, sve_vq_partial_map, sve_vq_map,
> +		      SVE_VQ_MAX);
> +
> +	b = find_last_bit(sve_tmp_vq_map, SVE_VQ_MAX);
> +	if (b >= SVE_VQ_MAX)
> +		/* No non-virtualisable VLs found */
> +		sve_max_virtualisable_vl = SVE_VQ_MAX;
> +	else if (WARN_ON(b == SVE_VQ_MAX - 1))
> +		/* No virtualisable VLs?  This is architecturally forbidden. */
> +		sve_max_virtualisable_vl = SVE_VQ_MIN;
> +	else /* b + 1 < SVE_VQ_MAX */
> +		sve_max_virtualisable_vl = sve_vl_from_vq(bit_to_vq(b + 1));
> +
> +	if (sve_max_virtualisable_vl > sve_max_vl)
> +		sve_max_virtualisable_vl = sve_max_vl;
> +
>  	pr_info("SVE: maximum available vector length %u bytes per vector\n",
>  		sve_max_vl);
>  	pr_info("SVE: default vector length %u bytes per vector\n",
>  		sve_default_vl);
>
> +	/* KVM decides whether to support mismatched systems. Just warn here: */
> +	if (sve_max_virtualisable_vl < sve_max_vl)
> +		pr_info("SVE: unvirtualisable vector lengths present\n");
> +
>  	sve_efi_setup();
>  }


--
Alex Bennée
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply	other threads:[~2018-11-15 15:39 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-28 13:39 [RFC PATCH v2 00/23] KVM: arm64: Initial support for SVE guests Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 01/23] arm64: fpsimd: Always set TIF_FOREIGN_FPSTATE on task state flush Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 02/23] KVM: arm64: Delete orphaned declaration for __fpsimd_enabled() Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 03/23] KVM: arm64: Refactor kvm_arm_num_regs() for easier maintenance Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 04/23] KVM: arm64: Add missing #include of <linux/bitmap.h> to kvm_host.h Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 05/23] KVM: arm: Add arch vcpu uninit hook Dave Martin
2018-11-02  8:05   ` Christoffer Dall
2018-11-15 16:40     ` Dave Martin
2018-11-20 10:56       ` Christoffer Dall
2018-09-28 13:39 ` [RFC PATCH v2 06/23] arm64/sve: Check SVE virtualisability Dave Martin
2018-11-15 15:39   ` Alex Bennée [this message]
2018-11-15 17:09     ` Dave Martin
2018-11-16 12:32       ` Alex Bennée
2018-11-16 15:09         ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 07/23] arm64/sve: Enable SVE state tracking for non-task contexts Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 08/23] KVM: arm64: Add a vcpu flag to control SVE visibility for the guest Dave Martin
2018-11-15 15:44   ` Alex Bennée
2018-09-28 13:39 ` [RFC PATCH v2 09/23] KVM: arm64: Propagate vcpu into read_id_reg() Dave Martin
2018-11-15 15:56   ` Alex Bennée
2018-09-28 13:39 ` [RFC PATCH v2 10/23] KVM: arm64: Extend reset_unknown() to handle mixed RES0/UNKNOWN registers Dave Martin
2018-11-02  8:11   ` Christoffer Dall
2018-11-15 17:11     ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 11/23] KVM: arm64: Support runtime sysreg filtering for KVM_GET_REG_LIST Dave Martin
2018-11-02  8:16   ` Christoffer Dall
2018-11-15 17:27     ` Dave Martin
2018-11-22 10:53       ` Christoffer Dall
2018-11-22 11:13         ` Peter Maydell
2018-11-22 12:34           ` Christoffer Dall
2018-11-22 12:59             ` Peter Maydell
2018-11-22 11:27         ` Alex Bennée
2018-11-22 12:32           ` Dave P Martin
2018-11-22 13:07             ` Christoffer Dall
2018-11-23 17:42               ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 12/23] KVM: arm64/sve: System register context switch and access support Dave Martin
2018-11-15 16:37   ` Alex Bennée
2018-11-15 17:59     ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 13/23] KVM: arm64/sve: Context switch the SVE registers Dave Martin
2018-11-19 16:36   ` Alex Bennée
2018-11-19 17:03     ` Dave Martin
2018-11-20 12:25       ` Alex Bennée
2018-11-20 14:17         ` Dave Martin
2018-11-20 15:30           ` Alex Bennée
2018-11-20 17:18             ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 14/23] KVM: Allow 2048-bit register access via ioctl interface Dave Martin
2018-11-19 16:48   ` Alex Bennée
2018-11-19 17:07     ` Dave Martin
2018-11-20 11:20       ` Alex Bennée
2018-09-28 13:39 ` [RFC PATCH v2 15/23] KVM: arm64/sve: Add SVE support to register access " Dave Martin
2018-11-21 15:20   ` Alex Bennée
2018-11-21 18:05     ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 16/23] KVM: arm64: Enumerate SVE register indices for KVM_GET_REG_LIST Dave Martin
2018-11-21 16:09   ` Alex Bennée
2018-11-21 16:32     ` Dave Martin
2018-11-21 16:49       ` Alex Bennée
2018-11-21 17:46         ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 17/23] arm64/sve: In-kernel vector length availability query interface Dave Martin
2018-11-21 16:16   ` Alex Bennée
2018-11-21 16:35     ` Dave Martin
2018-11-21 16:46       ` Alex Bennée
2018-09-28 13:39 ` [RFC PATCH v2 18/23] KVM: arm64: Add arch vcpu ioctl hook Dave Martin
2018-11-02  8:30   ` Christoffer Dall
2018-09-28 13:39 ` [RFC PATCH v2 19/23] KVM: arm64/sve: Report and enable SVE API extensions for userspace Dave Martin
2018-11-22 15:23   ` Alex Bennée
2018-12-05 18:22     ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 20/23] KVM: arm64: Add arch vm ioctl hook Dave Martin
2018-11-02  8:32   ` Christoffer Dall
2018-11-15 18:04     ` Dave Martin
2018-11-20 10:58       ` Christoffer Dall
2018-11-20 14:19         ` Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 21/23] KVM: arm64/sve: allow KVM_ARM_SVE_CONFIG_QUERY on vm fd Dave Martin
2018-11-22 15:29   ` Alex Bennée
2018-09-28 13:39 ` [RFC PATCH v2 22/23] KVM: Documentation: Document arm64 core registers in detail Dave Martin
2018-09-28 13:39 ` [RFC PATCH v2 23/23] KVM: arm64/sve: Document KVM API extensions for SVE Dave Martin
2018-11-22 15:31   ` Alex Bennée
2018-12-05 17:59     ` Dave Martin
2018-11-22 15:34 ` [RFC PATCH v2 00/23] KVM: arm64: Initial support for SVE guests Alex Bennée
2018-12-04 15:50   ` 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=87in0ycpuy.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=Dave.Martin@arm.com \
    --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=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