[PATCH v11 00/42] arm64: Support for Arm CCA in KVM

Steven Price
2025-10-17T14:55:08Z

Hi all,

v6.18-rc1 is out, so I've rebased and refreshed the series. Branches are
below:

kernel: https://gitlab.arm.com/linux-arm/linux-cca cca-host/v11
kvmtool: https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v9

However I'm not going to spam you all with the patches because there are
some significant changes that are still to be worked out which Marc has
pointed out (thanks for the review!). Specifically:

* We've agreed that the uAPI should be more like "normal" KVM. So
rather than expose the underlying operations (create RECs, init
RIPAS, populate memory, activate), the VMM should set this up 'as
normal' (but using the guestmem_fd capabilities to mark the memory
private) and then on first vcpu run the realm should be configured,
RIPAS set based on the memslots/guestmem_fd and any data written in
the guestmem_fd populated into the realm.

The upshot of which is that a VMM will require only minimal changes
to support CCA, and the ordering requirements (for attestation of
setting up the realm will be handled by KVM).

Since this is a big change in the uAPI it's going to take a while to
prototype and figure out all the details, so please bear with me
while I work on an updated version.

* There are issues with the PMU handling where the host is not provided
with as much flexibility it should. For the PMU it's not possible for
the host to maintain a PMU counter while the realm is executing. This
means that sensible uses like getting an overflow interrupt on the
cycle counter break with the use of a realm. This, however, will
require a spec update to fix as the RMM will need to in some cases
emulate the PMU registers.

* The GIC handling is also more restrictive then it should be. Although
the host is responsible for emulating the GIC, it is unable to set
trap bits, restricting the host's ability to do this. There is
concern that this could limit the ability to implement hardware
workarounds in the future. Again a spec update is needed to fix this.

However, changes that you can see (in the branch) include:

* Fixing the naming of various symbols. There were previously a lot of
instances of "rme" in functions which were not directly related to
the hardware extension. These are now renamed to "rmi" reflecting
that they are part of the interface to the RMM.
(This is the only change affecting kvmtool, although it is also
binary compatible)

* The code now checks with the hardware feature (RME) before probing
for RMI.

* There is now an allowlist for CAPs rather than individually disabling
the ones known to be an issue with realms. (This also simplified the
code, dropping one patch).

* Fixes for the vgic handling: make sure the VGIC v4 state is
synchronised and only populate valid lrs.

* A few other minor updates from reviews, and some minor changes from
rebasing.

Thanks,
Steve