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

Re: [PATCH v4 08/12] xen/physinfo: encode Arm SVE vector length in arch_capabilities


  • To: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 30 Mar 2023 12:49:41 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=VqlUBDKmuxRPMK2AGhLdnImiD1oR+j16HHXc92V7FCM=; b=N8J/YmU1Qhfxdp6uFV0CTqsOPXLgRPDHEQ4JmQ7zHU2AtAuO5/3wJ0bdOQPLk2yqfKXpwhCQCpXwumf09EXCjjSM5W1xUHq4wsil/+JD+rAiY/n0HSlXy1TJ0fwpD0Km1hrtSYHdyScbmcpJUwbL2zF9yLBimENWtCNmZNm8PU9cphtxB/7XHqpn2/LWEr+1cQdHvTIpbDXEwR7fOvCKSvfXa5RNCfxZlB6RpplWDN5p2o9UHpt+O22aD89ty18m0qLZLSTl2krr8aLq0V87r9+PgWUWAcui/xaXMnrUAwduwOEE0NQ+AQjG7d/PDp3orGiA5kPdtC1NL4GZsQRzvQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TTaea0kTbbH869ueOIJCGOEPxH9bfh6qLr6qoteRKMVAE6/etiM6txmc3rGY/BvZCiJkj1kEEZXCkuIh4GIjfyMu7Z64xHEjDmeGsyB4ERG3gi4rsslsZGfZQGLnYkf/t2lwQCCOWLw3wfVWt91XME9HMIltxAK0w93wTWJcHZ+GbF2HKOWMyygTn3NwSVHPElDlEJRSFa8yX5fplDuMwXjYc4SAEgnXfRZe1WnMv2cMU3jQpbn/nFMnwl6Uc9gUeX5yJ5RmYzAXeSwClt+OY1fJ6ss194AhgotwVUuqhSUcl/YOm2TI+qvkCgxAK2YCpPFUAffpRJPQ3O5KNsIygw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.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: Thu, 30 Mar 2023 10:49:58 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 30.03.2023 12:41, Luca Fancellu wrote:
> 
> 
>> On 28 Mar 2023, at 11:14, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 27.03.2023 12:59, Luca Fancellu wrote:
>>> --- a/xen/arch/arm/arm64/sve.c
>>> +++ b/xen/arch/arm/arm64/sve.c
>>> @@ -124,3 +124,15 @@ int __init sve_parse_dom0_param(const char *str_begin, 
>>> const char *str_end)
>>> {
>>>     return parse_integer("sve", str_begin, str_end, (int*)&opt_dom0_sve);
>>> }
>>> +
>>> +void sve_arch_cap_physinfo(uint32_t *arch_capabilities)
>>> +{
>>> +    if ( cpu_has_sve )
>>> +    {
>>> +        /* Vector length is divided by 128 to save some space */
>>> +        uint32_t sve_vl = MASK_INSR(sve_encode_vl(get_sys_vl_len()),
>>> +                                    XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK);
>>> +
>>> +        *arch_capabilities |= sve_vl;
>>> +    }
>>> +}
>>
>> I'm again wondering why a separate function is needed, when everything
>> that's needed is ...
>>
>>> --- a/xen/arch/arm/sysctl.c
>>> +++ b/xen/arch/arm/sysctl.c
>>> @@ -11,11 +11,14 @@
>>> #include <xen/lib.h>
>>> #include <xen/errno.h>
>>> #include <xen/hypercall.h>
>>> +#include <asm/arm64/sve.h>
>>
>> ... becoming available here for use ...
>>
>>> #include <public/sysctl.h>
>>>
>>> void arch_do_physinfo(struct xen_sysctl_physinfo *pi)
>>> {
>>>     pi->capabilities |= XEN_SYSCTL_PHYSCAP_hvm | XEN_SYSCTL_PHYSCAP_hap;
>>> +
>>> +    sve_arch_cap_physinfo(&pi->arch_capabilities);
>>
>> ... here. That would be even more so if, like suggested before,
>> get_sys_vl_len() returned 0 when !cpu_has_sve.
> 
> I’ve had a look on this, I can do everything In arch_do_physinfo if in 
> xen/include/public/sysctl.h
> the XEN_SYSCTL_PHYSCAP_ARM_SVE_MASK is protected by __aarch64__ or __arm__ .
> 
> Do you agree on that?

I don't see the connection, but guarding the #define in the public header
looks not only okay, but even desirable to me.

Jan



 


Rackspace

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