VT-d: fix off-by-one error in RMRR validation

(base_addr,end_addr) is an inclusive range, and hence there shouldn't
be a subtraction of 1 in the second invocation of page_is_ram_type().
For RMRRs covering a single page that actually resulted in the
immediately preceding page to get checked (which could have resulted
in a false warning).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
xen-unstable changeset:   23868:28147fd781af
xen-unstable date:        Thu Sep 22 18:32:34 2011 +0100

diff --git a/xen/drivers/passthrough/vtd/dmar.c b/xen/drivers/passthrough/vtd/dmar.c
index 1c7f9f3027f97409233b29dfa7c52fcbd6fa7c5b..0737c5af8b279187afb4ff4cb8fb5730fa2b4321 100644 (file)
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -515,7 +515,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_entry_header *header)
      * inform the user
      */
     if ( (!page_is_ram_type(paddr_to_pfn(base_addr), RAM_TYPE_RESERVED)) ||
-         (!page_is_ram_type(paddr_to_pfn(end_addr) - 1, RAM_TYPE_RESERVED)) )
+         (!page_is_ram_type(paddr_to_pfn(end_addr), RAM_TYPE_RESERVED)) )
     {
         dprintk(XENLOG_WARNING VTDPREFIX,
                 "  RMRR address range not in reserved memory "