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 89118C678D5 for ; Wed, 8 Mar 2023 13:14:03 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=zjCgqtm+YsfSd3oX9rUNAyGwh3+cDAAKkK2ass/2kYA=; b=dPUyCW8O+LDe8q zE8aG+sJF+B80ziNd+aoRu/SY4TkZifHgt7TOi0AGe42DZbC/du+5DNsvXdRyyhL//Gi2n+XR2OdT UpHBR+CrIAiL4DjY5KoDG3po7JtRRtgHuToHbQqyGDzxoj6tH2++HFBgOceK7E40d5PT9v9hZXoM1 Rl0kf8EUCu3y663n3T8iV66CZwPA9+QS+8Jv5X/Zya2UpEFAnPRLniDiv2lLOEe5pj+hHBfZad4BP cDppTn151WnJF39++gnKA+D0Sljgyd3+ysWVom9eUrkFRRmGmSUhnfxQaPBnDK8Fq0x34O08WaV0T 6Wvub5tx2AvOCQ/ObZZw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZtb6-0056HX-4C; Wed, 08 Mar 2023 13:12:48 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZtX3-0054Bl-60 for linux-arm-kernel@lists.infradead.org; Wed, 08 Mar 2023 13:08:40 +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 BA59A106F; Wed, 8 Mar 2023 05:09:14 -0800 (PST) Received: from [10.57.90.59] (unknown [10.57.90.59]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 110903F67D; Wed, 8 Mar 2023 05:08:29 -0800 (PST) Message-ID: <8291b66d-b9b8-47c9-f5ed-a4e951c92154@arm.com> Date: Wed, 8 Mar 2023 13:08:24 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] iommu/arm-smmu-v3: Fix event queue overflow acknowledgment To: Tomas Krcka , linux-arm-kernel@lists.infradead.org Cc: Will Deacon , Joerg Roedel , Lu Baolu , Shameer Kolothum , iommu@lists.linux.dev, linux-kernel@vger.kernel.org References: <20230308092048.71390-1-krckatom@amazon.de> Content-Language: en-GB From: Robin Murphy In-Reply-To: <20230308092048.71390-1-krckatom@amazon.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230308_050837_336283_F376BAD5 X-CRM114-Status: GOOD ( 20.65 ) 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-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 2023-03-08 09:20, 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. If I've understood correctly, the upshot of this is that if the queue has overflowed once, become empty, then somehow goes from empty to full before we manage to consume a single event, we won't print the "events lost" message a second time. Have you seen this happen in practice? TBH if the event queue ever overflows even once it's indicative that the system is hosed anyway, so it's not clear to me that there's any great loss of value in sometimes failing to repeat a warning for a chronic ongoing operational failure. It could be argued that we have a subtle inconsistency between arm_smmu_evtq_thread() and arm_smmu_priq_thread() here, but the fact is that the Event queue and PRI queue *do* have different overflow behaviours, so it could equally be argued that inconsistency in the code helps reflect that. FWIW I can't say I have a strong preference either way. Thanks, Robin. > 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; > } > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel