[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 2/2] VT-d: reconcile iommu_inclusive_mapping and iommu=dom0-strict
> From: Paul Durrant [mailto:paul.durrant@xxxxxxxxxx] > 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.durrant@xxxxxxxxxx> > Reviewed-by: Roger Pau Monne <roger.pau@xxxxxxxxxx> Acked-by: Kevin Tian <kevin.tian@xxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |