[PATCH v2 12/30] KVM: arm64: Hoist MTE validation check out of MMU lock path

[Anshuman Khandual]

On 31/03/26 11:58 PM, Marc Zyngier wrote:
> On Tue, 31 Mar 2026 07:57:48 +0100,
> Anshuman Khandual <anshuman.khandual at arm.com> wrote:
>>
>> On 27/03/26 5:06 PM, Marc Zyngier wrote:
>>> From: Fuad Tabba <tabba at google.com>
>>>
>>> Simplify the non-cacheable attributes assignment by using a ternary
>>> operator. Additionally, hoist the MTE validation check (mte_allowed) out
>>> of kvm_s2_fault_map() and into kvm_s2_fault_compute_prot(). This allows
>>> us to fail faster and avoid acquiring the KVM MMU lock unnecessarily
>>> when the VMM introduces a disallowed VMA for an MTE-enabled guest.
>>>
>>> Signed-off-by: Fuad Tabba <tabba at google.com>
>>> Signed-off-by: Marc Zyngier <maz at kernel.org>
>>> ---
>>>  arch/arm64/kvm/mmu.c | 28 ++++++++++++----------------
>>>  1 file changed, 12 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
>>> index 0c71e3a9af8b0..ee2a548999b1b 100644
>>> --- a/arch/arm64/kvm/mmu.c
>>> +++ b/arch/arm64/kvm/mmu.c
>>> @@ -1870,18 +1870,21 @@ static int kvm_s2_fault_compute_prot(struct kvm_s2_fault *fault)
>>>  	if (fault->exec_fault)
>>>  		fault->prot |= KVM_PGTABLE_PROT_X;
>>>  
>>> -	if (fault->s2_force_noncacheable) {
>>> -		if (fault->vm_flags & VM_ALLOW_ANY_UNCACHED)
>>> -			fault->prot |= KVM_PGTABLE_PROT_NORMAL_NC;
>>> -		else
>>> -			fault->prot |= KVM_PGTABLE_PROT_DEVICE;
>>> -	} else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC)) {
>>> +	if (fault->s2_force_noncacheable)
>>> +		fault->prot |= (fault->vm_flags & VM_ALLOW_ANY_UNCACHED) ?
>>> +			       KVM_PGTABLE_PROT_NORMAL_NC : KVM_PGTABLE_PROT_DEVICE;
>>> +	else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
>>>  		fault->prot |= KVM_PGTABLE_PROT_X;
>>> -	}
>>
>> Is not the existing code block bit more cleaner though ?
> 
> What is wrong with this? Are you stating a matter of personal taste ?
> > Ternary operators are great at making things more readable by reducing
> the amount of nesting, and I'm all in favour of anything that makes
> this $%^&*( code easier to parse.
> 
> Or are you pointing out a technical issue?

There is no technical issue here. Just that the existing code block
appeared bit easier to read but as you mentioned earlier that is
probably subjective. Never mind and please feel free to ignore this
comment.