From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A6CE1CEF14D for ; Tue, 8 Oct 2024 11:07:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=wxNxFS3ZbI3W4kQXbO0lCunpQ22o9dZ3gjnqPR7i4vQ=; b=TE5Gk8U4AUND71DuNzO8nSX3By CvyQKQSWcnczD3uydgTho6fE0zC8oRXvkK2eHERys5IE76HHEqLktDfmEFo41RA6mPIEBOmP1k72d VYT3kbcxZKCqLNO8MPMc14bMR+lfpbSJvFhgL2Xrbzf+aYB1m2jt7GWpmMJK8E2RIUj1jAD8oOO53 Kb14yKaDsA1vfMYdyeWjK03JjGQybhn6u9YG05ijfdwTdqypztxSUiYhFbm2Jc9JemUr5URbQYNry mMkQRHFJVVsiDbAQEWRvN5BmMsBY6BrKy7uEVJ4M8OWfzw9pm1CFlCrLX6sUuA04CtLxgCn+OM5BP hqU9QTdg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1sy83o-00000005YZz-0v1u; Tue, 08 Oct 2024 11:07:24 +0000 Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1sy82D-00000005Y3x-1AYL for linux-arm-kernel@lists.infradead.org; Tue, 08 Oct 2024 11:05:55 +0000 Received: by mail-lj1-x22b.google.com with SMTP id 38308e7fff4ca-2fabb837ddbso75250811fa.1 for ; Tue, 08 Oct 2024 04:05:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1728385542; x=1728990342; darn=lists.infradead.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=wxNxFS3ZbI3W4kQXbO0lCunpQ22o9dZ3gjnqPR7i4vQ=; b=d8hlE6RedAig7SxomKS7AnZst3ihRNdUiTo8PBZl2+fyY2cwXSyxsnkQ/6otMcBnlJ mPJy68aDGI/VthjD2VW7F4U611/LUxN40zHNpTMQi5gAAgBuW0x4uF6vOlXoq2LOKODS IjTnivnfGTJD9NND3B6hW0bKEXw99AVrScJ+GWLrC87oeqRmxvQyK6vRgvZVbF62AtwE qFeWVonxBh+bOM2epIK01irfJyrOPgs3265k2mdee5pC+4CdKiStmKcmpB48cfdPXiVv E9JkJy7yuaIEqPK5HlfqcTzNHkEYTpbjKID1sfFqzjl6bqUJvox5rTnJHaaI/rONcvSI hAKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728385542; x=1728990342; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=wxNxFS3ZbI3W4kQXbO0lCunpQ22o9dZ3gjnqPR7i4vQ=; b=wmfo9pi7yxXU2vscETOUW1GhtVDASAitMbKGEGENaJ9aAfE6HQHK95J9uciayPNWkI 6MP389+eYIUgqJtKMUT72kQFrVib9dq/qJgdnFyxTHhDw70sf2PE3lTttFefqb9g7oyj cFFF1Pfz3Gdh9JneCmRGbhn88tvEPRtezFbQtgdec3nWTjo8nkVbNw8n1i6Q0RdR3hWB I4R/RenDP23rtLx6xQns1hfOEPKuOchHFgJUHZBH+drRv54mctCyPEIl1pbMkGPC268m m6gloHuH/W6Mzb/vDKbfPnbCD4xfBggwK+p8PbWz9ivTpO9aoAN9I5jZVUNDnsjfh4sV SoVQ== X-Forwarded-Encrypted: i=1; AJvYcCU/dZu2667zuE+gCDp92G4JJuDD5hdsNZ89MW2uaw5HIIPpuBXZVNAvhmJO13B33R/2uPsdArxkbtr8E0OgksVr@lists.infradead.org X-Gm-Message-State: AOJu0Yxed/C8ljENWDwpnue9Dk8UEpuX/GVHuxunUz84QXB+U5in+1hj dhBRsiDVT1kBnYTAYXjk0umcGUc07J3hPfDH/UQBt2DqCIdHvlYvhg5eZ/K3hPE= X-Google-Smtp-Source: AGHT+IFUUVsOSGGJPAphsOFCoHIZ+0khfsB4/lk7TDogJccRq5ZqzE4wbYgRX+9fbyD9s7dMaYkATg== X-Received: by 2002:a05:651c:2211:b0:2f0:27da:6864 with SMTP id 38308e7fff4ca-2faf3c1e75emr93401371fa.17.1728385529761; Tue, 08 Oct 2024 04:05:29 -0700 (PDT) Received: from myrica ([2.221.137.100]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a993d92ed5dsm434265866b.63.2024.10.08.04.05.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 08 Oct 2024 04:05:29 -0700 (PDT) Date: Tue, 8 Oct 2024 12:05:49 +0100 From: Jean-Philippe Brucker 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" Subject: Re: [PATCH v6 11/11] arm64: Document Arm Confidential Compute Message-ID: <20241008110549.GA1058742@myrica> References: <20241004144307.66199-1-steven.price@arm.com> <20241004144307.66199-12-steven.price@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241004144307.66199-12-steven.price@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241008_040545_404797_3EEAE9F3 X-CRM114-Status: GOOD ( 38.38 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 04, 2024 at 03:43:06PM +0100, Steven Price wrote: > Add some documentation on Arm CCA and the requirements for running Linux > as a Realm guest. Also update booting.rst to describe the requirement > for RIPAS RAM. > > Signed-off-by: Steven Price > --- > Documentation/arch/arm64/arm-cca.rst | 67 ++++++++++++++++++++++++++++ > Documentation/arch/arm64/booting.rst | 3 ++ > Documentation/arch/arm64/index.rst | 1 + > 3 files changed, 71 insertions(+) > create mode 100644 Documentation/arch/arm64/arm-cca.rst > > diff --git a/Documentation/arch/arm64/arm-cca.rst b/Documentation/arch/arm64/arm-cca.rst > new file mode 100644 > index 000000000000..ab7f90e64c2f > --- /dev/null > +++ b/Documentation/arch/arm64/arm-cca.rst > @@ -0,0 +1,67 @@ > +.. SPDX-License-Identifier: GPL-2.0 > + > +===================================== > +Arm Confidential Compute Architecture > +===================================== > + > +Arm systems that support the Realm Management Extension (RME) contain > +hardware to allow a VM guest to be run in a way which protects the code > +and data of the guest from the hypervisor. It extends the older "two > +world" model (Normal and Secure World) into four worlds: Normal, Secure, > +Root and Realm. Linux can then also be run as a guest to a monitor > +running in the Realm world. > + > +The monitor running in the Realm world is known as the Realm Management > +Monitor (RMM) and implements the Realm Management Monitor > +specification[1]. The monitor acts a bit like a hypervisor (e.g. it runs > +in EL2 and manages the stage 2 page tables etc of the guests running in > +Realm world), however much of the control is handled by a hypervisor > +running in the Normal World. The Normal World hypervisor uses the Realm > +Management Interface (RMI) defined by the RMM specification to request > +the RMM to perform operations (e.g. mapping memory or executing a vCPU). > + > +The RMM defines an environment for guests where the address space (IPA) > +is split into two. The lower half is protected - any memory that is > +mapped in this half cannot be seen by the Normal World and the RMM > +restricts what operations the Normal World can perform on this memory > +(e.g. the Normal World cannot replace pages in this region without the > +guest's cooperation). The upper half is shared, the Normal World is free > +to make changes to the pages in this region, and is able to emulate MMIO > +devices in this region too. > + > +A guest running in a Realm may also communicate with the RMM to request > +changes in its environment or to perform attestation about its > +environment. In particular it may request that areas of the protected > +address space are transitioned between 'RAM' and 'EMPTY' (in either > +direction). This allows a Realm guest to give up memory to be returned > +to the Normal World, or to request new memory from the Normal World. > +Without an explicit request from the Realm guest the RMM will otherwise > +prevent the Normal World from making these changes. We could mention that this interface is "RSI", so readers know what to look for next > + > +Linux as a Realm Guest > +---------------------- > + > +To run Linux as a guest within a Realm, the following must be provided > +either by the VMM or by a `boot loader` run in the Realm before Linux: > + > + * All protected RAM described to Linux (by DT or ACPI) must be marked > + RIPAS RAM before handing over the Linux. "handing control over to Linux", or something like that? > + > + * MMIO devices must be either unprotected (e.g. emulated by the Normal > + World) or marked RIPAS DEV. > + > + * MMIO devices emulated by the Normal World and used very early in boot > + (specifically earlycon) must be specified in the upper half of IPA. > + For earlycon this can be done by specifying the address on the > + command line, e.g.: ``earlycon=uart,mmio,0x101000000`` This is going to be needed frequently, so maybe we should explain in a little more detail how we come up with this value: "e.g. with an IPA size of 33 and the base address of the emulated UART at 0x1000000, ``earlycon=uart,mmio,0x101000000``" (Because the example IPA size is rather unintuitive and specific to the kvmtool memory map) Thanks, Jean > + > + * Linux will use bounce buffers for communicating with unprotected > + devices. It will transition some protected memory to RIPAS EMPTY and > + expect to be able to access unprotected pages at the same IPA address > + but with the highest valid IPA bit set. The expectation is that the > + VMM will remove the physical pages from the protected mapping and > + provide those pages as unprotected pages. > + > +References > +---------- > +[1] https://developer.arm.com/documentation/den0137/ > diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst > index b57776a68f15..30164fb24a24 100644 > --- a/Documentation/arch/arm64/booting.rst > +++ b/Documentation/arch/arm64/booting.rst > @@ -41,6 +41,9 @@ to automatically locate and size all RAM, or it may use knowledge of > the RAM in the machine, or any other method the boot loader designer > sees fit.) > > +For Arm Confidential Compute Realms this includes ensuring that all > +protected RAM has a Realm IPA state (RIPAS) of "RAM". > + > > 2. Setup the device tree > ------------------------- > diff --git a/Documentation/arch/arm64/index.rst b/Documentation/arch/arm64/index.rst > index 78544de0a8a9..12c243c3af20 100644 > --- a/Documentation/arch/arm64/index.rst > +++ b/Documentation/arch/arm64/index.rst > @@ -10,6 +10,7 @@ ARM64 Architecture > acpi_object_usage > amu > arm-acpi > + arm-cca > asymmetric-32bit > booting > cpu-feature-registers > -- > 2.34.1 > >