From nobody Thu Oct 30 16:42:14 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=1760975930; cv=none; d=zohomail.com; s=zohoarc; b=VFFVBiHP0xpGsvElAuGYaaDVzbO9nNlj/afHFQLyYFlXy0kDp7nVgV9rDItUZoqhAiEBfK62PZBxxwaEYZK8CTwaMFX0OQubz9S3t9E5NuHaXhNoLLNPyO0Hmv42AsWdCb2zueCb4km0FAEGCCovnDVEOOTYctL9kMNt67edXww= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1760975930; h=Content-Type: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=MkYFJ9zErQoksj5TICQm5GZ8ZBubAIBB0QgY0lfMcMo=; b=dBFh8+OblmQb05ArmlUd6tBoA6uDl7WFn5C9zN5Kt9GsNtmuxWMxndWUE3Mq8m/kdT21sW3N9TfxbTM6ksaH5UXzzaAZ4xTM8T3/OFNBPNkHaWuE6LPzSEaY1Zk1gcGWagw1w9s7JF7DFWzhEL3i5D25xhPq3eNoc5LDyeL1MP8= 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 17609759304351002.2243224118669; Mon, 20 Oct 2025 08:58:50 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1146550.1479073 (Exim 4.92) (envelope-from ) id 1vAsHG-0008E3-MT; Mon, 20 Oct 2025 15:58:30 +0000 Received: by outflank-mailman (output) from mailman id 1146550.1479073; Mon, 20 Oct 2025 15:58:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vAsHG-0008Ct-2d; Mon, 20 Oct 2025 15:58:30 +0000 Received: by outflank-mailman (input) for mailman id 1146550; Mon, 20 Oct 2025 15:58:27 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1vAsHD-0004nC-2w for xen-devel@lists.xenproject.org; Mon, 20 Oct 2025 15:58:27 +0000 Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [2a00:1450:4864:20::52a]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id 9c72f692-adcd-11f0-980a-7dc792cee155; Mon, 20 Oct 2025 17:58:25 +0200 (CEST) Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-63c4b41b38cso5340998a12.3 for ; Mon, 20 Oct 2025 08:58:25 -0700 (PDT) Received: from fedora (user-109-243-146-38.play-internet.pl. [109.243.146.38]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-63c48ab560esm6966067a12.12.2025.10.20.08.58.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Oct 2025 08:58:24 -0700 (PDT) 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: 9c72f692-adcd-11f0-980a-7dc792cee155 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760975905; x=1761580705; 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=MkYFJ9zErQoksj5TICQm5GZ8ZBubAIBB0QgY0lfMcMo=; b=H9HzZC8+xyIf4gfgzxzRprsCXUB4eUqxt7O7OwToMdxLjJ0RITApRnna5X6WRgR+Yr l2mkC70Qy9zF9F18UulnkC2SmMgZji+103dgS6aKY+sCyCA+7D8VVYugd71SuUq8wfnu b736G9AyVevKx/VebwoyUMaKNTekquAtC8z5yc4BmoKVQE6MmAVy9MyrtWCjJwWKu6cO 7LYOw7ThK22JgdYwr78bFvUiZYmgHurKLIzTs8rlXy0PdIHHueMaRviGWu4zbN9iI4Sj rXsImWfCfz7KYR4WqtRcMvtotoiz7HW29Iar0ZgAIGaKpIFSHa+B4Ujxzq3mVOJcwY0a Bbaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760975905; x=1761580705; 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=MkYFJ9zErQoksj5TICQm5GZ8ZBubAIBB0QgY0lfMcMo=; b=gd68dNMT/sCDJ0wH8bSyvYeaBloquxoWCh7ecvQZLdOFcn1ZuFZRf3yzyqF/3elPjz YlhIIdVDLJIsujPjhVAyswAmYyAwkhd921J0z7aA9VzzwoNTe0xB2kiFjmS7BRkid3Lf 9V6tjlqRMYroEwLhFZHVAH6vEKuMuMRgi7tlzU01DMXcIbuDXY7GNafxyRARqUVpKAfe 0xa91MwWFNmDaEe7D1XVpL1iyBmX7KkxUk+/jIwnC+4NsGKiddJYJ7yVWkgaFHJ6wpGv pbHulaGcnEDUnCXjmbZPaN1CY44diDSHXbZPPZkxYMcrKseVSiegdoDRDUej3JRJBTLV Ntcw== X-Gm-Message-State: AOJu0YxZK0nZ/vEmRywRhQYr7C3bt1u4sCEe2WBslOM7f8mrznG45bKh B0X4afxJu1InTiGJHqDh8S/FNZk0/lUCkdDyagvZAefieBbl8opFBGXWh41jxg== X-Gm-Gg: ASbGncu5ZcQmkpRJr59xEdyi17MioJl42yOsopFqi9mdIauEmV+9K0qpJOdeJTnXgHd JTZxLGD2wnWcXuNLBO9w6kuU8+Niio1fUUWHTBYpA7Q0dSf+hEnJAVHh5Tp9LZAwOwkYekLgdp9 2cumWW5q2pvhStefecpW0zWEpwD8mcj1b8WpddoDPLW6GEAYQW39+N6tu0f/pT5PSsih4YXBxMW uy6ehkK9NDVKE3p/9c9hN0JQbwJ1PyMOcBGutwVlcc4rxyZMLRUnpBRpy1Bwkwr35diVxY1hP1v 69BwUTgI4Zb4tDZ21vwI8t3kcb53ZzTUPS4sMjAWDX4G1vTDDb2IvFfkwsFAqfQ2KhVs+SVM3pl 1v+6DC1cy/TlzYOdNKdB4NKQYGjL/8MjOvyI+0uzoRNgmoiqWf9eiOA/pTx6EjFOE77F9YWp7F+ ITmDaaDQuCHAVAYJqi6dpgFEeWzDoxE/7wSpEkWCEcVZj1EZg= X-Google-Smtp-Source: AGHT+IE+N6aBidIuBuDN8zDsY4bu5srQfeHwXqQ1F4VgjSOhMruGnk2DKADIDBYqol9L5KY/HiVu6A== X-Received: by 2002:a05:6402:358a:b0:61c:9852:bb9f with SMTP id 4fb4d7f45d1cf-63c1f630745mr12406192a12.1.1760975904493; Mon, 20 Oct 2025 08:58:24 -0700 (PDT) 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: [for 4.22 v5 14/18] xen/riscv: Implement superpage splitting for p2m mappings Date: Mon, 20 Oct 2025 17:57:57 +0200 Message-ID: <5ee174bc9b0a5ad4de91d65116d7844ca2bcdceb.1760974017.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.51.0 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1760975931887158500 Add support for down large memory mappings ("superpages") in the RISC-V p2m mapping so that smaller, more precise mappings ("finer-grained entries") can be inserted into lower levels of the page table hierarchy. To implement that the following is done: - Introduce p2m_split_superpage(): Recursively shatters a superpage into smaller page table entries down to the target level, preserving original permissions and attributes. - p2m_set_entry() updated to invoke superpage splitting when inserting entries at lower levels within a superpage-mapped region. This implementation is based on the ARM code, with modifications to the part that follows the BBM (break-before-make) approach, some parts are simplified as according to RISC-V spec: It is permitted for multiple address-translation cache entries to co-exist for the same address. This represents the fact that in a conventional TLB hierarchy, it is possible for multiple entries to match a single address if, for example, a page is upgraded to a superpage without first clearing the original non-leaf PTE=E2=80=99s valid bit and executing an S= FENCE.VMA with rs1=3Dx0, or if multiple TLBs exist in parallel at a given level of = the hierarchy. In this case, just as if an SFENCE.VMA is not executed between a write to the memory-management tables and subsequent implicit read of t= he same address: it is unpredictable whether the old non-leaf PTE or the new leaf PTE is used, but the behavior is otherwise well defined. In contrast to the Arm architecture, where BBM is mandatory and failing to use it in some cases can lead to CPU instability, RISC-V guarantees stability, and the behavior remains safe =E2=80=94 though unpredictable in = terms of which translation will be used. Additionally, the page table walk logic has been adjusted, as ARM uses the opposite level numbering compared to RISC-V. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich --- Changes in V5: - Add Acked-by: Jan Beulich . - use next_level when p2m_split_superpage() is recursively called instead of using "level-1". --- Changes in V4: - s/number of levels/level numbering in the commit message. - s/permissions/attributes. - Remove redundant comment in p2m_split_superpage() about page splitting. - Use P2M_PAGETABLE_ENTRIES as XEN_PT_ENTRIES doesn't takeinto into acount that G stage root page table is extended by 2 bits. - Use earlier introduced P2M_LEVEL_ORDER(). --- Changes in V3: - Move page_list_add(page, &p2m->pages) inside p2m_alloc_page(). - Use 'unsigned long' for local vairiable 'i' in p2m_split_superpage(). - Update the comment above if ( next_level !=3D target ) in p2m_split_supe= rpage(). - Reverse cycle to iterate through page table levels in p2m_set_entry(). - Update p2m_split_superpage() with the same changes which are done in the patch "P2M: Don't try to free the existing PTE if we can't allocate a ne= w table". --- Changes in V2: - New patch. It was a part of a big patch "xen/riscv: implement p2m mapping functionality" which was splitted to smaller. - Update the commit above the cycle which creates new page table as RISC-V travserse page tables in an opposite to ARM order. - RISC-V doesn't require BBM so there is no needed for invalidating and TLB flushing before updating PTE. --- xen/arch/riscv/p2m.c | 116 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 114 insertions(+), 2 deletions(-) diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 6018cac336..383047580a 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -735,7 +735,88 @@ static void p2m_free_subtree(struct p2m_domain *p2m, p2m_free_page(p2m, pg); } =20 -/* Insert an entry in the p2m */ +static bool p2m_split_superpage(struct p2m_domain *p2m, pte_t *entry, + unsigned int level, unsigned int target, + const unsigned int *offsets) +{ + struct page_info *page; + unsigned long i; + pte_t pte, *table; + bool rv =3D true; + + /* Convenience aliases */ + mfn_t mfn =3D pte_get_mfn(*entry); + unsigned int next_level =3D level - 1; + unsigned int level_order =3D P2M_LEVEL_ORDER(next_level); + + /* + * This should only be called with target !=3D level and the entry is + * a superpage. + */ + ASSERT(level > target); + ASSERT(pte_is_superpage(*entry, level)); + + page =3D p2m_alloc_page(p2m); + if ( !page ) + { + /* + * The caller is in charge to free the sub-tree. + * As we didn't manage to allocate anything, just tell the + * caller there is nothing to free by invalidating the PTE. + */ + memset(entry, 0, sizeof(*entry)); + return false; + } + + table =3D __map_domain_page(page); + + for ( i =3D 0; i < P2M_PAGETABLE_ENTRIES(next_level); i++ ) + { + pte_t *new_entry =3D table + i; + + /* + * Use the content of the superpage entry and override + * the necessary fields. So the correct attributes are kept. + */ + pte =3D *entry; + pte_set_mfn(&pte, mfn_add(mfn, i << level_order)); + + write_pte(new_entry, pte); + } + + /* + * Shatter superpage in the page to the level we want to make the + * changes. + * This is done outside the loop to avoid checking the offset + * for every entry to know whether the entry should be shattered. + */ + if ( next_level !=3D target ) + rv =3D p2m_split_superpage(p2m, table + offsets[next_level], + next_level, target, offsets); + + if ( p2m->clean_dcache ) + clean_dcache_va_range(table, PAGE_SIZE); + + /* + * TODO: an inefficiency here: the caller almost certainly wants to map + * the same page again, to update the one entry that caused the + * request to shatter the page. + */ + unmap_domain_page(table); + + /* + * Even if we failed, we should (according to the current implemetation + * of a way how sub-tree is freed if p2m_split_superpage hasn't been + * finished fully) install the newly allocated PTE + * entry. + * The caller will be in charge to free the sub-tree. + */ + p2m_write_pte(entry, page_to_p2m_table(page), p2m->clean_dcache); + + return rv; +} + +/* Insert an entry in the p2m. */ static int p2m_set_entry(struct p2m_domain *p2m, gfn_t gfn, unsigned long page_order, @@ -800,7 +881,38 @@ static int p2m_set_entry(struct p2m_domain *p2m, */ if ( level > target ) { - panic("Shattering isn't implemented\n"); + /* We need to split the original page. */ + pte_t split_pte =3D *entry; + + ASSERT(pte_is_superpage(*entry, level)); + + if ( !p2m_split_superpage(p2m, &split_pte, level, target, offsets)= ) + { + /* Free the allocated sub-tree */ + p2m_free_subtree(p2m, split_pte, level); + + rc =3D -ENOMEM; + goto out; + } + + p2m_write_pte(entry, split_pte, p2m->clean_dcache); + + p2m->need_flush =3D true; + + /* Then move to the level we want to make real changes */ + for ( ; level > target; level-- ) + { + rc =3D p2m_next_level(p2m, true, level, &table, offsets[level]= ); + + /* + * The entry should be found and either be a table + * or a superpage if level 0 is not targeted + */ + ASSERT(rc =3D=3D P2M_TABLE_NORMAL || + (rc =3D=3D P2M_TABLE_SUPER_PAGE && target > 0)); + } + + entry =3D table + offsets[level]; } =20 /* --=20 2.51.0