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

Suzuki K Poulose <[email protected]>
Newsgroups dev.linux.lists.linux-coco,dev.linux.lists.kvmarm,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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.