VT-d: reconcile iommu_inclusive_mapping and iommu=dom0-strict

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 of 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@citrix.com>
Reviewed-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Kevin Tian <kevin.tian@intel.com>
This commit is contained in:
Paul Durrant authored and Jan Beulich committed 2018-07-02 13:06:49 +02:00
1 parent 2af20930a5
commit 402ab7cb66
4 files changed
+13 -3

No files matched your search

+3 -1
View File
@@ -1213,7 +1213,9 @@ wait descriptor timed out', try increasing this value.
Use this to work around firmware issues providing incorrect RMRR entries.
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.
get a mapping established. Note that this option is only applicable to a
PV dom0. Also note that if `dom0-strict` mode is enabled then conventional
RAM pages not assigned to dom0 will not be mapped.
### irq\_ratelimit (x86)
> `= <integer>`
+1 -1
View File
@@ -1304,7 +1304,7 @@ static void __hwdom_init intel_iommu_hwdom_init(struct domain *d)
{
struct acpi_drhd_unit *drhd;
if ( !iommu_passthrough && !need_iommu(d) )
if ( !iommu_passthrough && is_pv_domain(d) )
{
/* Set up 1:1 page table for hardware domain. */
vtd_set_hwdom_mapping(d);
+8
View File
@@ -144,6 +144,14 @@ void __hwdom_init vtd_set_hwdom_mapping(struct domain *d)
if ( xen_in_range(pfn) )
continue;
/*
* If dom0-strict mode is enabled then exclude conventional RAM
* and let the common code map dom0's pages.
*/
if ( iommu_dom0_strict &&
page_is_ram_type(pfn, RAM_TYPE_CONVENTIONAL) )
continue;
tmp = 1 << (PAGE_SHIFT - PAGE_SHIFT_4K);
for ( j = 0; j < tmp; j++ )
{
+1 -1
View File
@@ -29,7 +29,7 @@
#include <asm/iommu.h>
extern bool_t iommu_enable, iommu_enabled;
extern bool_t force_iommu, iommu_verbose;
extern bool_t force_iommu, iommu_dom0_strict, iommu_verbose;
extern bool_t iommu_workaround_bios_bug, iommu_igfx, iommu_passthrough;
extern bool_t iommu_snoop, iommu_qinval, iommu_intremap, iommu_intpost;
extern bool_t iommu_hap_pt_share;
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.