Re: [PATCH v19 00/20] KVM: arm64: CCA: Add basic plumbing for Realms

[Suzuki K Poulose]

On 24/09/2026 11:40, Gavin Shan wrote:
> On 9/21/26 7:28 AM, Suzuki K Poulose wrote:
> > This series is a trimmed down version of the Arm CCA KVM support, 
> > previously
> > posted here [0]. Like in the v17, we have tried to split the entire 
> > series
> > into the following chunks.
> >
> >   1) Base RMM RMI support under drivers/firmware/arm_rmm -> [1]
> >   2) Linux Host support for handling GPFs - [2]
> >   3) NEW: Enlighten KVM arm64 about the different VM types and use call
> >      backs for the VM type, rather than spilling the is_this_type_of_vm()
> >      everywhere. Adds VCPU and Stage2 MMU related callbacks with support
> >      for the existing VM types. There are other places where we may be
> >      able to abstract, but those need careful performance evaluations
> >      to make sure they are fit (e.g., vcpu_run)
> >
> >     With that in place we generalise the predicate 
> > "kvm_vm_is_protected()"
> >     to cover all  "Confidential" VMs (which includes Protected VM and 
> > Realms),
> >     allowing us to handle common themes without having to do things 
> > like :
> >
> >       if (kvm_vm_is_protected() || kvm_vm_is_realm())
> >
> >     Also replaces the code with precise check for a given VM type to
> >     avoiding combination of if (). e.g,, kvm_vm_is_unprotected_pkvm(kvm).
> >     The checks under arch/arm64/kvm/{nvhe,pkvm} still retain the 
> > vm_is_protected()
> >     check as pVMs are the only possible protected VMs there.
> >   4) Bare minimal Realm VM support without the actual functionality to
> >      run a Realm. This would help the maintainers to review the series in
> >      smaller chunks. This doesn't depend on [1] and can be independently
> >      merged, without being "functional".
> >      This series includes vcpu operations and the s2 vm operations, which
> >      do need the RMI driver backend to be meaningful. But the KVM handler
> >      is in the right shape. The remaining changes would be added once the
> >      RMI firmware library lands. Also covers the SET_ONE_REG/GET_ONE_REG
> >
> >   5) Core implementation of the RMI driver for KVM and actual 
> > enablement of the
> >      Realm support. This depends on (1), (2) and the guest-memfd-in-place
> >      conversion series v12 from Ackerley. This is available here at 
> > the integration
> >      branch [3]
> >
> > This series is comprised of (3) and (4) above.
> >
> > The integration branch has been tested with the following components:
> >
> >    tf-RMM:   main branch (commit 5e6e2acd) compliant to RMM-v2.0-beta3 
> > [4]
> >    kvmtool: git@xxxxxxxxxxxxxxxxxx:linux-arm/kvmtool-cca.git cca/kvm-v18
> >
> > [0] Arm CCA KVM Support v16 : https://lore.kernel.org/ 
> > all/20260803134403.80630-1-steven.price@xxxxxxx
> > [1] Linux firmware RMI https://lore.kernel.org/ 
> > all/20260912083611.2513845-1-suzuki.poulose@xxxxxxx
> > [2] Linux GPF Host https://lore.kernel.org/ 
> > all/20260913070459.2547407-1-suzuki.poulose@xxxxxxx
> > [3] https://git.gitlab.arm.com/linux-arm/linux-cca/ cca/cca-host/kvm- 
> > v19/integration
> > [4] https://support.arm.com/documentation/den0137/2-0bet3/
>
> Apart from the issue found against PATCH[v19 05/20], I didn't see more 
> issues with this
> series in my tests where kselftest/kvm cases and kvm-unit-tests are done 
> on various
> combinations: 4KB host kernel, 64KB host kernel, kernel parameter "kvm- 
> arm.mode=
> {nvhe, protected}" or nil. So with the found issue caused by PATCH[v19 
> 05/20] fixed:
>
> Tested-by: Gavin Shan <gshan@xxxxxxxxxx>

Thank you Gavin, much appreciated !

Cheers
Suzuki