Re: [PATCH v15 15/37] KVM: arm64: CCA: Handle RMI_EXIT_RIPAS_CHANGE

Suzuki K Poulose <[email protected]> Tue, 4 Aug 2026 14:19:22 +0100
Newsgroups dev.linux.lists.kvmarm,dev.linux.lists.linux-coco,org.infradead.lists.linux-arm-kernel,org.kernel.vger.kvm,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
Hi Fuad

Thanks for your feedback.

On 04/08/2026 13:20, Fuad Tabba wrote:
> Hi Suzuki,
> 
> + Quentin (who's on leave, but for when he gets back)
> 
> On Mon, 3 Aug 2026 at 16:30, Suzuki K Poulose <[email protected]> wrote:
> ...
>>> I.e don't hack into the API. Use the information you already have to
>>> decide whether you need to use the existing API at all.
>>>
>>> If that cannot be done for whatever reason, then you need to indirect
>>> the call with a set of operations that leave the existing code
>>> untouched.
>>
>> Please let us know if you think we need to explore this ^ ?
> 
> FWIW, pKVM already has this kind of indirection: in protected mode,
> the kvm_pgtable_stage2_* calls in mmu.c dispatch to the
> pkvm_pgtable_stage2_* wrappers through KVM_PGT_FN(), and the callers
> don't branch. It is global today because pKVM owns the whole host, but
> a per-VM version would let the CCA backend handle the filter and the
> IPA aliasing internally, keeping __unmap_stage2_range()'s signature
> intact. That should work for pKVM as well.

Sure, will explore this option. For the record, the patch here only 
passes down the "filter" parameter to __unmap_stage2_range() [ though
in a different name, only_shared ] and we still handle the aliasing 
inside the CCA code. Let me explore on this front.

Suzuki



> 
> Cheers,
> /fuad