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.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 06D38C07E95 for ; Tue, 13 Jul 2021 15:40:47 +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 C66B9610A6 for ; Tue, 13 Jul 2021 15:40:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C66B9610A6 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=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bFnFuZA/AjAFKOQUv31SpGMisnQ6YxAHp2YHuVqe93w=; b=2Uip1aRYnaLUF6 KhCYTjiwXUC4hFDTTTmebKPfM7Hh9ibMHLsdedDUR6Tk/vjNjMKPsz+4acBWPCNvHxsAj+O9ye06S W1MjVwk3Z6Ky5h+JCfP3G5xYeRJF5DCiHoFiFe2/B5sJMPJ+/r/gOISo4ObJ0abTocHuXOak6WOkK J/w/T4ssT45ugkub0/dxswyhDoON0mYhObvKKwG/ANtkYMBgrztnJmC4Zth9NCC2r015qbPukrF29 WcM9q36WvRzlbgmr2xkj6/NnnqTt1QZtCNcVs7gVj3LtG8vHRToE3DQ+205p5KnpNlXTto9NKw96P ytsBGeoLR9L+W1SCnN5A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m3KUy-00Anp5-35; Tue, 13 Jul 2021 15:39:04 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m3KUu-00AnoW-1E for linux-arm-kernel@lists.infradead.org; Tue, 13 Jul 2021 15:39:01 +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 62D12610A6; Tue, 13 Jul 2021 15:38:59 +0000 (UTC) Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1m3KUr-00D6yp-7k; Tue, 13 Jul 2021 16:38:57 +0100 Date: Tue, 13 Jul 2021 16:38:56 +0100 Message-ID: <87o8b66x67.wl-maz@kernel.org> From: Marc Zyngier To: Bharat Bhushan Cc: Mark Rutland , "catalin.marinas@arm.com" , "will@kernel.org" , "daniel.lezcano@linaro.org" , "konrad.dybcio@somainline.org" , "saiprakash.ranjan@codeaurora.org" , "robh@kernel.org" , "marcan@marcan.st" , "suzuki.poulose@arm.com" , "broonie@kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Linu Cherian , Sunil Kovvuri Goutham Subject: Re: [EXT] Re: [PATCH] clocksource: Add Marvell Errata-38627 workaround In-Reply-To: References: <20210705060843.3150-1-bbhushan2@marvell.com> <20210705090753.GD38629@C02TD0UTHF1T.local> <20210708114157.GC24650@C02TD0UTHF1T.local> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: bbhushan2@marvell.com, mark.rutland@arm.com, catalin.marinas@arm.com, will@kernel.org, daniel.lezcano@linaro.org, konrad.dybcio@somainline.org, saiprakash.ranjan@codeaurora.org, robh@kernel.org, marcan@marcan.st, suzuki.poulose@arm.com, broonie@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, lcherian@marvell.com, sgoutham@marvell.com 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-20210713_083900_130914_3D0F1014 X-CRM114-Status: GOOD ( 21.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Bharat, On Tue, 13 Jul 2021 03:40:22 +0100, Bharat Bhushan wrote: > > Hi Mark, > > -----Original Message----- > From: Mark Rutland [...] > > From your description so far, this doesn't sound like it is > > specific to the timer interrupt. Is it possible for a different > > interrupt to trigger this, e.g: > > > > * Can the same happen with another PPI, e.g. the PMU interrupt if that > > gets de-asserted, or there's a race with DAIF.I? > > > > * Can the same happen with an SGI, e.g. if one CPU asserts then > > de-asserts an SGI targetting another CPU, or there's a race with > > DAIF.I? > > > > * Can the same happen with an SPI, e.g. if a device asserts then > > de-asserts its IRQ line, or there's a race with DAIF.I? > > No issue with edge triggered, but this can happen with any level > sensitive interrupt. So let's say CPU0 is targeted by a level-triggered SPI, and right when the interrupt is reaching the CPU interface, CPU1 disables this interrupt, which gets recalled, and CPU0 never takes the interrupt. Bug hits again. Drivers do that. I actually suspect that an edge-triggered interrupt would result in the same issue, unless your GIC implementation isn't able to perform a recall on edge interrupts. I don't understand why you are only considering the timer here. Any interrupt can trigger this, and if there is going to be a workaround, it will need to be robust against all interrupts being retired, no matter what device triggers it. And given that the OoO nature of the machine leaks non architectural state, potentially belonging to a different security context, this isn't something that should be taken lightly. M. -- Without deviation from the norm, progress is not possible. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel