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 20E5D214810; Wed, 19 Feb 2025 18:02:27 +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=1739988148; cv=none; b=pRTifMEm6/pIKxfdbSOnKHC/tJVKM/Z/MTDhjGSOuSOEKDGZYcTNqaqKK1Mh4tgW3qaTK7ZUjYZkvRTE+UMTUXJG3XsqDuReL77S79EUVROwxBtFKN7HDlIG4QjkHAm8lu2CMJfW1zc7acGo8a30MQQs4U/ZqgnIwXSkoiQiHsk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1739988148; c=relaxed/simple; bh=jIxiebXULrZLfiLVV15tFXoNClQddGSFBGNxWb8PZvw=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=jibwdjD8bypokbCIRcfyL5WaxPcXGEvMNhu1AMlOegLmpJwhPkbkkyoKOhCe9zBZDSsdgpmvV+U4WP4CsdPaRPYy1QS+vLOfb5g48Ws7cYTDLniJC7yj3KFrLto4DoNuBaL2RdnokB/JMxJmdgXGog8SXQ0+vv8SX8eMch7tKSI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q+SwWDxE; 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="q+SwWDxE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9270FC4CED1; Wed, 19 Feb 2025 18:02:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739988147; bh=jIxiebXULrZLfiLVV15tFXoNClQddGSFBGNxWb8PZvw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=q+SwWDxE5346KmNvnWU5IU3DD7Kz5NT5RNA/UsiW/yHdA/uBSpW13obnxOHu3PIwb 2HvYTGDk5TS1BzB4pnePDZI0Qh8xD21Y8k3d7xmaacGomDJxQSHQIspBfgKphd6JUf hMS/hPy3cLLxIZ04q8Up96csFG+cJq45merKJGD8DgSInTqa0YBgMSXCHFJAUw9wTt vBul1HBfJ1dcwC7W1Ttut8I4FSh1IuM+c9n1xcqL4xkqQpSvTZ4EliuOJSPMaVuzA5 LlRyR/BvWzGae5Oui24oNt80KfwVSusOvbAMYuSvOr1Gk6TuM6uwze+mI2sT14Hfjc HUNL04hRyF1kg== 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 1tkoOv-005uv3-LS; Wed, 19 Feb 2025 18:02:25 +0000 Date: Wed, 19 Feb 2025 18:02:24 +0000 Message-ID: <8634g9sthr.wl-maz@kernel.org> From: Marc Zyngier To: Manivannan Sadhasivam Cc: Brian Norris , Manivannan Sadhasivam , Tsai Sung-Fu , Jingoo Han , Lorenzo Pieralisi , Krzysztof =?UTF-8?B?V2lsY3p5xYRza2k=?= , Rob Herring , Bjorn Helgaas , linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Chant , Sajid Dalvi Subject: Re: [PATCH] PCI: dwc: Separate MSI out to different controller In-Reply-To: <20250219175119.vjfdgvltutpzyyp5@thinkpad> References: <20250115083215.2781310-1-danielsftsai@google.com> <20250127100740.fqvg2bflu4fpqbr5@thinkpad> <20250211075654.zxjownqe5guwzdlf@thinkpad> <20250214071552.l4fufap6q5latcit@thinkpad> <20250219175119.vjfdgvltutpzyyp5@thinkpad> 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/29.4 (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: mani@kernel.org, briannorris@chromium.org, manivannan.sadhasivam@linaro.org, danielsftsai@google.com, jingoohan1@gmail.com, lpieralisi@kernel.org, kw@linux.com, robh@kernel.org, bhelgaas@google.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, achant@google.com, sdalvi@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 19 Feb 2025 17:51:19 +0000, Manivannan Sadhasivam wrote: > > On Fri, Feb 14, 2025 at 11:54:52AM -0800, Brian Norris wrote: > > On Fri, Feb 14, 2025 at 12:45:52PM +0530, Manivannan Sadhasivam wrote: > > > On Tue, Feb 11, 2025 at 04:23:53PM +0800, Tsai Sung-Fu wrote: > > > > >Because you cannot set affinity for chained MSIs as these MSIs are muxed to > > > > >another parent interrupt. Since the IRQ affinity is all about changing which CPU > > > > >gets the IRQ, affinity setting is only possible for the MSI parent. > > > > > > > > So if we can find the MSI parent by making use of chained > > > > relationships (32 MSI vectors muxed to 1 parent), > > > > is it possible that we can add that implementation back ? > > > > We have another patch that would like to add the > > > > dw_pci_msi_set_affinity feature. > > > > Would it be a possible try from your perspective ? > > > > > > > > > > This question was brought up plenty of times and the concern from the irqchip > > > maintainer Marc was that if you change the affinity of the parent when the child > > > MSI affinity changes, it tends to break the userspace ABI of the parent. > > > > > > See below links: > > > > > > https://lore.kernel.org/all/87mtg0i8m8.wl-maz@kernel.org/ > > > https://lore.kernel.org/all/874k0bf7f7.wl-maz@kernel.org/ > > > > It's hard to meaningfully talk about a patch that hasn't been posted > > yet, but the implementation we have at least attempts to make *some* > > kind of resolution to those ABI questions. For one, it rejects affinity > > changes that are incompatible (by some definition) with affinities > > requested by other virqs shared on the same parent line. It also updates > > their effective affinities upon changes. > > > > Those replies seem to over-focus on dynamic, user-space initiated > > changes too. But how about for "managed-affinity" interrupts? Those are > > requested by drivers internally to the kernel (a la > > pci_alloc_irq_vectors_affinity()), and can't be changed by user space > > afterward. It seems like there'd be room for supporting that, provided > > we don't allow conflicting/non-overlapping configurations. > > > > I do see that Marc sketched out a complex sysfs/hierarchy API in some of > > his replies. I'm not sure that would provide too much value to the > > managed-affinity cases we're interested in, but I get the appeal for > > user-managed affinity. > > > > Whatever your proposal is, please get it reviewed by Marc. Please see b673fe1a6229a and avoid dragging me into discussion I have purposely removed myself from. I'd also appreciate if you didn't volunteer me for review tasks I have no intention to perform (this is the second time you are doing it, and that's not on). M. -- Without deviation from the norm, progress is not possible.