Message-ID: <461fa23f-9add-40e5-a0d0-759030e7c70b@arm.com>
Date: Fri, 17 Oct 2025 15:55:01 +0100
From: Steven Price <steven.price@....com>
To: kvm@...r.kernel.org, kvmarm@...ts.linux.dev
Cc: Catalin Marinas <catalin.marinas@....com>, Marc Zyngier <maz@...nel.org>,
 Will Deacon <will@...nel.org>, James Morse <james.morse@....com>,
 Oliver Upton <oliver.upton@...ux.dev>,
 Suzuki K Poulose <suzuki.poulose@....com>, Zenghui Yu
 <yuzenghui@...wei.com>, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Joey Gouly <joey.gouly@....com>,
 Alexandru Elisei <alexandru.elisei@....com>,
 Christoffer Dall <christoffer.dall@....com>, Fuad Tabba <tabba@...gle.com>,
 linux-coco@...ts.linux.dev,
 Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>,
 Gavin Shan <gshan@...hat.com>, Shanker Donthineni <sdonthineni@...dia.com>,
 Alper Gun <alpergun@...gle.com>, "Aneesh Kumar K . V"
 <aneesh.kumar@...nel.org>, Emi Kisanuki <fj0570is@...itsu.com>,
 Vishal Annapurve <vannapurve@...gle.com>
Subject: [PATCH v11 00/42] arm64: Support for Arm CCA in KVM

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

Powered by blists - more mailing lists