On Mon, Jul 22, 2019 at 08:20:36AM +0000, Paul Durrant wrote: > > -----Original Message----- > [snip] > > > (XEN) Domain heap initialised > > > (XEN) ACPI: 32/64X FACS address mismatch in FADT - > > > 8ce8ef80/0000000000000000, using 32 > > > (XEN) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-119 > > > (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs > > > (XEN) [VT-D] RMRR address range 8d800000..8fffffff not in reserved > > > memory; need "iommu_inclusive_mapping=1"? > > This is your problem. In versions prior to 4.11 (I think, and certainly 4.12) > iommu_inclusive_mapping used to default on, whereas now it appears to default > off. In most circumstances this is fine because there is a new flag, > iommu_hwdom_reserved, which defaults on and this makes sure that all e820 > reserved regions are identity mapped (which usually covers undeclared RMRRs). > You have the opposite problem... a declared RMRR which is not reserved, so > you will need iommu_inclusive_mapping.
I think there's a bug in the initialization of iommu for a PV dom0, which leaves dom0 without rmrr entries. Can you try the patch below and report whether it solves your issue? Thanks, Roger. ---8<--- diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c index 79ec6719f5..9d91f0d633 100644 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -185,7 +185,7 @@ void __hwdom_init iommu_hwdom_init(struct domain *d) register_keyhandler('o', &iommu_dump_p2m_table, "dump iommu p2m table", 0); hd->status = IOMMU_STATUS_initializing; - hd->need_sync = iommu_hwdom_strict && !iommu_use_hap_pt(d); + hd->need_sync = !iommu_use_hap_pt(d); if ( need_iommu_pt_sync(d) ) { struct page_info *page; _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel