[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: Tue, 24 Jun 2025 08:02:03 +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=V4H55WUnEx4Z2Q3LTWJ1157yEqKV64s+HISe0A4fU8I=; b=b6FJDEWR/rfKysvIXdNWlvAsPB4yOhjkjDyRgNiy2UXUnbDJAT8p+07c5SrTzb0AcP5nvUPV4rGQRzsmTgN+wRlYhj+dXxYT1KNtwH5fgjhJQtxGQ7yBPW/eaBxK3+iuz8DdvmVtL5odD1Iso2yJke176jFN78mddi6nJ47ShoWwNjXjEYgkIB+dLaBroTSshv5q/rf6OLdZXOjIgbssOD5p8tlbOukSOGJl7g/REuIeajRfGPzYufn+vc+B2eOqVLAgMTdI9/xyexGqsYtzOjaGLQG6JFLetaX8KVzCVs4S1hxS1LZovYl751nJlSjFsftnDpisCRkYDrcR4yjlAA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=wkwrc2+hn7NpB/bakSmizquOmrGecjwmp4gSXUwbWXw1GEmHbyMkvNSKq/bm1sz0Lh3WFkza2Kkg5LIbb3L4EmRf3n5mhhG7IM71zhCZx3DXhd4UiAJWeBfvSBPL17iCJ9PJFXrzwGLAg4MwlhpvLHdahj4lAIOM5+zhyKHETToz4prMR9ZKOquRmoc5AQpl9d56CoFFDH7qyzmTtDQ4eFWuRX2IPCuRxqj9kGMXOQVQi3N9SU39qdVAPR8w+gUalWhSbo3LgJ5dsWmv33ItUt3NoqjK0xI+/T2+pBG0M/wlER08f6lM6tm6t3BljgZzRTx63TbuPzXhPMz3vypQ2w==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: "Huang, Ray" <Ray.Huang@xxxxxxx>, 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>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Tue, 24 Jun 2025 08:02:11 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHb23yakGdVC9XxvEWnYcnp8zrTt7QI/QAAgAGa9QCAAQzVgIAG5D6A
  • Thread-topic: [PATCH v6 2/8] vpci: Refactor REGISTER_VPCI_INIT

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?

>> 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?
Since I encountered errors that the values of __start_vpci_array are not right 
when I use them in vpci_init_capabilities().

> 
> Jan

-- 
Best regards,
Jiqian Chen.

 


Rackspace

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