From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0282B36D4FD for ; Tue, 17 Feb 2026 17:47:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771350473; cv=none; b=sO/Ic3bY/0+IM0KgPXUw7WnAcvNhv4HBYM3gOskxKoMfbfUv7BZpqeAAIIHkJjKwV/FREMu+/OmOtZ1XTgi/zPh3e7EE0+vMAAa/HWGecv7oP+/vXmERSDldJ09IVf/yBkqJynlOFLGo/jnX8wXRP5fXN4h+GJfb9zI4xCFlcFA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771350473; c=relaxed/simple; bh=Ldc3kA/B8po7HRBL7zpvt1BJaIEwgDG3685rS8QLkdY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LzTQc1whg6M8bvcuOBDctv7aGK94LRywZVIkcbbRnmlpcSSBKVpHhwMZg50qODn+d+jOLFhZ6NRvJqKET/dSHTH1W2pNNnv9A5pWY2XPo95kziifNBT9V8WO2/9tBbALLOII7dFwNoZf5dusOU5R4ImHUrT13cnwPr+iE+zIFVM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=ZppstiaU; arc=none smtp.client-ip=209.85.210.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="ZppstiaU" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-8217f2ad01eso446041b3a.2 for ; Tue, 17 Feb 2026 09:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1771350471; x=1771955271; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=NzMITkEXZs34lceKZ1bkvJdV8jpP8i6Cd6H1ke9i4qg=; b=ZppstiaUMgdxGhYrJCK250bmu3M9qtXXEJzvjNUBaSe3/OFvucS6HjQ4UpIiJ9Py5A dRFSD5h+l8n63UQD93tuYuvJPdquc5FUMTVFBcunYehH6X/eYb6ROUXDWff8pldEIwBH Ye7GpKqkFbzC51GlX2N2rxyEZ+A0qMZmzNgYCBm3CTVpTJQ+klVrhoYkt9QlfXc+NVoR iLooG79GbkeLB2qvDgxg/+dyvwdwHXUxC3Q1v1aN/CIGUGPhrWXvDPh1QqzcWu2PPQK3 M7x4MgWRRR4eEONtFxzPKmtqOHCv47SnIsimg+DSnyz8z7dcuB08Uyf5cDJd2J8daJ+F xJjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771350471; x=1771955271; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NzMITkEXZs34lceKZ1bkvJdV8jpP8i6Cd6H1ke9i4qg=; b=xGY8zCDz/FfB2kwN9rw77yDYPwymFUxqxftxzYLS811E+EIAdwxcoqu0ipVxzHmi5K nrr8Zt8cR3tUPrCfhHbt1jQ7fx8+1trJyMr3ObpM2HOtudIkpQWqE1LDmdtNjsyu0jPJ ELVzpbZpb8pg0DNEawiLFIdq/zndvkDTPHeOAcLkeA6NFi1pdrKD28FQ1SCYPvwAOlda JS4ImR5RssThN5rl3+NaMEEkDvctMkn1suF/SP/uARlchUTaMvilz/jomVgGtco+fjIn XDIz+q/cpTEwZfJV7yQPAj/R2F412tV++IUgFlUy4n6kHBL0v15La7L5NgZTA9eSL6Ts mmrw== X-Forwarded-Encrypted: i=1; AJvYcCWaFXmDXJGsUn4nngkBlHfJvpElFPuuCANqtNMnl9dYegVZkVMlgdZmz9P7FpTLnP6Lh+kNyWuQ1cDGL+c=@vger.kernel.org X-Gm-Message-State: AOJu0YypkhuQ7IDt4X0cKgaYm3igUoTQxqnltNG3cfqR8Z4Y6DKaxJAj fPcCbtpKwcFaPh6Kkr6U28oWULLaeLYHAnM8qbucgaJFdKtNdUxjjIudyzNqIgS53lc= X-Gm-Gg: AZuq6aJArnTJpdfryBROIw8zjDgs7xy75vOWzya85YdHx8FAdMhF7yqNAWZFiiBoze4 HytuX1pgblZvIoxurEHNBgOh9xZ7LWCxAV3uULO9U2J0sy+SWHOBdFPMKDyqHMMX9WTYmizF5Pc fZy+K0R6cjej7tRDBdFSftdfulv5J0+9A8vr5PRXiWek3fez1aKDXROy5wU3EzAjO7ebhX1uaG4 4YzSCRqLBGV6aw0f8XK2+e9utrD0WBE+jfeWNBNs/MweUCi7Or8wchb8EqjbLLk6973gqoFdMbz 9PzntdP20PLJ1LrTvFC9bYRvBLU/HINauXGJs+8xRmOdRgaNlae0upfV8aoBKm4EmQ75iK/Pmjq 49shFAhs+BR2kL1zU3jvkvVQypoH01/7N2X+2Ei68DoktcNQ+0EqyEAvhqTjz4i/BHgfmLh7ZEi Lga0+ZVFB5bXd7dy1QnFJjvxT7CA== X-Received: by 2002:a05:6a21:4916:b0:38b:ebdd:919f with SMTP id adf61e73a8af0-394671145b5mr13583057637.1.1771350471095; Tue, 17 Feb 2026 09:47:51 -0800 (PST) Received: from p14s ([2604:3d09:148c:c800:970a:754:4a36:44d0]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c6e5331ba14sm10310210a12.29.2026.02.17.09.47.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Feb 2026 09:47:50 -0800 (PST) Date: Tue, 17 Feb 2026 10:47:46 -0700 From: Mathieu Poirier To: Steven Price Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, Catalin Marinas , Marc Zyngier , Will Deacon , James Morse , Oliver Upton , Suzuki K Poulose , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , "Aneesh Kumar K . V" , Emi Kisanuki , Vishal Annapurve Subject: Re: [PATCH v12 00/46] arm64: Support for Arm CCA in KVM Message-ID: References: <20251217101125.91098-1-steven.price@arm.com> <55fc4877-666c-4d5f-a167-5692f7cfbd0b@arm.com> <9140efaa-dc54-4a1b-8936-3ef876ca9121@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9140efaa-dc54-4a1b-8936-3ef876ca9121@arm.com> On Mon, Feb 16, 2026 at 02:27:02PM +0000, Steven Price wrote: > 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); That also worked on my side. > > 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. > Very well. Thanks for looking into this. > Steve >