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

Re: [PATCH v6 1/8] vpci/header: Emulate extended capability list for dom0


  • To: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Date: Thu, 19 Jun 2025 02:29:34 +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=BlK9si+JYJ+M2ry0Oz6tLH4rxAx2vknZg8hY8BAJrTk=; b=JCJ9hs3sFyRY4SrgxESFAxElyUvJT0sdf9wTGAERmDnqN0FJLzp1f9mCSmLKAM0f+D19O2bc/BV07d7KiovrAzH61XkQpGgu6eqRNkD3uJZg51a1clpGWaXUd8pLwO4Cs39O8Jfr2nIsHtWmjPlnSGp7KMEpcfx24RVgukMigIMU/5VJMgzLZsjRe4fcco3EJRbfQSCAyaEdqWt505Ss8diNimDoch6E80eACcUGMmCvpjebo6HWvQ1Lhh/BJuERwTrr64tAAiMUZZh++NtOb2CT/OA18d5411k+skgBVRRTksgtJAv+GHqygYQX2lx9z4+h6b6dsOjrA/aEBHgX9Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=ceTww7p5PN/pWFX5c2/q4kkoSJsCPUudYfjAe4qcoQxkkKk6b6lgPsZzXr7t8ulmZaPZ2U8WK0ESf/l1m+DirA0fuX6tkyJVojOwMwZH7v7vsvEH9EBI66vjshT0rf9yOSTRnlc00DFwc6pRYhMAD0u4Ep1NruUEL/ZA8nOCENA6sh3Mladd+y3WV+9PNS7QpxeUjVrJ0QHO/6GtTK6gHEGXu5YPLKoxJm0OaP73kU8VkityKsTxPBzS2oTtAZ1FYV4tf/AfjHMtPKGwSKd3BpQyYyS0FoAvJUwqTZueNGyE9XZ1ZCXxbwS+tQDrTaAJm2L16SNFaAswxCcLHNvX8A==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com;
  • Cc: "Huang, Ray" <Ray.Huang@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Chen, Jiqian" <Jiqian.Chen@xxxxxxx>
  • Delivery-date: Thu, 19 Jun 2025 02:30:02 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHb23yZHYwoBN0glE68BnOedByoqrQI+ZKAgAFXGYA=
  • Thread-topic: [PATCH v6 1/8] vpci/header: Emulate extended capability list for dom0

On 2025/6/18 21:52, Jan Beulich wrote:
> On 12.06.2025 11:29, Jiqian Chen wrote:
>> --- a/xen/drivers/vpci/header.c
>> +++ b/xen/drivers/vpci/header.c
>> @@ -836,6 +836,42 @@ static int vpci_init_capability_list(struct pci_dev 
>> *pdev)
>>                                    PCI_STATUS_RSVDZ_MASK);
>>  }
>>  
>> +static int vpci_init_ext_capability_list(struct pci_dev *pdev)
>> +{
>> +    unsigned int pos = PCI_CFG_SPACE_SIZE;
>> +
>> +    if ( !is_hardware_domain(pdev->domain) )
>> +        /* Extended capabilities read as zero, write ignore for guest */
> 
> s/guest/DomU/ ?
Will do.

> 
>> +        return vpci_add_register(pdev->vpci, vpci_read_val, NULL,
>> +                                 pos, 4, (void *)0);
>> +
>> +    while ( pos >= PCI_CFG_SPACE_SIZE )
>> +    {
>> +        uint32_t header = pci_conf_read32(pdev->sbdf, pos);
>> +        int rc;
>> +
>> +        if ( !header )
>> +            return 0;
> 
> Is this a valid check to make for anything other than the first read? And even
> if valid for the first one, shouldn't that also go through ...
> 
>> +        rc = vpci_add_register(pdev->vpci, vpci_read_val, vpci_hw_write32,
>> +                               pos, 4, (void *)(uintptr_t)header);
> 
> ... here?
If header of first is zero. There is no need to add a register I think, since 
the dom0 can read/write directly.

> 
>> +        if ( rc == -EEXIST )
>> +        {
>> +            printk(XENLOG_WARNING
>> +                   "%pd %pp: overlap in extended cap list, offset %#x\n",
>> +                   pdev->domain, &pdev->sbdf, pos);
>> +            return 0;
>> +        }
>> +
>> +        if ( rc )
>> +            return rc;
>> +
>> +        pos = PCI_EXT_CAP_NEXT(header);
>> +    }
> 
> As a more general remark - this is imo the kind of situation where using
> do ... while() would be better.
> 
>> --- a/xen/drivers/vpci/vpci.c
>> +++ b/xen/drivers/vpci/vpci.c
>> @@ -267,6 +267,12 @@ void cf_check vpci_hw_write16(
>>      pci_conf_write16(pdev->sbdf, reg, val);
>>  }
>>  
>> +void cf_check vpci_hw_write32(
>> +    const struct pci_dev *pdev, unsigned int reg, uint32_t val, void *data)
>> +{
>> +    pci_conf_write32(pdev->sbdf, reg, val);
>> +}
> 
> Iirc we've been there before, yet I continue to wonder whether we're doing
> ourselves any good in allowing writes to something that certainly better
> wouldn't change. Even if we limit this to Dom0.
I remember this was suggested by Roger in V2, since the Dom0 has no limitations 
to write the extended register.

> 
> Jan

-- 
Best regards,
Jiqian Chen.



 


Rackspace

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