[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] VT-d: fix off-by-one when handling extra RMRR ranges


  • To: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Fri, 13 Feb 2026 09:16:50 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=b1DxPtAxWmb7dtdCnvOLkEStofqosmDjEqaC8bau+nI=; b=VUPtGfdBOEFg7UctCgIC16Yy8NQTbs9X7Fur9/MHX0mL27eyObAUs+JU5vuWDkTSc8dHopkfdgvShr465M1V3IY3nwd3JH6nwWNaai4Q0l+vG8u1yjDaX911AzrnmIRReriO94f1buQj8wT1ERRSbrtWruBIZOfTJ5hD8IRvh76AL58mIlSQkYD6FRh5kD/8QFzeRSBbq+3JQIkCQFDFdmW74l6Eogb0pTg10ObSPnXOpseC9zw6McboIO3jQfpeKf253AG6XFEDa/ENqvYFe6Wgoiqu5oYBjjkDqF9gQ973tXsJD4o5MjCGPsVaVAKNCG8/qD9WLTyHceyg6hey9Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=sNpL/94X3zkDjxkly0ZhmOCJlA3qWBdv7QdBlAkWx0n1oSxoxfjrPj7G78Jn2u/G+uERAAQH+hGJ+4xsHil6dHfids05q3Zs0iD7hDzGrE2sUvK5SexmvJY7bGNiiJcLhzFwhRqlqjZe5cX/Igu2JklZ/RzguiiaUzHTfqa/nJ7wQ4aI8wDivXh7Khev/hAWFqsxi9yIkT0bXNYiyfXQDwPE2bH3NI2p7XqkHvEE/IMtZqOwArw57NsYCQuDc5wXASXqAcynjDoc40zAPm45BX5GWk2qKtamvykNl03nUCl9iOIILFkfFKtOZfj6s6ZbrFPLsUpn6vu/1iy5j1ZkHQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Delivery-date: Fri, 13 Feb 2026 08:17:08 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Fri, Feb 13, 2026 at 04:17:48AM +0100, Marek Marczykowski-Górecki wrote:
> 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
> 

You possibly want:

Fixes: 2d9b3699136d ("IOMMU/VT-d: wire common device reserved memory API")

> Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>

Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>

> ---
>  xen/drivers/passthrough/vtd/dmar.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/xen/drivers/passthrough/vtd/dmar.c 
> b/xen/drivers/passthrough/vtd/dmar.c
> index 91c22b833043..3da0854e6d91 100644
> --- a/xen/drivers/passthrough/vtd/dmar.c
> +++ b/xen/drivers/passthrough/vtd/dmar.c
> @@ -1065,7 +1065,7 @@ 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);

While here, would you mind if we add a newline between the sbdf_array
definition and the return?

Thanks, Roger.



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.