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 D5878C3DA6D for ; Mon, 19 May 2025 15:11:54 +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=CRuxufbvOdqzJWw916LL93YzGVhdMdUTy5cQknnLhDM=; b=IIWxV9NeIQMxk3QBdK4oUo4coG xWnO9oN23ued3RvhsoiLDTbUVK3pphqmrl/KLU3kgfTVHWlKyGcyaUnYuEc02i0iNrULbDV7bz+Z8 2tMLXMJHl+lR8JoVZBVI959nWx/ogFDTiCSkrsHmlqpqmmAkoch10gkKrcDuHyXUwX6zP3y8qYr7A DDAMaIpbbeIQ1OzUQ1QaTe3Lk2CuJmSEg8V0j0kccc8Ato2On8EnlpvmKPJ+lPYqOpBmYJHnQlogG mQxvghjh8hdKnWnhlha+gL78B0zGBkgr5vzUmRkSagLboQ4LdZ11zVeSHY3yBNJpvnuc1YnW90ti4 FKn4HpQA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uH29X-00000009Xef-28Ez; Mon, 19 May 2025 15:11:43 +0000 Received: from nyc.source.kernel.org ([147.75.193.91]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uH1TJ-00000009Rm3-2Uui for linux-arm-kernel@lists.infradead.org; Mon, 19 May 2025 14:28:06 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id C7F07A4D410; Mon, 19 May 2025 14:28:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 644DAC4CEE4; Mon, 19 May 2025 14:28:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747664884; bh=Ec6so1mXK7PYIl4ePJtuR09PRnO4g6cAtK3x4K4qwYQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=YHfTeVn39xgQlmHNE9gL+amRgbq8b2y0P4EgtJGFD6b4OJqkQfgKqw+SuvyssMQkM 0uHBK/DxP3BgcosHt4IN3KkNlyqNBOllk3L7xqZ6BCY5p/C+jSNP8N1cbXsYRo81C1 3P4lulpv5cefeUg7rq71WioDa2LVyxuF2rlwqRUk46BEhgkP9yP6aQJkb9oSavCOgL WXOnviA3uYaNsuI9cKB9O0Pfd3H5TN1vT3g5mT1r24I1GQIIeF8nCg32lLgGGSvArf 2FDoec5sK5yLCCTwps0coJO80egPeNVynkJl++Szo7Pbai4X+WRHs+MIp7+/0OY7FX N7/5NC5sLfTdA== 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 1uH1TG-00GFoI-8U; Mon, 19 May 2025 15:28:02 +0100 Date: Mon, 19 May 2025 15:28:01 +0100 Message-ID: <86v7pwekum.wl-maz@kernel.org> From: Marc Zyngier To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Lorenzo Pieralisi , Sascha Bischoff , Timothy Hayes Subject: Re: [PATCH v2 5/5] irqchip/gic-v3-its: Use allocation size from the prepare call In-Reply-To: <87zff8hk1x.ffs@tglx> References: <20250513163144.2215824-1-maz@kernel.org> <20250513163144.2215824-6-maz@kernel.org> <8734d1iwcp.ffs@tglx> <86wmacewjr.wl-maz@kernel.org> <87zff8hk1x.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, lpieralisi@kernel.org, sascha.bischoff@arm.com, timothy.hayes@arm.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-20250519_072805_767623_A5B388B7 X-CRM114-Status: GOOD ( 25.33 ) 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 Mon, 19 May 2025 13:16:58 +0100, Thomas Gleixner wrote: > > On Mon, May 19 2025 at 11:15, Marc Zyngier wrote: > > On Sun, 18 May 2025 19:53:42 +0100, > > Thomas Gleixner wrote: > >> > >> On Tue, May 13 2025 at 17:31, Marc Zyngier wrote: > >> > >> > Now that .msi_prepare() gets called at the right time and not > >> > with semi-random parameters, remove the ugly hack that tried > >> > to fix up the number of allocated vectors. > >> > > >> > It is now correct by construction. > >> > >> FWIW, while looking at something related, it occured to me that with > >> this change you can enable MSI_FLAG_PCI_MSIX_ALLOC_DYN now on GIC ITS. > > > > Maybe. It is rather unclear to me what this "dynamic allocation" > > actually provides in terms of guarantees to the endpoint driver. > > It allows the driver to avoid allocating a gazillion of interrupts > upfront during initialization. Instead it can allocate them on demand, > when e.g. a queue is initialized. Of course that means that such an > allocation can fail, but so can request_irq() and other things. I'm not > sure what you mean with guarantees here. What is the endpoint driver allowed to expect in terms of continuity of allocation in the IRQ space? If this is solely limited to MSI-X, then the answer probably is "none whatsoever", and the driver should only manage the MSI descriptor index. Can any other MSI-like mechanism end-up with multiple allocations and require extra alignment/contiguity guarantees in the hwirq space, more or less similar to what MultiMSI requires? Because that'd be much harder to provide. M. -- Without deviation from the norm, progress is not possible.