VT-d: fix and extend RMRR reservation check

First of all in commit d6573bc6e6b7 ("VT-d: check all of an RMRR for
being E820-reserved") along with changing the function used, the enum-
like value passed should have been changed too (to E820_*). Do so now.
(Luckily the actual values of RAM_TYPE_RESERVED and E820_RESERVED
match, so the breakage introduced was "only" latent.)

Furthermore one of my systems surfaces RMRR in an ACPI NVS E820 range.
The purpose of the check is just to make sure there won't be "ordinary"
mappings of these ranges, and domains (including Dom0) won't want to
use the region to e.g. put PCI device BARs there. The two ACPI related
E820 types are good enough for this purpose, so allow them as well.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>

diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index 9408e6db37dc150b3d378dbeb5ca00f2f3611c05..29cd5c5d70e76080edc1aac3bb5ac62c3638837e 100644 (file)
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -632,7 +632,9 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
      * not properly represented in the system memory map and
      * inform the user
      */
-    if ( !e820_all_mapped(base_addr, end_addr + 1, RAM_TYPE_RESERVED) )
+    if ( !e820_all_mapped(base_addr, end_addr + 1, E820_RESERVED) &&
+         !e820_all_mapped(base_addr, end_addr + 1, E820_NVS) &&
+         !e820_all_mapped(base_addr, end_addr + 1, E820_ACPI) )
         printk(XENLOG_WARNING VTDPREFIX
                " RMRR [%"PRIx64",%"PRIx64"] not in reserved memory;"
                " need \"iommu_inclusive_mapping=1\"?\n",