From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1295D283FCA for ; Mon, 19 May 2025 14:28:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747664885; cv=none; b=hco174TBi8TjID9eB5bdzUTchlICfRvtX8rlz+bUfkcM/bbuSC8FcG9lUjcMFEZ1vyXsk9mCG49dbIAlwj9ATC3vgr81xyPzVu0b+Qd1xXdKf1Tw9SwbvFku5aODTTe4ZP0/Hk3MAJGVOJAPWAKAyKweJlIa9JQMRVoepdIIw1Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747664885; c=relaxed/simple; bh=Ec6so1mXK7PYIl4ePJtuR09PRnO4g6cAtK3x4K4qwYQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=fXbAV7EB8x281CxwYRtXLhdtzqo9yRgxCe5RuA7rtpxFMM+6JmmwunyXGmVSjwR2RpVdcw6gpr5cxvOBxIdbd38n8Thfoah0fjAvge/iTtPZNOnYmeCstcH0mY6ls3vsi7rj91kLt2KKZR2nLGlk+XCybfNeZuwFBXDFtIq6hAY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YHfTeVn3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YHfTeVn3" 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) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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 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.