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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 4AC6BC76195 for ; Tue, 28 Mar 2023 07:14:59 +0000 (UTC) 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:Content-ID:In-Reply-To: References:Message-ID:Date:Subject:CC:To:From:Reply-To:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=wgR4lmLbpXJv4MrFdXrTAFetp78slP2n4DFMvwOWY5U=; b=vsSuQs7XhfqeBY hC8Mtd5OF7KjtBX/1J1QzpjdXHxf5s1zr6ugRyR0OkDbJQknFfya97Cbh9qiMRygQfud4QqRnrkLw Nym360KGZcJUlgpxasEQPM3koqGnUztH5xqLpWHhOrbZqxcmfcPmgLkA307kIImh67+WfDkM/wR3W vF1y4xaZpi3bOuAJDGKnWX3LNxkJGTV0g/M29a8zfh6Pfto1Rh/fvsqaiyYypjZokw3uWMwUgdWRh 1BSHueAhIvPPfSM3CIzLlYciAwDMztbcIDvPL7CabVlWwejH6NmPWAc9lK/3TXufWsTy+3T4bw9qD DACIFmbJo8GoPDdYIc2Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1ph3Ww-00DPZ8-2b; Tue, 28 Mar 2023 07:14:06 +0000 Received: from smtp-fw-80006.amazon.com ([99.78.197.217]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1ph3Wt-00DPXI-19 for linux-arm-kernel@lists.infradead.org; Tue, 28 Mar 2023 07:14:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.de; i=@amazon.de; q=dns/txt; s=amazon201209; t=1679987643; x=1711523643; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:mime-version: content-transfer-encoding; bh=cs515H+pAY5a8BjNWqt1o2h2IfKbYZ5CffOpLSxnAZU=; b=T7KmTj8V2if894eppsGYT0YFRJENrfQ0+I8us96bfEHf0P8n1gedhRzn P2FqFoPVFdW8qTS6aYI5Kfil5fUN0brnkcX1fsBOqbhit/Ebf1fmjoT8d pO6jqy2D4lQOHxWiM7s1H+a1vOTA4IcNWx+/HpnlvSPkcHF5Npg4VU0rZ 0=; X-IronPort-AV: E=Sophos;i="5.98,296,1673913600"; d="scan'208";a="198148107" Received: from pdx4-co-svc-p1-lb2-vlan2.amazon.com (HELO email-inbound-relay-iad-1e-m6i4x-3e1fab07.us-east-1.amazon.com) ([10.25.36.210]) by smtp-border-fw-80006.pdx80.corp.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Mar 2023 07:13:56 +0000 Received: from EX19D012EUA002.ant.amazon.com (iad12-ws-svc-p26-lb9-vlan3.iad.amazon.com [10.40.163.38]) by email-inbound-relay-iad-1e-m6i4x-3e1fab07.us-east-1.amazon.com (Postfix) with ESMTPS id 8D44780C82; Tue, 28 Mar 2023 07:13:53 +0000 (UTC) Received: from EX19D030EUC003.ant.amazon.com (10.252.61.173) by EX19D012EUA002.ant.amazon.com (10.252.50.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.26; Tue, 28 Mar 2023 07:13:53 +0000 Received: from EX19D030EUC004.ant.amazon.com (10.252.61.164) by EX19D030EUC003.ant.amazon.com (10.252.61.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1118.26; Tue, 28 Mar 2023 07:13:52 +0000 Received: from EX19D030EUC004.ant.amazon.com ([fe80::f98a:db18:b0eb:477]) by EX19D030EUC004.ant.amazon.com ([fe80::f98a:db18:b0eb:477%3]) with mapi id 15.02.1118.026; Tue, 28 Mar 2023 07:13:52 +0000 From: "Krcka, Tomas" To: Will Deacon CC: "Krcka, Tomas" , "linux-arm-kernel@lists.infradead.org" , Robin Murphy , Joerg Roedel , Lu Baolu , "Shameer Kolothum" , "iommu@lists.linux.dev" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] iommu/arm-smmu-v3: Fix event queue overflow acknowledgment Thread-Topic: [PATCH] iommu/arm-smmu-v3: Fix event queue overflow acknowledgment Thread-Index: AQHZYUTaFwYdqW+H5UaPJVsYwN0JvQ== Date: Tue, 28 Mar 2023 07:13:52 +0000 Message-ID: <8845FA6A-45F1-4090-B4A2-C0C28F709095@amazon.com> References: <20230308092048.71390-1-krckatom@amazon.de> <20230327121234.GA31342@willie-the-truck> In-Reply-To: <20230327121234.GA31342@willie-the-truck> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.212.24] Content-ID: MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230328_001403_465842_35FB35E7 X-CRM114-Status: GOOD ( 18.92 ) 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 > On 27. Mar 2023, at 14:12, Will Deacon wrote: > > > On Wed, Mar 08, 2023 at 09:20:47AM +0000, Tomas Krcka wrote: >> When an overflow occurs in the event queue, the SMMU toggles overflow >> flag OVFLG in the PROD register. >> The evtq thread is supposed to acknowledge the overflow flag by toggling >> flag OVACKFLG in the CONS register, otherwise the overflow condition is >> still active (OVFLG != OVACKFLG). >> >> Currently the acknowledge register is toggled after clearing the event >> queue but is never propagated to the hardware. It would be done next >> time when executing evtq thread. >> >> The SMMU still adds elements to the queue when the overflow condition is >> active but any subsequent overflow information after clearing the event >> queue will be lost. >> >> This change keeps the SMMU in sync as it's expected by design. >> >> Signed-off-by: Tomas Krcka >> Suggested-by: KarimAllah Ahmed >> --- >> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >> index f2425b0f0cd6..acc1ff5ff69b 100644 >> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c >> @@ -1579,6 +1579,7 @@ static irqreturn_t arm_smmu_evtq_thread(int irq, void *dev) >> /* Sync our overflow flag, as we believe we're up to speed */ >> llq->cons = Q_OVF(llq->prod) | Q_WRP(llq, llq->cons) | >> Q_IDX(llq, llq->cons); >> + queue_sync_cons_out(q); >> return IRQ_HANDLED; >> } > > I think I probably did mean to have something like this, but can we > only do the actual h/w update if overflow has occurred? Otherwise I think > we're pointlessly writing back the same value most of the time. > > Will Yes, we can, but then same applies for the priq as well, there we also write back every time. Tomas Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel