linux.git/drivers/pci/controller/vmd.c, branch v5.17-rc4

Merge branch 'pci/errors'

2022-01-13T15:57:52+00:00

- Add PCI_ERROR_RESPONSE and related definitions for signaling and checking
  for transaction errors on PCI (Naveen Naidu)

- Fabricate PCI_ERROR_RESPONSE data (~0) in config read wrappers, instead
  of in host controller drivers, when transactions fail on PCI (Naveen
  Naidu)

- Use PCI_POSSIBLE_ERROR() to check for possible failure of config reads
  (Naveen Naidu)

* pci/errors:
  PCI: xgene: Use PCI_ERROR_RESPONSE to identify config read errors
  PCI: hv: Use PCI_ERROR_RESPONSE to identify config read errors
  PCI: keystone: Use PCI_ERROR_RESPONSE to identify config read errors
  PCI: Use PCI_ERROR_RESPONSE to identify config read errors
  PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads
  PCI/PME: Use PCI_POSSIBLE_ERROR() to check config reads
  PCI/DPC: Use PCI_POSSIBLE_ERROR() to check config reads
  PCI: pciehp: Use PCI_POSSIBLE_ERROR() to check config reads
  PCI: vmd: Use PCI_POSSIBLE_ERROR() to check config reads
  PCI/ERR: Use PCI_POSSIBLE_ERROR() to check config reads
  PCI: rockchip-host: Drop error data fabrication when config read fails
  PCI: rcar-host: Drop error data fabrication when config read fails
  PCI: altera: Drop error data fabrication when config read fails
  PCI: mvebu: Drop error data fabrication when config read fails
  PCI: aardvark: Drop error data fabrication when config read fails
  PCI: kirin: Drop error data fabrication when config read fails
  PCI: histb: Drop error data fabrication when config read fails
  PCI: exynos: Drop error data fabrication when config read fails
  PCI: mediatek: Drop error data fabrication when config read fails
  PCI: iproc: Drop error data fabrication when config read fails
  PCI: thunder: Drop error data fabrication when config read fails
  PCI: Drop error data fabrication when config read fails
  PCI: Use PCI_SET_ERROR_RESPONSE() for disconnected devices
  PCI: Set error response data when config read fails
  PCI: Add PCI_ERROR_RESPONSE and related definitions

PCI: vmd: Add DID 8086:A77F for all Intel Raptor Lake SKU's

2022-01-05T16:24:45+00:00

Add support for this VMD device which supports the bus restriction mode.
The feature that turns off vector 0 for MSI-X remapping is also enabled.

Link: https://lore.kernel.org/r/20211217231211.46018-1-francisco.munoz.ruiz@linux.intel.com
Signed-off-by: Karthik L Gopalakrishnan 
Signed-off-by: Francisco Munoz 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Jon Derrick

PCI: vmd: Honor ACPI _OSC on PCIe features

2022-01-04T15:25:27+00:00

When Samsung PCIe Gen4 NVMe is connected to Intel ADL VMD, the
combination causes AER message flood and drags the system performance
down.

The issue doesn't happen when VMD mode is disabled in BIOS, since AER
isn't enabled by acpi_pci_root_create() . When VMD mode is enabled, AER
is enabled regardless of _OSC:
[    0.410076] acpi PNP0A08:00: _OSC: platform does not support [AER]
...
[    1.486704] pcieport 10000:e0:06.0: AER: enabled with IRQ 146

Since VMD is an aperture to regular PCIe root ports, honor ACPI _OSC to
disable PCIe features accordingly to resolve the issue.

Suggested-by: Rafael J. Wysocki 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215027
Link: https://lore.kernel.org/r/20211203031541.1428904-1-kai.heng.feng@canonical.com
Signed-off-by: Kai-Heng Feng 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Rafael J. Wysocki

PCI: vmd: Clean up domain before enumeration

2021-12-01T12:00:07+00:00

During VT-d pass-through, the VMD driver occasionally fails to
enumerate underlying NVMe devices when repetitive reboots are
performed in the guest OS. The issue can be resolved by resetting
VMD root ports for proper enumeration and triggering secondary bus
reset which will also propagate reset through downstream bridges.

Link: https://lore.kernel.org/r/20211116221136.85134-1-nirmal.patel@linux.intel.com
Signed-off-by: Nirmal Patel 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Jon Derrick

PCI: vmd: Use PCI_POSSIBLE_ERROR() to check config reads

2021-11-18T20:13:18+00:00

When config pci_ops.read() can detect failed PCI transactions, the data
returned to the CPU is PCI_ERROR_RESPONSE (~0 or 0xffffffff).

Obviously a successful PCI config read may *also* return that data if a
config register happens to contain ~0, so it doesn't definitively indicate
an error unless we know the register cannot contain ~0.

Use PCI_POSSIBLE_ERROR() to check the response we get when we read data
from hardware.  This unifies PCI error response checking and makes error
checks consistent and easier to find.

Link: https://lore.kernel.org/r/ed01cad87a2e35f3865275b5fb34290817a1ebf8.1637243717.git.naveennaidu479@gmail.com
Signed-off-by: Naveen Naidu 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Jonathan Derrick

Merge branch 'remotes/lorenzo/pci/vmd'

2021-11-05T16:28:53+00:00

- Assign a number to each VMD controller to distinguish them in
  /proc/interrupts (Chunguang Xu)

- Don't disable VMD MSI-X remapping if IOMMU remapping is enabled (Adrian
  Huang)

- Add Kconfig dependency on !UML for allyesconfig build issue (Johannes
  Berg)

* remotes/lorenzo/pci/vmd:
  PCI: vmd: depend on !UML
  PCI: vmd: Do not disable MSI-X remapping if interrupt remapping is enabled by IOMMU
  PCI: vmd: Assign a number to each VMD controller

PCI: vmd: Drop redundant includes of ,

2021-11-04T14:14:51+00:00

We already include  and , which
include  and .

Drop the redundant includes of  and .

[bhelgaas: squash in fix from Wan Jiabing :
https://lore.kernel.org/r/20211104063720.29375-1-wanjiabing@vivo.com]
Link: https://lore.kernel.org/r/20211013003145.1107148-1-kw@linux.com
Signed-off-by: Krzysztof Wilczyński 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Jonathan Derrick

PCI: vmd: Do not disable MSI-X remapping if interrupt remapping is enabled by IOMMU

2021-10-12T13:52:53+00:00

When enabling VMD in BIOS setup (Ice Lake Processor: Whitley platform),
the host OS cannot boot successfully with the following error message:

  nvme nvme0: I/O 12 QID 0 timeout, completion polled
  nvme nvme0: Shutdown timeout set to 6 seconds
  DMAR: DRHD: handling fault status reg 2
  DMAR: [INTR-REMAP] Request device [0x00:0x00.5] fault index 0xa00 [fault reason 0x25] Blocked a compatibility format interrupt request

The request device is the VMD controller:
  # lspci -s 0000:00.5 -nn
  0000:00:00.5 RAID bus controller [0104]: Intel Corporation Volume
  Management Device NVMe RAID Controller [8086:28c0] (rev 04)

`git bisect` points to this offending commit ee81ee84f873 ("PCI:
vmd: Disable MSI-X remapping when possible"), which disables VMD MSI
remapping. The IOMMU hardware blocks the compatibility format
interrupt request because Interrupt Remapping Enable Status (IRES) and
Extended Interrupt Mode Enable (EIME) are enabled. Please refer to
section "5.1.4 Interrupt-Remapping Hardware Operation" in Intel VT-d
spec.

To fix the issue, VMD driver still enables the interrupt remapping
irrespective of VMD_FEAT_CAN_BYPASS_MSI_REMAP if the IOMMU subsystem
enables the interrupt remapping.

Test configuration is shown as follows:
  * Two VMD controllers
    1. 8086:28c0 (Whitley's VMD)
    2. 8086:201d (Purley's VMD: The issue does not appear in this
       controller. Just make sure if any side effect occurs.)
  * w/wo intremap=off

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=214219
Link: https://lore.kernel.org/r/20210901124047.1615-1-adrianhuang0701@gmail.com
Signed-off-by: Adrian Huang 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Jon Derrick 
Cc: Jon Derrick 
Cc: Nirmal Patel 
Cc: Joerg Roedel

PCI: vmd: Assign a number to each VMD controller

2021-10-07T15:28:44+00:00

If the system has multiple VMD controllers, the driver does not assign
a number to each controller, so when analyzing the interrupt through
/proc/interrupts, the names of all controllers are the same, which is
not very convenient for problem analysis. Here, try to assign a number
to each VMD controller.

Link: https://lore.kernel.org/r/1631884404-24141-1-git-send-email-brookxu.cn@gmail.com
Signed-off-by: Chunguang Xu 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Jon Derrick 
Reviewed-by: Krzysztof Wilczyński

PCI: VMD: ACPI: Make ACPI companion lookup work for VMD bus

2021-09-02T15:59:58+00:00

On some systems, in order to get to the deepest low-power state of
the platform (which may be necessary to save significant enough
amounts of energy while suspended to idle. for example), devices on
the PCI bus exposed by the VMD driver need to be power-managed via
ACPI.  However, the layout of the ACPI namespace below the VMD
controller device object does not reflect the layout of the PCI bus
under the VMD host bridge, so in order to identify the ACPI companion
objects for the devices on that bus, it is necessary to use a special
_ADR encoding on the ACPI side.  In other words, acpi_pci_find_companion()
does not work for these devices, so it needs to be amended with a
special lookup logic specific to the VMD bus.

Address this issue by allowing the VMD driver to temporarily install
an ACPI companion lookup hook containing the code matching the devices
on the VMD PCI bus with the corresponding objects in the ACPI
namespace.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Jon Derrick