From: Catalin Marinas <catalin.marinas@arm.com>
To: Yang Shi <yang@os.amperecomputing.com>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Will Deacon <will@kernel.org>,
"David Hildenbrand (Arm)" <david@kernel.org>,
Dev Jain <dev.jain@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Jinjiang Tu <tujinjiang@huawei.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
Subject: Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
Date: Thu, 9 Apr 2026 19:33:34 +0100 [thread overview]
Message-ID: <adfw_hNDsIWwSAIv@arm.com> (raw)
In-Reply-To: <07054475-6b07-4b19-a393-cbe037adef8b@os.amperecomputing.com>
On Thu, Apr 09, 2026 at 09:48:58AM -0700, Yang Shi wrote:
> On 4/9/26 8:20 AM, Catalin Marinas wrote:
> > On Thu, Apr 09, 2026 at 11:53:41AM +0200, Kevin Brodsky wrote:
> > > What would make more sense to me is to enable the use of BBML2-noabort
> > > unconditionally if !force_pte_mapping(). We can then have
> > > can_set_direct_map() return true if we have BBML2-noabort, and we no
> > > longer need to check it in map_mem().
> >
> > Indeed.
>
> I'm trying to wrap up my head for this discussion. IIUC, if none of the
> features is enabled, it means we don't need do anything because the direct
> map is not changed. For example, if vmalloc doesn't change direct map
> permission when rodata != full, there is no need to call
> set_direct_map_*_noflush(). So unconditionally checking BBML2_NOABORT will
> change the behavior unnecessarily. Did I miss something?
>
> I think the only exception is secretmem if I don't miss something.
> Currently, secretmem is actually not supported if none of the features is
> enabled. But BBML2_NOABORT allows to lift the restriction.
Yes, it's secretmem only AFAICT. I think execmem will only change the
linear map if rodata_full anyway.
--
Catalin
next prev parent reply other threads:[~2026-04-09 18:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-30 16:17 [PATCH v2 0/3] Fix bugs for realm guest plus BBML2_NOABORT Ryan Roberts
2026-03-30 16:17 ` [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests Ryan Roberts
2026-03-31 14:35 ` Suzuki K Poulose
2026-04-02 20:43 ` Catalin Marinas
2026-04-03 10:31 ` Catalin Marinas
2026-04-07 8:43 ` Ryan Roberts
2026-04-07 9:32 ` Catalin Marinas
2026-04-07 10:13 ` Ryan Roberts
2026-04-07 10:52 ` Catalin Marinas
2026-04-07 13:06 ` Ryan Roberts
2026-04-07 17:37 ` Catalin Marinas
2026-04-09 9:53 ` Kevin Brodsky
2026-04-09 15:20 ` Catalin Marinas
2026-04-09 16:48 ` Yang Shi
2026-04-09 18:33 ` Catalin Marinas [this message]
2026-04-09 23:08 ` Yang Shi
2026-04-07 8:33 ` Ryan Roberts
2026-04-07 9:19 ` Catalin Marinas
2026-04-07 9:57 ` Suzuki K Poulose
2026-04-07 17:21 ` Catalin Marinas
2026-04-09 9:38 ` Suzuki K Poulose
2026-04-09 14:09 ` Catalin Marinas
2026-04-09 14:18 ` Suzuki K Poulose
2026-03-30 16:17 ` [PATCH v2 2/3] arm64: mm: Handle invalid large leaf mappings correctly Ryan Roberts
2026-03-30 16:17 ` [PATCH v2 3/3] arm64: mm: Remove pmd_sect() and pud_sect() Ryan Roberts
2026-04-02 21:11 ` [PATCH v2 0/3] Fix bugs for realm guest plus BBML2_NOABORT Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=adfw_hNDsIWwSAIv@arm.com \
--to=catalin.marinas@arm.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ryan.roberts@arm.com \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=tujinjiang@huawei.com \
--cc=will@kernel.org \
--cc=yang@os.amperecomputing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox