From nobody Fri Mar 14 08:46:09 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1738934031; cv=none; d=zohomail.com; s=zohoarc; b=KT5lVXb4YCtBUDNgaxHaWhsJZwQ08eoTh1aRlzgxFNSke5uECE+ZPG4Fsqg5U9h9TMCgjoiU7OG3KuTDe0LOV9U6Rb2Cvq8DM/aR4Dx/6gxDp2+xGTJAT/HEVJJR3oTXsvnhWz2L5hx9b7TO882WsNvh5D2Ivaqms+DWeqp+E2c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1738934031; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=S94d57Wmr71Llwx4AHp+ArbUnvlYxF3SDWP4jvX1jYI=; b=cfUAb4SzflPKQ9C0VjMUAZuu69R2KFjpxIrp2NhjWQIrvrBhmCgpX4N5txE4mQjROBqewpgdyWIpcpm2hkgFMVbv6yCNYgLSBN1h4jRSAUA4zWFnhOlA+G+/pH9/BehzEHcrHSuru9VzSxMS36L8ahS+1BLCFpdlOtQxQHu0rjI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1738934031842915.8429680299821; Fri, 7 Feb 2025 05:13:51 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.883670.1293618 (Exim 4.92) (envelope-from ) id 1tgOAj-0008Vd-Iq; Fri, 07 Feb 2025 13:13:29 +0000 Received: by outflank-mailman (output) from mailman id 883670.1293618; Fri, 07 Feb 2025 13:13:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tgOAj-0008Ul-CI; Fri, 07 Feb 2025 13:13:29 +0000 Received: by outflank-mailman (input) for mailman id 883670; Fri, 07 Feb 2025 13:13:29 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1tgOAi-0008Md-Um for xen-devel@lists.xenproject.org; Fri, 07 Feb 2025 13:13:28 +0000 Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [2a00:1450:4864:20::52c]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 51c13b04-e555-11ef-a073-877d107080fb; Fri, 07 Feb 2025 14:13:27 +0100 (CET) Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-5de38c3d2acso2371624a12.1 for ; Fri, 07 Feb 2025 05:13:27 -0800 (PST) Received: from fedora.. ([94.75.70.14]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ab794d96481sm19759666b.154.2025.02.07.05.13.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Feb 2025 05:13:25 -0800 (PST) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 51c13b04-e555-11ef-a073-877d107080fb DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1738934007; x=1739538807; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=S94d57Wmr71Llwx4AHp+ArbUnvlYxF3SDWP4jvX1jYI=; b=fGhWFoG/LIvP74jugOnCuvBoiZB4WdBIQetJxcsNEJmOhPAKI6NI0VaZ8TqxwJArWQ vJYrDgqDMU8zrn3d3ICyguN+aD1CMuZ5cY7pjcXL7QvAwz0V0PCXtGzdT9fkhDv4ckBv 9KIwBdXPNRQpARPMsumc0KkDcb1znyrRRKkHsCqcbHMd2LrtaESlztcDYiQTRf5YXHrF HNyexpYXNHU5IGZvzv8mDI9WhY0uA6ObXAl5S3GC8z7yP7wI/d5yq9+QiYbAxPLn0LD5 95BKrowmRTmzs4f/Jp9a8kUX4DKeBd3Kam7dAbCkJNGhGl1V55YjnqYU82hN0FpbX8mM /WiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738934007; x=1739538807; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=S94d57Wmr71Llwx4AHp+ArbUnvlYxF3SDWP4jvX1jYI=; b=nm646Fh2y2M3GosR7yojdleDTVu93sXpNXi0u5q+vql125Cm2d1/xcRKF+FR6NIZ5O xOR14wIMSAhXb4OvJgM7NKnZdAhlsJMBnY+P7hZm0O2aTxoFnuHEIpFHAw1QlzDp4uw1 Qs9laHusP8QODbSagWRnEQn1z+vxxvGB66Xi4YZukULbtbUPa8pbqNJMIvqoko3qGsEm eR8WkBtSnnqTg5/2wMKDl+LeAtE+vOWpWuYLCz/vwWQT+Hpd/njRrRpx/mzDTy+jslJc JYZK+Kkc1FD4K9KWqf1H2CoGVCNgYTepEKzc6KkZtOxfGxyaGjEWKXw9vEylZZAKalDW J1Ng== X-Gm-Message-State: AOJu0YygTZAt6GfEAHfw7+caolJCur3eFr6ygjE3WiZYo071F0wwxMBA ybgHyfbHCBjzVhqK4lLci0bZdH7/hR0uvlBB29ZF0Gu9RVk6m87lT5ZxaA== X-Gm-Gg: ASbGncvzHh/yjPg14XnAtO9o690RuZOIHZngIw+vMSYGmhFr44DT9flnXGoFi+3/HaL y95Herjt3JN9sYnwS5CdcKIJBy8XAmOGt4YQskGBVU+LoYhTOdeBZpujP0tEzF4Ue1XRKoQzsgp TvIXygNMUvDhWKAGnYy986czlobWzm6euEBdBQPNVbfJLfeleaC/Uqfuq6ZuSqqwItN1mInKHXY 8SFAWb4/gPdaAjMX+i2aM41dreN6ZEOquAvGkvpHfQ7ryFXp68S3WnzWt+J4vFlO4QygY0NxaFp KlYEhgmQVKDYCIYN X-Google-Smtp-Source: AGHT+IF/9T0x9u+t6xzP7RNuwJ++2PxWzEYX3tEAbyO7Z+EJ7scpuGgSrIh7Ku6gtmSXOZLeDAGqFA== X-Received: by 2002:a17:907:2d13:b0:ab7:5a5f:115 with SMTP id a640c23a62f3a-ab789c87e6amr349438066b.49.1738934006269; Fri, 07 Feb 2025 05:13:26 -0800 (PST) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Oleksii Kurochko , Alistair Francis , Bob Eshleman , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH for 4.20? v3 3/3] xen/riscv: update mfn calculation in pt_mapping_level() Date: Fri, 7 Feb 2025 14:13:20 +0100 Message-ID: <0290ae707cdd98d57714afb9bc4c3386683c1190.1738933678.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.48.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1738934033543019000 Content-Type: text/plain; charset="utf-8" When pt_update() is called with arguments (..., INVALID_MFN, ..., 0 or 1), it indicates that a mapping is being destroyed/modifyed. In the case when modifying or destroying a mapping, it is necessary to search until a leaf node is found, instead of searching for a page table entry based on the precalculated `level` and `order`(look at pt_update()). This is because when `mfn` =3D=3D INVALID_MFN, the `mask` (in pt_mapping_le= vel()) will take into account only `vfn`, which could accidentally return an incorrect level, leading to the discovery of an incorrect page table entry. For example, if `vfn` is page table level 1 aligned, but it was mapped as page table level 0, then pt_mapping_level() will return `level` =3D 1, since only `vfn` (which is page table level 1 aligned) is taken into account when `mfn` =3D=3D INVALID_MFN (look at pt_mapping_level()). Fixes: c2f1ded524 ("xen/riscv: page table handling") Signed-off-by: Oleksii Kurochko --- Changes in v3: - Drop ASSERT() for order as it isn't needed anymore. - Drop PTE_LEAF_SEARCH and use instead level=3DCONFIG_PAGING_LEVELS; refactor connected code correspondingly. - Calculate order once. - Drop initializer for local variable order. - Drop BUG_ON(!pte_is_mapping(*entry)) for the case when leaf searching happens as there is a similar check in pt_check_entry(). Look at pt.c:41 and pt.c:75. --- Changes in v2: - Introduce PTE_LEAF_SEARCH to tell page table update operation to walk down to wherever the leaf entry is. - Use introduced PTE_LEAF_SEARCH to not searching pte_t entry twice. - Update the commit message. --- xen/arch/riscv/pt.c | 90 +++++++++++++++++++++++++++++---------------- 1 file changed, 59 insertions(+), 31 deletions(-) diff --git a/xen/arch/riscv/pt.c b/xen/arch/riscv/pt.c index 66cb976b55..8c15a48f60 100644 --- a/xen/arch/riscv/pt.c +++ b/xen/arch/riscv/pt.c @@ -238,11 +238,10 @@ pte_t pt_walk(vaddr_t va, unsigned int *pte_level) =20 /* Update an entry at the level @target. */ static int pt_update_entry(mfn_t root, vaddr_t virt, - mfn_t mfn, unsigned int target, + mfn_t mfn, unsigned int *target, unsigned int flags) { int rc; - unsigned int level =3D HYP_PT_ROOT_LEVEL; pte_t *table; /* * The intermediate page table shouldn't be allocated when MFN isn't @@ -256,39 +255,45 @@ static int pt_update_entry(mfn_t root, vaddr_t virt, bool alloc_tbl =3D !mfn_eq(mfn, INVALID_MFN) || (flags & PTE_POPULATE); pte_t pte, *entry; =20 - /* convenience aliases */ - DECLARE_OFFSETS(offsets, virt); - - table =3D map_table(root); - for ( ; level > target; level-- ) + if ( *target =3D=3D CONFIG_PAGING_LEVELS ) + entry =3D _pt_walk(virt, target); + else { - rc =3D pt_next_level(alloc_tbl, &table, offsets[level]); - if ( rc =3D=3D XEN_TABLE_MAP_NOMEM ) + unsigned int level =3D HYP_PT_ROOT_LEVEL; + /* convenience aliases */ + DECLARE_OFFSETS(offsets, virt); + + table =3D map_table(root); + for ( ; level > *target; level-- ) { - rc =3D -ENOMEM; - goto out; + rc =3D pt_next_level(alloc_tbl, &table, offsets[level]); + if ( rc =3D=3D XEN_TABLE_MAP_NOMEM ) + { + rc =3D -ENOMEM; + goto out; + } + + if ( rc =3D=3D XEN_TABLE_MAP_NONE ) + { + rc =3D 0; + goto out; + } + + if ( rc !=3D XEN_TABLE_NORMAL ) + break; } =20 - if ( rc =3D=3D XEN_TABLE_MAP_NONE ) + if ( level !=3D *target ) { - rc =3D 0; + dprintk(XENLOG_ERR, + "%s: Shattering superpage is not supported\n", __func_= _); + rc =3D -EOPNOTSUPP; goto out; } =20 - if ( rc !=3D XEN_TABLE_NORMAL ) - break; - } - - if ( level !=3D target ) - { - dprintk(XENLOG_ERR, - "%s: Shattering superpage is not supported\n", __func__); - rc =3D -EOPNOTSUPP; - goto out; + entry =3D table + offsets[level]; } =20 - entry =3D table + offsets[level]; - rc =3D -EINVAL; if ( !pt_check_entry(*entry, mfn, flags) ) goto out; @@ -413,17 +418,40 @@ static int pt_update(vaddr_t virt, mfn_t mfn, =20 while ( left ) { - unsigned int order, level; - - level =3D pt_mapping_level(vfn, mfn, left, flags); - order =3D XEN_PT_LEVEL_ORDER(level); + unsigned int order, level =3D CONFIG_PAGING_LEVELS; =20 - ASSERT(left >=3D BIT(order, UL)); + /* + * In the case when modifying or destroying a mapping, it is neces= sary + * to search until a leaf node is found, instead of searching for + * a page table entry based on the precalculated `level` and `orde= r` + * (look at pt_update()). + * This is because when `mfn` =3D=3D INVALID_MFN, the `mask`(in + * pt_mapping_level()) will take into account only `vfn`, which co= uld + * accidentally return an incorrect level, leading to the discover= y of + * an incorrect page table entry. + * + * For example, if `vfn` is page table level 1 aligned, but it was + * mapped as page table level 0, then pt_mapping_level() will retu= rn + * `level` =3D 1, since only `vfn` (which is page table level 1 al= igned) + * is taken into account when `mfn` =3D=3D INVALID_MFN + * (look at pt_mapping_level()). + * + * To force searching until a leaf node is found is necessary to h= ave + * `level` =3D=3D CONFIG_PAGING_LEVELS which is a default value for + * `level`. + * + * For other cases (when a mapping is not being modified or destro= yed), + * pt_mapping_level() should be used. + */ + if ( !mfn_eq(mfn, INVALID_MFN) || (flags & PTE_POPULATE) ) + level =3D pt_mapping_level(vfn, mfn, left, flags); =20 - rc =3D pt_update_entry(root, vfn << PAGE_SHIFT, mfn, level, flags); + rc =3D pt_update_entry(root, vfn << PAGE_SHIFT, mfn, &level, flags= ); if ( rc ) break; =20 + order =3D XEN_PT_LEVEL_ORDER(level); + vfn +=3D 1UL << order; if ( !mfn_eq(mfn, INVALID_MFN) ) mfn =3D mfn_add(mfn, 1UL << order); --=20 2.48.1