Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp7582039ybl; Thu, 16 Jan 2020 02:02:50 -0800 (PST) X-Google-Smtp-Source: APXvYqyWEphswu+E58wcR24dWKA6RIWFKoWn33V6iJstCH6wd4vDtkdQ8Ip3pApGCShHoSwQVF2O X-Received: by 2002:aca:d483:: with SMTP id l125mr3400594oig.124.1579168970628; Thu, 16 Jan 2020 02:02:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579168970; cv=none; d=google.com; s=arc-20160816; b=WLNMxkeBR+kIoJeD/aKQ0DLlnB1jyyJChCFqItYGmSvmKJi73hi1MncRvcCssrZ26j q9YAwv8sIdY/Pw2G7udiu2zqz3tiF1l3ZzFAdR8C3f1yma6E1zp/579SryyM2Nuz2u52 wvYJq1rLieYHFx88XAuo+kCosQ+ntkfVGapSlglS78l2UiYsqTsWaQ2x78A8Ub1seAxw 3AFJy+Nvsfl7WTpWqZGiPwGz/VANldZTGwpTdZvxLJ+qyjtfmfMZDb2Ir1OwdKODJhKo PoIYmrNAYwTc9BlvIigfeEPYQG7WUp4fILhnAuCKuK0csH3Mu6J/BK21xCqOdXLlr3lR QxJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from; bh=r0W0XfAYvjH8SIV7Bt03K5VWdO/gmzUeyfeg8z+0n+s=; b=tHI5HfmMSQ5951XNOq1x0o/pJ6bR7pyFnXzy6kWxlIRUJn4TMEkxK1UT9R3aSUTkMb 00JuC9E5FmGYevd4GPDbdSOj8pgNv/dIyAmkjU0mZkmnXPEka4beAH7ulq/f9nuN2YtQ k0yVe3qFmDM5NzAcX/C589sRmi4Bl8z2b+uVFM1s+3+5e0SnPOZ6Azszjp16E76PXbWZ FbOhkgUX/8+N1xHzuqdVn7SwxgjSNmEWwKEiOO0zZfjPP9l5vwLW+olRtfkprZPUJPof wJpfSre+BheQsWa7GENtVnsqjCA4poGQZP0T3dU+aTGY0q3t3zA0/MZwl+vq+JFgG2GW vzEA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i25si11279558oii.259.2020.01.16.02.02.37; Thu, 16 Jan 2020 02:02:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730705AbgAPJcu (ORCPT + 99 others); Thu, 16 Jan 2020 04:32:50 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:50957 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726329AbgAPJct (ORCPT ); Thu, 16 Jan 2020 04:32:49 -0500 Received: from p5b06da22.dip0.t-ipconnect.de ([91.6.218.34] helo=nanos.tec.linutronix.de) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1is1W7-0002YM-Pv; Thu, 16 Jan 2020 10:32:44 +0100 Received: by nanos.tec.linutronix.de (Postfix, from userid 1000) id E3797100C1E; Thu, 16 Jan 2020 10:32:42 +0100 (CET) From: Thomas Gleixner To: Ramon Fried Cc: hkallweit1@gmail.com, Bjorn Helgaas , maz@kernel.org, lorenzo.pieralisi@arm.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: MSI irqchip configured as IRQCHIP_ONESHOT_SAFE causes spurious IRQs In-Reply-To: References: <87wo9ub5f6.fsf@nanos.tec.linutronix.de> <87imldbqe3.fsf@nanos.tec.linutronix.de> <87v9pcw55q.fsf@nanos.tec.linutronix.de> Date: Thu, 16 Jan 2020 10:32:42 +0100 Message-ID: <87pnfjwxtx.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ramon, Ramon Fried writes: > On Thu, Jan 16, 2020 at 3:39 AM Thomas Gleixner wrote: >> Ramon Fried writes: > > Basically, 32 MSI vectors are represented by a single GIC irq. > There's a status registers which every bit correspond to an MSI vector, and > individual MSI needs to be acked on that registers. in any case where > there's asserted bit the GIC IRQ level is high. Which is not that bad. >> > It's configured with handle_level_irq() as the GIC is level IRQ. >> >> Which is completely bonkers. MSI has edge semantics and sharing an >> interrupt line for edge type interrupts is broken by design, unless the >> hardware which handles the incoming MSIs and forwards them to the level >> type interrupt line is designed properly and the driver does the right >> thing. > > Yes, the design of the HW is sort of broken. I concur. As you describe it, it's not that bad. >> > The ack callback acks the GIC irq. the mask/unmask calls >> > pci_msi_mask_irq() / pci_msi_unmask_irq() >> >> What? How is that supposed to work with multiple MSIs? > Acking is per MSI vector as I described above, so it should work. No. This is the wrong approach. Lets look at the hardware: | GIC line X |------| MSI block | <--- Messages from devices The MSI block latches the incoming message up to the point where it is acknowledged in the MSI block. This makes sure that the level semantics of the GIC are met. So from a software perspective you want to do something like this: gic_irq_handler() { mask_ack(gic_irqX); pending = read(msi_status); for_each_bit(bit, pending) { ack(msi_status, bit); // This clears the latch in the MSI block handle_irq(irqof(bit)); } unmask(gic_irqX); } And that works perfectly correct without masking the MSI interrupt at the PCI level for a threaded handler simply because the PCI device will not send another interrupt until the previous one has been handled by the driver unless the PCI device is broken. If that's the case, then you have to work around that at the device driver level, not at the irq chip level, by installing a primary handler which quiesces the device (not the MSI part). Thanks, tglx