On Thu, Apr 03, 2025 at 06:01:42PM -0700, Stefano Stabellini wrote: > On one Sapphire AMD x86 board, I see this: > > > (XEN) [0000003943ca6ff2] [00000000f0000000, 00000000f7ffffff] (reserved) > (XEN) [00000039460886d9] [00000000fd000000, 00000000ffffffff] (reserved) > [...] > (XEN) [ 4.612235] 0000:02:00.0: not mapping BAR [fea00, fea03] invalid > position > > > Linux boots fine on this platform but Linux as Dom0 on Xen does not. > This is because the pci_check_bar->is_memory_hole check fails due to the > MMIO region overlapping with the EFI reserved region.
That's weird. (Partially) the reason to not attempt to map such BAR is that it should already be mapped, because at dom0 creation time all reserved regions are added to the p2m (see arch_iommu_hwdom_init()). If that's not the case we should figure out why this reserved region is not added to dom0 p2m as part of arch_iommu_hwdom_init(). Can you paste the dom0 build output when booted with `iommu=verbose dom0=pvh,verbose`? Does using `dom0=pvh,verbose,pf-fixup` solve the boot issue? (and can you paste the output if it does) The issue with allowing BARs to modify p2m reserved regions is that if memory decoding is disabled for the PCI device, the BAR will be unmapped from the p2m, thus creating a hole in the p2m for a reserved region, which would be undesirable IMO. Thanks, Roger.
