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

Re: [PATCH v5 07/12] xen: enable Dom0 to use SVE feature


  • To: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • Date: Wed, 19 Apr 2023 07:41:50 +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=xSHOW64FiWvIeoQDQYQfnO8qeilHAcWJniHIJc1w5j4=; b=E+zmEwJs2VjMekq2KAUGsxM4HEg/uJ2I4BJXnw6sM/Zw7dllsFDOlfpkkPS/ER4px+CGSXGmja8UnoD7bnJMh26w6KwR1zvweE4gscR9PcJ9V6m9rih5MUSinQa6LwwSiEiEZkos+aQIEBny8zNDp+jpchDFqP2G+lWG/CaazkXPhbl1b7Nco/SkueskRyLkz7YKjcNoO6YQXuoXqXeeIdpH8RkJUC6bPXe8AT2vrGTDwl0JhUYnyNpJWmjRA2SiB0AUDqg81F4zXLhENxkvpuGgBbvmDU7PBOgaSufG2VvFA67E0k3Ug+IEwrJD8lRbNC4p9PlJAL9kfMvc1ItfrQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=drd2Gg2MOirxK2NHtgFjeCXB/uil5eZ9DeI5YuULKxeMd/1GTD/nyXHs//HGo3pHRr8l1wOiiOa/u35COVHdVfoT/hlKehT4058NF4oTA1Ihw93NZVQU8y3nVLQ6PB+UkUKjGXwU+Jen7yHsmO4/W6YfCsIsaBq06ivvctb8/ScVl73dV1WQFSgjyKZSrb5BKzWmGinIQ8DDpMVVmINMVOSVKHX80l0Xc0/7yISTrWO1bFVoNngfhXrObmaxV/YgS6/f0ARaqCvO49ICnES9LdALikV23e58I5Q53Im3HeY10vwP14wTSB3pFm6OdVl0kO7b/qwHFQjjvY5q9rfeuw==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Wei Chen <Wei.Chen@xxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Wed, 19 Apr 2023 07:42:53 +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: AQHZbSQ+XccnxtxNG0WbEgpX88e2za8xDZ2AgAE1hQCAAAGYAIAABb6A
  • Thread-topic: [PATCH v5 07/12] xen: enable Dom0 to use SVE feature


> On 19 Apr 2023, at 08:21, Bertrand Marquis <Bertrand.Marquis@xxxxxxx> wrote:
> 
> Hi Luca,
> 
>> On 19 Apr 2023, at 09:15, Luca Fancellu <Luca.Fancellu@xxxxxxx> wrote:
>> 
>> Hi Bertrand,
>> 
>>>> 
>>>> diff --git a/xen/arch/arm/arm64/sve.c b/xen/arch/arm/arm64/sve.c
>>>> index 5485648850a0..ad5db62e1805 100644
>>>> --- a/xen/arch/arm/arm64/sve.c
>>>> +++ b/xen/arch/arm/arm64/sve.c
>>>> @@ -9,6 +9,9 @@
>>>> #include <xen/sizes.h>
>>>> #include <asm/arm64/sve.h>
>>>> 
>>>> +/* opt_dom0_sve: allow Dom0 to use SVE and set maximum vector length. */
>>>> +int __initdata opt_dom0_sve;
>>>> +
>>>> extern unsigned int sve_get_hw_vl(void);
>>>> extern void sve_save_ctx(uint64_t *sve_ctx, uint64_t *pregs, int save_ffr);
>>>> extern void sve_load_ctx(uint64_t const *sve_ctx, uint64_t const *pregs,
>>>> @@ -118,3 +121,21 @@ void sve_restore_state(struct vcpu *v)
>>>> 
>>>>  sve_load_ctx(sve_ctx_zreg_end, v->arch.vfp.fpregs, 1);
>>>> }
>>>> +
>>>> +int __init sve_sanitize_vl_param(int val, unsigned int *out)
>>>> +{
>>>> +    /*
>>>> +     * Negative SVE parameter value means to use the maximum supported
>>>> +     * vector length, otherwise if a positive value is provided, check if 
>>>> the
>>>> +     * vector length is a multiple of 128 and not bigger than the maximum 
>>>> value
>>>> +     * 2048
>>>> +     */
>>>> +    if ( val < 0 )
>>>> +        *out = get_sys_vl_len();
>>>> +    else if ( ((val % SVE_VL_MULTIPLE_VAL) == 0) && (val <= 
>>>> SVE_VL_MAX_BITS) )
>>>> +        *out = val;
>>> 
>>> Shouldn't you also check if it is not greater than the maximum vector 
>>> length ?
>> 
>> I don’t understand, I am checking that the value is below or equal to 
>> SVE_VL_MAX_BITS,
>> If you mean if it should be checked also against the maximum supported 
>> length by the platform,
>> I think this is not the right place, the check is already in 
>> arch_sanitise_domain_config(), introduced
>> in patch #2
> 
> If this is not the right place to check it then why checking the rest here ?
> 
> From a user or a developer point of view I would expect the validity of the 
> input to be checked only
> in one place.
> If here is not the place for that it is ok but then i would check everything 
> in arch_sanitise_domain_config
> (multiple, min and supported) instead of doing it partly in 2 places.

Ok, given the way we encoded the value in xen_domctl_createdomain structure, we 
have that the value takes
very little space, but a small issue is that when we encode it, we are dividing 
it by 128, which is fine for user params
that are multiple of 128, but it’s less fine if the user passes “129”.

To overcome this issue we are checking the value when it is not already 
encoded. Now, thinking about it, the check 
"&& (val <= SVE_VL_MAX_BITS)” is not really needed, because even if the value 
is above, then in arch_sanitise_domain_config
we will hit the top limit of the platform maximum VL.

int arch_sanitise_domain_config(struct xen_domctl_createdomain *config)
{
    unsigned int max_vcpus;
    unsigned int flags_required = (XEN_DOMCTL_CDF_hvm | XEN_DOMCTL_CDF_hap);
    unsigned int flags_optional = (XEN_DOMCTL_CDF_iommu | XEN_DOMCTL_CDF_vpmu);
    unsigned int sve_vl_bits = sve_decode_vl(config->arch.sve_vl);

    if ( (config->flags & ~flags_optional) != flags_required )
    {
        dprintk(XENLOG_INFO, "Unsupported configuration %#x\n",
                config->flags);
        return -EINVAL;
    }

    /* Check feature flags */
    if ( sve_vl_bits > 0 )
    {
        unsigned int zcr_max_bits = get_sys_vl_len();

        if ( !zcr_max_bits )
        {
            dprintk(XENLOG_INFO, "SVE is unsupported on this machine.\n");
            return -EINVAL;
        }

        if ( sve_vl_bits > zcr_max_bits )
        {
            dprintk(XENLOG_INFO,
                    "Requested SVE vector length (%u) > supported length 
(%u)\n",
                    sve_vl_bits, zcr_max_bits);
            return -EINVAL;
        }
    }
   [...]

Now, I understand your point, we could check everything in 
sve_sanitize_vl_param(), but it would leave a problem
for domains created by hypercalls if I am not wrong.

What do you think?



 


Rackspace

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