[PATCH] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[PATCH] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[Ali Alaei]

Intel Arrow Lake-HX platforms (e.g., Core Ultra 9 275HX) use VMD device
8086:ad0b, which is already in the driver's ID table. However, on these
platforms the VMCONFIG register's BUS_RESTRICT_CFG field returns 3 during
probe. vmd_get_bus_number_start() only handles values 0-2 and returns
-ENODEV for anything else, causing VMD probe to fail and leaving NVMe
drives behind the VMD controller invisible to the OS.

Handle cfg=3 the same as cfg=2 (busn_start=224).

Tested on: Acer Predator PH16-73 with Intel Core Ultra 9 275HX
           (VMD controller 0000:00:0e.0, 8086:ad0b).

Signed-off-by: Ali Alaei <ali.alaei.tabatabaei@gmail.com>
---
 drivers/pci/controller/vmd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index XXXXXXX..YYYYYYY 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -649,6 +649,7 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
 		case 1:
 			vmd->busn_start = 128;
 			break;
+		case 3:
 		case 2:
 			vmd->busn_start = 224;
 			break;
--
2.49.0

Re: [PATCH] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Unchecked PCI configuration reads can cause device removal or read failures to be treated as a valid configuration (case 3), falsely continuing probe.
--

commit fde973a5965da08fe76816c224c875b5ef1e4a2e
Author: Ali Alaei <ali.alaei.tabatabaei@gmail.com>

PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

This commit adds support for Intel Arrow Lake-HX platforms where the VMD
controller's VMCONFIG register returns 3 for the BUS_RESTRICT_CFG field,
mapping it to a bus number start of 224.

> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index d4ae250d4bc6d..9cf5ea2e1e20f 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c

[ ... ]

> @@ -648,6 +648,7 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
>  		case 1:
>  			vmd->busn_start = 128;
>  			break;
> +		case 3:

[Severity: Medium]
Does this change unintentionally mask device removal errors?

If the device is removed during probe, pci_read_config_word() does not
necessarily return an error code and the hardware typically returns 0xFFFF.
Because BUS_RESTRICT_CFG(0xFFFF) evaluates to 3, the driver will now treat a
read failure as a valid configuration instead of aborting the probe.

Before this patch, the value 3 hit the default case and safely returned
-ENODEV. Should there be a check to ensure the register value is not 0xFFFF
before evaluating the configuration?

>  		case 2:
>  			vmd->busn_start = 224;
>  			break;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260604185953.17177-1-ali.alaei.tabatabaei@gmail.com?part=1

[PATCH v2] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[Ali Alaei]

Intel Arrow Lake-HX platforms (e.g., Core Ultra 9 275HX) use VMD device
8086:ad0b, which is already in the driver's ID table. However, on these
platforms the VMCONFIG register's BUS_RESTRICT_CFG field returns 3 during
probe. vmd_get_bus_number_start() only handles values 0-2 and returns
-ENODEV for anything else, causing VMD probe to fail and leaving NVMe
drives behind the VMD controller invisible to the OS.

Handle cfg=3 the same as cfg=2 (busn_start=224).

Also add a PCI_POSSIBLE_ERROR() check after reading VMCONFIG: when a
device is removed or a config read fails, pci_read_config_word() returns
0xFFFF, and BUS_RESTRICT_CFG(0xFFFF) = 3. Without this check the new
case 3 would silently treat a read failure as a valid configuration,
masking the error instead of aborting probe. The driver already applies
this pattern for the VMLOCK read in vmd_get_phys_offsets().

Tested on: Acer Predator PH16-73 with Intel Core Ultra 9 275HX
           (VMD controller 0000:00:0e.0, 8086:ad0b).

v2: Add PCI_POSSIBLE_ERROR() guard after VMCONFIG read to avoid treating
    a config read failure (0xFFFF) as a valid cfg=3 value.

Signed-off-by: Ali Alaei <ali.alaei.tabatabaei@gmail.com>
---
 drivers/pci/controller/vmd.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index XXXXXXX..YYYYYYY 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -640,6 +640,8 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
 	pci_read_config_word(dev, PCI_REG_VMCAP, &reg);
 	if (BUS_RESTRICT_CAP(reg)) {
 		pci_read_config_word(dev, PCI_REG_VMCONFIG, &reg);
+		if (PCI_POSSIBLE_ERROR(reg))
+			return -ENODEV;

 		switch (BUS_RESTRICT_CFG(reg)) {
 		case 0:
@@ -649,6 +651,7 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
 		case 1:
 			vmd->busn_start = 128;
 			break;
+		case 3:
 		case 2:
 			vmd->busn_start = 224;
 			break;
--
2.49.0

Re: [PATCH v2] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[Manivannan Sadhasivam]

On Thu, Jun 04, 2026 at 11:40:51PM +0200, Ali Alaei wrote:
> Intel Arrow Lake-HX platforms (e.g., Core Ultra 9 275HX) use VMD device
> 8086:ad0b, which is already in the driver's ID table. However, on these
> platforms the VMCONFIG register's BUS_RESTRICT_CFG field returns 3 during
> probe. vmd_get_bus_number_start() only handles values 0-2 and returns
> -ENODEV for anything else, causing VMD probe to fail and leaving NVMe
> drives behind the VMD controller invisible to the OS.
> 
> Handle cfg=3 the same as cfg=2 (busn_start=224).
> 
> Also add a PCI_POSSIBLE_ERROR() check after reading VMCONFIG: when a
> device is removed or a config read fails, pci_read_config_word() returns
> 0xFFFF, and BUS_RESTRICT_CFG(0xFFFF) = 3. Without this check the new
> case 3 would silently treat a read failure as a valid configuration,
> masking the error instead of aborting probe. The driver already applies
> this pattern for the VMLOCK read in vmd_get_phys_offsets().
> 
> Tested on: Acer Predator PH16-73 with Intel Core Ultra 9 275HX
>            (VMD controller 0000:00:0e.0, 8086:ad0b).
> 
> v2: Add PCI_POSSIBLE_ERROR() guard after VMCONFIG read to avoid treating
>     a config read failure (0xFFFF) as a valid cfg=3 value.

Changelog should go into the comments section i.e., after '---' below. Also, you
didn't CC all relevant people including VMD maintainers:

./scripts/get_maintainer.pl drivers/pci/controller/vmd.c
Nirmal Patel <nirmal.patel@linux.intel.com> (maintainer:PCI DRIVER FOR INTEL VOLUME MANAGEMENT DEVICE (...)
Jonathan Derrick <jonathan.derrick@linux.dev> (reviewer:PCI DRIVER FOR INTEL VOLUME MANAGEMENT DEVICE (...)
Lorenzo Pieralisi <lpieralisi@kernel.org> (maintainer:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS)
"Krzysztof Wilczyński" <kwilczynski@kernel.org> (maintainer:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS)
Manivannan Sadhasivam <mani@kernel.org> (maintainer:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS)
Rob Herring <robh@kernel.org> (reviewer:PCI NATIVE HOST BRIDGE AND ENDPOINT DRIVERS)
Bjorn Helgaas <bhelgaas@google.com> (maintainer:PCI SUBSYSTEM)
linux-pci@vger.kernel.org (open list:PCI DRIVER FOR INTEL VOLUME MANAGEMENT DEVICE (...)
linux-kernel@vger.kernel.org (open list)

- Mani

-- 
மணிவண்ணன் சதாசிவம்

[PATCH v3] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[Ali Alaei]

On Intel Arrow Lake-HX systems (e.g. Core Ultra 9 275HX on Acer Predator
PH16-73), the VMD controller reports BUS_RESTRICT_CFG = 3 in the VMCONFIG
register. The existing switch statement only handled values 0, 1, and 2,
causing vmd_get_bus_number_start() to return -ENODEV and aborting the
entire VMD probe. This leaves NVMe drives behind the VMD controller
invisible to the kernel.

Hardware registers (VMCAP/VMCONFIG at offsets 0x40/0x44):
  VMD 0000:00:0e.0 (8086:ad0b): VMCAP=0x000f, VMCONFIG=0x03b8
  BUS_RESTRICT_CFG(0x03b8) = (0x03b8 >> 8) & 0x3 = 3

Add cfg=3 as a fallthrough to cfg=2, setting busn_start=224, which is
the correct bus number base for this hardware.

Also add a PCI_POSSIBLE_ERROR() guard after reading VMCONFIG: a failed
config space read returns 0xFFFF, and BUS_RESTRICT_CFG(0xFFFF) = 3,
so without this guard a removed or errored device would falsely match
the new case 3 instead of being caught as an error.

Signed-off-by: Ali Alaei <ali.alaei.tabatabaei@gmail.com>
---
Changes in v3:
 - Move changelog to after '---' (was incorrectly in commit message body)
 - Add missing VMD maintainers to CC (Nirmal Patel, Jonathan Derrick)

Changes in v2:
 - Add PCI_POSSIBLE_ERROR() guard after VMCONFIG read to prevent a
   failed config read (0xFFFF) from falsely matching case 3

 drivers/pci/controller/vmd.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
index xxxxxxx..yyyyyyy 100644
--- a/drivers/pci/controller/vmd.c
+++ b/drivers/pci/controller/vmd.c
@@ -640,6 +640,8 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
 	pci_read_config_word(dev, PCI_REG_VMCAP, &reg);
 	if (BUS_RESTRICT_CAP(reg)) {
 		pci_read_config_word(dev, PCI_REG_VMCONFIG, &reg);
+		if (PCI_POSSIBLE_ERROR(reg))
+			return -ENODEV;

 		switch (BUS_RESTRICT_CFG(reg)) {
 		case 0:
@@ -651,6 +653,7 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
 		case 1:
 			vmd->busn_start = 128;
 			break;
+		case 3:
 		case 2:
 			vmd->busn_start = 224;
 			break;
--
2.49.0

Re: [PATCH v3] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[sashiko-bot]

> On Intel Arrow Lake-HX systems (e.g. Core Ultra 9 275HX on Acer Predator
> PH16-73), the VMD controller reports BUS_RESTRICT_CFG = 3 in the VMCONFIG
> register. The existing switch statement only handled values 0, 1, and 2,
> causing vmd_get_bus_number_start() to return -ENODEV and aborting the
> entire VMD probe. This leaves NVMe drives behind the VMD controller
> invisible to the kernel.
> 
> Hardware registers (VMCAP/VMCONFIG at offsets 0x40/0x44):
>   VMD 0000:00:0e.0 (8086:ad0b): VMCAP=0x000f, VMCONFIG=0x03b8
>   BUS_RESTRICT_CFG(0x03b8) = (0x03b8 >> 8) & 0x3 = 3
> 
> Add cfg=3 as a fallthrough to cfg=2, setting busn_start=224, which is
> the correct bus number base for this hardware.
> 
> Also add a PCI_POSSIBLE_ERROR() guard after reading VMCONFIG: a failed
> config space read returns 0xFFFF, and BUS_RESTRICT_CFG(0xFFFF) = 3,
> so without this guard a removed or errored device would falsely match
> the new case 3 instead of being caught as an error.
> 
> Signed-off-by: Ali Alaei <ali.alaei.tabatabaei@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260628143450.92492-1-ali.alaei.tabatabaei@gmail.com?part=1

Re: [PATCH v3] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[Ali Alaei]

Ping. Any feedback on this patch?

Re: [PATCH v3] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[Manivannan Sadhasivam]

On Sun, 28 Jun 2026 16:34:50 +0200, Ali Alaei wrote:
> On Intel Arrow Lake-HX systems (e.g. Core Ultra 9 275HX on Acer Predator
> PH16-73), the VMD controller reports BUS_RESTRICT_CFG = 3 in the VMCONFIG
> register. The existing switch statement only handled values 0, 1, and 2,
> causing vmd_get_bus_number_start() to return -ENODEV and aborting the
> entire VMD probe. This leaves NVMe drives behind the VMD controller
> invisible to the kernel.
> 
> [...]

Applied, thanks!

[1/1] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX
      commit: 22b47bd49e45c2f8288ee6b760a6b23508d9d799

Best regards,
-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v3] PCI: vmd: Handle BUS_RESTRICT_CFG value 3 for Arrow Lake-HX

[Bjorn Helgaas]

On Sun, Jun 28, 2026 at 04:34:50PM +0200, Ali Alaei wrote:
> On Intel Arrow Lake-HX systems (e.g. Core Ultra 9 275HX on Acer Predator
> PH16-73), the VMD controller reports BUS_RESTRICT_CFG = 3 in the VMCONFIG
> register. The existing switch statement only handled values 0, 1, and 2,
> causing vmd_get_bus_number_start() to return -ENODEV and aborting the
> entire VMD probe. This leaves NVMe drives behind the VMD controller
> invisible to the kernel.
> 
> Hardware registers (VMCAP/VMCONFIG at offsets 0x40/0x44):
>   VMD 0000:00:0e.0 (8086:ad0b): VMCAP=0x000f, VMCONFIG=0x03b8
>   BUS_RESTRICT_CFG(0x03b8) = (0x03b8 >> 8) & 0x3 = 3
> 
> Add cfg=3 as a fallthrough to cfg=2, setting busn_start=224, which is
> the correct bus number base for this hardware.
> 
> Also add a PCI_POSSIBLE_ERROR() guard after reading VMCONFIG: a failed
> config space read returns 0xFFFF, and BUS_RESTRICT_CFG(0xFFFF) = 3,
> so without this guard a removed or errored device would falsely match
> the new case 3 instead of being caught as an error.

I suppose this should fix
https://bugzilla.kernel.org/show_bug.cgi?id=221136, which is a problem
on an Arrow-Lake-S system?  I bcc'd the reporter, and we could add a
Reported-by: and/or Closes: tag if appropriate.

That report mentions a 8086:09ab VMD device, and it looks like this
patch addresses a 8086:ad0b device.  I suppose there are lots of VMD
devices IDs that appear in lots of systems and implement this feature,
which the bugzilla suggests is called "Dynamic Bus Offset".

Given that this is apparently a new VMD mode, AFAIK there is no public
hardware spec for this, and the patch doesn't add any new code (and I
would expect a new feature to require some new code), it would really
be nice to have the Intel VMD maintainers chime in here.

> Signed-off-by: Ali Alaei <ali.alaei.tabatabaei@gmail.com>
> ---
> Changes in v3:
>  - Move changelog to after '---' (was incorrectly in commit message body)
>  - Add missing VMD maintainers to CC (Nirmal Patel, Jonathan Derrick)
> 
> Changes in v2:
>  - Add PCI_POSSIBLE_ERROR() guard after VMCONFIG read to prevent a
>    failed config read (0xFFFF) from falsely matching case 3
> 
>  drivers/pci/controller/vmd.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index xxxxxxx..yyyyyyy 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -640,6 +640,8 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
>  	pci_read_config_word(dev, PCI_REG_VMCAP, &reg);
>  	if (BUS_RESTRICT_CAP(reg)) {
>  		pci_read_config_word(dev, PCI_REG_VMCONFIG, &reg);
> +		if (PCI_POSSIBLE_ERROR(reg))
> +			return -ENODEV;
> 
>  		switch (BUS_RESTRICT_CFG(reg)) {
>  		case 0:
> @@ -651,6 +653,7 @@ static int vmd_get_bus_number_start(struct vmd_dev *vmd)
>  		case 1:
>  			vmd->busn_start = 128;
>  			break;
> +		case 3:
>  		case 2:
>  			vmd->busn_start = 224;
>  			break;
> --
> 2.49.0