[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx
On Mon, Jul 22, 2019 at 01:54:00PM +0200, Paul Durrant wrote: > > -----Original Message----- > > From: Roger Pau Monne <roger.pau@xxxxxxxxxx> > > Sent: 22 July 2019 12:49 > > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; 'Roman Shaposhnik' > > <roman@xxxxxxxxxx> > > Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx; jgross@xxxxxxxx; Andrew Cooper > > <Andrew.Cooper3@xxxxxxxxxx>; > > boris.ostrovsky@xxxxxxxxxx; jbeulich@xxxxxxxx > > Subject: Re: [Xen-devel] [BUG] After upgrade to Xen 4.12.0 iommu=no-igfx > > > > 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); > > But this is going to mean the if() below is true for non-strict dom0, which > means it pointlessly maps the dom0 page list when hwdom_iommu_map() should > have already mapped all conventional RAM. Right, this all seems quite broken. Non-translated guests (ie: PV) would always need iommu page-table sync, but set_identity_p2m_entry contains the following: if ( !paging_mode_translate(p2m->domain) ) { if ( !need_iommu_pt_sync(d) ) return 0; return iommu_legacy_map(d, _dfn(gfn_l), _mfn(gfn_l), PAGE_ORDER_4K, IOMMUF_readable | IOMMUF_writable); } I wonder whether the usage of need_iommu_pt_sync is wrong there, and should instead be !has_iommu_pt(d), since non-translated domains would never share the iommu page-tables anyway. In any case, I think need_sync must be set when the iommu page tables are not shared, and gating it on iommu_hwdom_strict seems wrong to me, the strictness of the iommu doesn't affect whether a sync is need or not. I've updated the patch to avoid the pointless mapping of dom0 page list, but I haven't included the change to set_identity_p2m_entry. Thanks, Roger. ---8<--- diff --git a/xen/drivers/passthrough/iommu.c b/xen/drivers/passthrough/iommu.c index 79ec6719f5..abf9e38607 100644 --- a/xen/drivers/passthrough/iommu.c +++ b/xen/drivers/passthrough/iommu.c @@ -185,8 +185,8 @@ 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); - if ( need_iommu_pt_sync(d) ) + hd->need_sync = !iommu_use_hap_pt(d); + if ( iommu_hwdom_strict && need_iommu_pt_sync(d) ) { struct page_info *page; unsigned int i = 0, flush_flags = 0; _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |