Re: [PATCH v4 00/15] arm64: Support for running as a guest in Arm CCA
From: Steven Price <steven.price@arm.com>
Date: 2024-08-16 16:06:29
Also in:
kvm, kvmarm, linux-coco, lkml
On 15/08/2024 23:16, Shanker Donthineni wrote:
Hi Steven, On 7/12/24 03:54, Matias Ezequiel Vara Larsen wrote:quoted
On Mon, Jul 01, 2024 at 10:54:50AM +0100, Steven Price wrote:quoted
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/v4Which 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