lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f87145e5-5a86-4ccf-96ac-61e16e894b81@infradead.org>
Date: Thu, 21 Aug 2025 23:50:58 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Mark Brown <broonie@...nel.org>, Marc Zyngier <maz@...nel.org>,
 Oliver Upton <oliver.upton@...ux.dev>, Joey Gouly <joey.gouly@....com>,
 Catalin Marinas <catalin.marinas@....com>,
 Suzuki K Poulose <suzuki.poulose@....com>, Will Deacon <will@...nel.org>,
 Paolo Bonzini <pbonzini@...hat.com>, Jonathan Corbet <corbet@....net>,
 Shuah Khan <shuah@...nel.org>
Cc: Dave Martin <Dave.Martin@....com>, Fuad Tabba <tabba@...gle.com>,
 Mark Rutland <mark.rutland@....com>, linux-arm-kernel@...ts.infradead.org,
 kvmarm@...ts.linux.dev, linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v7 11/29] KVM: arm64: Document the KVM ABI for SME



On 8/21/25 6:53 PM, Mark Brown wrote:
> SME, the Scalable Matrix Extension, is an arm64 extension which adds
> support for matrix operations, with core concepts patterned after SVE.
> 
> SVE introduced some complication in the ABI since it adds new vector
> floating point registers with runtime configurable size, the size being
> controlled by a prameter called the vector length (VL). To provide control

                  parameter

> of this to VMMs we offer two phase configuration of SVE, SVE must first be
> enabled for the vCPU with KVM_ARM_VCPU_INIT(KVM_ARM_VCPU_SVE), after which
> vector length may then be configured but the configurably sized floating
> point registers are inaccessible until finalized with a call to
> KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE) after which the configurably sized
> registers can be accessed.
> 
...
> 
> Signed-off-by: Mark Brown <broonie@...nel.org>
> ---
>  Documentation/virt/kvm/api.rst | 117 +++++++++++++++++++++++++++++------------
>  1 file changed, 82 insertions(+), 35 deletions(-)
> 
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 6aa40ee05a4a..71f46b342641 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst

> @@ -2600,12 +2600,12 @@ Specifically:
>    0x6020 0000 0010 00d5 FPCR        32  fp_regs.fpcr
>  ======================= ========= ===== =======================================
>  
> -.. [1] These encodings are not accepted for SVE-enabled vcpus.  See
> -       :ref:`KVM_ARM_VCPU_INIT`.
> +.. [1] These encodings are not accepted for SVE enabled vcpus.  See

                                               SVE-enabled
was good.

> +       :ref:`KVM_ARM_VCPU_INIT`.  They are also not accepted when SME is
> +       enabled without SVE and the vcpu is in streaming mode.
>  

> @@ -2665,19 +2675,25 @@ follows::
>  	/* Vector length vq * 16 bytes not supported */
>  
>  .. [2] The maximum value vq for which the above condition is true is
> -       max_vq.  This is the maximum vector length available to the guest on
> -       this vcpu, and determines which register slices are visible through
> -       this ioctl interface.
> +       max_vq.  This is the maximum vector length currently available to
> +       the guest on this vcpu, and determines which register slices are
> +       visible through this ioctl interface.
> +
> +       If SME is supported then the max_vq used for the Z and P registers
> +       then while SVCR.SM is 1 this vector length will be the maximum SME

I'm having trouble parsing the 2 lines above.

> +       vector length available for the guest, otherwise it will be the
> +       maximum SVE vector length available.
>  
>  (See Documentation/arch/arm64/sve.rst for an explanation of the "vq"
>  nomenclature.)
>  

> @@ -3520,7 +3537,7 @@ Possible features:
>  	        initial value of this pseudo-register indicates the best set of
>  	        vector lengths possible for a vcpu on this host.
>  
> -	   * Before KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE):
> +	   * Before KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC}):

		Why the inserted '}', please?

>  
>  	      - KVM_RUN and KVM_GET_REG_LIST are not available;
>  
> @@ -3533,11 +3550,40 @@ Possible features:
>  	        KVM_SET_ONE_REG, to modify the set of vector lengths available
>  	        for the vcpu.
>  
> -	   * After KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_SVE):
> +	   * After KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC):
>  
>  	      - the KVM_REG_ARM64_SVE_VLS pseudo-register is immutable, and can
>  	        no longer be written using KVM_SET_ONE_REG.
>  
> +	- KVM_ARM_VCPU_SME: Enables SME for the CPU (arm64 only).
> +	  Depends on KVM_CAP_ARM_SME.
> +	  Requires KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC):
> +
> +	   * After KVM_ARM_VCPU_INIT:
> +
> +	      - KVM_REG_ARM64_SME_VLS may be read using KVM_GET_ONE_REG: the
> +	        initial value of this pseudo-register indicates the best set of
> +	        vector lengths possible for a vcpu on this host.
> +
> +	   * Before KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC}):

	ditto: inserted '}'

> +
> +	      - KVM_RUN and KVM_GET_REG_LIST are not available;
> +
> +	      - KVM_GET_ONE_REG and KVM_SET_ONE_REG cannot be used to access
> +	        the scalable architectural SVE registers
> +	        KVM_REG_ARM64_SVE_ZREG(), KVM_REG_ARM64_SVE_PREG() or
> +	        KVM_REG_ARM64_SVE_FFR, the matrix register
> +		KVM_REG_ARM64_SME_ZA() or the LUT register KVM_REG_ARM64_ZT();
> +
> +	      - KVM_REG_ARM64_SME_VLS may optionally be written using
> +	        KVM_SET_ONE_REG, to modify the set of vector lengths available
> +	        for the vcpu.
> +
> +	   * After KVM_ARM_VCPU_FINALIZE(KVM_ARM_VCPU_VEC):

-- 
~Randy


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ