[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:15:34 +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=KK7PKWpjrjn0hXtChFEkJ3JAre4L3RVXSIAdZH3Vf4o=; b=fLv3RQMcTz4sVwiSeBfr7LeLA3/CliN6I8xg4C7U5i8R1fC/cyRl3c5tH15i0F19St+EKRR9CbaZ6tl0O9xQs+0be8p5QXvrR2XRbbTADM6yIN0sovkIcPbPr3XX3FSSFSkJrK60TxeaTziIyJOo8s9A9jB/6sZ+QUqbeBbiOpTkR+68VCDhHMaQq5suCgs6JbJWUJxCED6zpJpc6QaXFR1Smp1lGWIJO57au4BYOx0VsS2ATgXldkmivHyYS9Qau5A7vMgV5A6pSLjwVhX9O/GnLwebxueZw19rUZ83hmOhdhF+cDCaiEWJGSmRD1nwR5eHP6P+s664zP6Z0zTxxQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G6nYrMOnhxs+l/g+ceDv9S1D1BvUq4HVsW4cTs41pj0vk6T/b6HoSw5Ydr2CzxD8lTfAwQeO0j5MJMuTmmQ59QcbD2EngKdccwh1X9PiirnhEe2wcPl5f+HLO8TxdT6Q9uK/5cX9oQA+FjCMQtIDnQwc9yaDqoNvlHxcZMI+qM1+HiBQSFjRkVsJkk5Tr9XXGOJkVBG5jpLiVRrKBtEI2p++AtL+aeFcgjnDkrdNsiyb8C60mO09Sko4Sz207JUQEnDzQBLAD/2g+v9fzsrNKTji8v8wAADspsw7GBeqwL5MNxrmBdw8jNQQ9iotHHoOz7RVxV7jppisr1Fg3XZK5g==
  • 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:16:10 +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+XccnxtxNG0WbEgpX88e2za8xDZ2AgAE1hQA=
  • Thread-topic: [PATCH v5 07/12] xen: enable Dom0 to use SVE feature

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

> 
>> +    else
>> +        return -1;
>> +
>> +    return 0;
>> +}
>> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
>> index eeb4662f0eee..3f30ef5c37b6 100644
>> --- a/xen/arch/arm/domain_build.c
>> +++ b/xen/arch/arm/domain_build.c
>> @@ -26,6 +26,7 @@
>> #include <asm/platform.h>
>> #include <asm/psci.h>
>> #include <asm/setup.h>
>> +#include <asm/arm64/sve.h>
>> #include <asm/cpufeature.h>
>> #include <asm/domain_build.h>
>> #include <xen/event.h>
>> @@ -61,6 +62,21 @@ custom_param("dom0_mem", parse_dom0_mem);
>> 
>> int __init parse_arch_dom0_param(const char *s, const char *e)
>> {
>> +    long long val;
>> +
>> +    if ( !parse_signed_integer("sve", s, e, &val) )
>> +    {
>> +#ifdef CONFIG_ARM64_SVE
>> +        if ( (val >= INT_MIN) && (val <= INT_MAX) )
>> +            opt_dom0_sve = val;
>> +        else
>> +            printk(XENLOG_INFO "'sve=%lld' value out of range!\n", val);
>> +#else
>> +        no_config_param("ARM64_SVE", "sve", s, e);
>> +#endif
> 
> Correct me if my understanding is wrong but here you just ignore the sve
> parameter if SVE is not supported by Xen ?
> 
> I am a bit wondering if we should not just refuse it here as the user might
> wrongly think that his parameter had some effect.
> 
> Or is it a usual way to handle this case ?

Jan suggested this approach, as it should be the preferred way to handle the 
case,
looking into the x86 code it seems so.


 


Rackspace

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