From nobody Thu Nov 5 07:33:59 2026 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=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1793353773; cv=none; d=zohomail.com; s=zohoarc; b=dMmpxx7kKAha0sJFA4p4T8Csdq+YvhjHgDfjMnhr1SbSYX1ln+HHeGYoc7u5JdzY2POnCWaMYa8VI81bkTGKK3euz5uol6YbQUsbZOWgSp4cHSFNz7LJ5hyVG4aX2UEAk+bhd2u1hgf6LzvGhJsIUC5rc4pWMVCbYuQCFcPv+iQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1793353773; h=Content-Type:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=4S4x9uJISY6OZNhEpNG6U0qgVxMfzMivSsrG54a80SI=; b=WGUcb76mrQEY39EfmVNVQLFBEzBEjwcNMVnfdbZA4NgBhs4pJCRrp+T00pnrqwjii6koJ2BeXQFqciFctHAs078giZn95d8bbWyjD1AYmnCw/XSKS1If0eDgHW2MXBj8nG2B4A/alXHjDIqWoj6YD0PAv+E/Rv5H0O4Me3eQcFM= 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 1793353773559674.8043778323207; Fri, 30 Oct 2026 02:49:33 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1465518.1676040 (Exim 4.92) (envelope-from ) id 1xMjEc-0005B7-UF; Fri, 30 Oct 2026 09:49:18 +0000 Received: by outflank-mailman (output) from mailman id 1465518.1676040; Fri, 30 Oct 2026 09:49:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMjEc-0005B0-Qn; Fri, 30 Oct 2026 09:49:18 +0000 Received: by outflank-mailman (input) for mailman id 1465518; Fri, 30 Oct 2026 09:49:17 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1xMjEb-0005Au-3S for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 09:49:17 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1xMjEa-008Q6p-Cy for xen-devel@lists.xenproject.org; Fri, 30 Oct 2026 10:49:16 +0100 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6ae46810-8faa-0a2a0a5109dd-0a2a4501ac8c-36 for ; Fri, 30 Oct 2026 10:49:16 +0100 Received: from [185.255.28.34] (helo=prod-mta-13-01.swg-srv.net) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6ae4681b-5984-0a2a45010019-b9ff1c229eb3-3 for ; Fri, 30 Oct 2026 10:49:16 +0100 Received: from mail2.vates.fr ([37.26.189.201] mail2.vates.fr) (Authenticated sender: 8631fc262581453bbf619ec5b2062170/smtp/7773de5a-2839-4720-82ee-e06722ae1d3e) by prod-mta-13-01.swg-srv.net (ZoneMTA - prod-mta-13) with ESMTPSA id 1a18c369323000cae1.006 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 30 Oct 2026 09:49:09 +0000 Received: from julian.home (82-67-211-29.subs.proxad.net [82.67.211.29]) (Authenticated sender: julian.vetter@vates.tech) by mail2.vates.fr (Postfix) with ESMTPSA id 49EF8820C8; Fri, 30 Oct 2026 10:49:08 +0100 (CET) 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" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References:Feedback-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; q=dns/txt; s=selector1; bh=4S4x9uJISY6OZNhEpNG6U0qgVxMfzMivSsrG54a80SI=; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to:references:feedback-id; b=SolBV1cBnULlCDxDdlry9WhCx9H06S8mj7czZbMZiZ+rOw4eCszx/+9xj7bcfPNL9BTqCszWl 1UtE2xXVYlSTN+SrEYCaCjBU9DMK+jOUym0+mK8mUbFZjxhlPuYoLUfxc7XVDz/q/Lon/6/sdl5 msG6KCyFpfqBT9QZFVn6ZRgPg2sPo0ihMtYH/kh4vsLrOQMR75MSZBtBW7R5uJnjfbkFyIjRL19 vBocoEymvr8pR0LBS25Jdm8/tpnnGBQMx0xim5ko7xt8ttoXVYpuXLt7oGwDr96IbUmbgbfTrH4 lySrGWYLchq2/6RaR3cjnP9XKtADUQKsGN2Pdgnj+R8Q== X-Zone-Loop: 0847c501746e4e27bae7bd4aac9d5516b3611dee3c0f x-campaign-type: default x-transaction-id: 5d8eba6a-ab2a-468b-ae01-4b8c103c7a0e x-swg-uid: 01-a981b766-31b1-406a-80c2-73e2c5810315 X-Mailer: Sweego Message-ID: <1793353749.8631fc262581453bbf619ec5b2062170.1a18c369323000cae1@vates.tech> x-swg-bid: 1793353749.8631fc262581453bbf619ec5b2062170.1a18c369323000cae1 Feedback-ID: default:8631fc262581453bbf619ec5b2062170:Sweego x-campaign-id: default x-client-id: 8631fc262581453bbf619ec5b2062170 X-Originating-IP: [37.26.189.201] From: Julian Vetter To: xen-devel@lists.xenproject.org Cc: Stefano Stabellini , Julien Grall , Bertrand Marquis , Michal Orzel , Volodymyr Babchuk , Andrew Cooper , Julian Vetter Subject: [PATCH v3 1/1] xen/arm: populate a default P2M pool for new domains Date: Fri, 30 Oct 2026 10:49:01 +0100 In-Reply-To: <1793353546.8631fc262581453bbf619ec5b2062170.1a18c337b6e000cae1@vates.tech> References: <1793353546.8631fc262581453bbf619ec5b2062170.1a18c337b6e000cae1@vates.tech> MIME-Version: 1.0 X-BM-Disclaimer: Yes Content-Type: multipart/alternative; boundary="-=Part.314.55c39cd100e6c943.1a18c3690dd.2facb68d8a81c68d=-" X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1793353748701 X-purgate-ID: tlsNG-d62444/1793353756-C5341757-8019050C/0/0 X-purgate-type: clean X-purgate-size: 3280 X-ZohoMail-DKIM: pass (identity @vates.tech) X-ZM-MESSAGEID: 1793353776192154100 ---=Part.314.55c39cd100e6c943.1a18c3690dd.2facb68d8a81c68d=- Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" On x86, a domain can be populated directly after the XEN_DOMCTL_createdomain call. Sizing the pool is thus an optional tuning step for the toolstack (libxl: "the Xen minimum is for safety, not performance"). On ARM however, the P2M pool of a non-hardware domain starts empty. So, any toolstack must size the pool before populating the domain's physmap, otherwise no P2M tables can be allocated. This is an ARM specific step, which every toolstack has to know about. Instead, populate a default pool of 256 pages (1MByte) in p2m_init(), matching what x86 HAP does in hap_enable(). The size is intentionally fixed, because p2m_init() isn't preemptible, so the allocation must stay bounded. Then dom0less and libxl set the full size, as they do today. Skip the hardware domain, which has no dedicated P2M pool. Also skip LLC colored setups, as the domain's colors are only configured after domain creation, so the pool pages would be allocated with the default colors. Signed-off-by: Julian Vetter --- Changes in v3: - Use a fixed default of 256 pages, as x86 HAP does - Drop the domain_p2m_default_kb() helper and the dom0less change - Adapt the commit message to explain why a fixed size is used Changes in v2: - Size the default pool based on the exisiting formula - Rewrite commit message to explain why a default pool is desirable --- xen/arch/arm/mmu/p2m.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/xen/arch/arm/mmu/p2m.c b/xen/arch/arm/mmu/p2m.c index 70d7c9fed9..9579e905d8 100644 --- a/xen/arch/arm/mmu/p2m.c +++ b/xen/arch/arm/mmu/p2m.c @@ -3,6 +3,7 @@ #include #include #include +#include #include #include =20 @@ -1555,6 +1556,26 @@ int p2m_init(struct domain *d) if ( rc ) return rc; =20 + /* + * Populate a default of 256 pages (1MB) to the P2M pages pool here, as + * x86 HAP does. So, the domain is usable without the pool being sized + * first. The toolstack, or dom0less, still sets the full size later, + * taking the domain's RAM into account. A fixed size keeps this + * non-preemptible allocation bounded, independent of the number of vC= PUs. + * + * Skip the hardware domain, which has no dedicated P2M pool, and LLC + * colored setups, as the domain's colors are only configured after do= main + * creation. + */ + if ( !is_hardware_domain(d) && !llc_coloring_enabled ) + { + spin_lock(&d->arch.paging.lock); + rc =3D p2m_set_allocation(d, 256, /* can_preempt */ false); + spin_unlock(&d->arch.paging.lock); + if ( rc ) + return rc; + } + return 0; } =20 --=20 2.53.0 --=20 Julian Vetter | Vates Hypervisor & Kernel Developer XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech ---=Part.314.55c39cd100e6c943.1a18c3690dd.2facb68d8a81c68d=---