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

[Suzuki K Poulose <suzuki.poulose@arm.com>]

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@git.gitlab.arm.com:linux-arm/kvmtool-cca.git cca/kvm-v18
>>
>> [0] Arm CCA KVM Support v16 : https://lore.kernel.org/ 
>> all/20260803134403.80630-1-steven.price@arm.com
>> [1] Linux firmware RMI https://lore.kernel.org/ 
>> all/20260912083611.2513845-1-suzuki.poulose@arm.com
>> [2] Linux GPF Host https://lore.kernel.org/ 
>> all/20260913070459.2547407-1-suzuki.poulose@arm.com
>> [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@redhat.com>

Thank you Gavin, much appreciated !

Cheers
Suzuki