Re: [PATCH v8 8/8] PCI: vmd: Workaround for hardwired BUS1 bus number

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: vmd: fake root bus number 0x80 causes resource conflict and breaks hotplug
--

commit 96fa114ac906af61b74b8a37fc6def3f417dbf5b
Author: Szymon Durawa <szymon.durawa@linux.intel.com>

    PCI: vmd: Workaround for hardwired BUS1 bus number

This commit implements a workaround for the VMD BUS1 root bus number being
fixed to 0x80 in hardware. It overrides the root bus number in vmd_create_bus()
and attempts to handle the translation during config accesses and ACPI matching.

> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index 51b8c2d9b7f0b..91c5b02bf91d1 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -467,10 +467,23 @@ static unsigned int vmd_bus_to_ecam(struct vmd_dev *vmd, unsigned int busnr)
>  static void __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus *bus,
>  				  unsigned int devfn, int reg, int len)
>  {
[ ... ]
> +	if (vmd->bus1_rootbus && bus->number == VMD_PRIMARY_BUS1)
> +		bus_number = vmd->busn_start[VMD_BUS_1];
> +	else
> +		bus_number = bus->number;

[Severity: High]
Does this break configuration space accesses for dynamically assigned downstream
bus numbers?

During dynamic bus assignment like hotplug or SR-IOV on root ports behind
VMD BUS1, the PCI core sees 0x80 as the parent bus number and assigns child
buses starting from 0x81 instead of the physical downstream window (e.g., 0xE1).

When accessing these dynamically assigned buses, this code falls through to the
untranslated bus->number (e.g., 0x81). It then subtracts the physical ECAM
start (e.g., 0xE0) from 0x81, leading to a massive unsigned underflow
(0xFFFFFFA1).

This out-of-bounds offset will cause vmd_cfg_addr() to return NULL, silently
breaking all configuration accesses.

[ ... ]
> @@ -1188,6 +1223,7 @@ static int vmd_create_bus(struct vmd_dev *vmd, enum vmd_rootbus bus_number,
>  			  struct pci_sysdata *sd, resource_size_t *offset,
>  			  bool vmd_in_guest, u8 primary)
>  {
[ ... ]
> +	/*
> +	 * Workaround: set VMD_BUS_1's bus number to VMD_PRIMARY_BUS1 so it
> +	 * matches vmd->bus[VMD_BUS_1]->primary and bypasses bus number
> +	 * reconfiguration.
> +	 */
> +	if (bus_number == VMD_BUS_1 && vmd->bus1_rootbus)
> +		root_busnr = VMD_PRIMARY_BUS1;

[Severity: High]
Does overriding the root bus number to 0x80 here initiate a resource conflict
that breaks the dynamic allocator's base range?

By overriding the BUS1 root bus number to 0x80 instead of its physical ECAM
base (e.g., 0xE1), pci_register_host_bridge() requests the bus resource range
[0x80-0xFF]. This overlaps with BUS0's physical range (e.g., [0xE0-0xF0]).

pci_bus_insert_busn_res() detects this conflict and fails to attach the bus
resource of BUS1 to the domain, breaking hotplug and SR-IOV completely on
VMD BUS1.

> +	else
> +		root_busnr = vmd->busn_start[bus_number];
> +
> +	vmd_bus = pci_create_root_bus(&vmd->dev->dev, root_busnr, &vmd_ops, sd,
>  				      &resources);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260921164316.3860312-1-szymon.durawa@linux.intel.com?part=8