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=-4.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 15C18C433DB for ; Thu, 4 Feb 2021 12:28:10 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 AC0CC64F53 for ; Thu, 4 Feb 2021 12:28:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC0CC64F53 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+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=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:To:From: Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=MAXwHF0GLonAcZXJ3pwZU++rvcUufB04OfLwxDGpTSQ=; b=YeeqlNoqLtZ6muV5dreAhgrVx 9iTg/PSSfki67cgNeP4Pi6/vxm1LWvSwKNHe77SutZ5Uwh24Mr4ld+sDhm41ZlHqZzyLKQ2oEzNTA AsKzf9M/Ks9WRw2IVLaw7IiLj//Mpx12OxlUv2BkyCkOJD5AwfyHMxuhpYniD3Zmz4kRDCxfwOYFC DzR3wz94eBHfcroP4F2jISFsDk9ztlMtKfmSMnOr+7X+cULwCZemt1SWEF+jMRANXeQRlhZvIgoRa q8Pn+3tL26wnr8t1iNlPbh9Etx2X5L7fDauqSwcb99EApXpzbjVL105OEtZPZynVyO0oukx/qx+Mv 9Ly5CEqkg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7dil-0008Ew-88; Thu, 04 Feb 2021 12:26:51 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l7dii-0008EZ-8T for linux-arm-kernel@lists.infradead.org; Thu, 04 Feb 2021 12:26:49 +0000 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9258F64F53; Thu, 4 Feb 2021 12:26:46 +0000 (UTC) Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1l7die-00C0QN-4h; Thu, 04 Feb 2021 12:26:44 +0000 MIME-Version: 1.0 Date: Thu, 04 Feb 2021 12:26:44 +0000 From: Marc Zyngier To: Ard Biesheuvel Subject: Re: next/master bisection: baseline.login on rk3288-rock2-square In-Reply-To: References: <601b773a.1c69fb81.9f381.a32a@mx.google.com> <6c65bcef-d4e7-25fa-43cf-2c435bb61bb9@collabora.com> <20210204100601.GT1463@shell.armlinux.org.uk> <20210204104714.GU1463@shell.armlinux.org.uk> User-Agent: Roundcube Webmail/1.4.10 Message-ID: <090003e6f825de1f8460c0e987e14577@kernel.org> X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: ardb@kernel.org, linux@armlinux.org.uk, guillaume.tucker@collabora.com, geert+renesas@glider.be, linux-kernel@vger.kernel.org, linus.walleij@linaro.org, linux-arm-kernel@lists.infradead.org, nico@fluxnic.net, kernelci-results@groups.io X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210204_072648_509226_500B6496 X-CRM114-Status: GOOD ( 28.27 ) 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: kernelci-results@groups.io, Geert Uytterhoeven , Nicolas Pitre , Guillaume Tucker , Linus Walleij , Russell King - ARM Linux admin , Linux Kernel Mailing List , Linux ARM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2021-02-04 10:55, Ard Biesheuvel wrote: > (cc Marc) > > On Thu, 4 Feb 2021 at 11:48, Russell King - ARM Linux admin > wrote: >> >> On Thu, Feb 04, 2021 at 11:27:16AM +0100, Ard Biesheuvel wrote: >> > Hi Russell, >> > >> > If Guillaume is willing to do the experiment, and it fixes the issue, >> > it proves that rk3288 is relying on the flush before the MMU is >> > disabled, and so in that case, the fix is trivial, and we can just >> > apply it. >> > >> > If the experiment fails (which would mean rk3288 does not tolerate the >> > cache maintenance being performed after cache off), it is going to be >> > hairy, and so it will definitely take more time. >> > >> > So in the latter case (or if Guillaume does not get back to us), I >> > think reverting my queued fix is the only sane option. But in that >> > case, may I suggest that we queue the revert of the original by-VA >> > change for v5.12 so it gets lots of coverage in -next, and allows us >> > an opportunity to come up with a proper fix in the same timeframe, and >> > backport the revert and the subsequent fix as a pair? Otherwise, we'll >> > end up in the situation where v5.10.x until today has by-va, v5.10.x-y >> > has set/way, and v5.10y+ has by-va again. (I don't think we care about >> > anything before that, given that v5.4 predates any of this) >> >> I'm suggesting dropping your fix (9052/1) and reverting >> "ARM: decompressor: switch to by-VA cache maintenance for v7 cores" >> which gets us to a point where _both_ regressions are fixed. >> > > I understand, but we don't know whether doing so might regress other > platforms that were added in the mean time. > >> I'm of the opinion that the by-VA patch was incorrect when it was >> merged (it caused a regression), and it's only a performance >> improvement. > > It is a correctness improvement, not a performance improvement. > > Without that change, the 32-bit ARM kernel cannot boot bare metal on > platforms with a system cache such as 8040 or SynQuacer, and can only > boot under KVM on such systems because of the special handling of > set/way instructions by the host. I agree. With set/way CMOs, there is no way to reach the PoC if it beyond the system cache, leading to an unbootable kernel. This is actually pretty well documented in the architecture, and it did bite us for the first time on XGene-1, 7 years ago. In retrospect, having KVM to handle set/way CMOs in was a mistake, as it just papered over the problem for the sake of running older 32bit guests. It violated the principle of KVM/arm being strictly architectural and provided unrealistic expectations. I'll take the blame for this. Thanks, M. -- Jazz is not dead. It just smells funny... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel