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

[Yang Shi <yang@os.amperecomputing.com>]

On 4/13/26 7:57 AM, Kevin Brodsky wrote:
> 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

Yes, agreed.

> 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.

I don't have data regarding the overhead. The set_direct_map_*_noflush() 
does walk the page table and they will be called for each page for the 
area. It sounds not cheap anyway. In addition, it may split direct map 
into smaller granules unnecessarily, it may result in unexpected direct 
map fragmentation when rodata != full.

So it seems like introducing a new API is worth it.

Thanks,
Yang


>
> - Kevin
>
> [1] https://lore.kernel.org/lkml/20260317141031.514-1-kalyazin@amazon.com/