linux-dev/arch/x86/pci, branch master

x86/PCI: Revert "x86/PCI: Clip only host bridge windows for E820 regions"

2022-06-17T19:24:14Z

This reverts commit 4c5e242d3e93. Prior to 4c5e242d3e93 ("x86/PCI: Clip only host bridge windows for E820 regions"), E820 regions did not affect PCI host bridge windows. We only looked at E820 regions and avoided them when allocating new MMIO space. If firmware PCI bridge window and BAR assignments used E820 regions, we left them alone. After 4c5e242d3e93, we removed E820 regions from the PCI host bridge windows before looking at BARs, so firmware assignments in E820 regions looked like errors, and we moved things around to fit in the space left (if any) after removing the E820 regions. This unnecessary BAR reassignment broke several machines. Guilherme reported that Steam Deck fails to boot after 4c5e242d3e93. We clipped the window that contained most 32-bit BARs: BIOS-e820: [mem 0x00000000a0000000-0x00000000a00fffff] reserved acpi PNP0A08:00: clipped [mem 0x80000000-0xf7ffffff window] to [mem 0xa0100000-0xf7ffffff window] for e820 entry [mem 0xa0000000-0xa00fffff] which forced us to reassign all those BARs, for example, this NVMe BAR: pci 0000:00:01.2: PCI bridge to [bus 01] pci 0000:00:01.2: bridge window [mem 0x80600000-0x806fffff] pci 0000:01:00.0: BAR 0: [mem 0x80600000-0x80603fff 64bit] pci 0000:00:01.2: can't claim window [mem 0x80600000-0x806fffff]: no compatible bridge window pci 0000:01:00.0: can't claim BAR 0 [mem 0x80600000-0x80603fff 64bit]: no compatible bridge window pci 0000:00:01.2: bridge window: assigned [mem 0xa0100000-0xa01fffff] pci 0000:01:00.0: BAR 0: assigned [mem 0xa0100000-0xa0103fff 64bit] All the reassignments were successful, so the devices should have been functional at the new addresses, but some were not. Andy reported a similar failure on an Intel MID platform. Benjamin reported a similar failure on a VMWare Fusion VM. Note: this is not a clean revert; this revert keeps the later change to make the clipping dependent on a new pci_use_e820 bool, moving the checking of this bool to arch_remove_reservations(). [bhelgaas: commit log, add more reporters and testers] BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216109 Reported-by: Guilherme G. Piccoli Reported-by: Andy Shevchenko Reported-by: Benjamin Coddington Reported-by: Jongman Heo Fixes: 4c5e242d3e93 ("x86/PCI: Clip only host bridge windows for E820 regions") Link: https://lore.kernel.org/r/20220612144325.85366-1-hdegoede@redhat.com Tested-by: Guilherme G. Piccoli Tested-by: Andy Shevchenko Tested-by: Benjamin Coddington Signed-off-by: Hans de Goede Signed-off-by: Bjorn Helgaas

Merge tag 'pci-v5.19-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci

2022-05-27T22:25:10Z

Pull pci updates from Bjorn Helgaas: "Resource management: - Restrict E820 clipping to PCI host bridge windows (Bjorn Helgaas) - Log E820 clipping better (Bjorn Helgaas) - Add kernel cmdline options to enable/disable E820 clipping (Hans de Goede) - Disable E820 reserved region clipping for IdeaPads, Yoga, Yoga Slip, Acer Spin 5, Clevo Barebone systems where clipping leaves no usable address space for touchpads, Thunderbolt devices, etc (Hans de Goede) - Disable E820 clipping by default starting in 2023 (Hans de Goede) PCI device hotplug: - Include files to remove implicit dependencies (Christophe Leroy) - Only put Root Ports in D3 if they can signal and wake from D3 so AMD Yellow Carp doesn't miss hotplug events (Mario Limonciello) Power management: - Define pci_restore_standard_config() only for CONFIG_PM_SLEEP since it's unused otherwise (Krzysztof Kozlowski) - Power up devices completely, including anything platform firmware needs to do, during runtime resume (Rafael J. Wysocki) - Move pci_resume_bus() to PM callbacks so we observe the required bridge power-up delays (Rafael J. Wysocki) - Drop unneeded runtime_d3cold device flag (Rafael J. Wysocki) - Split pci_raw_set_power_state() between pci_power_up() and a new pci_set_low_power_state() (Rafael J. Wysocki) - Set current_state to D3cold if config read returns ~0, indicating the device is not accessible (Rafael J. Wysocki) - Do not call pci_update_current_state() from pci_power_up() so BARs and ASPM config are restored correctly (Rafael J. Wysocki) - Write 0 to PMCSR in pci_power_up() in all cases (Rafael J. Wysocki) - Split pci_power_up() to pci_set_full_power_state() to avoid some redundant operations (Rafael J. Wysocki) - Skip restoring BARs if device is not in D0 (Rafael J. Wysocki) - Rearrange and clarify pci_set_power_state() (Rafael J. Wysocki) - Remove redundant BAR restores from pci_pm_thaw_noirq() (Rafael J. Wysocki) Virtualization: - Acquire device lock before config space access lock to avoid AB/BA deadlock with sriov_numvfs_store() (Yicong Yang) Error handling: - Clear MULTI_ERR_COR/UNCOR_RCV bits, which a race could previously leave permanently set (Kuppuswamy Sathyanarayanan) Peer-to-peer DMA: - Whitelist Intel Skylake-E Root Ports regardless of which devfn they are (Shlomo Pongratz) ASPM: - Override L1 acceptable latency advertised by Intel DG2 so ASPM L1 can be enabled (Mika Westerberg) Cadence PCIe controller driver: - Set up device-specific register to allow PTM Responder to be enabled by the normal architected bit (Christian Gmeiner) - Override advertised FLR support since the controller doesn't implement FLR correctly (Parshuram Thombare) Cadence PCIe endpoint driver: - Correct bitmap size for the ob_region_map of outbound window usage (Dan Carpenter) Freescale i.MX6 PCIe controller driver: - Fix PERST# assertion/deassertion so we observe the required delays before accessing device (Francesco Dolcini) Freescale Layerscape PCIe controller driver: - Add "big-endian" DT property (Hou Zhiqiang) - Update SCFG DT property (Hou Zhiqiang) - Add "aer", "pme", "intr" DT properties (Li Yang) - Add DT compatible strings for ls1028a (Xiaowei Bao) Intel VMD host bridge driver: - Assign VMD IRQ domain before enumeration to avoid IOMMU interrupt remapping errors when MSI-X remapping is disabled (Nirmal Patel) - Revert VMD workaround that kept MSI-X remapping enabled when IOMMU remapping was enabled (Nirmal Patel) Marvell MVEBU PCIe controller driver: - Add of_pci_get_slot_power_limit() to parse the 'slot-power-limit-milliwatt' DT property (Pali Rohár) - Add mvebu support for sending Set_Slot_Power_Limit message (Pali Rohár) MediaTek PCIe controller driver: - Fix refcount leak in mtk_pcie_subsys_powerup() (Miaoqian Lin) MediaTek PCIe Gen3 controller driver: - Reset PHY and MAC at probe time (AngeloGioacchino Del Regno) Microchip PolarFlare PCIe controller driver: - Add chained_irq_enter()/chained_irq_exit() calls to mc_handle_msi() and mc_handle_intx() to avoid lost interrupts (Conor Dooley) - Fix interrupt handling race (Daire McNamara) NVIDIA Tegra194 PCIe controller driver: - Drop tegra194 MSI register save/restore, which is unnecessary since the DWC core does it (Jisheng Zhang) Qualcomm PCIe controller driver: - Add SM8150 SoC DT binding and support (Bhupesh Sharma) - Fix pipe clock imbalance (Johan Hovold) - Fix runtime PM imbalance on probe errors (Johan Hovold) - Fix PHY init imbalance on probe errors (Johan Hovold) - Convert DT binding to YAML (Dmitry Baryshkov) - Update DT binding to show that resets aren't required for MSM8996/APQ8096 platforms (Dmitry Baryshkov) - Add explicit register names per chipset in DT binding (Dmitry Baryshkov) - Add sc7280-specific clock and reset definitions to DT binding (Dmitry Baryshkov) Rockchip PCIe controller driver: - Fix bitmap size when searching for free outbound region (Dan Carpenter) Rockchip DesignWare PCIe controller driver: - Remove "snps,dw-pcie" from rockchip-dwc DT "compatible" property because it's not fully compatible with rockchip (Peter Geis) - Reset rockchip-dwc controller at probe (Peter Geis) - Add rockchip-dwc INTx support (Peter Geis) Synopsys DesignWare PCIe controller driver: - Return error instead of success if DMA mapping of MSI area fails (Jiantao Zhang) Miscellaneous: - Change pci_set_dma_mask() documentation references to dma_set_mask() (Alex Williamson)" * tag 'pci-v5.19-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (64 commits) dt-bindings: PCI: qcom: Add schema for sc7280 chipset dt-bindings: PCI: qcom: Specify reg-names explicitly dt-bindings: PCI: qcom: Do not require resets on msm8996 platforms dt-bindings: PCI: qcom: Convert to YAML PCI: qcom: Fix unbalanced PHY init on probe errors PCI: qcom: Fix runtime PM imbalance on probe errors PCI: qcom: Fix pipe clock imbalance PCI: qcom: Add SM8150 SoC support dt-bindings: pci: qcom: Document PCIe bindings for SM8150 SoC x86/PCI: Disable E820 reserved region clipping starting in 2023 x86/PCI: Disable E820 reserved region clipping via quirks x86/PCI: Add kernel cmdline options to use/ignore E820 reserved regions PCI: microchip: Fix potential race in interrupt handling PCI/AER: Clear MULTI_ERR_COR/UNCOR_RCV bits PCI: cadence: Clear FLR in device capabilities register PCI: cadence: Allow PTM Responder to be enabled PCI: vmd: Revert 2565e5b69c44 ("PCI: vmd: Do not disable MSI-X remapping if interrupt remapping is enabled by IOMMU.") PCI: vmd: Assign VMD IRQ domain before enumeration PCI: Avoid pci_dev_lock() AB/BA deadlock with sriov_numvfs_store() PCI: rockchip-dwc: Add legacy interrupt support ...

Merge tag 'dma-mapping-5.19-2022-05-25' of git://git.infradead.org/users/hch/dma-mapping

2022-05-26T02:18:36Z

Pull dma-mapping updates from Christoph Hellwig: - don't over-decrypt memory (Robin Murphy) - takes min align mask into account for the swiotlb max mapping size (Tianyu Lan) - use GFP_ATOMIC in dma-debug (Mikulas Patocka) - fix DMA_ATTR_NO_KERNEL_MAPPING on xen/arm (me) - don't fail on highmem CMA pages in dma_direct_alloc_pages (me) - cleanup swiotlb initialization and share more code with swiotlb-xen (me, Stefano Stabellini) * tag 'dma-mapping-5.19-2022-05-25' of git://git.infradead.org/users/hch/dma-mapping: (23 commits) dma-direct: don't over-decrypt memory swiotlb: max mapping size takes min align mask into account swiotlb: use the right nslabs-derived sizes in swiotlb_init_late swiotlb: use the right nslabs value in swiotlb_init_remap swiotlb: don't panic when the swiotlb buffer can't be allocated dma-debug: change allocation mode from GFP_NOWAIT to GFP_ATIOMIC dma-direct: don't fail on highmem CMA pages in dma_direct_alloc_pages swiotlb-xen: fix DMA_ATTR_NO_KERNEL_MAPPING on arm x86: remove cruft from swiotlb: remove swiotlb_init_with_tbl and swiotlb_init_late_with_tbl swiotlb: merge swiotlb-xen initialization into swiotlb swiotlb: provide swiotlb_init variants that remap the buffer swiotlb: pass a gfp_mask argument to swiotlb_init_late swiotlb: add a SWIOTLB_ANY flag to lift the low memory restriction swiotlb: make the swiotlb_init interface more useful x86: centralize setting SWIOTLB_FORCE when guest memory encryption is enabled x86: remove the IOMMU table infrastructure MIPS/octeon: use swiotlb_init instead of open coding it arm/xen: don't check for xen_initial_domain() in xen_create_contiguous_region swiotlb: rename swiotlb_late_init_with_default_size ...

Merge tag 'x86-irq-2022-05-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2022-05-24T00:18:25Z

Pull x86 PCI irq routing updates from Thomas Gleixner: - Cleanup and robustify the PCI interrupt routing table handling including proper range checks - Add support for Intel 82378ZB/82379AB, SiS85C497 PIRQ routers - Fix the ALi M1487 router handling - Handle the IRT routing table format in AMI BIOSes correctly * tag 'x86-irq-2022-05-23' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/PCI: Fix coding style in PIRQ table verification x86/PCI: Fix ALi M1487 (IBC) PIRQ router link value interpretation x86/PCI: Add $IRT PIRQ routing table support x86/PCI: Handle PIRQ routing tables with no router device given x86/PCI: Add PIRQ routing table range checks x86/PCI: Add support for the SiS85C497 PIRQ router x86/PCI: Disambiguate SiS85C503 PIRQ router code entities x86/PCI: Handle IRQ swizzling with PIRQ routers x86/PCI: Also match function number in $PIR table x86/PCI: Include function number in $PIR table dump x86/PCI: Show the physical address of the $PIR table

x86/PCI: Disable E820 reserved region clipping starting in 2023

2022-05-19T21:56:24Z

Some firmware includes unusable space (host bridge registers, hidden PCI device BARs, etc) in PCI host bridge _CRS. As far as we know, there's nothing in the ACPI, UEFI, or PCI Firmware spec that requires the OS to remove E820 reserved regions from _CRS, so this seems like a firmware defect. As a workaround, 4dc2287c1805 ("x86: avoid E820 regions when allocating address space") has clipped out the unusable space in the past. This is required for machines like the following: - Dell Precision T3500 (the original motivator for 4dc2287c1805); see https://bugzilla.kernel.org/show_bug.cgi?id=16228 - Asus C523NA (Coral) Chromebook; see https://lore.kernel.org/all/4e9fca2f-0af1-3684-6c97-4c35befd5019@redhat.com/ - Lenovo ThinkPad X1 Gen 2; see: https://bugzilla.redhat.com/show_bug.cgi?id=2029207 But other firmware supplies E820 reserved regions that cover entire _CRS windows, and clipping throws away the entire window, leaving none for hot-added or uninitialized devices. This clipping breaks a whole range of Lenovo IdeaPads, Yogas, Yoga Slims, and notebooks, as well as Acer Spin 5 and Clevo X170KM-G Barebone machines. E820 reserved entries that cover a memory-mapped PCI host bridge, including its registers and memory/IO windows, are probably *not* a firmware defect. Per ACPI v5.4, sec 15.2, the E820 memory map may include: Address ranges defined for baseboard memory-mapped I/O devices, such as APICs, are returned as reserved. Disable the E820 clipping by default for all post-2022 machines. We already have quirks to disable clipping for pre-2023 machines, and we'll likely need quirks to *enable* clipping for post-2022 machines that incorrectly include unusable space in _CRS, including Chromebooks and Lenovo ThinkPads. Here's the rationale for doing this. If we do nothing, and continue clipping by default: - Future systems like the Lenovo IdeaPads, Yogas, etc, Acer Spin, and Clevo Barebones will require new quirks to disable clipping. - The problem here is E820 entries that cover entire _CRS windows that should not be clipped out. - I think these E820 entries are legal per spec, and it would be hard to get BIOS vendors to change them. - We will discover new systems that need clipping disabled piecemeal as they are released. - Future systems like Lenovo X1 Carbon and the Chromebooks (probably anything using coreboot) will just work, even though their _CRS is incorrect, so we will not notice new ones that rely on the clipping. - BIOS updates will not require new quirks unless they change the DMI model string. If we add the date check in this commit that disables clipping, e.g., "no clipping when date >= 2023": - Future systems like Lenovo *IIL*, Acer Spin, and Clevo Barebones will just work without new quirks. - Future systems like Lenovo X1 Carbon and the Chromebooks will require new quirks to *enable* clipping. - The problem here is that _CRS contains regions that are not usable by PCI devices, and we rely on the E820 kludge to clip them out. - I think this use of E820 is clearly a firmware bug, so we have a fighting chance of getting it changed eventually. - BIOS updates after the cutoff date *will* require quirks, but only for systems like Lenovo X1 Carbon and Chromebooks that we already think have broken firmware. It seems to me like it's better to add quirks for firmware that we think is broken than for firmware that seems unusual but correct. [bhelgaas: comment and commit log] Link: https://lore.kernel.org/linux-pci/20220518220754.GA7911@bhelgaas/ Link: https://lore.kernel.org/r/20220519152150.6135-4-hdegoede@redhat.com Signed-off-by: Hans de Goede Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki Cc: Benoit Grégoire Cc: Hui Wang

x86/PCI: Disable E820 reserved region clipping via quirks

2022-05-19T21:55:46Z

To avoid unusable space that some firmware includes in PCI host bridge _CRS, Linux currently excludes E820 reserved regions from _CRS windows; see 4dc2287c1805 ("x86: avoid E820 regions when allocating address space"). However, some systems supply E820 reserved regions that cover the entire memory window from _CRS, so clipping them out leaves no space for hot-added or uninitialized PCI devices. For example, from a Lenovo IdeaPad 3 15IIL 81WE: BIOS-e820: [mem 0x4bc50000-0xcfffffff] reserved pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window] pci 0000:00:15.0: BAR 0: [mem 0x00000000-0x00000fff 64bit] pci 0000:00:15.0: BAR 0: no space for [mem size 0x00001000 64bit] Add quirks to disable the E820 clipping for machines known to do this. A single DMI_PRODUCT_VERSION "IIL" quirk matches all the below: Lenovo IdeaPad 3 14IIL05 Lenovo IdeaPad 3 15IIL05 Lenovo IdeaPad 3 17IIL05 Lenovo IdeaPad 5 14IIL05 Lenovo IdeaPad 5 15IIL05 Lenovo IdeaPad Slim 7 14IIL05 Lenovo IdeaPad Slim 7 15IIL05 Lenovo IdeaPad S145-15IIL Lenovo IdeaPad S340-14IIL Lenovo IdeaPad S340-15IIL Lenovo IdeaPad C340-15IIL Lenovo BS145-15IIL Lenovo V14-IIL Lenovo V15-IIL Lenovo V17-IIL Lenovo Yoga C940-14IIL Lenovo Yoga S740-14IIL Lenovo Yoga Slim 7 14IIL05 Lenovo Yoga Slim 7 15IIL05 in addition to the following that don't actually need it because they have no E820 reserved regions that overlap _CRS windows: Lenovo IdeaPad Flex 5 14IIL05 Lenovo IdeaPad Flex 5 15IIL05 Lenovo ThinkBook 14-IIL Lenovo ThinkBook 15-IIL Lenovo Yoga S940-14IIL Other quirks match these: Acer Spin 5 (SP513-54N) Clevo X170KM-G Barebone Link: https://bugzilla.kernel.org/show_bug.cgi?id=206459 Lenovo Yoga C940-14IIL Link: https://bugzilla.kernel.org/show_bug.cgi?id=214259 Clevo X170KM Barebone Link: https://bugzilla.redhat.com/show_bug.cgi?id=1868899 Lenovo IdeaPad 3 15IIL05 Link: https://bugzilla.redhat.com/show_bug.cgi?id=1871793 Lenovo IdeaPad 5 14IIL05 Link: https://bugs.launchpad.net/bugs/1878279 Lenovo IdeaPad 5 14IIL05 Link: https://bugs.launchpad.net/bugs/1880172 Lenovo IdeaPad 3 14IIL05 Link: https://bugs.launchpad.net/bugs/1884232 Acer Spin SP513-54N Link: https://bugs.launchpad.net/bugs/1921649 Lenovo IdeaPad S145 Link: https://bugs.launchpad.net/bugs/1931715 Lenovo IdeaPad S145 Link: https://bugs.launchpad.net/bugs/1932069 Lenovo BS145-15IIL Link: https://lore.kernel.org/r/20220519152150.6135-3-hdegoede@redhat.com Signed-off-by: Hans de Goede Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki Cc: Benoit Grégoire Cc: Hui Wang

x86/PCI: Add kernel cmdline options to use/ignore E820 reserved regions

2022-05-19T19:26:55Z

Some firmware supplies PCI host bridge _CRS that includes address space unusable by PCI devices, e.g., space occupied by host bridge registers or used by hidden PCI devices. To avoid this unusable space, Linux currently excludes E820 reserved regions from _CRS windows; see 4dc2287c1805 ("x86: avoid E820 regions when allocating address space"). However, this use of E820 reserved regions to clip things out of _CRS is not supported by ACPI, UEFI, or PCI Firmware specs, and some systems have E820 reserved regions that cover the entire memory window from _CRS. 4dc2287c1805 clips the entire window, leaving no space for hot-added or uninitialized PCI devices. For example, from a Lenovo IdeaPad 3 15IIL 81WE: BIOS-e820: [mem 0x4bc50000-0xcfffffff] reserved pci_bus 0000:00: root bus resource [mem 0x65400000-0xbfffffff window] pci 0000:00:15.0: BAR 0: [mem 0x00000000-0x00000fff 64bit] pci 0000:00:15.0: BAR 0: no space for [mem size 0x00001000 64bit] Future patches will add quirks to enable/disable E820 clipping automatically. Add a "pci=no_e820" kernel command line option to disable clipping with E820 reserved regions. Also add a matching "pci=use_e820" option to enable clipping with E820 reserved regions if that has been disabled by default by further patches in this patch-set. Both options taint the kernel because they are intended for debugging and workaround purposes until a quirk can set them automatically. [bhelgaas: commit log, add printk] Link: https://bugzilla.redhat.com/show_bug.cgi?id=1868899 Lenovo IdeaPad 3 Link: https://lore.kernel.org/r/20220519152150.6135-2-hdegoede@redhat.com Signed-off-by: Hans de Goede Signed-off-by: Bjorn Helgaas Acked-by: Rafael J. Wysocki Cc: Benoit Grégoire Cc: Hui Wang

x86/pci/xen: Disable PCI/MSI[-X] masking for XEN_HVM guests

2022-04-29T12:37:39Z

When a XEN_HVM guest uses the XEN PIRQ/Eventchannel mechanism, then PCI/MSI[-X] masking is solely controlled by the hypervisor, but contrary to XEN_PV guests this does not disable PCI/MSI[-X] masking in the PCI/MSI layer. This can lead to a situation where the PCI/MSI layer masks an MSI[-X] interrupt and the hypervisor grants the write despite the fact that it already requested the interrupt. As a consequence interrupt delivery on the affected device is not happening ever. Set pci_msi_ignore_mask to prevent that like it's done for XEN_PV guests already. Fixes: 809f9267bbab ("xen: map MSIs into pirqs") Reported-by: Jeremi Piotrowski Reported-by: Dusty Mabe Reported-by: Salvatore Bonaccorso Signed-off-by: Thomas Gleixner Tested-by: Noah Meyerhans Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87tuaduxj5.ffs@tglx

swiotlb: provide swiotlb_init variants that remap the buffer

2022-04-18T05:21:13Z

To shared more code between swiotlb and xen-swiotlb, offer a swiotlb_init_remap interface and add a remap callback to swiotlb_init_late that will allow Xen to remap the buffer without duplicating much of the logic. Signed-off-by: Christoph Hellwig Reviewed-by: Konrad Rzeszutek Wilk Tested-by: Boris Ostrovsky

swiotlb: pass a gfp_mask argument to swiotlb_init_late

2022-04-18T05:21:12Z

Let the caller chose a zone to allocate from. This will be used later on by the xen-swiotlb initialization on arm. Signed-off-by: Christoph Hellwig Reviewed-by: Anshuman Khandual Reviewed-by: Konrad Rzeszutek Wilk Tested-by: Boris Ostrovsky