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 94F26C3DA6D for ; Fri, 23 May 2025 09:09:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/E+ZjxkfOttG3kawews00XIw73vJRAtIRMufeziSll4=; b=uZGx2+a6LMNgRVIDn7u87I0HhO AsYSeAjQ7GD6ybWObTUBYC/HU5VPzLosUNEuq7QziNhXg3Fe1YkcMlEkIcpBovVbu01eCKyaXwQ0N bXJlhgKqQUhTTwY0y+J06Us9/fQQgPrT0NdBlbiNf1C6OYQbgqPpmtPP0WfBa3E5pbqRycEuRZaoM K1y5CO2TQAL56AFz2OMx0oKGJbrVQh0DOrjnhbwDh7sV37mT8Gj59qXzZKoC58M0v8rFyIk3MMvvP y/nAjopf5pu3UMvE36lRDMRgSPQlxG2rfGeZxAt1bZRwCASGLJkTU3F4wjS8c+4Kgm1NfYzuX8ITO TqUGFVvw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uIOOr-00000003OyW-12wU; Fri, 23 May 2025 09:09:09 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uIOMi-00000003Ood-2Ytb for linux-arm-kernel@lists.infradead.org; Fri, 23 May 2025 09:06:56 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 0F677629F6; Fri, 23 May 2025 09:06:56 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B7F33C4CEE9; Fri, 23 May 2025 09:06:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747991215; bh=y58D5o2WeeI79/6c3GDc1hkPTe1ukMuyCQePGAsny4w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=mkMqqaj8qqVUg/i8Ibnp0GiFcnYVqp9L6/uu99NNxg9pT9bZdw0crjneUZM4rVCxn iYQ9lFVjf1l63O03aHGbXJJy/pYaL0Lhwlt4KgosM+fNc0kxfJVa707gxZfD17QmEg czWMNXCJOFzXdvNob0WtqwZ4Bbq/hJZPg2g4oy8htK4tCKLGCFANH1Ygf60mDuH2Mk 2S1jG37p14cLGuytRfK07jmp1Z42e0xl0EPEaJf/OLPXWNc8srmwnWKHseSNfKGdfW Wby40wcqfbPSbvVt3IF1EZo2jKY2ovrKWyyvVBs/cs9knr3Xu8/OitWQs+quppRx29 Ac9wgXC2k1fBg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uIOMf-00HWek-Hc; Fri, 23 May 2025 10:06:53 +0100 Date: Fri, 23 May 2025 10:06:53 +0100 Message-ID: <86o6vjelw2.wl-maz@kernel.org> From: Marc Zyngier To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] irqchip/msi-lib: Honor the MSI_FLAG_PCI_MSI_MASK_PARENT flag In-Reply-To: <875xhzhuup.ffs@tglx> References: <20250517103011.2573288-1-maz@kernel.org> <875xhzhuup.ffs@tglx> 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/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: tglx@linutronix.de, linux-kernel@vger.kernel.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-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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sat, 17 May 2025 20:59:10 +0100, Thomas Gleixner wrote: > > On Sat, May 17 2025 at 11:30, Marc Zyngier wrote: > > + /* > > + * If the parent domain insists on being in charge of masking, obey > > + * blindly. The default mask/unmask become the shutdown/enable > > + * callbacks, ensuring that we correctly start/stop the interrupt. > > + * We make a point in not using the irq_disable() in order to > > + * preserve the "lazy disable" behaviour. > > + */ > > + if (info->flags & MSI_FLAG_PCI_MSI_MASK_PARENT) { > > + chip->irq_shutdown = chip->irq_mask; > > + chip->irq_enable = chip->irq_unmask; > > This is only correct, when the chip does not have dedicated > irq_shutdown/enable callbacks. The chip structure provided by the PCI MSI code doesn't provide such callback, meaning that they are unused for the whole hierarchy. > And I really hate the asymmetry of this. So do I, but that's how the lazy disable thing currently works. Drop the bizarre asymmetry on irq_disable, and we can make this nicely symmetric as well. > > > + chip->irq_mask = irq_chip_mask_parent; > > + chip->irq_unmask = irq_chip_unmask_parent; > > + } > > I'm still trying to understand, what's the actual problem is you are > trying to solve. I'm trying to remove some overhead from machines that don't need to suffer from this nonsense double masking. Specially in VMs when masking/unmasking requires *two* extremely costly exits (write + synchronising read-back). This change reduces the overhead significantly by only masking where it actually matters. > MSIs are edge type interrupts, so the interrupt handling hotpath usually > does not mask at all. The only time masking happens is when it's lazy > disabled or during affinity changes, which is not the end of the world. And that's part of the problem. The lazy disable ends up being way more costly than it should when the interrupt fires during the "disabled but not quite" phase, and in turn makes the critical section delineated by disable_irq()/enable_irq() more expensive. So while, as you put it, it's "not the end of the world", this seems to me like a valuable optimisation. Another possible improvement would be to teach the PCI code it can still rely on masking even when the endpoint is not capable of masking individual MSIs. Thanks, M. -- Without deviation from the norm, progress is not possible.