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 0AFBAC531DC for ; Fri, 16 Aug 2024 16:07:22 +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:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=37iwFfT4oTeqzOLCcCdIP9vbzr7hKqdpOt9+xtjEsFA=; b=AtciK+4XrvLrAhpaTxyl2Fg2cs NmOQLV6Slhoru+yrBBtlIjYPqUIvWpAvJkm3Qk3r+YNvFROvaaAavOM4qx9xII4Xi9Ap3yH0Z0gti zB3Q+zv8Xm60ky2+o0wARCPWc0v+kDCY7x1Sv+PppLGNG1GxGFyCIVi2CdogfBQxRm2gPsKtafKSI 2txyndCGksU88il4wqF5mQsubV9WAhI7ajSW2l4msfRzEB5ln8DZE/zcBgViEeZNmOxFBXLxtwcJn U3GvPGIyJhzg+tXdnYse+wJnMuz7o91AS2ICezXZ2OYcSl50xOnmG1s6dWAAfiYtd1aLxdJWKqpKc wQgIiP6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sezTq-0000000DWRk-1aWw; Fri, 16 Aug 2024 16:07:10 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sezTB-0000000DWKw-2Smk for linux-arm-kernel@lists.infradead.org; Fri, 16 Aug 2024 16:06:31 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C928013D5; Fri, 16 Aug 2024 09:06:54 -0700 (PDT) Received: from [10.1.34.14] (e122027.cambridge.arm.com [10.1.34.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 44E003F58B; Fri, 16 Aug 2024 09:06:26 -0700 (PDT) Message-ID: <27c942e0-0e7c-4e71-b1df-1a8f70df5411@arm.com> Date: Fri, 16 Aug 2024 17:06:24 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 00/15] arm64: Support for running as a guest in Arm CCA To: Shanker Donthineni , Matias Ezequiel Vara Larsen 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 References: <20240701095505.165383-1-steven.price@arm.com> <09fdebd7-32a0-4a88-9002-0f24eebe00a8@nvidia.com> From: Steven Price Content-Language: en-GB In-Reply-To: <09fdebd7-32a0-4a88-9002-0f24eebe00a8@nvidia.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240816_090629_756923_2FEC08E3 X-CRM114-Status: GOOD ( 27.91 ) 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 15/08/2024 23:16, Shanker Donthineni wrote: > Hi Steven, > > On 7/12/24 03:54, Matias Ezequiel Vara Larsen wrote: >> On Mon, Jul 01, 2024 at 10:54:50AM +0100, Steven Price wrote: >>> This series adds support for running Linux in a protected VM under the >>> Arm Confidential Compute Architecture (CCA). This has been updated >>> following the feedback from the v3 posting[1]. Thanks for the feedback! >>> Individual patches have a change log. But things to highlight: >>> >>>   * a new patch ("firmware/psci: Add psci_early_test_conduit()") to >>>     prevent SMC calls being made on systems which don't support them - >>>     i.e. systems without EL2/EL3 - thanks Jean-Philippe! >>> >>>   * two patches dropped (overriding set_fixmap_io). Instead >>>     FIXMAP_PAGE_IO is modified to include PROT_NS_SHARED. When support >>>     for assigning hardware devices to a realm guest is added this will >>>     need to be brought back in some form. But for now it's just adding >>>     complixity and confusion for no gain. >>> >>>   * a new patch ("arm64: mm: Avoid TLBI when marking pages as valid") >>>     which avoids doing an extra TLBI when doing the break-before-make. >>>     Note that this changes the behaviour in other cases when making >>>     memory valid. This should be safe (and saves a TLBI for those >>> cases), >>>     but it's a separate patch in case of regressions. >>> >>>   * GIC ITT allocation now uses a custom genpool-based allocator. I >>>     expect this will be replaced with a generic way of allocating >>>     decrypted memory (see [4]), but for now this gets things working >>>     without wasting too much memory. >>> >>> The ABI to the RMM from a realm (the RSI) is based on the final RMM v1.0 >>> (EAC 5) specification[2]. Future RMM specifications will be backwards >>> compatible so a guest using the v1.0 specification (i.e. this series) >>> will be able to run on future versions of the RMM without modification. >>> >>> This series is based on v6.10-rc1. It is also available as a git >>> repository: >>> >>> https://gitlab.arm.com/linux-arm/linux-cca cca-guest/v4 > > Which cca-host branch should I use for testing cca-guest/v4? > > I'm getting compilation errors with cca-host/v3 and cca-guest/v4, is there > any known WAR or fix to resolve this issue? cca-host/v3 should work with cca-guest/v4. I've been working on rebasing/updating the branches and should be able to post v4/v5 series next week. > > arch/arm64/kvm/rme.c: In function ‘kvm_realm_reset_id_aa64dfr0_el1’: > ././include/linux/compiler_types.h:487:45: error: call to > ‘__compiletime_assert_650’ declared with attribute error: FIELD_PREP: > value too large for the field >   487 |         _compiletime_assert(condition, msg, > __compiletime_assert_, __COUNTER__) >       |                                             ^ > ././include/linux/compiler_types.h:468:25: note: in definition of macro > ‘__compiletime_assert’ >   468 |                         prefix ## > suffix();                             \ >       |                         ^~~~~~ > ././include/linux/compiler_types.h:487:9: note: in expansion of macro > ‘_compiletime_assert’ >   487 |         _compiletime_assert(condition, msg, > __compiletime_assert_, __COUNTER__) >       |         ^~~~~~~~~~~~~~~~~~~ > ./include/linux/build_bug.h:39:37: note: in expansion of macro > ‘compiletime_assert’ >    39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), > msg) >       |                                     ^~~~~~~~~~~~~~~~~~ > ./include/linux/bitfield.h:68:17: note: in expansion of macro > ‘BUILD_BUG_ON_MSG’ >    68 |                 BUILD_BUG_ON_MSG(__builtin_constant_p(_val) > ?           \ >       |                 ^~~~~~~~~~~~~~~~ > ./include/linux/bitfield.h:115:17: note: in expansion of macro > ‘__BF_FIELD_CHECK’ >   115 |                 __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: > ");    \ >       |                 ^~~~~~~~~~~~~~~~ > arch/arm64/kvm/rme.c:315:16: note: in expansion of macro ‘FIELD_PREP’ >   315 |         val |= FIELD_PREP(ID_AA64DFR0_EL1_BRPs_MASK, bps - 1) | >       |                ^~~~~~~~~~ > make[5]: *** [scripts/Makefile.build:244: arch/arm64/kvm/rme.o] Error 1 > make[4]: *** [scripts/Makefile.build:485: arch/arm64/kvm] Error 2 > make[3]: *** [scripts/Makefile.build:485: arch/arm64] Error 2 > make[3]: *** Waiting for unfinished jobs.... > > I'm using gcc-13.3.0 compiler and cross-compiling on X86 machine. I'm not sure quite how this happens. The 'value' (bps - 1) shouldn't be considered constant, so I don't see how the compiler has decided to complain here - the __builtin_constant_p() should really be evaluating to 0. The only thing I can think of is if the compiler has somehow determined that rmm_feat_reg0 is 0 - which in theory it could do if it knew that kvm_init_rme() cannot succeed (rmi_features() would never be called, so the variable will never be set). Which makes me wonder if you're building with a PAGE_SIZE other than 4k? Obviously the code should still build if that's the case (so this would be a bug) but we don't currently support CCA with PAGE_SIZE != 4k. Steve