[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()


>       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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.