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=-7.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS 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 66744C433E0 for ; Mon, 6 Jul 2020 12:28:39 +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 36DD9206E6 for ; Mon, 6 Jul 2020 12:28:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="P8GEjPWr"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="ndMC1fd0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36DD9206E6 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=sEyveGBfuCHxqfJupfWbEWwtBXbCmMwAcuev0JFJ1QU=; b=P8GEjPWr+M1YCpLp8M2IbTnpA G5jHIPesKZsnFVP6GSOM2YICPvzvS7pQknQSwcqnQDRyXNv5KnY+MI16GTm96R/p5CMuvn1XHIXm6 LRSJvWX8pJtnQJLYF1ctQRZs1ZckOQ6Kc26Z4iFkl6WjW69jGZKcwZUSyS/zatvEBU2gtBs4YXgmR /ErJ6sIrP5QaTQICFfYlyEZwDFYaR7Dxi3t805fJjWJmfJzpS+jaceSCzOEizbJAg3UgCfbPVyq+L YaeMb0F7RCIto+D3oEDvLnKyFbSAzvdCCmpHDfl5B9jIag6lQllfRtnsFC4yaIu27LvrOharzkYhh fp7giFE6A==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jsQDQ-0006uZ-Tt; Mon, 06 Jul 2020 12:27:20 +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 1jsQDO-0006uC-QI for linux-arm-kernel@lists.infradead.org; Mon, 06 Jul 2020 12:27:19 +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 0ABDF206E6; Mon, 6 Jul 2020 12:27:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594038438; bh=Pu5XZ1xsfw61RzFfsAzWnkshXIf28pMpyecgrXGMTTQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ndMC1fd0RTmrHRnEtNFdlhTlT76Lu9gJA1/Sg0JJbXC4P2IjF4MGaZaBxWh38j912 hyd7xsz2qfc38wHtiRdvhlqUU46K/zt/fcYMcKY8XYYTQ1IyS+7aB7NrgkcU3YAudz abharqSTqkqvFLvS3P2hRlQapz7DLNDZG0D1PEVw= Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jsQDM-009RiM-ED; Mon, 06 Jul 2020 13:27:16 +0100 MIME-Version: 1.0 Date: Mon, 06 Jul 2020 13:27:16 +0100 From: Marc Zyngier To: Will Deacon Subject: Re: Query regarding ERRATUM_1418040 In-Reply-To: <20200706120946.GA23341@willie-the-truck> References: <1ce7dad5-a981-5968-cc34-7648faea8636@codeaurora.org> <062be27686369d28bd2054a54c307400@misterjones.org> <20200617112542.GB3503@willie-the-truck> <20200701162731.GA15317@willie-the-truck> <4196efaea5fbdf11dd6fa3ba460967d3@kernel.org> <20200706120946.GA23341@willie-the-truck> User-Agent: Roundcube Webmail/1.4.5 Message-ID: X-Sender: maz@kernel.org X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: will@kernel.org, neeraju@codeaurora.org, linux-arm-kernel@lists.infradead.org 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-20200706_082718_997806_FF00AB74 X-CRM114-Status: GOOD ( 34.46 ) 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: Neeraj Upadhyay , linux-arm-kernel@lists.infradead.org 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 2020-07-06 13:09, Will Deacon wrote: > On Thu, Jul 02, 2020 at 09:19:04AM +0100, Marc Zyngier wrote: >> On 2020-07-01 17:27, Will Deacon wrote: >> > On Wed, Jun 17, 2020 at 03:29:46PM +0100, Marc Zyngier wrote: >> > > On 2020-06-17 12:25, Will Deacon wrote: >> > > > Hmm, but in conjunction with the previous point, doesn't this mean if >> > > > some CPUs are affected by an erratum which requires CNTVCT trapping for >> > > > AArch64 and others are affected by 1418040, then the former won't >> > > > actually >> > > > be trapped? >> > > >> > > Indeed. Having CPUs that require opposite workarounds is one of the >> > > many >> > > fascinating aspects of BL systems... :-/ Does such a system exist >> > > today? >> > >> > I don't know, but it feels like we should either address the issue of >> > scream >> > loudly if we detect it! >> >> I have no idea how you plan to detect that. > > You'd end up having to have workarounds know about each other and, yes, > it would be awful. > >> > I think re-enabling on entry from a 32-bit task would be the easiest >> > thing to >> > do. Since you're playing with 32-bit timer bugs atm, do you fancy taking >> > a >> > look ;) >> >> I came up with this, tested in a guest only by fudging the detection >> code (I don't have the offending HW at hand). The use of branches vs >> NOPs is debatable, no strong opinion here. >> >> M. >> >> From 81126933d6c990dac7213d0ec66c4a9df21fe8b8 Mon Sep 17 00:00:00 2001 >> From: Marc Zyngier >> Date: Wed, 1 Jul 2020 21:29:24 +0100 >> Subject: [PATCH] arm64: Rework ARM_ERRATUM_1414080 handling >> >> The current handling of erratum 1414080 has the side effect that >> cntkctl_el1 can get changed for both 32 and 64bit tasks. >> >> This isn't a problem so far, but if we ever need to mitigate another >> of these errata on the 64bit side, we'd better keep the messing with >> cntkctl_el1 local to 32bit tasks. >> >> For that, make sure that on entering the kernel from a 32bit tasks, >> userspace access to cntvct gets enabled, and disabled returning to >> userspace, while it never gets changed for 64bit tasks. >> >> Signed-off-by: Marc Zyngier >> --- >> arch/arm64/kernel/entry.S | 44 >> +++++++++++++++++++++++++-------------- >> 1 file changed, 28 insertions(+), 16 deletions(-) > > Mostly looks fine, just some small nits below. Looking at it now, > though, > I suspect it would make more sense to do this at context-switch. We can > do that later on. > >> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S >> index 5304d193c79d..357bce62c31e 100644 >> --- a/arch/arm64/kernel/entry.S >> +++ b/arch/arm64/kernel/entry.S >> @@ -167,6 +167,19 @@ alternative_cb_end >> stp x28, x29, [sp, #16 * 14] >> >> .if \el == 0 >> + .if \regsize == 32 >> + // If we come back from a 32bit task on a system affected by >> + // 1418040, let's reenable userspace access to the virtual counter. >> +#ifdef CONFIG_ARM64_ERRATUM_1418040 >> +alternative_if_not ARM64_WORKAROUND_1418040 >> + b .L__entry_wa_1418040\@ >> +alternative_else_nop_endif >> + mrs x0, cntkctl_el1 >> + orr x0, x0, #2 // ARCH_TIMER_USR_VCT_ACCESS_EN >> + msr cntkctl_el1, x0 >> +.L__entry_wa_1418040\@: > > nit: naming this .L__entry_skip_wa_1418040\@ would be clearer to me, > as we take the branch to jump over the workaround. Indeed. >> +#endif >> + .endif >> clear_gp_regs >> mrs x21, sp_el0 >> ldr_this_cpu tsk, __entry_task, x20 >> @@ -318,7 +331,21 @@ alternative_else_nop_endif >> ldr x23, [sp, #S_SP] // load return stack pointer >> msr sp_el0, x23 >> tst x22, #PSR_MODE32_BIT // native task? >> - b.eq 3f >> + b.eq 4f >> + >> +#ifdef CONFIG_ARM64_ERRATUM_1418040 >> +alternative_if_not ARM64_WORKAROUND_1418040 >> + b 3f >> +alternative_else_nop_endif >> + /* >> + * if (x22.mode32 == 1) >> + * cntkctl_el1.el0vcten = 0 >> + */ > > I think we can probably drop this comment now, as I find it more > confusing > that helpful. > >> + mrs x1, cntkctl_el1 >> + bfi x1, xzr, #1, #1 // ARCH_TIMER_USR_VCT_ACCESS_EN > > Can you use BIC here? You wish. Turns out that BIC is labelled as a v8.2 instruction, even if is just yet another alias for BFM, and gas sends me packing if I dare using it. So the above BFI is a poor man's version of BIC. Which objdump happily disassembles as... BIC! Yes, this is all braindead. Anyway, I'll fix this up and repost it together with the rest of the vdso series. 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