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