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=-8.3 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 C4A21C433FF for ; Mon, 12 Aug 2019 15:45:32 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9291D20679 for ; Mon, 12 Aug 2019 15:45:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="UaDx8fLk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9291D20679 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=xf0L4ICCNBul0VQ8kH/O1sHRk7aFAs/qYUmE+L8tcho=; b=UaDx8fLk6tC/b8vtoyL+bl2RH OXwEDreX2KEhv6MxJL7GM9VqlyHk8pDqJUSYBd1m3Ueb4jT5lDypCOuHTAFVGw1rvMLasFSXCjK9l arErksOAXD194PLZZGr12gf7A9WrwXumv3VFYyYl1OTUFVEnIkDlurA+aU5HGu6rwo2TBpUNP7nsi yjXvf0EaM7p3bhQ9TwxFOylwLp9Ix6D6J1XzzgMJhkOisskfxA7c4KrB9Nd6SyQel//V2dHh99qcy U1pzBA6WBDNZWPFDCwn0YVqrHvhL5mh2Y1i04tVNDyGYuNjZOgrO6PXTUk+9DD56DCldLMjAu6jID /FLlE31Yg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hxCVn-00054S-OJ; Mon, 12 Aug 2019 15:45:31 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hxCVk-000548-Qn for linux-arm-kernel@lists.infradead.org; Mon, 12 Aug 2019 15:45:30 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1130F15A2; Mon, 12 Aug 2019 08:45:27 -0700 (PDT) Received: from [10.37.8.210] (unknown [10.37.8.210]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 045713F718; Mon, 12 Aug 2019 08:45:25 -0700 (PDT) Subject: Re: [PATCH] arm64: cpufeature: Don't treat granule sizes as strict To: will@kernel.org, linux-arm-kernel@lists.infradead.org References: <20190812150225.25386-1-will@kernel.org> From: Suzuki K Poulose Message-ID: Date: Mon, 12 Aug 2019 16:48:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20190812150225.25386-1-will@kernel.org> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190812_084528_958031_4DE01130 X-CRM114-Status: GOOD ( 25.65 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, khilman@baylibre.com, catalin.marinas@arm.com, maz@kernel.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Will, On 08/12/2019 04:02 PM, Will Deacon wrote: > 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. Treat the granule fields as non-strict and let Kevin run > without a tainted kernel. I think it may be a good idea to mention the "KVM sanitised feature reg" feature as a pre-req for KVM safety in the comment section to alert people backporting this commit to older kernels. > > Cc: Mark Rutland > Cc: Marc Zyngier > Cc: Suzuki Poulose > Cc: Catalin Marinas > Reported-by: Kevin Hilman > Signed-off-by: Will Deacon > --- > 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 d19d14ba9ae4..b1fdc486aed8 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), Eitherway, Acked-by: Suzuki K Poulose _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel