Documentation/virt/kvm/api.rst | 86 +- arch/arm64/include/asm/kvm_emulate.h | 31 + arch/arm64/include/asm/kvm_host.h | 15 +- arch/arm64/include/asm/kvm_pgtable.h | 5 +- arch/arm64/include/asm/kvm_pkvm.h | 2 +- arch/arm64/include/asm/kvm_rmi.h | 129 ++ arch/arm64/include/asm/rmi_cmds.h | 692 +++++++++ arch/arm64/include/asm/rmi_smc.h | 430 ++++++ arch/arm64/include/asm/virt.h | 1 + arch/arm64/kernel/cpufeature.c | 1 + arch/arm64/kvm/Kconfig | 2 + arch/arm64/kvm/Makefile | 2 +- arch/arm64/kvm/arch_timer.c | 28 +- arch/arm64/kvm/arm.c | 178 ++- arch/arm64/kvm/guest.c | 95 +- arch/arm64/kvm/hyp/pgtable.c | 1 + arch/arm64/kvm/hypercalls.c | 4 +- arch/arm64/kvm/inject_fault.c | 5 +- arch/arm64/kvm/mmio.c | 16 +- arch/arm64/kvm/mmu.c | 214 ++- arch/arm64/kvm/pmu-emul.c | 6 + arch/arm64/kvm/psci.c | 30 + arch/arm64/kvm/reset.c | 13 +- arch/arm64/kvm/rmi-exit.c | 207 +++ arch/arm64/kvm/rmi.c | 1948 ++++++++++++++++++++++++++ arch/arm64/kvm/sys_regs.c | 53 +- arch/arm64/kvm/vgic/vgic-init.c | 2 +- arch/arm64/mm/fault.c | 28 +- include/kvm/arm_arch_timer.h | 2 + include/kvm/arm_pmu.h | 4 + include/kvm/arm_psci.h | 2 + include/uapi/linux/kvm.h | 41 +- 32 files changed, 4176 insertions(+), 97 deletions(-) create mode 100644 arch/arm64/include/asm/kvm_rmi.h create mode 100644 arch/arm64/include/asm/rmi_cmds.h create mode 100644 arch/arm64/include/asm/rmi_smc.h create mode 100644 arch/arm64/kvm/rmi-exit.c create mode 100644 arch/arm64/kvm/rmi.c
This series adds support for running protected VMs using KVM under the
Arm Confidential Compute Architecture (CCA).
New major version number! This now targets RMM v2.0-bet0[1]. And unlike
for Linux this represents a significant change.
RMM v2.0 brings with it the ability to configure the RMM to have the
same page size as the host (so no more RMM_PAGE_SIZE and dealing with
granules being different from host pages). It also introduces range
based APIs for many operations which should be more efficient and
simplifies the code in places.
The handling of the GIC has changed, so the system registers are used to
pass the GIC state rather than memory. This means fewer changes to the
KVM code as it looks much like a normal VM in this respect.
And of course the new uAPI introduced in the previous v12 posting is
retained so that also remains simplified compared to earlier postings.
The RMM support for v2.0 is still early and so this series includes a
few hacks to ease the integration. Of note are that there are some RMM
v1.0 SMCs added to paper over areas where the RMM implementation isn't
quite ready for v2.0, and "SROs" (see below) are deferred to the final
patch in the series.
The PMU in RMM v2.0 requires more handling on the RMM-side (and
therefore simplifies the implementation on Linux), but this isn't quite
ready yet. The Linux side is implemented (but untested).
PSCI still requires the VMM to provide the "target" REC for operations
that affect another vCPU. This is likely to change in a future version
of the specification. There's also a desire to force PSCI to be handled
in the VMM for realm guests - this isn't implemented yet as I'm waiting
for the dust to settle on the RMM interface first.
Stateful RMI Operations
-----------------------
The RMM v2.0 spec brings a new concept of Stateful RMI Operations (SROs)
which allow the RMM to complete an operation over several SMC calls and
requesting/returning memory to the host. This has the benefit of
allowing interrupts to be handled in the middle of an operation (by
returning to the host to handle the interrupt without completing the
operation) and enables the RMM to dynamically allocate memory for
internal tracking purposes. One example of this is RMI_REC_CREATE no
longer needs "auxiliary granules" provided upfront but can request the
memory needed during the RMI_REC_CREATE operation.
There are a fairly large number of operations that are defined as SROs
in the specification, but current both Linux and RMM only have support
for RMI_REC_CREATE and RMI_REC_DESTROY. There a number of TODOs/FIXMEs
in the code where support is missing.
Given the early stage support for this, the SRO handling is all confined
to the final patch. This patch can be dropped to return to a pre-SRO
state (albeit a mixture of RMM v1.0 and v2.0 APIs) for testing purposes.
A future posting will reorder the series to move the generic SRO support
to an early patch and will implement the proper support for this in all
RMI SMCs.
One aspect of SROs which is not yet well captured is that in some
circumstances the Linux kernel will need to call an SRO call in a
context where memory allocation is restricted (e.g. because a spinlock
is held). In this case the intention is that the SRO will be cancelled,
the spinlock dropped so the memory allocation can be completed, and then
the SRO restarted (obviously after rechecking the state that the
spinlock was protecting). For this reason the code stores the memory
allocations within a struct rmi_sro_state object - see the final patch
for more details.
This series is based on v7.0-rc1. It is also available as a git
repository:
https://gitlab.arm.com/linux-arm/linux-cca cca-host/v13
Work in progress changes for kvmtool are available from the git
repository below:
https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v11
Note that the kvmtool code has been tidied up (thanks to Suzuki) and
this involves a minor change in flags. The "--restricted_mem" flag is no
longer recognised (or necessary).
The TF-RMM has not yet merged the RMMv2.0 support, so you will need to
use the following branch:
https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc
[1] https://developer.arm.com/documentation/den0137/2-0bet0/
Jean-Philippe Brucker (7):
arm64: RMI: Propagate number of breakpoints and watchpoints to
userspace
arm64: RMI: Set breakpoint parameters through SET_ONE_REG
arm64: RMI: Initialize PMCR.N with number counter supported by RMM
arm64: RMI: Propagate max SVE vector length from RMM
arm64: RMI: Configure max SVE vector length for a Realm
arm64: RMI: Provide register list for unfinalized RMI RECs
arm64: RMI: Provide accurate register list
Joey Gouly (2):
arm64: RMI: allow userspace to inject aborts
arm64: RMI: support RSI_HOST_CALL
Steven Price (36):
kvm: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h
arm64: RME: Handle Granule Protection Faults (GPFs)
arm64: RMI: Add SMC definitions for calling the RMM
arm64: RMI: Temporarily add SMCs from RMM v1.0 spec
arm64: RMI: Add wrappers for RMI calls
arm64: RMI: Check for RMI support at KVM init
arm64: RMI: Configure the RMM with the host's page size
arm64: RMI: Check for LPA2 support
arm64: RMI: Ensure that the RMM has GPT entries for memory
arm64: RMI: Define the user ABI
arm64: RMI: Basic infrastructure for creating a realm.
KVM: arm64: Allow passing machine type in KVM creation
arm64: RMI: RTT tear down
arm64: RMI: Activate realm on first VCPU run
arm64: RMI: Allocate/free RECs to match vCPUs
arm64: RMI: Support for the VGIC in realms
KVM: arm64: Support timers in realm RECs
arm64: RMI: Handle realm enter/exit
arm64: RMI: Handle RMI_EXIT_RIPAS_CHANGE
KVM: arm64: Handle realm MMIO emulation
KVM: arm64: Expose support for private memory
arm64: RMI: Allow populating initial contents
arm64: RMI: Set RIPAS of initial memslots
arm64: RMI: Create the realm descriptor
arm64: RMI: Runtime faulting of memory
KVM: arm64: Handle realm VCPU load
KVM: arm64: Validate register access for a Realm VM
KVM: arm64: Handle Realm PSCI requests
KVM: arm64: WARN on injected undef exceptions
arm64: Don't expose stolen time for realm guests
arm64: RMI: Always use 4k pages for realms
arm64: RMI: Prevent Device mappings for Realms
arm64: RMI: Enable PMU support with a realm guest
KVM: arm64: Expose KVM_ARM_VCPU_REC to user space
arm64: RMI: Enable realms to be created
[WIP] arm64: RMI: Add support for SRO
Suzuki K Poulose (3):
kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h
kvm: arm64: Don't expose unsupported capabilities for realm guests
arm64: RMI: Allow checking SVE on VM instance
Documentation/virt/kvm/api.rst | 86 +-
arch/arm64/include/asm/kvm_emulate.h | 31 +
arch/arm64/include/asm/kvm_host.h | 15 +-
arch/arm64/include/asm/kvm_pgtable.h | 5 +-
arch/arm64/include/asm/kvm_pkvm.h | 2 +-
arch/arm64/include/asm/kvm_rmi.h | 129 ++
arch/arm64/include/asm/rmi_cmds.h | 692 +++++++++
arch/arm64/include/asm/rmi_smc.h | 430 ++++++
arch/arm64/include/asm/virt.h | 1 +
arch/arm64/kernel/cpufeature.c | 1 +
arch/arm64/kvm/Kconfig | 2 +
arch/arm64/kvm/Makefile | 2 +-
arch/arm64/kvm/arch_timer.c | 28 +-
arch/arm64/kvm/arm.c | 178 ++-
arch/arm64/kvm/guest.c | 95 +-
arch/arm64/kvm/hyp/pgtable.c | 1 +
arch/arm64/kvm/hypercalls.c | 4 +-
arch/arm64/kvm/inject_fault.c | 5 +-
arch/arm64/kvm/mmio.c | 16 +-
arch/arm64/kvm/mmu.c | 214 ++-
arch/arm64/kvm/pmu-emul.c | 6 +
arch/arm64/kvm/psci.c | 30 +
arch/arm64/kvm/reset.c | 13 +-
arch/arm64/kvm/rmi-exit.c | 207 +++
arch/arm64/kvm/rmi.c | 1948 ++++++++++++++++++++++++++
arch/arm64/kvm/sys_regs.c | 53 +-
arch/arm64/kvm/vgic/vgic-init.c | 2 +-
arch/arm64/mm/fault.c | 28 +-
include/kvm/arm_arch_timer.h | 2 +
include/kvm/arm_pmu.h | 4 +
include/kvm/arm_psci.h | 2 +
include/uapi/linux/kvm.h | 41 +-
32 files changed, 4176 insertions(+), 97 deletions(-)
create mode 100644 arch/arm64/include/asm/kvm_rmi.h
create mode 100644 arch/arm64/include/asm/rmi_cmds.h
create mode 100644 arch/arm64/include/asm/rmi_smc.h
create mode 100644 arch/arm64/kvm/rmi-exit.c
create mode 100644 arch/arm64/kvm/rmi.c
--
2.43.0
Hi Steven, On 3/19/26 1:53 AM, Steven Price wrote: > > This series is based on v7.0-rc1. It is also available as a git > repository: > > https://gitlab.arm.com/linux-arm/linux-cca cca-host/v13 > > Work in progress changes for kvmtool are available from the git > repository below: > > https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v11 > Could you please share if we have a working qemu repository on top of this (v13) series? The previous qemu repository [1] seems out of dated for long time. I heard Jean won't be able to continue his efforts on QEMU part, who is going to pick it up in this case. [1] https://git.codelinaro.org/linaro/dcap/qemu.git (branch: cca/latest) > Note that the kvmtool code has been tidied up (thanks to Suzuki) and > this involves a minor change in flags. The "--restricted_mem" flag is no > longer recognised (or necessary). > > The TF-RMM has not yet merged the RMMv2.0 support, so you will need to > use the following branch: > > https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc > I'm seeing error to initialize RMM with the suggested RMM branch (topics/rmm-v2.0-poc) and the upstream TF-A [1]. It seems the problem is compatible issue in the RMM-EL3 interface. RMM requires verion 2.0 while TF-A only supports 0.8. So I guess I must be using a wrong TF-A repository. Could you please share which TF-A repository you use for testing? [1] git@github.com:ARM-software/arm-trusted-firmware.git (branch: master) Booting logs ============= NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.14.0(debug):67edb4f8e NOTICE: BL1: Built : 00:01:39, Mar 25 2026 INFO: BL1: RAM 0xe0ee000 - 0xe0f7000 INFO: BL1: Loading BL2 INFO: Loading image id=1 at address 0xe05b000 INFO: Image id=1 loaded: 0xe05b000 - 0xe0642bc NOTICE: BL1: Booting BL2 INFO: Entry point address = 0xe05b000 INFO: SPSR = 0x3cd NOTICE: BL2: v2.14.0(debug):67edb4f8e NOTICE: BL2: Built : 00:01:39, Mar 25 2026 INFO: BL2: Doing platform setup INFO: Reserved RMM memory [0x40100000, 0x418fffff] in Device tree INFO: BL2: Loading image id 3 INFO: Loading image id=3 at address 0xe090000 INFO: Image id=3 loaded: 0xe090000 - 0xe0a292b INFO: BL2: Loading image id 35 INFO: Loading image id=35 at address 0x40100000 INFO: Image id=35 loaded: 0x40100000 - 0x401a11e0 INFO: BL2: Loading image id 5 INFO: Loading image id=5 at address 0x60000000 INFO: Image id=5 loaded: 0x60000000 - 0x60200000 NOTICE: BL2: Booting BL31 INFO: Entry point address = 0xe090000 INFO: SPSR = 0x3cd INFO: GPT: Boot Configuration INFO: PPS/T: 0x2/40 INFO: PGS/P: 0x0/12 INFO: L0GPTSZ/S: 0x0/30 INFO: PAS count: 6 INFO: L0 base: 0xedfe000 INFO: Enabling Granule Protection Checks NOTICE: BL31: v2.14.0(debug):67edb4f8e NOTICE: BL31: Built : 00:01:39, Mar 25 2026 INFO: GICv3 without legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: Maximum SPI INTID supported: 287 INFO: BL31: Initializing runtime services INFO: RMM setup done. INFO: BL31: Initializing RMM INFO: RMM init start. ERROR: RMM init failed: -2 <<<< Error raised by RMM here WARNING: BL31: RMM initialization failed INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x60000000 INFO: SPSR = 0x3c9 UEFI firmware (version built at 19:33:51 on Mar 3 2026) Thanks, Gavin
Hi Gavin On 25/03/2026 04:07, Gavin Shan wrote: > Hi Steven, > > On 3/19/26 1:53 AM, Steven Price wrote: >> >> This series is based on v7.0-rc1. It is also available as a git >> repository: >> >> https://gitlab.arm.com/linux-arm/linux-cca cca-host/v13 >> >> Work in progress changes for kvmtool are available from the git >> repository below: >> >> https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v11 >> > > Could you please share if we have a working qemu repository on top of this > (v13) series? The previous qemu repository [1] seems out of dated for long > time. I heard Jean won't be able to continue his efforts on QEMU part, who > is going to pick it up in this case. > > [1] https://git.codelinaro.org/linaro/dcap/qemu.git (branch: cca/latest) Unfortunately not at the moment. We have moved on to a simpler UABI, which drops most of the previous configuration steps. > >> Note that the kvmtool code has been tidied up (thanks to Suzuki) and >> this involves a minor change in flags. The "--restricted_mem" flag is no >> longer recognised (or necessary). >> >> The TF-RMM has not yet merged the RMMv2.0 support, so you will need to >> use the following branch: >> >> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc >> > > I'm seeing error to initialize RMM with the suggested RMM branch > (topics/rmm-v2.0-poc) > and the upstream TF-A [1]. It seems the problem is compatible issue in the > RMM-EL3 interface. RMM requires verion 2.0 while TF-A only supports 0.8. So > I guess I must be using a wrong TF-A repository. Could you please share > which > TF-A repository you use for testing? See the other thread with Mathieu. Kind regards Suzuki
Good day, On Wed, Mar 18, 2026 at 03:53:24PM +0000, Steven Price wrote: > This series adds support for running protected VMs using KVM under the > Arm Confidential Compute Architecture (CCA). > > New major version number! This now targets RMM v2.0-bet0[1]. And unlike > for Linux this represents a significant change. > > RMM v2.0 brings with it the ability to configure the RMM to have the > same page size as the host (so no more RMM_PAGE_SIZE and dealing with > granules being different from host pages). It also introduces range > based APIs for many operations which should be more efficient and > simplifies the code in places. > > The handling of the GIC has changed, so the system registers are used to > pass the GIC state rather than memory. This means fewer changes to the > KVM code as it looks much like a normal VM in this respect. > > And of course the new uAPI introduced in the previous v12 posting is > retained so that also remains simplified compared to earlier postings. > > The RMM support for v2.0 is still early and so this series includes a > few hacks to ease the integration. Of note are that there are some RMM > v1.0 SMCs added to paper over areas where the RMM implementation isn't > quite ready for v2.0, and "SROs" (see below) are deferred to the final > patch in the series. > > The PMU in RMM v2.0 requires more handling on the RMM-side (and > therefore simplifies the implementation on Linux), but this isn't quite > ready yet. The Linux side is implemented (but untested). > > PSCI still requires the VMM to provide the "target" REC for operations > that affect another vCPU. This is likely to change in a future version > of the specification. There's also a desire to force PSCI to be handled > in the VMM for realm guests - this isn't implemented yet as I'm waiting > for the dust to settle on the RMM interface first. > > Stateful RMI Operations > ----------------------- > > The RMM v2.0 spec brings a new concept of Stateful RMI Operations (SROs) > which allow the RMM to complete an operation over several SMC calls and > requesting/returning memory to the host. This has the benefit of > allowing interrupts to be handled in the middle of an operation (by > returning to the host to handle the interrupt without completing the > operation) and enables the RMM to dynamically allocate memory for > internal tracking purposes. One example of this is RMI_REC_CREATE no > longer needs "auxiliary granules" provided upfront but can request the > memory needed during the RMI_REC_CREATE operation. > > There are a fairly large number of operations that are defined as SROs > in the specification, but current both Linux and RMM only have support > for RMI_REC_CREATE and RMI_REC_DESTROY. There a number of TODOs/FIXMEs > in the code where support is missing. > > Given the early stage support for this, the SRO handling is all confined > to the final patch. This patch can be dropped to return to a pre-SRO > state (albeit a mixture of RMM v1.0 and v2.0 APIs) for testing purposes. > > A future posting will reorder the series to move the generic SRO support > to an early patch and will implement the proper support for this in all > RMI SMCs. > > One aspect of SROs which is not yet well captured is that in some > circumstances the Linux kernel will need to call an SRO call in a > context where memory allocation is restricted (e.g. because a spinlock > is held). In this case the intention is that the SRO will be cancelled, > the spinlock dropped so the memory allocation can be completed, and then > the SRO restarted (obviously after rechecking the state that the > spinlock was protecting). For this reason the code stores the memory > allocations within a struct rmi_sro_state object - see the final patch > for more details. > > This series is based on v7.0-rc1. It is also available as a git > repository: > > https://gitlab.arm.com/linux-arm/linux-cca cca-host/v13 > > Work in progress changes for kvmtool are available from the git > repository below: > > https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v11 > > Note that the kvmtool code has been tidied up (thanks to Suzuki) and > this involves a minor change in flags. The "--restricted_mem" flag is no > longer recognised (or necessary). > > The TF-RMM has not yet merged the RMMv2.0 support, so you will need to > use the following branch: > > https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc This RMM version is expecting a RMM EL3 interface version of at least 2.0. Do you have a TF-A to use with it? Thanks, Mathieu > > [1] https://developer.arm.com/documentation/den0137/2-0bet0/ > > Jean-Philippe Brucker (7): > arm64: RMI: Propagate number of breakpoints and watchpoints to > userspace > arm64: RMI: Set breakpoint parameters through SET_ONE_REG > arm64: RMI: Initialize PMCR.N with number counter supported by RMM > arm64: RMI: Propagate max SVE vector length from RMM > arm64: RMI: Configure max SVE vector length for a Realm > arm64: RMI: Provide register list for unfinalized RMI RECs > arm64: RMI: Provide accurate register list > > Joey Gouly (2): > arm64: RMI: allow userspace to inject aborts > arm64: RMI: support RSI_HOST_CALL > > Steven Price (36): > kvm: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h > arm64: RME: Handle Granule Protection Faults (GPFs) > arm64: RMI: Add SMC definitions for calling the RMM > arm64: RMI: Temporarily add SMCs from RMM v1.0 spec > arm64: RMI: Add wrappers for RMI calls > arm64: RMI: Check for RMI support at KVM init > arm64: RMI: Configure the RMM with the host's page size > arm64: RMI: Check for LPA2 support > arm64: RMI: Ensure that the RMM has GPT entries for memory > arm64: RMI: Define the user ABI > arm64: RMI: Basic infrastructure for creating a realm. > KVM: arm64: Allow passing machine type in KVM creation > arm64: RMI: RTT tear down > arm64: RMI: Activate realm on first VCPU run > arm64: RMI: Allocate/free RECs to match vCPUs > arm64: RMI: Support for the VGIC in realms > KVM: arm64: Support timers in realm RECs > arm64: RMI: Handle realm enter/exit > arm64: RMI: Handle RMI_EXIT_RIPAS_CHANGE > KVM: arm64: Handle realm MMIO emulation > KVM: arm64: Expose support for private memory > arm64: RMI: Allow populating initial contents > arm64: RMI: Set RIPAS of initial memslots > arm64: RMI: Create the realm descriptor > arm64: RMI: Runtime faulting of memory > KVM: arm64: Handle realm VCPU load > KVM: arm64: Validate register access for a Realm VM > KVM: arm64: Handle Realm PSCI requests > KVM: arm64: WARN on injected undef exceptions > arm64: Don't expose stolen time for realm guests > arm64: RMI: Always use 4k pages for realms > arm64: RMI: Prevent Device mappings for Realms > arm64: RMI: Enable PMU support with a realm guest > KVM: arm64: Expose KVM_ARM_VCPU_REC to user space > arm64: RMI: Enable realms to be created > [WIP] arm64: RMI: Add support for SRO > > Suzuki K Poulose (3): > kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h > kvm: arm64: Don't expose unsupported capabilities for realm guests > arm64: RMI: Allow checking SVE on VM instance > > Documentation/virt/kvm/api.rst | 86 +- > arch/arm64/include/asm/kvm_emulate.h | 31 + > arch/arm64/include/asm/kvm_host.h | 15 +- > arch/arm64/include/asm/kvm_pgtable.h | 5 +- > arch/arm64/include/asm/kvm_pkvm.h | 2 +- > arch/arm64/include/asm/kvm_rmi.h | 129 ++ > arch/arm64/include/asm/rmi_cmds.h | 692 +++++++++ > arch/arm64/include/asm/rmi_smc.h | 430 ++++++ > arch/arm64/include/asm/virt.h | 1 + > arch/arm64/kernel/cpufeature.c | 1 + > arch/arm64/kvm/Kconfig | 2 + > arch/arm64/kvm/Makefile | 2 +- > arch/arm64/kvm/arch_timer.c | 28 +- > arch/arm64/kvm/arm.c | 178 ++- > arch/arm64/kvm/guest.c | 95 +- > arch/arm64/kvm/hyp/pgtable.c | 1 + > arch/arm64/kvm/hypercalls.c | 4 +- > arch/arm64/kvm/inject_fault.c | 5 +- > arch/arm64/kvm/mmio.c | 16 +- > arch/arm64/kvm/mmu.c | 214 ++- > arch/arm64/kvm/pmu-emul.c | 6 + > arch/arm64/kvm/psci.c | 30 + > arch/arm64/kvm/reset.c | 13 +- > arch/arm64/kvm/rmi-exit.c | 207 +++ > arch/arm64/kvm/rmi.c | 1948 ++++++++++++++++++++++++++ > arch/arm64/kvm/sys_regs.c | 53 +- > arch/arm64/kvm/vgic/vgic-init.c | 2 +- > arch/arm64/mm/fault.c | 28 +- > include/kvm/arm_arch_timer.h | 2 + > include/kvm/arm_pmu.h | 4 + > include/kvm/arm_psci.h | 2 + > include/uapi/linux/kvm.h | 41 +- > 32 files changed, 4176 insertions(+), 97 deletions(-) > create mode 100644 arch/arm64/include/asm/kvm_rmi.h > create mode 100644 arch/arm64/include/asm/rmi_cmds.h > create mode 100644 arch/arm64/include/asm/rmi_smc.h > create mode 100644 arch/arm64/kvm/rmi-exit.c > create mode 100644 arch/arm64/kvm/rmi.c > > -- > 2.43.0 > >
On 19/03/2026 23:02, Mathieu Poirier wrote: > Good day, > > On Wed, Mar 18, 2026 at 03:53:24PM +0000, Steven Price wrote: >> This series adds support for running protected VMs using KVM under the >> Arm Confidential Compute Architecture (CCA). >> >> New major version number! This now targets RMM v2.0-bet0[1]. And unlike >> for Linux this represents a significant change. >> >> RMM v2.0 brings with it the ability to configure the RMM to have the >> same page size as the host (so no more RMM_PAGE_SIZE and dealing with >> granules being different from host pages). It also introduces range >> based APIs for many operations which should be more efficient and >> simplifies the code in places. >> >> The handling of the GIC has changed, so the system registers are used to >> pass the GIC state rather than memory. This means fewer changes to the >> KVM code as it looks much like a normal VM in this respect. >> >> And of course the new uAPI introduced in the previous v12 posting is >> retained so that also remains simplified compared to earlier postings. >> >> The RMM support for v2.0 is still early and so this series includes a >> few hacks to ease the integration. Of note are that there are some RMM >> v1.0 SMCs added to paper over areas where the RMM implementation isn't >> quite ready for v2.0, and "SROs" (see below) are deferred to the final >> patch in the series. >> >> The PMU in RMM v2.0 requires more handling on the RMM-side (and >> therefore simplifies the implementation on Linux), but this isn't quite >> ready yet. The Linux side is implemented (but untested). >> >> PSCI still requires the VMM to provide the "target" REC for operations >> that affect another vCPU. This is likely to change in a future version >> of the specification. There's also a desire to force PSCI to be handled >> in the VMM for realm guests - this isn't implemented yet as I'm waiting >> for the dust to settle on the RMM interface first. >> >> Stateful RMI Operations >> ----------------------- >> >> The RMM v2.0 spec brings a new concept of Stateful RMI Operations (SROs) >> which allow the RMM to complete an operation over several SMC calls and >> requesting/returning memory to the host. This has the benefit of >> allowing interrupts to be handled in the middle of an operation (by >> returning to the host to handle the interrupt without completing the >> operation) and enables the RMM to dynamically allocate memory for >> internal tracking purposes. One example of this is RMI_REC_CREATE no >> longer needs "auxiliary granules" provided upfront but can request the >> memory needed during the RMI_REC_CREATE operation. >> >> There are a fairly large number of operations that are defined as SROs >> in the specification, but current both Linux and RMM only have support >> for RMI_REC_CREATE and RMI_REC_DESTROY. There a number of TODOs/FIXMEs >> in the code where support is missing. >> >> Given the early stage support for this, the SRO handling is all confined >> to the final patch. This patch can be dropped to return to a pre-SRO >> state (albeit a mixture of RMM v1.0 and v2.0 APIs) for testing purposes. >> >> A future posting will reorder the series to move the generic SRO support >> to an early patch and will implement the proper support for this in all >> RMI SMCs. >> >> One aspect of SROs which is not yet well captured is that in some >> circumstances the Linux kernel will need to call an SRO call in a >> context where memory allocation is restricted (e.g. because a spinlock >> is held). In this case the intention is that the SRO will be cancelled, >> the spinlock dropped so the memory allocation can be completed, and then >> the SRO restarted (obviously after rechecking the state that the >> spinlock was protecting). For this reason the code stores the memory >> allocations within a struct rmi_sro_state object - see the final patch >> for more details. >> >> This series is based on v7.0-rc1. It is also available as a git >> repository: >> >> https://gitlab.arm.com/linux-arm/linux-cca cca-host/v13 >> >> Work in progress changes for kvmtool are available from the git >> repository below: >> >> https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v11 >> >> Note that the kvmtool code has been tidied up (thanks to Suzuki) and >> this involves a minor change in flags. The "--restricted_mem" flag is no >> longer recognised (or necessary). >> >> The TF-RMM has not yet merged the RMMv2.0 support, so you will need to >> use the following branch: >> >> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc > > This RMM version is expecting a RMM EL3 interface version of at least 2.0. Do > you have a TF-A to use with it? You should be able to use the 'master' branch of the TF-A repository. For now you need to set RMM_V1_COMPAT=0 to enable 2.0 support. Thanks, Steve > Thanks, > Mathieu > >> >> [1] https://developer.arm.com/documentation/den0137/2-0bet0/ >> >> Jean-Philippe Brucker (7): >> arm64: RMI: Propagate number of breakpoints and watchpoints to >> userspace >> arm64: RMI: Set breakpoint parameters through SET_ONE_REG >> arm64: RMI: Initialize PMCR.N with number counter supported by RMM >> arm64: RMI: Propagate max SVE vector length from RMM >> arm64: RMI: Configure max SVE vector length for a Realm >> arm64: RMI: Provide register list for unfinalized RMI RECs >> arm64: RMI: Provide accurate register list >> >> Joey Gouly (2): >> arm64: RMI: allow userspace to inject aborts >> arm64: RMI: support RSI_HOST_CALL >> >> Steven Price (36): >> kvm: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h >> arm64: RME: Handle Granule Protection Faults (GPFs) >> arm64: RMI: Add SMC definitions for calling the RMM >> arm64: RMI: Temporarily add SMCs from RMM v1.0 spec >> arm64: RMI: Add wrappers for RMI calls >> arm64: RMI: Check for RMI support at KVM init >> arm64: RMI: Configure the RMM with the host's page size >> arm64: RMI: Check for LPA2 support >> arm64: RMI: Ensure that the RMM has GPT entries for memory >> arm64: RMI: Define the user ABI >> arm64: RMI: Basic infrastructure for creating a realm. >> KVM: arm64: Allow passing machine type in KVM creation >> arm64: RMI: RTT tear down >> arm64: RMI: Activate realm on first VCPU run >> arm64: RMI: Allocate/free RECs to match vCPUs >> arm64: RMI: Support for the VGIC in realms >> KVM: arm64: Support timers in realm RECs >> arm64: RMI: Handle realm enter/exit >> arm64: RMI: Handle RMI_EXIT_RIPAS_CHANGE >> KVM: arm64: Handle realm MMIO emulation >> KVM: arm64: Expose support for private memory >> arm64: RMI: Allow populating initial contents >> arm64: RMI: Set RIPAS of initial memslots >> arm64: RMI: Create the realm descriptor >> arm64: RMI: Runtime faulting of memory >> KVM: arm64: Handle realm VCPU load >> KVM: arm64: Validate register access for a Realm VM >> KVM: arm64: Handle Realm PSCI requests >> KVM: arm64: WARN on injected undef exceptions >> arm64: Don't expose stolen time for realm guests >> arm64: RMI: Always use 4k pages for realms >> arm64: RMI: Prevent Device mappings for Realms >> arm64: RMI: Enable PMU support with a realm guest >> KVM: arm64: Expose KVM_ARM_VCPU_REC to user space >> arm64: RMI: Enable realms to be created >> [WIP] arm64: RMI: Add support for SRO >> >> Suzuki K Poulose (3): >> kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h >> kvm: arm64: Don't expose unsupported capabilities for realm guests >> arm64: RMI: Allow checking SVE on VM instance >> >> Documentation/virt/kvm/api.rst | 86 +- >> arch/arm64/include/asm/kvm_emulate.h | 31 + >> arch/arm64/include/asm/kvm_host.h | 15 +- >> arch/arm64/include/asm/kvm_pgtable.h | 5 +- >> arch/arm64/include/asm/kvm_pkvm.h | 2 +- >> arch/arm64/include/asm/kvm_rmi.h | 129 ++ >> arch/arm64/include/asm/rmi_cmds.h | 692 +++++++++ >> arch/arm64/include/asm/rmi_smc.h | 430 ++++++ >> arch/arm64/include/asm/virt.h | 1 + >> arch/arm64/kernel/cpufeature.c | 1 + >> arch/arm64/kvm/Kconfig | 2 + >> arch/arm64/kvm/Makefile | 2 +- >> arch/arm64/kvm/arch_timer.c | 28 +- >> arch/arm64/kvm/arm.c | 178 ++- >> arch/arm64/kvm/guest.c | 95 +- >> arch/arm64/kvm/hyp/pgtable.c | 1 + >> arch/arm64/kvm/hypercalls.c | 4 +- >> arch/arm64/kvm/inject_fault.c | 5 +- >> arch/arm64/kvm/mmio.c | 16 +- >> arch/arm64/kvm/mmu.c | 214 ++- >> arch/arm64/kvm/pmu-emul.c | 6 + >> arch/arm64/kvm/psci.c | 30 + >> arch/arm64/kvm/reset.c | 13 +- >> arch/arm64/kvm/rmi-exit.c | 207 +++ >> arch/arm64/kvm/rmi.c | 1948 ++++++++++++++++++++++++++ >> arch/arm64/kvm/sys_regs.c | 53 +- >> arch/arm64/kvm/vgic/vgic-init.c | 2 +- >> arch/arm64/mm/fault.c | 28 +- >> include/kvm/arm_arch_timer.h | 2 + >> include/kvm/arm_pmu.h | 4 + >> include/kvm/arm_psci.h | 2 + >> include/uapi/linux/kvm.h | 41 +- >> 32 files changed, 4176 insertions(+), 97 deletions(-) >> create mode 100644 arch/arm64/include/asm/kvm_rmi.h >> create mode 100644 arch/arm64/include/asm/rmi_cmds.h >> create mode 100644 arch/arm64/include/asm/rmi_smc.h >> create mode 100644 arch/arm64/kvm/rmi-exit.c >> create mode 100644 arch/arm64/kvm/rmi.c >> >> -- >> 2.43.0 >> >>
Hi Steven,
On 3/21/26 2:45 AM, Steven Price wrote:
> On 19/03/2026 23:02, Mathieu Poirier wrote:
[...]
>>>
>>> The TF-RMM has not yet merged the RMMv2.0 support, so you will need to
>>> use the following branch:
>>>
>>> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc
>>
>> This RMM version is expecting a RMM EL3 interface version of at least 2.0. Do
>> you have a TF-A to use with it?
>
> You should be able to use the 'master' branch of the TF-A repository.
> For now you need to set RMM_V1_COMPAT=0 to enable 2.0 support.
>
In upstream TF-A repository [1], I don't see the config option 'RMM_V1_COMPAT'.
would it be something else?
[1] git@github.com:ARM-software/arm-trusted-firmware.git (branch: master)
I use the following command to build TF-A image. The RMM-EL3 compatible issue is
still seen.
TFA_PATH=$PWD
EDK2_IMAGE=${TFA_PATH}/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC5/FV/QEMU_EFI.fd
RMM_IMAGE=${TFA_PATH}/../tf-rmm/build-qemu/Debug/rmm.img
make CROSS_COMPILE=aarch64-none-elf- \
PLAT=qemu ENABLE_RME=1 RMM_V1_COMPAT=0 DEBUG=1 LOG_LEVEL=40 \
QEMU_USE_GIC_DRIVER=QEMU_GICV3 \
BL33=${EDK2_IMAGE} RMM=${RMM_IMAGE} \
-j 8 all fip
Booting messages
================
INFO: BL31: Initializing runtime services
INFO: RMM setup done.
INFO: BL31: Initializing RMM
INFO: RMM init start.
ERROR: RMM init failed: -2
WARNING: BL31: RMM initialization failed
Thanks,
Gavin
Hi Gavin
Steven is on holidays, so I am jumping in here.
On 25/03/2026 06:37, Gavin Shan wrote:
> Hi Steven,
>
> On 3/21/26 2:45 AM, Steven Price wrote:
>> On 19/03/2026 23:02, Mathieu Poirier wrote:
>
> [...]
>
>>>>
>>>> The TF-RMM has not yet merged the RMMv2.0 support, so you will need to
>>>> use the following branch:
>>>>
>>>> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc
>>>
>>> This RMM version is expecting a RMM EL3 interface version of at least
>>> 2.0. Do
>>> you have a TF-A to use with it?
>>
>> You should be able to use the 'master' branch of the TF-A repository.
>> For now you need to set RMM_V1_COMPAT=0 to enable 2.0 support.
>>
>
> In upstream TF-A repository [1], I don't see the config option
> 'RMM_V1_COMPAT'.
> would it be something else?
>
> [1] git@github.com:ARM-software/arm-trusted-firmware.git (branch:
> master)
>
suzuki@ewhatever:trusted-firmware-a$ git grep RMM_V1_COMPAT
Makefile: RMM_V1_COMPAT \
Makefile: RMM_V1_COMPAT \
docs/getting_started/build-options.rst:- ``RMM_V1_COMPAT``: Boolean
flag to enable support for RMM v1.x compatibility
include/services/rmmd_svc.h:#if RMM_V1_COMPAT
include/services/rmmd_svc.h:#endif /* RMM_V1_COMPAT */
make_helpers/defaults.mk:RMM_V1_COMPAT := 1
services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_main.c:#if !RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
suzuki@ewhatever:trusted-firmware-a$ git log --oneline -1
8dae0862c (HEAD, origin/master, origin/integration, origin/HEAD) Merge
changes from topic "qti_lemans_evk" into integration
suzuki@ewhatever:trusted-firmware-a$ git remote get-url origin
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
> I use the following command to build TF-A image. The RMM-EL3 compatible
> issue is
> still seen.
>
> TFA_PATH=$PWD
> EDK2_IMAGE=${TFA_PATH}/../edk2/Build/ArmVirtQemuKernel-AARCH64/
> RELEASE_GCC5/FV/QEMU_EFI.fd
> RMM_IMAGE=${TFA_PATH}/../tf-rmm/build-qemu/Debug/rmm.img
> make CROSS_COMPILE=aarch64-none-elf- \
> PLAT=qemu ENABLE_RME=1 RMM_V1_COMPAT=0 DEBUG=1 LOG_LEVEL=40 \
> QEMU_USE_GIC_DRIVER=QEMU_GICV3 \
> BL33=${EDK2_IMAGE} RMM=${RMM_IMAGE} \
> -j 8 all fip
>
> Booting messages
> ================
> INFO: BL31: Initializing runtime services
> INFO: RMM setup done.
> INFO: BL31: Initializing RMM
> INFO: RMM init start.
> ERROR: RMM init failed: -2
> WARNING: BL31: RMM initialization failed
This is definitely the TF-A RMM incompatibility.
Btw, the shrinkwrap overlay configs in tf-RMM repository should work.
But unfortunately the Linux/kvmtool repositories are pointing to
internal repositories. The following patch should fix it and get
it all working. I am working with the tf-rmm team to fix this.
--8>--
diff --git a/tools/shrinkwrap/configs/cca.yaml
b/tools/shrinkwrap/configs/cca.yaml
index 1c0455ba..0d70a582 100644
--- a/tools/shrinkwrap/configs/cca.yaml
+++ b/tools/shrinkwrap/configs/cca.yaml
@@ -25,8 +25,8 @@ build:
linux:
repo:
- remote: https://gitlab.geo.arm.com/software/linux-arm/fkvm.git
- revision: stepri01/cca/v13-wip+sro
+ remote: https://gitlab.arm.com/linux-arm/linux-cca
+ revision: cca-host/v13
prebuild:
- ./scripts/config --file ${param:builddir}/.config --enable
CONFIG_PCI_TSM
- ./scripts/config --file ${param:builddir}/.config --enable
CONFIG_PCI_DOE
@@ -50,5 +50,5 @@ build:
remote: https://git.kernel.org/pub/scm/utils/dtc/dtc.git
revision: v1.7.2
kvmtool:
- remote: https://gitlab.geo.arm.com/software/linux-arm/fkvmtool.git
- revision: stepri01/cca/v13-wip
+ remote: https://gitlab.arm.com/linux-arm/kvmtool-cca
+ revision: cca/v11
Kind regards
Suzuki
>
> Thanks,
> Gavin
>
>
>
Hi Suzuki,
On 3/25/26 8:16 PM, Suzuki K Poulose wrote:
> On 25/03/2026 06:37, Gavin Shan wrote:
>> On 3/21/26 2:45 AM, Steven Price wrote:
[...]
>>
>> In upstream TF-A repository [1], I don't see the config option 'RMM_V1_COMPAT'.
>> would it be something else?
>>
>> [1] git@github.com:ARM-software/arm-trusted-firmware.git (branch: master)
>>
>
> suzuki@ewhatever:trusted-firmware-a$ git grep RMM_V1_COMPAT
> Makefile: RMM_V1_COMPAT \
> Makefile: RMM_V1_COMPAT \
> docs/getting_started/build-options.rst:- ``RMM_V1_COMPAT``: Boolean flag to enable support for RMM v1.x compatibility
> include/services/rmmd_svc.h:#if RMM_V1_COMPAT
> include/services/rmmd_svc.h:#endif /* RMM_V1_COMPAT */
> make_helpers/defaults.mk:RMM_V1_COMPAT := 1
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if !RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> suzuki@ewhatever:trusted-firmware-a$ git log --oneline -1
> 8dae0862c (HEAD, origin/master, origin/integration, origin/HEAD) Merge changes from topic "qti_lemans_evk" into integration
> suzuki@ewhatever:trusted-firmware-a$ git remote get-url origin
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
>
Thanks for the details. It turned out that I used the wrong TF-A repository. In
the proposed repository, I'm able to see the option 'RMM_V1_COMPAT' and the EL3-RMM
interface compatible issue disappears. However, there are more issues popped up.
I build everything manually where the host is emulated by QEMU instead of shrinkwrap
and FVP model. It's used to work well before. Maybe it's time to switch to shinkwrap
and FVP model since device assignment (DA) isn't supported by an emulated host
by QEMU and shrinkwrap and FVP model seems the only option. I need to learn how
to do that later.
There are two issues I can see with the following combinations. Details are provided
like below.
QEMU: https://git.qemu.org/git/qemu.git (branch: stable-9.2)
TF-RMM: https://git.trustedfirmware.org/TF-RMM/tf-rmm.git (branch: topics/rmm-v2.0-poc)
EDK2: git@github.com:tianocore/edk2.git (tag: edk2-stable202411)
TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git (branch: master)
HOST: https://git.gitlab.arm.com/linux-arm/linux-cca.git (branch: cca-host/v13)
BUILDROOT: https://github.com/buildroot/buildroot (branch: master)
KVMTOOL: https://gitlab.arm.com/linux-arm/kvmtool-cca (branch: cca/v11)
GUEST: https://github.com/torvalds/linux.git (branch: master)
(1) The emulated host is started by the following command lines.
sudo /home/gshan/sandbox/cca/host/qemu/build/qemu-system-aarch64 \
-M virt,virtualization=on,secure=on,gic-version=3,acpi=off \
-cpu max,x-rme=on -m 8G -smp 8 \
-serial mon:stdio -monitor none -nographic -nodefaults \
-bios /home/gshan/sandbox/cca/host/tf-a/flash.bin \
-kernel /home/gshan/sandbox/cca/host/linux/arch/arm64/boot/Image \
-initrd /home/gshan/sandbox/cca/host/buildroot/output/images/rootfs.cpio.xz \
-device pcie-root-port,bus=pcie.0,chassis=1,id=pcie.1 \
-device pcie-root-port,bus=pcie.0,chassis=2,id=pcie.2 \
-device pcie-root-port,bus=pcie.0,chassis=3,id=pcie.3 \
-device pcie-root-port,bus=pcie.0,chassis=4,id=pcie.4 \
-device virtio-9p-device,fsdev=shr0,mount_tag=shr0 \
-fsdev local,security_model=none,path=/home/gshan/sandbox/cca/guest,id=shr0 \
-netdev tap,id=tap1,script=/etc/qemu-ifup-gshan,downscript=/etc/qemu-ifdown-gshan \
-device virtio-net-pci,bus=pcie.2,netdev=tap1,mac=b8:3f:d2:1d:3e:f1
(2) Issue-1: TF-RMM complains about the root complex list is invalid. This error is
raised in TF-RMM::setup_root_complex_list() where the error code is still set to
0 (SUCCESS) in this failing case. The TF-RMM initialization is terminated early,
but TF-A still thinks the initialization has been completely done.
INFO: BL31: Initializing RMM
INFO: RMM init start.
RMM EL3 compat memory reservation enabled.
Dynamic VA pool base address: 0xc0000000
Reserved 20 pages. Remaining: 3615 pages
Reserve mem: 20 pages at PA: 0x401f2000 (alignment 0x1000)
Static Low VA initialized. xlat tables allocated: 20 used: 7
Reserved 514 pages. Remaining: 3101 pages
Reserve mem: 514 pages at PA: 0x40206000 (alignment 0x1000)
Dynamic Low VA initialized. xlat tables allocated: 514 used: 514
Invalid: Root Complex list <<<<< ERROR
INFO: RMM init end.
(3) Issue-2: The host kernel gets stuck in rmi_check_version() where SMC_RMI_VERSION
is issued to TF-A, but it can't be forwarded to TF-RMM because its initialization
isn't completely done (issue-1).
[ 37.438253] Unpacking initramfs...
[ 37.563460] kvm [1]: nv: 570 coarse grained trap handlers
[ 37.581139] kvm [1]: nv: 664 fine grained trap handlers
<... system becomes stuck here ...>
So my workaround is to skip fetching root complex list from the EL3-RMM manifest data
in TF-RMM::setup_root_complex_list() since it's not provided for the qemu platform by
TF-A. With this workaround, the host can boot up into shell prompt and the guest can
be started by kvmtool.
host$ uname -r
7.0.0-rc1-gavin-gd62aa44b2590
host$ lkvm run --realm -c 2 -m 256 \
-k /mnt/linux/arch/arm64/boot/Image \
-i /mnt/buildroot/output/images/rootfs.cpio.xz
-p earlycon=uart,mmio,0x101000000
Info: # lkvm run -k /mnt/linux/arch/arm64/boot/Image -m 256 -c 2 --name guest-163
Info: Enabling Guest memfd for confidential guest
Warning: The maximum recommended amount of VCPUs is 1
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510]
[ 0.000000] Linux version 7.0.0-rc2-gavin-g0031c06807cf (gshan@nvidia-grace-hopper-01.khw.eng.bos2.dc.redhat.com) (gcc (GCC) 14.3.1 20251022 (Red Hat 14.3.1-4), GNU ld version 2.41-64.el10) #2 SMP PREEMPT Wed Mar 25 20:28:05 EDT 2026
[ 0.000000] KASLR enabled
:
[ 267.578060] Freeing initrd memory: 4728K
[ 267.921865] Warning: unable to open an initial console.
[ 270.327960] Freeing unused kernel memory: 1792K
[ 270.669368] Run /init as init process
Thanks,
Gavin
Hi Gavin, On 26/03/2026 00:48, Gavin Shan wrote: > Hi Suzuki, > > On 3/25/26 8:16 PM, Suzuki K Poulose wrote: >> On 25/03/2026 06:37, Gavin Shan wrote: >>> On 3/21/26 2:45 AM, Steven Price wrote: > > [...] > >>> >>> In upstream TF-A repository [1], I don't see the config option >>> 'RMM_V1_COMPAT'. >>> would it be something else? >>> >>> [1] git@github.com:ARM-software/arm-trusted-firmware.git (branch: >>> master) >>> >> >> suzuki@ewhatever:trusted-firmware-a$ git grep RMM_V1_COMPAT >> Makefile: RMM_V1_COMPAT \ >> Makefile: RMM_V1_COMPAT \ >> docs/getting_started/build-options.rst:- ``RMM_V1_COMPAT``: Boolean >> flag to enable support for RMM v1.x compatibility >> include/services/rmmd_svc.h:#if RMM_V1_COMPAT >> include/services/rmmd_svc.h:#endif /* RMM_V1_COMPAT */ >> make_helpers/defaults.mk:RMM_V1_COMPAT := 1 >> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT >> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT >> services/std_svc/rmmd/rmmd_main.c:#if !RMM_V1_COMPAT >> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT >> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT >> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT >> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT >> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT >> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT >> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT >> suzuki@ewhatever:trusted-firmware-a$ git log --oneline -1 >> 8dae0862c (HEAD, origin/master, origin/integration, origin/HEAD) Merge >> changes from topic "qti_lemans_evk" into integration >> suzuki@ewhatever:trusted-firmware-a$ git remote get-url origin >> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git >> > > Thanks for the details. It turned out that I used the wrong TF-A > repository. In > the proposed repository, I'm able to see the option 'RMM_V1_COMPAT' and > the EL3-RMM > interface compatible issue disappears. However, there are more issues > popped up. > > I build everything manually where the host is emulated by QEMU instead > of shrinkwrap > and FVP model. It's used to work well before. Maybe it's time to switch > to shinkwrap > and FVP model since device assignment (DA) isn't supported by an > emulated host > by QEMU and shrinkwrap and FVP model seems the only option. I need to > learn how > to do that later. Thanks for the update. Yes, QEMU TF-RMM support is in progress, @Mathieu Poirier is looking into it > > There are two issues I can see with the following combinations. Details > are provided > like below. > > QEMU: https://git.qemu.org/git/ > qemu.git (branch: stable-9.2) > TF-RMM: https://git.trustedfirmware.org/TF-RMM/tf- > rmm.git (branch: topics/rmm-v2.0-poc) > EDK2: git@github.com:tianocore/ > edk2.git (tag: edk2-stable202411) > TF-A: https://git.trustedfirmware.org/TF-A/trusted-firmware- > a.git (branch: master) > HOST: https://git.gitlab.arm.com/linux-arm/linux- > cca.git (branch: cca-host/v13) > BUILDROOT: https://github.com/buildroot/ > buildroot (branch: master) > KVMTOOL: https://gitlab.arm.com/linux-arm/kvmtool- > cca (branch: cca/v11) > GUEST: https://github.com/torvalds/ > linux.git (branch: master) > > (1) The emulated host is started by the following command lines. > > sudo /home/gshan/sandbox/cca/host/qemu/build/qemu-system- > aarch64 \ > -M virt,virtualization=on,secure=on,gic- > version=3,acpi=off \ > -cpu max,x-rme=on -m 8G -smp > 8 \ > -serial mon:stdio -monitor none -nographic - > nodefaults \ > -bios /home/gshan/sandbox/cca/host/tf-a/ > flash.bin \ > -kernel /home/gshan/sandbox/cca/host/linux/arch/arm64/boot/ > Image \ > -initrd /home/gshan/sandbox/cca/host/buildroot/output/images/ > rootfs.cpio.xz \ > -device pcie-root- > port,bus=pcie.0,chassis=1,id=pcie.1 \ > -device pcie-root- > port,bus=pcie.0,chassis=2,id=pcie.2 \ > -device pcie-root- > port,bus=pcie.0,chassis=3,id=pcie.3 \ > -device pcie-root- > port,bus=pcie.0,chassis=4,id=pcie.4 \ > -device virtio-9p- > device,fsdev=shr0,mount_tag=shr0 \ > -fsdev local,security_model=none,path=/home/gshan/sandbox/cca/ > guest,id=shr0 \ > -netdev tap,id=tap1,script=/etc/qemu-ifup-gshan,downscript=/etc/ > qemu-ifdown-gshan \ > -device virtio-net-pci,bus=pcie.2,netdev=tap1,mac=b8:3f:d2:1d:3e:f1 > > (2) Issue-1: TF-RMM complains about the root complex list is invalid. > This error is > raised in TF-RMM::setup_root_complex_list() where the error code is > still set to > 0 (SUCCESS) in this failing case. The TF-RMM initialization is > terminated early, > but TF-A still thinks the initialization has been completely done. > > INFO: BL31: Initializing RMM > INFO: RMM init start. > RMM EL3 compat memory reservation enabled. > Dynamic VA pool base address: 0xc0000000 > Reserved 20 pages. Remaining: 3615 pages > Reserve mem: 20 pages at PA: 0x401f2000 (alignment 0x1000) > Static Low VA initialized. xlat tables allocated: 20 used: 7 > Reserved 514 pages. Remaining: 3101 pages > Reserve mem: 514 pages at PA: 0x40206000 (alignment 0x1000) > Dynamic Low VA initialized. xlat tables allocated: 514 used: 514 > Invalid: Root Complex list > <<<<< ERROR > INFO: RMM init end. > > (3) Issue-2: The host kernel gets stuck in rmi_check_version() where > SMC_RMI_VERSION > is issued to TF-A, but it can't be forwarded to TF-RMM because its > initialization > isn't completely done (issue-1). > > [ 37.438253] Unpacking initramfs... > [ 37.563460] kvm [1]: nv: 570 coarse grained trap handlers > [ 37.581139] kvm [1]: nv: 664 fine grained trap handlers > <... system becomes stuck here ...> > > So my workaround is to skip fetching root complex list from the EL3-RMM > manifest data > in TF-RMM::setup_root_complex_list() since it's not provided for the > qemu platform by ^^ This may have to do with the RMM<->TF-A Manifest changes > TF-A. With this workaround, the host can boot up into shell prompt and > the guest can > be started by kvmtool. > > host$ uname -r > 7.0.0-rc1-gavin-gd62aa44b2590 > host$ lkvm run --realm -c 2 -m 256 \ > -k /mnt/linux/arch/arm64/boot/Image \ > -i /mnt/buildroot/output/images/rootfs.cpio.xz > -p earlycon=uart,mmio,0x101000000 > Info: # lkvm run -k /mnt/linux/arch/arm64/boot/Image -m 256 -c 2 -- > name guest-163 > Info: Enabling Guest memfd for confidential guest > Warning: The maximum recommended amount of VCPUs is 1 > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510] > [ 0.000000] Linux version 7.0.0-rc2-gavin-g0031c06807cf > (gshan@nvidia-grace-hopper-01.khw.eng.bos2.dc.redhat.com) (gcc (GCC) > 14.3.1 20251022 (Red Hat 14.3.1-4), GNU ld version 2.41-64.el10) #2 SMP > PREEMPT Wed Mar 25 20:28:05 EDT 2026 > [ 0.000000] KASLR enabled > : > [ 267.578060] Freeing initrd memory: 4728K > [ 267.921865] Warning: unable to open an initial console. > [ 270.327960] Freeing unused kernel memory: 1792K > [ 270.669368] Run /init as init process > Cool, thanks! Suzuki > Thanks, > Gavin >
On 25/03/2026 10:16, Suzuki K Poulose wrote:
> Hi Gavin
>
> Steven is on holidays, so I am jumping in here.
>
> On 25/03/2026 06:37, Gavin Shan wrote:
>> Hi Steven,
>>
>> On 3/21/26 2:45 AM, Steven Price wrote:
>>> On 19/03/2026 23:02, Mathieu Poirier wrote:
>>
>> [...]
>>
>>>>>
>>>>> The TF-RMM has not yet merged the RMMv2.0 support, so you will need to
>>>>> use the following branch:
>>>>>
>>>>> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc
>>>>
>>>> This RMM version is expecting a RMM EL3 interface version of at
>>>> least 2.0. Do
>>>> you have a TF-A to use with it?
>>>
>>> You should be able to use the 'master' branch of the TF-A repository.
>>> For now you need to set RMM_V1_COMPAT=0 to enable 2.0 support.
>>>
>>
>> In upstream TF-A repository [1], I don't see the config option
>> 'RMM_V1_COMPAT'.
>> would it be something else?
>>
>> [1] git@github.com:ARM-software/arm-trusted-firmware.git (branch:
>> master)
>>
>
> suzuki@ewhatever:trusted-firmware-a$ git grep RMM_V1_COMPAT
> Makefile: RMM_V1_COMPAT \
> Makefile: RMM_V1_COMPAT \
> docs/getting_started/build-options.rst:- ``RMM_V1_COMPAT``: Boolean
> flag to enable support for RMM v1.x compatibility
> include/services/rmmd_svc.h:#if RMM_V1_COMPAT
> include/services/rmmd_svc.h:#endif /* RMM_V1_COMPAT */
> make_helpers/defaults.mk:RMM_V1_COMPAT := 1
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if !RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> suzuki@ewhatever:trusted-firmware-a$ git log --oneline -1
> 8dae0862c (HEAD, origin/master, origin/integration, origin/HEAD) Merge
> changes from topic "qti_lemans_evk" into integration
> suzuki@ewhatever:trusted-firmware-a$ git remote get-url origin
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
>
>
>
>> I use the following command to build TF-A image. The RMM-EL3
>> compatible issue is
>> still seen.
>>
>> TFA_PATH=$PWD
>> EDK2_IMAGE=${TFA_PATH}/../edk2/Build/ArmVirtQemuKernel-AARCH64/
>> RELEASE_GCC5/FV/QEMU_EFI.fd
>> RMM_IMAGE=${TFA_PATH}/../tf-rmm/build-qemu/Debug/rmm.img
>> make CROSS_COMPILE=aarch64-none-elf- \
>> PLAT=qemu ENABLE_RME=1 RMM_V1_COMPAT=0 DEBUG=1 LOG_LEVEL=40 \
>> QEMU_USE_GIC_DRIVER=QEMU_GICV3 \
>> BL33=${EDK2_IMAGE} RMM=${RMM_IMAGE} \
>> -j 8 all fip
>>
>
>
>
>
>> Booting messages
>> ================
>> INFO: BL31: Initializing runtime services
>> INFO: RMM setup done.
>> INFO: BL31: Initializing RMM
>> INFO: RMM init start.
>> ERROR: RMM init failed: -2
>> WARNING: BL31: RMM initialization failed
>
> This is definitely the TF-A RMM incompatibility.
>
> Btw, the shrinkwrap overlay configs in tf-RMM repository should work.
> But unfortunately the Linux/kvmtool repositories are pointing to
> internal repositories. The following patch should fix it and get
> it all working. I am working with the tf-rmm team to fix this.
This is now fixed in the branch :
https://git.trustedfirmware.org/plugins/gitiles/TF-RMM/tf-rmm/+/refs/heads/topics/rmm-v2.0-poc/tools/shrinkwrap/configs/cca.yaml
Cheers
Suzuki
On Fri, Mar 20, 2026 at 04:45:49PM +0000, Steven Price wrote: > On 19/03/2026 23:02, Mathieu Poirier wrote: > > Good day, > > > > On Wed, Mar 18, 2026 at 03:53:24PM +0000, Steven Price wrote: > >> This series adds support for running protected VMs using KVM under the > >> Arm Confidential Compute Architecture (CCA). > >> > >> New major version number! This now targets RMM v2.0-bet0[1]. And unlike > >> for Linux this represents a significant change. > >> > >> RMM v2.0 brings with it the ability to configure the RMM to have the > >> same page size as the host (so no more RMM_PAGE_SIZE and dealing with > >> granules being different from host pages). It also introduces range > >> based APIs for many operations which should be more efficient and > >> simplifies the code in places. > >> > >> The handling of the GIC has changed, so the system registers are used to > >> pass the GIC state rather than memory. This means fewer changes to the > >> KVM code as it looks much like a normal VM in this respect. > >> > >> And of course the new uAPI introduced in the previous v12 posting is > >> retained so that also remains simplified compared to earlier postings. > >> > >> The RMM support for v2.0 is still early and so this series includes a > >> few hacks to ease the integration. Of note are that there are some RMM > >> v1.0 SMCs added to paper over areas where the RMM implementation isn't > >> quite ready for v2.0, and "SROs" (see below) are deferred to the final > >> patch in the series. > >> > >> The PMU in RMM v2.0 requires more handling on the RMM-side (and > >> therefore simplifies the implementation on Linux), but this isn't quite > >> ready yet. The Linux side is implemented (but untested). > >> > >> PSCI still requires the VMM to provide the "target" REC for operations > >> that affect another vCPU. This is likely to change in a future version > >> of the specification. There's also a desire to force PSCI to be handled > >> in the VMM for realm guests - this isn't implemented yet as I'm waiting > >> for the dust to settle on the RMM interface first. > >> > >> Stateful RMI Operations > >> ----------------------- > >> > >> The RMM v2.0 spec brings a new concept of Stateful RMI Operations (SROs) > >> which allow the RMM to complete an operation over several SMC calls and > >> requesting/returning memory to the host. This has the benefit of > >> allowing interrupts to be handled in the middle of an operation (by > >> returning to the host to handle the interrupt without completing the > >> operation) and enables the RMM to dynamically allocate memory for > >> internal tracking purposes. One example of this is RMI_REC_CREATE no > >> longer needs "auxiliary granules" provided upfront but can request the > >> memory needed during the RMI_REC_CREATE operation. > >> > >> There are a fairly large number of operations that are defined as SROs > >> in the specification, but current both Linux and RMM only have support > >> for RMI_REC_CREATE and RMI_REC_DESTROY. There a number of TODOs/FIXMEs > >> in the code where support is missing. > >> > >> Given the early stage support for this, the SRO handling is all confined > >> to the final patch. This patch can be dropped to return to a pre-SRO > >> state (albeit a mixture of RMM v1.0 and v2.0 APIs) for testing purposes. > >> > >> A future posting will reorder the series to move the generic SRO support > >> to an early patch and will implement the proper support for this in all > >> RMI SMCs. > >> > >> One aspect of SROs which is not yet well captured is that in some > >> circumstances the Linux kernel will need to call an SRO call in a > >> context where memory allocation is restricted (e.g. because a spinlock > >> is held). In this case the intention is that the SRO will be cancelled, > >> the spinlock dropped so the memory allocation can be completed, and then > >> the SRO restarted (obviously after rechecking the state that the > >> spinlock was protecting). For this reason the code stores the memory > >> allocations within a struct rmi_sro_state object - see the final patch > >> for more details. > >> > >> This series is based on v7.0-rc1. It is also available as a git > >> repository: > >> > >> https://gitlab.arm.com/linux-arm/linux-cca cca-host/v13 > >> > >> Work in progress changes for kvmtool are available from the git > >> repository below: > >> > >> https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v11 > >> > >> Note that the kvmtool code has been tidied up (thanks to Suzuki) and > >> this involves a minor change in flags. The "--restricted_mem" flag is no > >> longer recognised (or necessary). > >> > >> The TF-RMM has not yet merged the RMMv2.0 support, so you will need to > >> use the following branch: > >> > >> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc > > > > This RMM version is expecting a RMM EL3 interface version of at least 2.0. Do > > you have a TF-A to use with it? > > You should be able to use the 'master' branch of the TF-A repository. > For now you need to set RMM_V1_COMPAT=0 to enable 2.0 support. > That worked - thanks for the clarification. > Thanks, > Steve > > > Thanks, > > Mathieu > > > >> > >> [1] https://developer.arm.com/documentation/den0137/2-0bet0/ > >> > >> Jean-Philippe Brucker (7): > >> arm64: RMI: Propagate number of breakpoints and watchpoints to > >> userspace > >> arm64: RMI: Set breakpoint parameters through SET_ONE_REG > >> arm64: RMI: Initialize PMCR.N with number counter supported by RMM > >> arm64: RMI: Propagate max SVE vector length from RMM > >> arm64: RMI: Configure max SVE vector length for a Realm > >> arm64: RMI: Provide register list for unfinalized RMI RECs > >> arm64: RMI: Provide accurate register list > >> > >> Joey Gouly (2): > >> arm64: RMI: allow userspace to inject aborts > >> arm64: RMI: support RSI_HOST_CALL > >> > >> Steven Price (36): > >> kvm: arm64: Avoid including linux/kvm_host.h in kvm_pgtable.h > >> arm64: RME: Handle Granule Protection Faults (GPFs) > >> arm64: RMI: Add SMC definitions for calling the RMM > >> arm64: RMI: Temporarily add SMCs from RMM v1.0 spec > >> arm64: RMI: Add wrappers for RMI calls > >> arm64: RMI: Check for RMI support at KVM init > >> arm64: RMI: Configure the RMM with the host's page size > >> arm64: RMI: Check for LPA2 support > >> arm64: RMI: Ensure that the RMM has GPT entries for memory > >> arm64: RMI: Define the user ABI > >> arm64: RMI: Basic infrastructure for creating a realm. > >> KVM: arm64: Allow passing machine type in KVM creation > >> arm64: RMI: RTT tear down > >> arm64: RMI: Activate realm on first VCPU run > >> arm64: RMI: Allocate/free RECs to match vCPUs > >> arm64: RMI: Support for the VGIC in realms > >> KVM: arm64: Support timers in realm RECs > >> arm64: RMI: Handle realm enter/exit > >> arm64: RMI: Handle RMI_EXIT_RIPAS_CHANGE > >> KVM: arm64: Handle realm MMIO emulation > >> KVM: arm64: Expose support for private memory > >> arm64: RMI: Allow populating initial contents > >> arm64: RMI: Set RIPAS of initial memslots > >> arm64: RMI: Create the realm descriptor > >> arm64: RMI: Runtime faulting of memory > >> KVM: arm64: Handle realm VCPU load > >> KVM: arm64: Validate register access for a Realm VM > >> KVM: arm64: Handle Realm PSCI requests > >> KVM: arm64: WARN on injected undef exceptions > >> arm64: Don't expose stolen time for realm guests > >> arm64: RMI: Always use 4k pages for realms > >> arm64: RMI: Prevent Device mappings for Realms > >> arm64: RMI: Enable PMU support with a realm guest > >> KVM: arm64: Expose KVM_ARM_VCPU_REC to user space > >> arm64: RMI: Enable realms to be created > >> [WIP] arm64: RMI: Add support for SRO > >> > >> Suzuki K Poulose (3): > >> kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h > >> kvm: arm64: Don't expose unsupported capabilities for realm guests > >> arm64: RMI: Allow checking SVE on VM instance > >> > >> Documentation/virt/kvm/api.rst | 86 +- > >> arch/arm64/include/asm/kvm_emulate.h | 31 + > >> arch/arm64/include/asm/kvm_host.h | 15 +- > >> arch/arm64/include/asm/kvm_pgtable.h | 5 +- > >> arch/arm64/include/asm/kvm_pkvm.h | 2 +- > >> arch/arm64/include/asm/kvm_rmi.h | 129 ++ > >> arch/arm64/include/asm/rmi_cmds.h | 692 +++++++++ > >> arch/arm64/include/asm/rmi_smc.h | 430 ++++++ > >> arch/arm64/include/asm/virt.h | 1 + > >> arch/arm64/kernel/cpufeature.c | 1 + > >> arch/arm64/kvm/Kconfig | 2 + > >> arch/arm64/kvm/Makefile | 2 +- > >> arch/arm64/kvm/arch_timer.c | 28 +- > >> arch/arm64/kvm/arm.c | 178 ++- > >> arch/arm64/kvm/guest.c | 95 +- > >> arch/arm64/kvm/hyp/pgtable.c | 1 + > >> arch/arm64/kvm/hypercalls.c | 4 +- > >> arch/arm64/kvm/inject_fault.c | 5 +- > >> arch/arm64/kvm/mmio.c | 16 +- > >> arch/arm64/kvm/mmu.c | 214 ++- > >> arch/arm64/kvm/pmu-emul.c | 6 + > >> arch/arm64/kvm/psci.c | 30 + > >> arch/arm64/kvm/reset.c | 13 +- > >> arch/arm64/kvm/rmi-exit.c | 207 +++ > >> arch/arm64/kvm/rmi.c | 1948 ++++++++++++++++++++++++++ > >> arch/arm64/kvm/sys_regs.c | 53 +- > >> arch/arm64/kvm/vgic/vgic-init.c | 2 +- > >> arch/arm64/mm/fault.c | 28 +- > >> include/kvm/arm_arch_timer.h | 2 + > >> include/kvm/arm_pmu.h | 4 + > >> include/kvm/arm_psci.h | 2 + > >> include/uapi/linux/kvm.h | 41 +- > >> 32 files changed, 4176 insertions(+), 97 deletions(-) > >> create mode 100644 arch/arm64/include/asm/kvm_rmi.h > >> create mode 100644 arch/arm64/include/asm/rmi_cmds.h > >> create mode 100644 arch/arm64/include/asm/rmi_smc.h > >> create mode 100644 arch/arm64/kvm/rmi-exit.c > >> create mode 100644 arch/arm64/kvm/rmi.c > >> > >> -- > >> 2.43.0 > >> > >> >
And for those who like to use shrinkwrap the following YAML config
should work on top of the 2025.12.0 tag to pull the various repos. Save
the below as e.g. cca-v13.yaml and follow the usual instructions in
cca-3world.yaml but refer to cca-v13.yaml instead.
---8<---
%YAML 1.2
---
concrete: true
layers:
- cca-3world.yaml
build:
linux:
repo:
revision: cca-host/v13
kvmtool:
repo:
kvmtool:
revision: cca/v11
tfa:
params:
RMM_V1_COMPAT: 0
repo:
revision: master
rmm:
repo:
revision: topics/rmm-v2.0-poc
© 2016 - 2026 Red Hat, Inc.