[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>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Tue, 24 Jun 2025 09:29:54 +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=6OSqX8TPdt+TwcOTXS9Rjh7LbVBuChZINYEOQvnZ0ag=; b=seaRE2srG21BAI3gFKKRoBSzapTBDO7vgqkK4j5UINxSlgbd8reDWfHN41GuopOOY5JF/wdAaF5oJX/+YBpUA8amZri9tC5D7zzG7kaeghcTXLitcd28HsJa3eF69+xcAkW/dpwTcg5vAaAf6RtkTlnbBWrdo4i5zO7WQVE/oy34wDwT2xXwc0su3Z3NTkLjJWWe4tITVktNCiAUkiOrsfMJiLX/HYZ/BliIpEE1pascvlLft9Qj1n967whS5wj+Busjm8ED2usb7c9RUe+paWAnDr3Vx9QY0NCS9OE2WnXhpFhR5PEmaVp6g8ZQX+3W5+z2dgRIg8ASmW7SGiYYQA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=reeW1U3OgHgPw+ZVaRvalU2JNm7tf7N/b6d7jQys6Jac4iOXnzyfxL21MwE3JQ2YPptWlWXIhdwyQrVPsXEjgKrrieTz0nyt9NhKLVjWQywGT3xaaM4tO1EHb6Mm6hvoZThHeaR/Z2mft4UWMqITCwFfcYH3ONNutFmx1u8mAbkIOVl+WP47OFXrdg53THHutI56vbHr0jlDZnvtXFrOzuXx1evN1IVcMaZfzdXczcib4xZfgDfrZqtV6qyKJMxMQg1I/6ANGF2AliJOYcGpAB4O9zBkFcePxy/sfcSSofkPj/vs5G0YwG15nJrVWKoZXhnEBcFUnMaugqaA+HPlPA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: "Huang, Ray" <Ray.Huang@xxxxxxx>, 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>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Tue, 24 Jun 2025 09:30:13 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A//99hgCAAJwoAA==
  • Thread-topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT

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:
>>>>>> --- a/xen/drivers/vpci/msix.c
>>>>>> +++ b/xen/drivers/vpci/msix.c
>>>>>> @@ -703,9 +703,13 @@ static int cf_check init_msix(struct pci_dev *pdev)
>>>>>>      pdev->vpci->msix = msix;
>>>>>>      list_add(&msix->next, &d->arch.hvm.msix_tables);
>>>>>>  
>>>>>> -    return 0;
>>>>>> +    spin_lock(&pdev->vpci->lock);
>>>>>> +    rc = vpci_make_msix_hole(pdev);
>>>>>> +    spin_unlock(&pdev->vpci->lock);
>>>>>
>>>>> If you add a call to vpci_make_msix_hole() here, doesn't it need (or at
>>>>> least want) removing somewhere else? Otherwise maybe a code comment is
>>>>> warranted next to the new call site?
>> Sorry, I misunderstood you in my last email.
>> After here's change, it seems the call in modify_decoding() is redundant.
>> What's your taste? Removing the call in modify_decoding() or adding a code 
>> comment?
> 
> I'd prefer the other call to be dropped if it's provably redundant. But Roger
> has the final say here anyway.
OK, let's wait Roger's input.

> 
>>>> The removing operation in modify_bars() and vpci_deassign_device() is not 
>>>> enough?
>>>
>>> I fear I don't understand this reply of yours. Which suggests that the patch
>>> description may want extending as to this part of the change.
>>>
>>>>>> @@ -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[];
 #define NUM_VPCI_INIT (__end_vpci_array - __start_vpci_array)

 #ifdef CONFIG_HAS_VPCI_GUEST_SUPPORT
@@ -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).


> 
> Jan

-- 
Best regards,
Jiqian Chen.

 


Rackspace

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