[PATCH v3 00/18] PCI SBDF Refactoring

Teddy Astie posted 18 patches 5 days, 2 hours ago
Only 0 patches received!
docs/misc/xen-command-line.pandoc          |  16 ++--
xen/arch/x86/include/asm/msi.h             |   2 +-
xen/arch/x86/msi.c                         |   4 +-
xen/arch/x86/physdev.c                     |  26 +++---
xen/drivers/char/ehci-dbgp.c               | 100 ++++++++-------------
xen/drivers/char/ns16550.c                 |  27 +++---
xen/drivers/char/xhci-dbc.c                |  12 +--
xen/drivers/passthrough/amd/iommu_acpi.c   |  26 +++---
xen/drivers/passthrough/amd/iommu_detect.c |   7 +-
xen/drivers/passthrough/amd/iommu_init.c   |   3 +-
xen/drivers/passthrough/pci.c              |  89 +++++++++---------
xen/drivers/passthrough/vtd/dmar.c         |  89 ++++++++----------
xen/drivers/passthrough/vtd/dmar.h         |   6 +-
xen/drivers/passthrough/vtd/intremap.c     |   2 +-
xen/drivers/passthrough/vtd/iommu.c        |   3 +-
xen/drivers/pci/pci.c                      |  41 +++------
xen/drivers/pci/physdev.c                  |   5 +-
xen/drivers/video/vga.c                    |   2 +-
xen/include/xen/pci.h                      |  21 ++---
19 files changed, 207 insertions(+), 274 deletions(-)
[PATCH v3 00/18] PCI SBDF Refactoring
Posted by Teddy Astie 5 days, 2 hours ago
The goal of this series is to make some refactoring of some
pci primitives to improve codegen and make code less verbose.

A big chunk of it is converting many places where (seg, bus, dev, fn)
is split into multiples variables and into being just pci_sbdf_t,
in particular in some PCI function parameters to reduce parameter count
which usually translate into less registers to pass to the function.
Moreover, we also avoid translating back and forth between pci_sbdf_t
and individual (seg, bus, dev, fn).

No major functional change, aside some parts of the codebase that will
now correctly handle PCI segment when parsed while it was previously
ignored (e.g dbgp).

---
CI: https://gitlab.com/xen-project/people/tsnake41/xen/-/pipelines/2637343578

v3:
 * addressed review comments
 * Split "use pci_sbdf_t in *" with surrounding changes

v2:
 * Dropped "Migrate pci_mmcfg_{read,write}() to pci.c", to be moved in
   a separate series
 * fixed dev_sbdf calculation in acpi_parse_dev_scope() 
 * Updated documentation on ehci_dbgp now accepting segment parameter
   (but I'm not sure it suffice to allow this interface to use non-0 segments)
 * Introduced similar changes for pci_prepare_msix(), pci_ro_device(),
   pci_hide_device(), pci_remove_device(), pci_add_device()
   and pci_check_disable_device()
 * Use pci_sbdf_t in struct ehci_dbgp
 * Introduced "vtd: Rewrite igd device check in acpi_parse_dev_scope()"
 * Introduced docs change (RFC)

Teddy Astie (18):
  pci: Use pci_sbdf_t in pci_device_detect()
  pci: Use pci_sbdf_t in pci_add_device()
  pci: Use pci_sbdf_t in pci_prepare_msix()
  pci: Use pci_sbdf_t in pci_remove_device()
  pci: Use pci_sbdf_t in pci_ro_device()
  pci: Use pci_sbdf_t in pci_hide_device()
  pci: Use pci_sbdf_t pci_check_disable_device()
  pci: Introduce parse_pci_sbdf{_seg}()
  amd/iommu: Parse into pci_sbdf_t directly
  vtd: Use pci_sbdf_t in acpi_parse_dev_scope()
  drivers/char/xhci: Parse into pci_sbdf_t directly
  ns16550: Parse into pci_sbdf_t directly
  vtd: Rename acpi_ioapic_unit.ioapic.info to acpi_ioapic_unit.bdf
  pci: Use pci_sbdf_t in _scan_pci_devices
  pci: Allow ommiting func when parsing with parse_pci_sbdf()
  ehci-dbgp: Use pci_sbdf_t instead of (bus, slot, func)
  pci: Drop parse_pci_split{_seg}()
  RFC: docs: Document support for PCI segment in dbgp and comN parameter

 docs/misc/xen-command-line.pandoc          |  16 ++--
 xen/arch/x86/include/asm/msi.h             |   2 +-
 xen/arch/x86/msi.c                         |   4 +-
 xen/arch/x86/physdev.c                     |  26 +++---
 xen/drivers/char/ehci-dbgp.c               | 100 ++++++++-------------
 xen/drivers/char/ns16550.c                 |  27 +++---
 xen/drivers/char/xhci-dbc.c                |  12 +--
 xen/drivers/passthrough/amd/iommu_acpi.c   |  26 +++---
 xen/drivers/passthrough/amd/iommu_detect.c |   7 +-
 xen/drivers/passthrough/amd/iommu_init.c   |   3 +-
 xen/drivers/passthrough/pci.c              |  89 +++++++++---------
 xen/drivers/passthrough/vtd/dmar.c         |  89 ++++++++----------
 xen/drivers/passthrough/vtd/dmar.h         |   6 +-
 xen/drivers/passthrough/vtd/intremap.c     |   2 +-
 xen/drivers/passthrough/vtd/iommu.c        |   3 +-
 xen/drivers/pci/pci.c                      |  41 +++------
 xen/drivers/pci/physdev.c                  |   5 +-
 xen/drivers/video/vga.c                    |   2 +-
 xen/include/xen/pci.h                      |  21 ++---
 19 files changed, 207 insertions(+), 274 deletions(-)

-- 
2.54.0



-- 
 | Vates 

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech
Re: [PATCH v3 00/18] PCI SBDF Refactoring
Posted by Jan Beulich 4 days, 14 hours ago
On 29.06.2026 19:21, Teddy Astie wrote:
> Teddy Astie (18):
>   pci: Use pci_sbdf_t in pci_device_detect()
>   pci: Use pci_sbdf_t in pci_add_device()
>   pci: Use pci_sbdf_t in pci_prepare_msix()
>   pci: Use pci_sbdf_t in pci_remove_device()
>   pci: Use pci_sbdf_t in pci_ro_device()
>   pci: Use pci_sbdf_t in pci_hide_device()
>   pci: Use pci_sbdf_t pci_check_disable_device()
>   pci: Introduce parse_pci_sbdf{_seg}()
>   amd/iommu: Parse into pci_sbdf_t directly
>   vtd: Use pci_sbdf_t in acpi_parse_dev_scope()
>   drivers/char/xhci: Parse into pci_sbdf_t directly
>   ns16550: Parse into pci_sbdf_t directly
>   vtd: Rename acpi_ioapic_unit.ioapic.info to acpi_ioapic_unit.bdf
>   pci: Use pci_sbdf_t in _scan_pci_devices
>   pci: Allow ommiting func when parsing with parse_pci_sbdf()
>   ehci-dbgp: Use pci_sbdf_t instead of (bus, slot, func)
>   pci: Drop parse_pci_split{_seg}()
>   RFC: docs: Document support for PCI segment in dbgp and comN parameter

Just to mention that your patches still arrive in an odd way (same as v2). In
my inbox, the cover letter is isolated while the patches themselves show as a
thread. On https://lists.xen.org/archives/html/xen-devel/2026-06/threads.html
it's even worse - all patches show up individually.

Jan
Re: [PATCH v3 00/18] PCI SBDF Refactoring
Posted by Teddy Astie 4 days, 11 hours ago
Le 30/06/2026 à 08:12, Jan Beulich a écrit :
> On 29.06.2026 19:21, Teddy Astie wrote:
>> Teddy Astie (18):
>>    pci: Use pci_sbdf_t in pci_device_detect()
>>    pci: Use pci_sbdf_t in pci_add_device()
>>    pci: Use pci_sbdf_t in pci_prepare_msix()
>>    pci: Use pci_sbdf_t in pci_remove_device()
>>    pci: Use pci_sbdf_t in pci_ro_device()
>>    pci: Use pci_sbdf_t in pci_hide_device()
>>    pci: Use pci_sbdf_t pci_check_disable_device()
>>    pci: Introduce parse_pci_sbdf{_seg}()
>>    amd/iommu: Parse into pci_sbdf_t directly
>>    vtd: Use pci_sbdf_t in acpi_parse_dev_scope()
>>    drivers/char/xhci: Parse into pci_sbdf_t directly
>>    ns16550: Parse into pci_sbdf_t directly
>>    vtd: Rename acpi_ioapic_unit.ioapic.info to acpi_ioapic_unit.bdf
>>    pci: Use pci_sbdf_t in _scan_pci_devices
>>    pci: Allow ommiting func when parsing with parse_pci_sbdf()
>>    ehci-dbgp: Use pci_sbdf_t instead of (bus, slot, func)
>>    pci: Drop parse_pci_split{_seg}()
>>    RFC: docs: Document support for PCI segment in dbgp and comN parameter
> 
> Just to mention that your patches still arrive in an odd way (same as v2). In
> my inbox, the cover letter is isolated while the patches themselves show as a
> thread. On https://lists.xen.org/archives/html/xen-devel/2026-06/threads.html
> it's even worse - all patches show up individually.
> 
> Jan
> 

We're aware of that, and hopefully trying to get it fixed on our side, 
but it doesn't seem that easy. Otherwise, I will eventually try some 
workarounds if the situation doesn't improve.

lore.kernel.org seems to have picked the series a bit better though
https://lore.kernel.org/xen-devel/1782753809.8631fc262581453bbf619ec5b2062170.19f14685405000701b@vates.tech/

Teddy
Re: [PATCH v3 00/18] PCI SBDF Refactoring
Posted by Andrew Cooper 4 days, 11 hours ago
On 30/06/2026 9:53 am, Teddy Astie wrote:
> Le 30/06/2026 à 08:12, Jan Beulich a écrit :
>> On 29.06.2026 19:21, Teddy Astie wrote:
>>> Teddy Astie (18):
>>>    pci: Use pci_sbdf_t in pci_device_detect()
>>>    pci: Use pci_sbdf_t in pci_add_device()
>>>    pci: Use pci_sbdf_t in pci_prepare_msix()
>>>    pci: Use pci_sbdf_t in pci_remove_device()
>>>    pci: Use pci_sbdf_t in pci_ro_device()
>>>    pci: Use pci_sbdf_t in pci_hide_device()
>>>    pci: Use pci_sbdf_t pci_check_disable_device()
>>>    pci: Introduce parse_pci_sbdf{_seg}()
>>>    amd/iommu: Parse into pci_sbdf_t directly
>>>    vtd: Use pci_sbdf_t in acpi_parse_dev_scope()
>>>    drivers/char/xhci: Parse into pci_sbdf_t directly
>>>    ns16550: Parse into pci_sbdf_t directly
>>>    vtd: Rename acpi_ioapic_unit.ioapic.info to acpi_ioapic_unit.bdf
>>>    pci: Use pci_sbdf_t in _scan_pci_devices
>>>    pci: Allow ommiting func when parsing with parse_pci_sbdf()
>>>    ehci-dbgp: Use pci_sbdf_t instead of (bus, slot, func)
>>>    pci: Drop parse_pci_split{_seg}()
>>>    RFC: docs: Document support for PCI segment in dbgp and comN
>>> parameter
>>
>> Just to mention that your patches still arrive in an odd way (same as
>> v2). In
>> my inbox, the cover letter is isolated while the patches themselves
>> show as a
>> thread. On
>> https://lists.xen.org/archives/html/xen-devel/2026-06/threads.html
>> it's even worse - all patches show up individually.
>>
>> Jan
>>
>
> We're aware of that, and hopefully trying to get it fixed on our side,
> but it doesn't seem that easy. Otherwise, I will eventually try some
> workarounds if the situation doesn't improve.

How are you sending the series?  Your old double-delivery problem (now
fixed) I can see being the intermediate infrastructure, but I don't see
how that would apply to this kind of issue.

~Andrew

Re: [PATCH v3 00/18] PCI SBDF Refactoring
Posted by Anthony PERARD 4 days, 11 hours ago
On Tue, Jun 30, 2026 at 09:57:35AM +0100, Andrew Cooper wrote:
> How are you sending the series?  Your old double-delivery problem (now
> fixed) I can see being the intermediate infrastructure, but I don't see
> how that would apply to this kind of issue.

It's the SMTP server that `@vates.tech` uses that mangle with
message-id, so `git send-email` can't make proper email thread and the
cover-letter appear isolated.


-- 
Anthony Perard | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech