mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev,
	Catalin Marinas <catalin.marinas@arm.com>,
	Marc Zyngier <maz@kernel.org>, Will Deacon <will@kernel.org>,
	James Morse <james.morse@arm.com>,
	Oliver Upton <oliver.upton@linux.dev>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Joey Gouly <joey.gouly@arm.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	Christoffer Dall <christoffer.dall@arm.com>,
	Fuad Tabba <tabba@google.com>,
	linux-coco@lists.linux.dev,
	Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
	Gavin Shan <gshan@redhat.com>,
	Shanker Donthineni <sdonthineni@nvidia.com>,
	Alper Gun <alpergun@google.com>,
	"Aneesh Kumar K . V" <aneesh.kumar@kernel.org>,
	Emi Kisanuki <fj0570is@fujitsu.com>,
	Vishal Annapurve <vannapurve@google.com>
Subject: Re: [PATCH v12 00/46] arm64: Support for Arm CCA in KVM
Date: Mon, 16 Feb 2026 14:27:02 +0000	[thread overview]
Message-ID: <9140efaa-dc54-4a1b-8936-3ef876ca9121@arm.com> (raw)
In-Reply-To: <55fc4877-666c-4d5f-a167-5692f7cfbd0b@arm.com>

On 16/02/2026 12:33, Steven Price wrote:
> On 12/02/2026 17:48, Mathieu Poirier wrote:
>> Hi Steven,
>>
>> On Wed, Dec 17, 2025 at 10:10:37AM +0000, Steven Price wrote:
>>> This series adds support for running protected VMs using KVM under the
>>> Arm Confidential Compute Architecture (CCA). I've changed the uAPI
>>> following feedback from Marc.
>>>
>>> The main change is that rather than providing a multiplex CAP and
>>> expecting the VMM to drive the different stages of realm construction,
>>> there's now just a minimal interface and KVM performs the necessary
>>> operations when needed.
>>>
>>> This series is lightly tested and is meant as a demonstration of the new
>>> uAPI. There are a number of (known) rough corners in the implementation
>>> that I haven't dealt with properly.
>>>
>>> In particular please note that this series is still targetting RMM v1.0.
>>> There is an alpha quality version of RMM v2.0 available[1]. Feedback was
>>> that there are a number of blockers for merging with RMM v1.0 and so I
>>> expect to rework this series to support RMM v2.0 before it is merged.
>>> That will necessarily involve reworking the implementation.
>>>
>>> Specifically I'm expecting improvements in:
>>>
>>>  * GIC handling - passing state in registers, and allowing the host to
>>>    fully emulate the GIC by allowing trap bits to be set.
>>>
>>>  * PMU handling - again providing flexibility to the host's emulation.
>>>
>>>  * Page size/granule size mismatch. RMM v1.0 defines the granule as 4k,
>>>    RMM v2.0 provide the option for the host to change the granule size.
>>>    The intention is that Linux would simply set the granule size equal
>>>    to its page size which will significantly simplify the management of
>>>    granules.
>>>
>>>  * Some performance improvement from the use of range-based map/unmap
>>>    RMI calls.
>>>
>>> This series is based on v6.19-rc1. It is also available as a git
>>> repository:
>>>
>>> https://gitlab.arm.com/linux-arm/linux-cca cca-host/v12
>>>
>>> Work in progress changes for kvmtool are available from the git
>>> repository below:
>>>
>>> https://gitlab.arm.com/linux-arm/kvmtool-cca cca/v10
>>
>> The first thing to note is that branch cca/v10 does not compile due to function
>> realm_configure_parameters() not being called anywhere.  Marking the function as
>> [[maybe_unused]] solved the problem on my side.
> 
> This is in the kvmtool code - and yes I agree "work in progress" is a
> bit generous for the current state of that code, "horrid ugly hacks to
> get things working" is probably more accurate ;)
> 
> The issue here is that the two things that realm_configure_parameters()
> set up (hash algorithm and RPV) are currently unsupported with the Linux
> changes, but will need to be reintroduced in the future. So the contents
> of the functions which set this up (using the old uAPI) are just #if 0'd
> out.
> 
> Depending on the compile flags the code will compile with a warning, but
> using __attribute__((unused)) would at least make this clear. I'd want
> to avoid the "[[maybe_unused]]" as it's not used elsewhere in the code
> base and limits compatibility.
> 
>> Using the FVP emulator, booting a Realm that includes EDK2 in its boot stack
>> worked.  If EDK2 is not part of the boot stack and a kernel is booted directly
>> from lkvm, mounting the initrd fails.  Looking into this issue further, I see
>> that from a Realm kernel's perspective, the content of the initrd is either
>> encrypted or has been trampled on.  
> 
> I can reproduce that, a quick fix is to change INITRD_ALIGN:
> 
> #define INITRD_ALIGN	SZ_64K
> 
> But the code was meant to be able to deal with an unaligned initrd -
> I'll see if I can figure out what's going wrong.

Looks like a simple bug in kvm_arm_realm_populate_ram() - it wasn't
updating the source address when it had to align the start of the
region. Simple fix below:

---8<---
diff --git a/arm/aarch64/realm.c b/arm/aarch64/realm.c
--- a/arm/aarch64/realm.c
+++ b/arm/aarch64/realm.c
@@ -104,7 +104,7 @@ void kvm_arm_realm_populate_ram(struct kvm *kvm,
unsigned long start,

        new_region->start = ALIGN_DOWN(start, SZ_64K);
        new_region->file_end = ALIGN(start + size, SZ_64K);
-       new_region->source = source;
+       new_region->source = source - (start - new_region->start);

        list_add_tail(&new_region->list, &realm_ram_regions);
 }
---8<---

Thanks for the pointer, and I'll try to remember to include initrd
testing in future.

Steve


  reply	other threads:[~2026-02-16 14:27 UTC|newest]

Thread overview: 82+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-17 10:10 Steven Price
2025-12-17 10:10 ` [PATCH v12 01/46] kvm: arm64: Include kvm_emulate.h in kvm/arm_psci.h Steven Price
2025-12-17 10:10 ` [PATCH v12 02/46] arm64: RME: Handle Granule Protection Faults (GPFs) Steven Price
2025-12-17 10:10 ` [PATCH v12 03/46] arm64: RMI: Add SMC definitions for calling the RMM Steven Price
2025-12-17 10:10 ` [PATCH v12 04/46] arm64: RMI: Add wrappers for RMI calls Steven Price
2025-12-17 10:10 ` [PATCH v12 05/46] arm64: RMI: Check for RMI support at KVM init Steven Price
2025-12-17 10:10 ` [PATCH v12 06/46] arm64: RMI: Define the user ABI Steven Price
2026-01-23 16:47   ` Suzuki K Poulose
2026-01-26  9:37     ` Steven Price
2026-03-02 14:25   ` Marc Zyngier
2026-03-02 15:23     ` Steven Price
2026-03-02 17:13       ` Suzuki K Poulose
2026-03-03 13:13         ` Marc Zyngier
2026-03-03 14:23           ` Suzuki K Poulose
2026-03-03 14:37             ` Marc Zyngier
2026-03-03 16:02               ` Suzuki K Poulose
2026-03-03 13:11       ` Marc Zyngier
2026-03-04 12:08         ` Steven Price
2026-03-11 19:10       ` Marc Zyngier
2026-03-12  9:28         ` Suzuki K Poulose
2026-03-12  9:39           ` Marc Zyngier
2026-03-12 10:45             ` Steven Price
2025-12-17 10:10 ` [PATCH v12 07/46] arm64: RMI: Basic infrastructure for creating a realm Steven Price
2025-12-17 10:10 ` [PATCH v12 08/46] kvm: arm64: Don't expose unsupported capabilities for realm guests Steven Price
2025-12-17 10:10 ` [PATCH v12 09/46] KVM: arm64: Allow passing machine type in KVM creation Steven Price
2025-12-17 10:10 ` [PATCH v12 10/46] arm64: RMI: RTT tear down Steven Price
2025-12-17 10:10 ` [PATCH v12 11/46] arm64: RMI: Activate realm on first VCPU run Steven Price
2025-12-17 14:29   ` Suzuki K Poulose
2026-03-02 14:40   ` Marc Zyngier
2026-03-02 16:31     ` Steven Price
2025-12-17 10:10 ` [PATCH v12 12/46] arm64: RMI: Allocate/free RECs to match vCPUs Steven Price
2025-12-17 10:10 ` [PATCH v12 13/46] KVM: arm64: vgic: Provide helper for number of list registers Steven Price
2025-12-17 10:10 ` [PATCH v12 14/46] arm64: RMI: Support for the VGIC in realms Steven Price
2025-12-17 10:10 ` [PATCH v12 15/46] KVM: arm64: Support timers in realm RECs Steven Price
2025-12-17 10:10 ` [PATCH v12 16/46] arm64: RMI: Handle realm enter/exit Steven Price
2025-12-17 10:10 ` [PATCH v12 17/46] arm64: RMI: Handle RMI_EXIT_RIPAS_CHANGE Steven Price
2025-12-17 10:10 ` [PATCH v12 18/46] KVM: arm64: Handle realm MMIO emulation Steven Price
2025-12-17 10:10 ` [PATCH v12 19/46] KVM: arm64: Expose support for private memory Steven Price
2025-12-20 13:46   ` kernel test robot
2025-12-20 13:59   ` kernel test robot
2025-12-20 14:18   ` kernel test robot
2025-12-17 10:10 ` [PATCH v12 20/46] arm64: RMI: Allow populating initial contents Steven Price
2025-12-20 14:34   ` kernel test robot
2026-03-02 14:56   ` Marc Zyngier
2026-03-02 16:46     ` Steven Price
2025-12-17 10:10 ` [PATCH v12 21/46] arm64: RMI: Set RIPAS of initial memslots Steven Price
2025-12-17 10:10 ` [PATCH v12 22/46] arm64: RMI: Create the realm descriptor Steven Price
2026-01-23 18:57   ` Alper Gun
2026-01-26  9:50     ` Steven Price
2025-12-17 10:11 ` [PATCH v12 23/46] arm64: RMI: Add a VMID allocator for realms Steven Price
2025-12-17 10:11 ` [PATCH v12 24/46] arm64: RMI: Runtime faulting of memory Steven Price
2025-12-17 10:11 ` [PATCH v12 25/46] KVM: arm64: Handle realm VCPU load Steven Price
2025-12-17 10:11 ` [PATCH v12 26/46] KVM: arm64: Validate register access for a Realm VM Steven Price
2025-12-17 10:11 ` [PATCH v12 27/46] KVM: arm64: Handle Realm PSCI requests Steven Price
2026-03-02 16:39   ` Marc Zyngier
2026-03-03  9:26     ` Suzuki K Poulose
2026-03-03 13:04       ` Marc Zyngier
2025-12-17 10:11 ` [PATCH v12 28/46] KVM: arm64: WARN on injected undef exceptions Steven Price
2025-12-17 10:11 ` [PATCH v12 29/46] arm64: Don't expose stolen time for realm guests Steven Price
2025-12-17 10:11 ` [PATCH v12 30/46] arm64: RMI: allow userspace to inject aborts Steven Price
2025-12-17 10:11 ` [PATCH v12 31/46] arm64: RMI: support RSI_HOST_CALL Steven Price
2025-12-17 10:11 ` [PATCH v12 32/46] arm64: RMI: Allow checking SVE on VM instance Steven Price
2025-12-17 10:11 ` [PATCH v12 33/46] arm64: RMI: Always use 4k pages for realms Steven Price
2025-12-17 10:11 ` [PATCH v12 34/46] arm64: RMI: Prevent Device mappings for Realms Steven Price
2025-12-17 10:11 ` [PATCH v12 35/46] HACK: Restore per-CPU cpu_armpmu pointer Steven Price
2025-12-17 10:11 ` [PATCH v12 36/46] arm_pmu: Provide a mechanism for disabling the physical IRQ Steven Price
2025-12-17 10:11 ` [PATCH v12 37/46] arm64: RMI: Enable PMU support with a realm guest Steven Price
2025-12-17 10:11 ` [PATCH v12 38/46] arm64: RMI: Propagate number of breakpoints and watchpoints to userspace Steven Price
2025-12-17 10:11 ` [PATCH v12 39/46] arm64: RMI: Set breakpoint parameters through SET_ONE_REG Steven Price
2025-12-17 10:11 ` [PATCH v12 40/46] arm64: RMI: Initialize PMCR.N with number counter supported by RMM Steven Price
2025-12-17 10:11 ` [PATCH v12 41/46] arm64: RMI: Propagate max SVE vector length from RMM Steven Price
2025-12-17 10:11 ` [PATCH v12 42/46] arm64: RMI: Configure max SVE vector length for a Realm Steven Price
2025-12-17 10:11 ` [PATCH v12 43/46] arm64: RMI: Provide register list for unfinalized RMI RECs Steven Price
2025-12-17 10:11 ` [PATCH v12 44/46] arm64: RMI: Provide accurate register list Steven Price
2025-12-17 10:11 ` [PATCH v12 45/46] KVM: arm64: Expose KVM_ARM_VCPU_REC to user space Steven Price
2025-12-17 10:11 ` [PATCH v12 46/46] arm64: RMI: Enable realms to be created Steven Price
2025-12-17 14:55 ` [PATCH v12 00/46] arm64: Support for Arm CCA in KVM Marc Zyngier
2025-12-17 15:28   ` Steven Price
2026-02-12 17:48 ` Mathieu Poirier
2026-02-16 12:33   ` Steven Price
2026-02-16 14:27     ` Steven Price [this message]
2026-02-17 17:47       ` Mathieu Poirier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9140efaa-dc54-4a1b-8936-3ef876ca9121@arm.com \
    --to=steven.price@arm.com \
    --cc=alexandru.elisei@arm.com \
    --cc=alpergun@google.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@arm.com \
    --cc=fj0570is@fujitsu.com \
    --cc=gankulkarni@os.amperecomputing.com \
    --cc=gshan@redhat.com \
    --cc=james.morse@arm.com \
    --cc=joey.gouly@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.poirier@linaro.org \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=sdonthineni@nvidia.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=vannapurve@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®