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

Re: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Wed, 25 Jun 2025 06:51:50 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=UsuGD6OSWKpBAf6O5TS+39FWcvIRYURXGfkHs+ayxx4=; b=HUtj16t1jeg+jUO0x7GVYOE0BEcGmGkGE1/dcTfDJBNzLJTq2CsgP7xdVQtnNibqNJpdNJrUHr0m/LIGFdG/RY4qTLeBHEifRunsycoomaxJc2ATDa0gLH/S4jrhZN5Ui+ydRRXDaI3kX4L8uAtYLDD6jhU+JZNeSH8zMasam2VeA+1slmjTfgEbA2Qf+n2+abUmT2RriiL1NU9FO59m8rRWv2Gp2YF50tctzybT8ga8n9RY7djM8Z60MpAC5PYPWjPqEMYlxvkxPBVWuyfgsVj2ssiUaPwOj+caHu6Tc7Sa2Z9CuLxb2nggdGGJgts7XP65j2sfAHLRm5MDi2QxAA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=JRmWqjGqvAIMuqVR2//gN7Jt50Reu5y18b27JbAS18AUScjsheGsc2sXwH7yFPLchFIWGkKqNu5jamjMnBgVN/Lo9w94wQH6mYnhnCUvO8S36MGLjjPen2YdQU1Cz7ET1BftCMzD1AH2KUw3gjQughC2YcKiGVf9u4a4abUEsn46e5xGPVTqxMAsOmDoZwh8vUvjXL7G6BOn+M2yztUkhbQfdaJcYp66T2hhimXA1Nt/2lCdM2Vby4rAztq66gHvP04YIpXxNpFelg9K1ZJ/RTd2d8one8VHB93zP2y7EVaPJyePVdULn/gU7MnvKIJA/bFuJfNRHL+s4vvRe38EDg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, "Orzel, Michal" <Michal.Orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Huang, Ray" <Ray.Huang@xxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Wed, 25 Jun 2025 06:52:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAP//hioAgAHew4A=
  • Thread-topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT

On 2025/6/24 18:08, Jan Beulich wrote:
> On 24.06.2025 11:29, Chen, Jiqian wrote:
>> On 2025/6/24 16:05, Jan Beulich wrote:
>>> On 24.06.2025 10:02, Chen, Jiqian wrote:
>>>> On 2025/6/20 14:38, Jan Beulich wrote:
>>>>> On 19.06.2025 08:39, Chen, Jiqian wrote:
>>>>>> On 2025/6/18 22:05, Jan Beulich wrote:
>>>>>>> On 12.06.2025 11:29, Jiqian Chen wrote:
>>>>>>>> @@ -29,9 +30,22 @@ typedef int vpci_register_init_t(struct pci_dev 
>>>>>>>> *dev);
>>>>>>>>   */
>>>>>>>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>>>>>>>  
>>>>>>>> -#define REGISTER_VPCI_INIT(x, p)                \
>>>>>>>> -  static vpci_register_init_t *const x##_entry  \
>>>>>>>> -               __used_section(".data.vpci." p) = (x)
>>>>>>>> +#define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>>>>> +    static const vpci_capability_t finit##_t = { \
>>>>>>>> +        .id = (cap), \
>>>>>>>> +        .init = (finit), \
>>>>>>>> +        .cleanup = (fclean), \
>>>>>>>> +        .is_ext = (ext), \
>>>>>>>> +    }; \
>>>>>>>> +    static const vpci_capability_t *const finit##_entry  \
>>>>>>>> +        __used_section(".data.rel.ro.vpci") = &finit##_t
>>>>>>>
>>>>>>> Could you remind me why the extra level of indirection is necessary 
>>>>>>> here?
>>>>>>> That is, why can't .data.rel.ro.vpci be an array of vpci_capability_t?
>>>>>> You mean I should change to be:
>>>>>> #define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>>>>>>     static const vpci_capability_t finit##_t \
>>>>>>         __used_section(".data.rel.ro.vpci") = { \
>>>>>>         .id = (cap), \
>>>>>>         .init = (finit), \
>>>>>>         .cleanup = (fclean), \
>>>>>>         .is_ext = (ext), \
>>>>>>     }
>>>>>>
>>>>>> Right?
>>>>>
>>>>> Yes, subject to the earlier comments on the identifier choice.
>>>> Got it.
>>>> One more question, if change to be that, then how should I modify the 
>>>> definition of VPCI_ARRAY?
>>>> Is POINTER_ALIGN still right?
>>>
>>> Yes. The struct doesn't require bigger alignment afaics. (In fact in 
>>> principle
>>> no alignment should need specifying there, except that this would require
>>> keeping the section separate in the final image. Which I don't think we 
>>> want.)
>>>
>>>> Since I encountered errors that the values of __start_vpci_array are not 
>>>> right when I use them in vpci_init_capabilities().
>>>
>>> Details please.
>> After changing __start_vpci_array to be vpci_capability_t array, codes will 
>> be (maybe I modified wrong somewhere):
>>
>> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
>> index c51bbb8abb19..9f2f438b4fdd 100644
>> --- a/xen/drivers/vpci/vpci.c
>> +++ b/xen/drivers/vpci/vpci.c
>> @@ -36,8 +36,8 @@ struct vpci_register {
>>  };
>>
>>  #ifdef __XEN__
>> -extern const vpci_capability_t *const __start_vpci_array[];
>> -extern const vpci_capability_t *const __end_vpci_array[];
>> +extern vpci_capability_t __start_vpci_array[];
>> +extern vpci_capability_t __end_vpci_array[];
> 
> Just fyi: You lost const here.
> 
>> @@ -255,7 +255,7 @@ static int vpci_init_capabilities(struct pci_dev *pdev)
>>  {
>>      for ( unsigned int i = 0; i < NUM_VPCI_INIT; i++ )
>>      {
>> -        const vpci_capability_t *capability = __start_vpci_array[i];
>> +        const vpci_capability_t *capability = &__start_vpci_array[i];
>>          const unsigned int cap = capability->id;
>>          const bool is_ext = capability->is_ext;
>>          int rc;
>> diff --git a/xen/include/xen/vpci.h b/xen/include/xen/vpci.h
>> index f4ec1c25922d..77750dd4131a 100644
>> --- a/xen/include/xen/vpci.h
>> +++ b/xen/include/xen/vpci.h
>> @@ -31,14 +31,13 @@ typedef struct {
>>  #define VPCI_MAX_VIRT_DEV       (PCI_SLOT(~0) + 1)
>>
>>  #define REGISTER_VPCI_CAPABILITY(cap, finit, fclean, ext) \
>> -    static const vpci_capability_t finit##_t = { \
>> +    static vpci_capability_t finit##_entry \
>> +        __used_section(".data.rel.ro.vpci") = { \
>>          .id = (cap), \
>>          .init = (finit), \
>>          .cleanup = (fclean), \
>>          .is_ext = (ext), \
>> -    }; \
>> -    static const vpci_capability_t *const finit##_entry  \
>> -        __used_section(".data.rel.ro.vpci") = &finit##_t
>> +    }
>>
>>  #define REGISTER_VPCI_CAP(cap, finit, fclean) \
>>      REGISTER_VPCI_CAPABILITY(cap, finit, fclean, false)
>>
>> I print the value of NUM_VPCI_INIT, it is a strange number 
>> (6148914691236517209).
> 
> What are the addresses of the two symbols __start_vpci_array and 
> __end_vpci_array?
__end_vpci_array is 0xffff82d0404251b8
__start_vpci_array is 0xffff82d040425160
NUM_VPCI_INIT is 0x5555555555555559
sizeof(vpci_capability_t) is 0x18

> At the first glance the changes above are what I would have expected.
> 
> Jan

-- 
Best regards,
Jiqian Chen.

 


Rackspace

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