> From: Paul Durrant [mailto:paul.durr...@citrix.com] > Sent: Saturday, June 16, 2018 12:31 AM > > The documentation for the iommu_inclusive_mapping Xen command line > option > states: > > "Use this to work around firmware issues providing incorrect RMRR > entries" > > Unfortunately this workaround does not function correctly if the dom0- > strict > iommu option is also specified. > > The documentation goes on to say: > > "Rather than only mapping RAM pages for IOMMU accesses for Dom0, with > this > option all pages up to 4GB, not marked as unusable in the E820 table, will > get a mapping established." > > This patch modifies the VT-d hardware domain initialization code such that > the workaround will continue to function in dom0-strict mode, by mapping > all pages not marked as unusable *unless* they are RAM pages not > assigned > to dom0. > > NOTE: This patch modifies the test in drivers/passthrough/vtd/iommu.c > from > need_iommu() to is_pv_domain() since dom0-strict implies > need_iommu() > so we no longer want to gate invocation od vtd_set_hwdom_mapping()
od->of > on that. > It also exports the iommu_dom0_strict flag so that the implementation > of vtd_set_hwdom_mapping() can test it explicitly. It would be > possible to test need_iommu() instead, but it is more illustrative > to test the original flag rather than one of its side-effects. > > Signed-off-by: Paul Durrant <paul.durr...@citrix.com> > Reviewed-by: Roger Pau Monne <roger....@citrix.com> Acked-by: Kevin Tian <kevin.t...@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
