Repository navigation
Backport #105 to 6.18-lts: iommu/xen: reserve dom0's PCI windows, and fix the modular pcifront link - #110
Open
edera-rebase-app[bot] wants to merge 2 commits into
Open
Backport #105 to 6.18-lts: iommu/xen: reserve dom0's PCI windows, and fix the modular pcifront link#110edera-rebase-app[bot] wants to merge 2 commits into
edera-rebase-app[bot] wants to merge 2 commits into
Conversation
Commit 1b82771 ("iommu/dma: Don't reserve PCI windows under a paravirtual IOMMU") skips iova_reserve_pci_windows() for every device the Xen IOMMU driver owns, because the windows a guest sees are invented: pcifront hands out iomem_resource itself and a PVH guest with no host-bridge _CRS gets Linux's catch-all default. That holds for a guest. Dom0 sees the real host bridges, and their windows route to the real BARs of the devices behind them. A PVH dom0 device gets a translated DMA domain, and dma-iommu hands out IOVAs top-down below 4 GiB. The driver reserves only the MSI range, so once the space above it is used, IOVAs land inside the host-bridge window where sibling devices' BARs live. On a root port or switch without ACS a DMA to such an address is decoded as peer-to-peer and delivered to the sibling's BAR: it never reaches the IOMMU, so the transfer is lost and the sibling's registers are written. Xen enables ACS where it can, which redirects such requests upstream, but that is defence in depth, not a reason to skip the reservation. Have xen_iommu_manages_iova() answer false in the initial domain, so dom0 reserves its windows as on bare metal. Signed-off-by: Ariadne Conill <ariadne@ariadne.space> (cherry picked from commit 55da034)
… when modular include/xen/pci.h declares pcifront_machine_sbdf() as a real function whenever CONFIG_XEN_PCIDEV_FRONTEND is defined, which it is for =m as well as =y. XEN_IOMMU is a bool and calls it from built-in code, so XEN_IOMMU=y with XEN_PCIDEV_FRONTEND=m fails to link vmlinux. Declare the function only when pcifront is built in and give built-in callers the -ENODEV stub otherwise. The IOMMU driver with that stub would silently use a pcifront device's guest BDF, which means nothing to Xen, so also keep XEN_IOMMU from being configured with a modular pcifront rather than let it build into a driver that cannot name the devices it manages. Signed-off-by: Ariadne Conill <ariadne@ariadne.space> (cherry picked from commit 9e5d4e3)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Backport of #105 from
edera/mainlinetoedera/6.18-lts(492d0ef30003), prepared by Claude. Run log.Merge with Rebase and merge, so
edera/6.18-ltsstays linear.Independent checks
Builds: success (x86_64 and arm64 vmlinux with the Edera features built in).
492d0ef300035e67325ad286Claude's report
Claude left no report (backport step: success).