Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750954AbcCFDff (ORCPT ); Sat, 5 Mar 2016 22:35:35 -0500 Received: from mail-ig0-f172.google.com ([209.85.213.172]:33960 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750940AbcCFDfd (ORCPT ); Sat, 5 Mar 2016 22:35:33 -0500 MIME-Version: 1.0 In-Reply-To: <1455712566-16727-10-git-send-email-matt@codeblueprint.co.uk> References: <1455712566-16727-1-git-send-email-matt@codeblueprint.co.uk> <1455712566-16727-10-git-send-email-matt@codeblueprint.co.uk> Date: Sun, 6 Mar 2016 04:35:32 +0100 Message-ID: Subject: Re: [PATCH 09/13] efi/arm64: Check for h/w support before booting a >4 KB granule kernel From: Ard Biesheuvel To: Matt Fleming , Ingo Molnar Cc: Thomas Gleixner , "H . Peter Anvin" , "linux-kernel@vger.kernel.org" , "linux-efi@vger.kernel.org" , Jeremy Linton , Mark Rutland , Suzuki K Poulose Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2739 Lines: 70 On 17 February 2016 at 13:36, Matt Fleming wrote: > From: Ard Biesheuvel > > A kernel built with support for a page size that is not supported by the > hardware it runs on cannot boot to a state where it can inform the user > about it. > > If we happen to be booting via UEFI, we can fail gracefully so check > if the currently configured page size is supported by the hardware before > entering the kernel proper. Note that UEFI mandates support for 4 KB pages, > so in that case, no check is needed. > > Reviewed-by: Jeremy Linton > Tested-by: Suzuki K Poulose > Signed-off-by: Ard Biesheuvel > Acked-by: Mark Rutland > Signed-off-by: Matt Fleming Hi Matt, This patch turned up in -next with 'granule' replaced with 'granular', both in the commit log and in the patch itself. The term 'granule' is part of the idiom used by the ARM Architecture Reference Manual, and so changing it silently to 'granular' is not entirely appropriate here (although harmless in practice, obviously). In general, I would appreciate it if in the future, such changes were not made silently somewhere in the merge pipeline. Thanks, Ard. > --- > drivers/firmware/efi/libstub/arm64-stub.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c > index 9e0342745e4f..aef04ad60e0d 100644 > --- a/drivers/firmware/efi/libstub/arm64-stub.c > +++ b/drivers/firmware/efi/libstub/arm64-stub.c > @@ -12,6 +12,26 @@ > #include > #include > #include > +#include > + > +efi_status_t check_platform_features(efi_system_table_t *sys_table_arg) > +{ > + u64 tg; > + > + /* UEFI mandates support for 4 KB granule, no need to check */ > + if (IS_ENABLED(CONFIG_ARM64_4K_PAGES)) > + return EFI_SUCCESS; > + > + tg = (read_cpuid(ID_AA64MMFR0_EL1) >> ID_AA64MMFR0_TGRAN_SHIFT) & 0xf; > + if (tg != ID_AA64MMFR0_TGRAN_SUPPORTED) { > + if (IS_ENABLED(CONFIG_ARM64_64K_PAGES)) > + pr_efi_err(sys_table_arg, "This 64 KB granule kernel is not supported by your CPU\n"); > + else > + pr_efi_err(sys_table_arg, "This 16 KB granule kernel is not supported by your CPU\n"); > + return EFI_UNSUPPORTED; > + } > + return EFI_SUCCESS; > +} > > efi_status_t handle_kernel_image(efi_system_table_t *sys_table_arg, > unsigned long *image_addr, > -- > 2.6.2 >