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 X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C818CC3A589 for ; Tue, 20 Aug 2019 13:41:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9DE8F22DBF for ; Tue, 20 Aug 2019 13:41:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566308511; bh=DDdouO8ebmkeL/1cMnnHpfKGuqbIm3aGqks+TdEDb60=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=MwuG+KiMuVlaly5HQoQy+4v6AjgiMzXqP5Vvw8TSyvc2m4yd4e3yC482H8j+B1U+B vpahe2ACJ/LslQAdSa+1CNHZZFSM2887E0E0l8/2c6KGUC7XIeAe9l/OLEeGcrTA79 NY7vsiMArVKrrdbXhqZ+i6NUNQpJTBintu6xQTWU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730483AbfHTNlv (ORCPT ); Tue, 20 Aug 2019 09:41:51 -0400 Received: from mail.kernel.org ([198.145.29.99]:36922 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730463AbfHTNls (ORCPT ); Tue, 20 Aug 2019 09:41:48 -0400 Received: from sasha-vm.mshome.net (unknown [12.236.144.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 65B2022DA7; Tue, 20 Aug 2019 13:41:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566308507; bh=DDdouO8ebmkeL/1cMnnHpfKGuqbIm3aGqks+TdEDb60=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=2SC6Mnq68OfuJKz8BCmYLoEC3Ok3vRmD46W3bFoBBTUum7q5MDOB8Kktf1lFOnva7 Jc9HW4X6vv5fthQia9RU1YbNzt6qdCuWOHLmjxhAAYAqftWVrtY1J37SRoeeNAGT0I yqE+ecGivGveTtVO5jZng2OJUUl7tV3HcH2HJYtU= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Will Deacon , Marc Zyngier , Kevin Hilman , Mark Rutland , Suzuki K Poulose , Catalin Marinas , Sasha Levin Subject: [PATCH AUTOSEL 5.2 36/44] arm64: cpufeature: Don't treat granule sizes as strict Date: Tue, 20 Aug 2019 09:40:20 -0400 Message-Id: <20190820134028.10829-36-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190820134028.10829-1-sashal@kernel.org> References: <20190820134028.10829-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Will Deacon [ Upstream commit 5717fe5ab38f9ccb32718bcb03bea68409c9cce4 ] If a CPU doesn't support the page size for which the kernel is configured, then we will complain and refuse to bring it online. For secondary CPUs (and the boot CPU on a system booting with EFI), we will also print an error identifying the mismatch. Consequently, the only time that the cpufeature code can detect a granule size mismatch is for a granule other than the one that is currently being used. Although we would rather such systems didn't exist, we've unfortunately lost that battle and Kevin reports that on his amlogic S922X (odroid-n2 board) we end up warning and taining with defconfig because 16k pages are not supported by all of the CPUs. In such a situation, we don't actually care about the feature mismatch, particularly now that KVM only exposes the sanitised view of the CPU registers (commit 93390c0a1b20 - "arm64: KVM: Hide unsupported AArch64 CPU features from guests"). Treat the granule fields as non-strict and let Kevin run without a tainted kernel. Cc: Marc Zyngier Reported-by: Kevin Hilman Tested-by: Kevin Hilman Acked-by: Mark Rutland Acked-by: Suzuki K Poulose Signed-off-by: Will Deacon [catalin.marinas@arm.com: changelog updated with KVM sanitised regs commit] Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin --- arch/arm64/kernel/cpufeature.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c index ae63eedea1c12..68faf535f40a3 100644 --- a/arch/arm64/kernel/cpufeature.c +++ b/arch/arm64/kernel/cpufeature.c @@ -184,9 +184,17 @@ static const struct arm64_ftr_bits ftr_id_aa64zfr0[] = { }; static const struct arm64_ftr_bits ftr_id_aa64mmfr0[] = { - S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI), - S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI), - ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI), + /* + * We already refuse to boot CPUs that don't support our configured + * page size, so we can only detect mismatches for a page size other + * than the one we're currently using. Unfortunately, SoCs like this + * exist in the wild so, even though we don't like it, we'll have to go + * along with it and treat them as non-strict. + */ + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN4_SHIFT, 4, ID_AA64MMFR0_TGRAN4_NI), + S_ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN64_SHIFT, 4, ID_AA64MMFR0_TGRAN64_NI), + ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_TGRAN16_SHIFT, 4, ID_AA64MMFR0_TGRAN16_NI), + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_BIGENDEL0_SHIFT, 4, 0), /* Linux shouldn't care about secure memory */ ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64MMFR0_SNSMEM_SHIFT, 4, 0), -- 2.20.1