On Wed, Oct 21, 2020 at 12:33:05PM +0200, Jan Beulich wrote: > On 21.10.2020 11:58, Roger Pau Monné wrote: > > On Fri, Oct 16, 2020 at 12:23:22PM -0400, Jason Andryuk wrote: > >> The RMRRs are: > >> (XEN) [VT-D]Host address width 39 > >> (XEN) [VT-D]found ACPI_DMAR_DRHD: > >> (XEN) [VT-D] dmaru->address = fed90000 > >> (XEN) [VT-D]drhd->address = fed90000 iommu->reg = ffff82c00021d000 > >> (XEN) [VT-D]cap = 1c0000c40660462 ecap = 19e2ff0505e > >> (XEN) [VT-D] endpoint: 0000:00:02.0 > >> (XEN) [VT-D]found ACPI_DMAR_DRHD: > >> (XEN) [VT-D] dmaru->address = fed91000 > >> (XEN) [VT-D]drhd->address = fed91000 iommu->reg = ffff82c00021f000 > >> (XEN) [VT-D]cap = d2008c40660462 ecap = f050da > >> (XEN) [VT-D] IOAPIC: 0000:00:1e.7 > >> (XEN) [VT-D] MSI HPET: 0000:00:1e.6 > >> (XEN) [VT-D] flags: INCLUDE_ALL > >> (XEN) [VT-D]found ACPI_DMAR_RMRR: > >> (XEN) [VT-D] endpoint: 0000:00:14.0 > >> (XEN) [VT-D]dmar.c:615: RMRR region: base_addr 78863000 end_addr 78882fff > >> (XEN) [VT-D]found ACPI_DMAR_RMRR: > >> (XEN) [VT-D] endpoint: 0000:00:02.0 > >> (XEN) [VT-D]dmar.c:615: RMRR region: base_addr 7d000000 end_addr 7f7fffff > >> (XEN) [VT-D]found ACPI_DMAR_RMRR: > >> (XEN) [VT-D] endpoint: 0000:00:16.7 > >> (XEN) [VT-D]dmar.c:581: Non-existent device (0000:00:16.7) is > >> reported in RMRR (78907000, 78986fff)'s scope! > >> (XEN) [VT-D]dmar.c:596: Ignore the RMRR (78907000, 78986fff) due to > > > > This is also part of a reserved region, so should be added to the > > iommu page tables anyway regardless of this message. > > Could you clarify why you think so? RMRRs are tied to devices, so > if a device in reality doesn't exist (and no other one uses the > same range), I don't see why an IOMMU mapping would be needed > (unless to work around some related firmware bug). Plus aiui none > of the IOMMU faults actually report this range as having got > accessed. Since it's the hardware domain that gets the gfx card assigned here it will get any reserved regions added to the IOMMU page tables in arch_iommu_hwdom_init. I agree it's not relevant here, since those are not the regions reported in the IOMMU faults. Roger. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
