Message-ID: <aa9a6b53-cfc4-4010-83f5-ccfa396bb75f@nvidia.com>
Date: Fri, 16 Aug 2024 16:13:35 -0500
From: Shanker Donthineni <sdonthineni@...dia.com>
To: Steven Price <steven.price@....com>,
 Matias Ezequiel Vara Larsen <mvaralar@...hat.com>
Cc: kvm@...r.kernel.org, kvmarm@...ts.linux.dev,
 Catalin Marinas <catalin.marinas@....com>, Marc Zyngier <maz@...nel.org>,
 Will Deacon <will@...nel.org>, James Morse <james.morse@....com>,
 Oliver Upton <oliver.upton@...ux.dev>,
 Suzuki K Poulose <suzuki.poulose@....com>, Zenghui Yu
 <yuzenghui@...wei.com>, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, Joey Gouly <joey.gouly@....com>,
 Alexandru Elisei <alexandru.elisei@....com>,
 Christoffer Dall <christoffer.dall@....com>, Fuad Tabba <tabba@...gle.com>,
 linux-coco@...ts.linux.dev,
 Ganapatrao Kulkarni <gankulkarni@...amperecomputing.com>
Subject: Re: [PATCH v4 00/15] arm64: Support for running as a guest in Arm CCA



On 8/16/24 11:06, Steven Price wrote:
> External email: Use caution opening links or attachments
> 
> 
> 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.
> 

I've encountered this error multiple times with both 4K and 64K, but it's
currently not reproducible. I'll update if the issue reappears. In the
meantime, I've verified the host-v3 and guest-v4 patches using v6.11.rc3,
tested Realm boot, CCA-KVM-UNIT-TESTs, and normal VM boot (without CCA).
No issues have been observed.

Additionally, I've validated Realm and CCA-KVM-UNIT-TESTs on a host with
PSZ=64K. For testing purposes, I modified KVM64 and KVM-UNIT-TESTS to
support PSZ=64K.


Tested-by: Shanker Donthineni <sdonthineni@...dia.com>


> Steve
> 

Powered by blists - more mailing lists