From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C9841D35145 for ; Wed, 1 Apr 2026 13:19:56 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.1270274.1558985 (Exim 4.92) (envelope-from ) id 1w7vTv-0002sy-2a; Wed, 01 Apr 2026 13:19:39 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 1270274.1558985; Wed, 01 Apr 2026 13:19:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w7vTv-0002sr-00; Wed, 01 Apr 2026 13:19:39 +0000 Received: by outflank-mailman (input) for mailman id 1270274; Wed, 01 Apr 2026 13:19:37 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1w7vTt-0002sl-Ep for xen-devel@lists.xenproject.org; Wed, 01 Apr 2026 13:19:37 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1w7vTs-006ySa-Bz for xen-devel@lists.xenproject.org; Wed, 01 Apr 2026 15:19:36 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 69cd1b67-2eae-0a2a0a5409dd-0a2a4508e4f2-2 for ; Wed, 01 Apr 2026 15:19:36 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.56.0) (envelope-from ) id 69cd1b68-fab6-0a2a45080019-d1558031d4df-3 for ; Wed, 01 Apr 2026 15:19:36 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4852a9c6309so57933505e9.0 for ; Wed, 01 Apr 2026 06:19:36 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4887e80a6ebsm141695325e9.6.2026.04.01.06.19.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Apr 2026 06:19:35 -0700 (PDT) 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=google header.d=suse.com header.i="@suse.com" header.h="Content-Transfer-Encoding:In-Reply-To:Autocrypt:From:Content-Language:References:Cc:To:Subject:User-Agent:MIME-Version:Date:Message-ID" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1775049576; x=1775654376; darn=lists.xenproject.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=zLQfiXJzjyIanyKM/ntrl0B1r1SLW8jps6XddgVsxEI=; b=PCYOgn52AEh4fydVvyhLzFrgSreCJ/3oomqJ39Mz80/AQuqq/2wXltMVky2Pb3wFnc n0lZGkjHneb2tGylF/fG6uov4uUvvSv6zeusEATx2VTObthcGR7xWK345KsYqLFlZuAO L6fB0oacGCrprTYjOTnP1Xe4/ZcYiJsxg8Ib8Fa543HDWKGWyfRLGqekzNWMjT58olnM Ldx4qcvC5ADhPf2Cm2tVim3cED4LY6yHb9dvhW8vZh6FRROr6dVgXO+BU9XBUpSeR4jj hRwtCpxYXbuWxi4pn1rgp4J80dN3UKx3Xnzcr2h8MPJ103nxsASixO/c4+2vdYXwGecH /YKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775049576; x=1775654376; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zLQfiXJzjyIanyKM/ntrl0B1r1SLW8jps6XddgVsxEI=; b=frndD0fCFkXENvv5afEOL7kCK4v5DN6eFJAfv5sWi67Ty2bcWVF2/r1LJ54iFFhq09 bUwxmcLtkkOmNb4hNlAwLaDTn2SRM4agKUVFo7U69nU4MOmvOh8rWpdnQ+rQImb07gzV sYHdXwa1X9thw9zM3wfpP92fSG06bBsNZxgWaYEffs7v/63CB+UkA306iWMBp3oTUfPY xHJVkEID7zmzDI0smogpxaJP1GBvUgCTFrckw8nb2iW18YWhGGT9ndZX67vvhgNdckXk oP5ZG0gVYIeJsKw4aImkkEEq916yJ0MgduV0xVsXXyLouCjJzoy8XTNIw/XoAc+wECTG 9xqQ== X-Forwarded-Encrypted: i=1; AJvYcCXVeJJCOxAIt8amtb9Xj325sZcAmNoInWT0Ph0kzY6xlfNaRKwf8raaU0t6wLNsKT675cOpUHdqiH4=@lists.xenproject.org X-Gm-Message-State: AOJu0Yws5FpEGR84i14qsCuO1wiExVxKoDcJkr5/8HxOJgv6XHNY2EUD YYHuWMiMoxzzrKMxx+KX4/6os22/IHCJLoCLA6j5BqTc+xY8aCjIuCxpEJJzbVbFcA== X-Gm-Gg: ATEYQzxsfFCHAOhj9H1J3t7oT2Ht09kINIpdjAjR1rFNNt8U3JIs6hg6bFEFM0crMiK ieIBhZ3GPw3VnEl45sHhkftuyssPVoe9rn4oMvBUWnv1MQZIrMnEr/l74xIYy8gFgpmbNvMxXvN dry1jliWpWDxdVQ4sbRXEx50wAHH8+5JTpbrvDS4l8vZYopH4MyDqmailaTqvJRgB/XiLGfIXXy WERJOPGoYox845IUmKyrNuRpCYzVelgxxlMwLSiTYHBiWwuUA66q7BmlIgtncgjHfQfbIRbD9Mp n+RkiXo+Mo+SI7EbNbn/oKpDXQJyWgqAXj+Nl8BPg9sYo9N7Hb1yhtSPFByZsCR1Q5puyBbXQb9 Is9ynSmZTzHol/6Yx8jRjBoAFsZVWFYCD4YRj6diyorZzWci/BtCFQJFv7CkE0/WFeMqkS+7YCY PzfZFV0UTXRGz4lVPCobNlHuxcIFIAc9ioN6pDTr0DKd93DTdJcGzh8kJsh10JW+7V7XeGxEXex 1Fdb2Flqiw5O3A= X-Received: by 2002:a05:600c:c04a:b0:486:fbf6:abd4 with SMTP id 5b1f17b1804b1-488835636f1mr45223005e9.9.1775049575591; Wed, 01 Apr 2026 06:19:35 -0700 (PDT) Message-ID: Date: Wed, 1 Apr 2026 15:19:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 04/27] xen/riscv: rework G-stage mode handling To: Oleksii Kurochko Cc: Romain Caritey , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Julien Grall , =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Stefano Stabellini , xen-devel@lists.xenproject.org References: <2c8f1ea25b8d3ec78b00510fbe604a87e759e194.1773157782.git.oleksii.kurochko@gmail.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <2c8f1ea25b8d3ec78b00510fbe604a87e759e194.1773157782.git.oleksii.kurochko@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-purgate-ID: tlsNG-c1860d/1775049576-7674E497-6799F8DF/0/0 X-purgate-type: clean X-purgate-size: 3413 On 10.03.2026 18:08, Oleksii Kurochko wrote: > Rework G-stage mode handling to make the selected mode descriptor reusable > outside of p2m initialization. > > As max_gstage_mode is going to be reused by code that creates CPU nodes for > guest domains, not only max_gstage_mode->mode but also max_gstage_mode->name > is required. I guess I'm not DT-savvy enough to understand why that would be. > To support this, make max_gstage_mode a global pointer to one of > the entries in a global modes[] array, and remove get_max_supported_mode(). > > Update struct p2m_domain to store a pointer to a mode descriptor instead of > embedding the structure directly. > > Refactor the modes[] array so that mode->name contains only the MMU scheme > name (without the "x4" suffix), as this value is reused when filling the > maximum MMU type passed to the guest. According to DT bindings [1], the MMU > type must not include the "x4" suffix. Use "none" for the Bare mode to match > the DT binding requirements. I expect this DT aspect is also why Sv changes to sv in the table? (Which is a little unhelpful for the printk() where it's used.) > Adjust modes[]->paging_levels to represent the maximum paging level rather > than the total number of levels. This ensures that P2M_ROOT_LEVEL() and its > users behave correctly without relying on hardcoded p2m mode values. > > Finally, drop __initconst from the modes[] declaration, as the array is > referenced via p2m->mode and max_gstage_mode beyond the init stage. > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/riscv/cpus.yaml?h=v6.19-rc3#n82 Is a reference into Linux doc really providing something "canonical"? Surely there's an independent spec somewhere? > --- a/xen/arch/riscv/p2m.c > +++ b/xen/arch/riscv/p2m.c > @@ -45,18 +45,32 @@ struct p2m_pte_ctx { > unsigned int level; /* Paging level at which the PTE resides. */ > }; > > -static struct gstage_mode_desc __ro_after_init max_gstage_mode = { > - .mode = HGATP_MODE_OFF, > - .paging_levels = 0, > - .name = "Bare", > -}; > - > /* > * Set to the maximum configured support for IPA bits, so the number of IPA bits can be > * restricted by external entity (e.g. IOMMU). > */ > unsigned int __read_mostly p2m_ipa_bits = PADDR_BITS; > > +static const struct gstage_mode_desc modes[] = { As a function scope static this was a fine identifier. Please consider whether with the wider scope gstage_modes[] might not be better. > + /* > + * Based on the RISC-V spec: > + * Bare mode is always supported, regardless of SXLEN. > + * When SXLEN=32, the only other valid setting for MODE is Sv32. > + * When SXLEN=64, three paged virtual-memory schemes are defined: > + * Sv39, Sv48, and Sv57. > + */ > + [0] = { HGATP_MODE_OFF, 0, "none" }, > +#ifdef CONFIG_RISCV_32 > + [1] = { HGATP_MODE_SV32X4, 1, "sv32" } > +#else > + [2] = { HGATP_MODE_SV39X4, 2, "sv39" }, > + [3] = { HGATP_MODE_SV48X4, 3, "sv48" }, > + [4] = { HGATP_MODE_SV57X4, 4, "sv57" }, > +#endif > +}; The dedicated initializer form isn't adding any value here (whereas it slightly hampers readability). You really don't want the array to be sparsely populated, so perhaps better to leave as it was before? Jan