Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests

[Kevin Brodsky]

On 10/04/2026 01:08, Yang Shi wrote:
> On 4/9/26 11:33 AM, Catalin Marinas wrote:
>> 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.
>
> Yes, execmem calls set_memory_rox(), which won't change linear map
> permission if rodata_full is not enabled.

That is a good point, AFAICT set_direct_map_*_noflush() are only used by
execmem and secretmem. excmem only modifies the direct map if
rodata=full, so the proposed change would only be useful for secretmem.

The current situation with execmem is pretty strange: if rodata!=full,
but another feature is enabled (say kfence), then set_memory_rox() won't
touch the direct map but we will still use set_direct_map_*_noflush() to
reset it (directly or via VM_FLUSH_RESET_PERMS). Checking BBML2-noabort
in can_set_direct_map() would make these unnecessary calls more likely,
but it doesn't fundamentally change the situation.

It's also worth considering the series unmapping parts of the direct map
for guest_memfd [1], since it gates the use of
set_direct_map_*_noflush() on can_set_direct_map().

I think it makes complete sense to enable secretmem and the guest_memfd
use-case if BBML2-noabort is available, regardless of the other
features. The question is: are we worried about the overhead of
needlessly calling set_direct_map_*_noflush() for execmem mappings? If
so, it seems that the right solution is to introduce a new API to check
whether set_memory_ro() and friends actually modify the direct map or not.

- Kevin

[1] https://lore.kernel.org/lkml/20260317141031.514-1-kalyazin@xxxxxxxxxx/