[Xen-devel] [PATCH] VT-d: fix and extend RMRR reservation check

[Jan Beulich <jbeulich@xxxxxxxx>]

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@xxxxxxxx>

--- 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_hea
      * 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",

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel