VT-d: fix off-by-one when handling extra RMRR ranges

add_one_user_rmrr() operates on inclusive [start,end] range, which means
the end page needs to be calculated as (start + page_count - 1).
This off-by-one error resulted in one extra pages being mapped in IOMMU
context, but not marked as reserved in the memory map. This in turns
confused PVH dom0 code, resulting in the following crash:

    (XEN) [    3.934848] d0: GFN 0x5475c (0x5475c,5,3) -> (0x46a0f4,0,7) not permitted (0x20)
    (XEN) [    3.969657] domain_crash called from arch/x86/mm/p2m.c:695
    (XEN) [    3.972568] Domain 0 reported crashed by domain 32767 on cpu#0:
    (XEN) [    3.975527] Hardware Dom0 crashed: rebooting machine in 5 seconds.
    (XEN) [    8.986353] Resetting with ACPI MEMORY or I/O RESET_REG.

I checked other parts of this API and it was the only error like this.
Other places:
 - iommu_get_extra_reserved_device_memory() -> reserve_e820_ram() - this
   function expects exclusive range, so the code is correct
 - add_one_extra_ivmd() - this operates on start address and memory
   length

Fixes: 2d9b369913 ("IOMMU/VT-d: wire common device reserved memory API")
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

xen/drivers/passthrough/vtd/dmar.c

@@ -1065,7 +1065,8 @@ static int __init add_user_rmrr(void)
 static int __init cf_check add_one_extra_rmrr(xen_pfn_t start, xen_ulong_t nr, u32 id, void *ctxt)
 {
     u32 sbdf_array[] = { id };
-    return add_one_user_rmrr(start, start+nr, 1, sbdf_array);
+
+    return add_one_user_rmrr(start, start + nr - 1, 1, sbdf_array);
 }
 
 static int __init add_extra_rmrr(void)