[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 02/12] xen/arm: add SVE vector length field to the domain


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • Date: Wed, 29 Mar 2023 10:01:24 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=fHnZMbeMZ3PnoU9T9KfP0M6BS5FCYGfEcsoEL51V7PE=; b=IJKB6KlYHN2WWSrNd4N25wc8elF/O5to2hjXivPa/Tkb363wbibvlzfWEvDkxOyEI/CgXX0LtJLQi2j9/Dm4x4MLLs3l01sIsRo5bMisG2eXAxdC/pdN+3WGn3ozMmVOO9cVfz/YgVGsHxIYIDxt0SS2g0LyvbJwmuEudJsnw+hyKoOOwM6V3ogmGRrdULA6wNdG30XpGnBpvFNVdGNq7192/WTvp4NiPOr4XzVVEYQIUuL4QyIgQ/JQXUL4CnuhWcih+sB3lywsMFrOm7oPpwLWV138sfCPa8oE3yFI4eSDu/fCeNvXhYmZRSYAbBTwowyZ1JxiU5/Dbg/4plo33w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TLYk30J/DXiQ0CHAm5TxUXW2QVekS8lDuOoBn82g405hWVE8J1/bdwIaqVr4GqAE7FI6mlAKULZ5KapTaWZcILW9s8CASJwbjCEWgt4L5Y/KInutxJ1VEhCwxKrGlnJjOVDvxnoIc/NLJCMgeaF6PFI0IWsMb/3lWS7Z7EjxOJ4Tq9sozQwIix12Edf6D9SovGrY0tR+6hYOIB+N4xASwxM8GQ23X7/6nL3MA5Joy4jC5gLUxVnDFgACM4YouSWI94pywIUrYzHnlrQNaHjDLrpxiatRYOXVm6myI7/zjmqFTUFT+mquHjSi+9r9HRwS/t1T0v2dGzhH79D2g3XTww==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 29 Mar 2023 10:01:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHZYJtYhPNp4K3qPECnSSUY8aM6MK8P8D+AgAGZUgA=
  • Thread-topic: [PATCH v4 02/12] xen/arm: add SVE vector length field to the domain

Hi Jan,

Thank you for your review, very appreciated,

> On 28 Mar 2023, at 10:36, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 27.03.2023 12:59, Luca Fancellu wrote:
>> @@ -43,8 +44,16 @@ register_t compute_max_zcr(void)
>> }
>> 
>> /* Takes a vector length in bits and returns the ZCR_ELx encoding */
>> -register_t vl_to_zcr(uint16_t vl)
>> +register_t vl_to_zcr(unsigned int vl)
>> {
>>     ASSERT(vl > 0);
>>     return ((vl / SVE_VL_MULTIPLE_VAL) - 1U) & ZCR_ELx_LEN_MASK;
>> }
>> +
>> +/* Get the system sanitized value for VL in bits */
>> +unsigned int get_sys_vl_len(void)
>> +{
>> +    /* ZCR_ELx len field is ((len+1) * 128) = vector bits length */
>> +    return ((system_cpuinfo.zcr64.bits[0] & ZCR_ELx_LEN_MASK) + 1U) *
>> +            SVE_VL_MULTIPLE_VAL;
>> +}
> 
> Wouldn't this function better return 0 when !cpu_has_sve?

Yes I agree

> 
>> @@ -602,6 +606,31 @@ int arch_sanitise_domain_config(struct 
>> xen_domctl_createdomain *config)
>>         return -EINVAL;
>>     }
>> 
>> +    /* Check feature flags */
>> +    if ( sve_vl_bits > 0 ) {
> 
> Nit: Style (brace placement).

Will fix

> 
>> +        unsigned int zcr_max_bits = get_sys_vl_len();
>> +
>> +        if ( !cpu_has_sve )
>> +        {
>> +            dprintk(XENLOG_INFO, "SVE is unsupported on this machine.\n");
>> +            return -EINVAL;
>> +        }
>> +        else if ( !is_vl_valid(sve_vl_bits) )
> 
> If this was code I'm the maintainer for, I'd ask for the "else" to be
> dropped. Please consider doing so, as it makes more visible that the
> earlier if() cannot "fall through". (This could then be further
> supported by inserting blank lines, here and again right below.)
> 
> As to the check - this being the only user of is_vl_valid() (at this
> point) I'd like to mention that half of what that function checks is
> now pointless, as we're dealing with a decoded value. Future further
> users may need the full value checked, but given that all interfaces
> are now using encoded values this doesn't seem very likely. Hence the
> respective part of the condition there may want to become an
> assertion instead (or be dropped).

Yes I can do that

> 
> Yet another question is whether both range checks (against
> SVE_VL_MAX_BITS and zcr_max_bits) are actually necessary / useful.
> Iirc 2048 is a hard upper bound, so zcr_max_bits being higher than
> that value should likely lead to not using SVE at all (if it doesn't
> already; didn't check).

I think the check sve_vl_bits > zcr_max_bits is needed because from 
sve_vl_bits = sve_decode_vl(config->arch.sve_vl); I can get values above the
maximum supported bits (zcr_max_bits), later on I will use the struct 
arch_domain
field sve_vl to compute the size of the registers to be saved/restore

Is there something I’ve missed from your comment?

> 
>> +        {
>> +            dprintk(XENLOG_INFO, "Unsupported SVE vector length (%u)\n",
>> +                    sve_vl_bits);
>> +            return -EINVAL;
>> +        }
>> +        else if ( sve_vl_bits > zcr_max_bits )
>> +        {
>> +            dprintk(XENLOG_INFO,
>> +                    "The requested SVE vector length (%u) must be lower or 
>> \n"
>> +                    "equal to the platform supported vector length (%u)\n",
>> +                    sve_vl_bits, zcr_max_bits);
> 
> Again, if I was the maintainer of this code, I'd ask for the message
> to be shortened, such that it easily fits on one line. E.g.
> "requested SVE vector length (%u) > supported length (%u)\n". This
> would then also avoid the apparent grammar issue of "lower" not fitting
> with "to" (i.e. a "than" needing inserting, or "below" being used
> instead).

Yes this suggestion makes sense to me.


To address your comments I’m doing these modifications to the patch, I hope
they caption all your feedbacks:

diff --git a/xen/arch/arm/arm64/sve.c b/xen/arch/arm/arm64/sve.c
index 3c3adfb5c6bd..78f7482619da 100644
--- a/xen/arch/arm/arm64/sve.c
+++ b/xen/arch/arm/arm64/sve.c
@@ -53,6 +53,9 @@ register_t vl_to_zcr(unsigned int vl)
 /* Get the system sanitized value for VL in bits */
 unsigned int get_sys_vl_len(void)
 {
+    if ( !cpu_has_sve )
+        return 0;
+
     /* ZCR_ELx len field is ((len+1) * 128) = vector bits length */
     return ((system_cpuinfo.zcr64.bits[0] & ZCR_ELx_LEN_MASK) + 1U) *
             SVE_VL_MULTIPLE_VAL;
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 7182d4567bf0..c1fb30dfc5ef 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -607,7 +607,8 @@ int arch_sanitise_domain_config(struct 
xen_domctl_createdomain *config)
     }
 
     /* Check feature flags */
-    if ( sve_vl_bits > 0 ) {
+    if ( sve_vl_bits > 0 )
+    {
         unsigned int zcr_max_bits = get_sys_vl_len();
 
         if ( !cpu_has_sve )
@@ -615,17 +616,18 @@ int arch_sanitise_domain_config(struct 
xen_domctl_createdomain *config)
             dprintk(XENLOG_INFO, "SVE is unsupported on this machine.\n");
             return -EINVAL;
         }
-        else if ( !is_vl_valid(sve_vl_bits) )
+
+        if ( !is_vl_valid(sve_vl_bits) )
         {
             dprintk(XENLOG_INFO, "Unsupported SVE vector length (%u)\n",
                     sve_vl_bits);
             return -EINVAL;
         }
-        else if ( sve_vl_bits > zcr_max_bits )
+
+        if ( sve_vl_bits > zcr_max_bits )
         {
             dprintk(XENLOG_INFO,
-                    "The requested SVE vector length (%u) must be lower or \n"
-                    "equal to the platform supported vector length (%u)\n",
+                    "Requested SVE vector length (%u) > supported length 
(%u)\n",
                     sve_vl_bits, zcr_max_bits);
             return -EINVAL;
         }
diff --git a/xen/arch/arm/include/asm/arm64/sve.h 
b/xen/arch/arm/include/asm/arm64/sve.h
index 8037f09b5b0a..e8c01a24e6da 100644
--- a/xen/arch/arm/include/asm/arm64/sve.h
+++ b/xen/arch/arm/include/asm/arm64/sve.h
@@ -16,7 +16,9 @@
 static inline bool is_vl_valid(unsigned int vl)
 {
     /* SVE vector length is multiple of 128 and maximum 2048 */
-    return ((vl % SVE_VL_MULTIPLE_VAL) == 0) && (vl <= SVE_VL_MAX_BITS);
+    ASSERT((vl % SVE_VL_MULTIPLE_VAL) == 0);
+
+    return vl <= SVE_VL_MAX_BITS;
 }
 
 static inline unsigned int sve_decode_vl(unsigned int sve_vl)

> 
> Jan


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.