On Wed, 21 Oct 2026 20:39:09 -0300 Jason Gunthorpe <[email protected]> wrote:
> On Wed, Oct 21, 2026 at 11:11:15AM -0700, Jonathan Cameron wrote: > > On Fri, 2 Oct 2026 20:31:52 -0300 > > Jason Gunthorpe <[email protected]> wrote: > > > > > Provide an implementation of the CONFIG_EFI_STUB_DRTM protocol for ARM64 > > > DEN0113 >= v1.1. > > > > > > First, it queries the FW for support and collects all the > > > information. This is needed to compute the extra_size, which comes > > > from FW reporting how much memory it needs during the launch for the > > > DLME Data and DCE-owned data. The generic stub ensures there is > > > trailing memory after Image for this. > > > > > > Then the DRTM_PARAMETERS launch structure is computed using the > > > offsets in the efi_info. > > > > > > Finally, the stub does ExitBootServices and calls the actual launch. > > > > > > The feature discovery process is deliberately fairly verbose to help > > > debug any FW weirdness in the field. Enable it with efi=debug > > > > > > It looks something like: > > > > > > EFI stub: DRTM: interface version 1.4 > > > EFI stub: DEBUG: DRTM: TPM algorithm 0xc, TPM hashing unavailable, PCR > > > schemas 0x1 > > > EFI stub: DEBUG: DRTM: minimum DLME data 73728 bytes, Normal-world DCE 0 > > > bytes > > > EFI stub: Decompressing Linux Kernel... > > > EFI stub: Generating empty DTB > > > EFI stub: Exiting boot services... > > > EFI stub: DEBUG: DRTM: will launch, selected launch features 0x0 > > > [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x000f0510] > > > > > > Eventually the launch'd kernel is going to require built in crypto > > > libraries that match what the FW is using so it can validate some of the > > > information left behind during early boot. Refuse to launch if these are > > > not built in and build in the most common ones from the ARM64_DRTM > > > kconfig. > > > > > > One nit, if the platform does not support SMC then using drtm=auto may > > > crash on the SMC op. As far as I can tell there is no way to discover SMC > > > support through EFI. Learning it from the ACPI FADT is doable and costs > > > about 250 lines of code. > > > > Ouch. Sounds like a must have if there is no easier way. > > Yeah, maybe so. I will include the patch in the next version. Though > I'm not keen on it and I don't know very much about ACPI. > > > > +/* True if SMCCC 1.0 or later is available. */ > > > +static bool efi_arm64_psci_smccc_compatible(void) > > > +{ > > > + struct arm_smccc_res res; > > > + s32 status; > > > + > > > + arm_smccc_1_1_smc(PSCI_0_2_FN_PSCI_VERSION, &res); > > > > A function that is meant to check for smccc 1.0 is using the > > smccc_1_1 namespaced calls? Maybe add a comment on why that > > is ok to do. Is anyone actually using SMCCC 1.0 on systems like this? > > This is a good point, I didn't quite get all these details at the > time, but yeah, technically we have to use the 1.0 calling convention > due the register clobber differnces. The other reason is we can't use > the kernels 1.0 helper since it is an asm function not an assembly.. > > Fixing everything I came with this: > > /* > * Discovery must tolerate SMCCC 1.0 clobbering x0-x17. The EFI stub cannot > * call the kernel's out-of-line SMCCC helper, so issue these calls inline. > */ > static u32 efi_arm64_smc_1_0(u32 function, u32 arg) > { > register unsigned long x0 asm("x0") = function; > register unsigned long x1 asm("x1") = arg; > > asm volatile("smc #0" > : "+r" (x0), "+r" (x1) > : > : "x2", "x3", "x4", "x5", "x6", "x7", "x8", "x9", > "x10", "x11", "x12", "x13", "x14", "x15", "x16", > "x17", "cc", "memory"); > > return x0; > } > > /* True if SMCCC 1.1 or later in the 1.x series is available. */ > static bool efi_arm64_psci_smccc_compatible(void) > { > u32 version; > s32 status; > > version = efi_arm64_smc_1_0(PSCI_0_2_FN_PSCI_VERSION, 0); > if ((s32)version < 0) > return false; > > if (PSCI_VERSION_MAJOR(version) < 1) > return false; > > status = efi_arm64_smc_1_0(PSCI_1_0_FN_PSCI_FEATURES, > ARM_SMCCC_VERSION_FUNC_ID); > if (status < 0) > return false; > > version = efi_arm64_smc_1_0(ARM_SMCCC_VERSION_FUNC_ID, 0); > return (version >> 16) == 1 && version >= ARM_SMCCC_VERSION_1_1; > } > > efistub can get away with this inline asm since it isn't 32 bit and it > doesn't deal with quirks. Smells plausible to me. > > > I a bit surprised we don't have a common helper for this - > > I guess the version checks are often explicit in a particular > > driver being bound. > > The PSCI stuff in the kernel is all very early when establishing what > the channel is and is done only once. Here is a bit different > since we only accept the smc instruction used by drtm.. > > And even if there was a helper we can't really call it from zboot.. True enough. I was just hoping there was code to compare this with :) > > Thanks, > Jason
