> Whatever your proposal is, please get it reviewed by Marc. Since Marc has removed him as the maintainer, I will add other IRQ chip maintainer as CC when sending out the patch for reviewing. Thanks On Thu, Feb 20, 2025 at 2:09 AM Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote: > > On Wed, Feb 19, 2025 at 06:02:24PM +0000, Marc Zyngier wrote: > > On Wed, 19 Feb 2025 17:51:19 +0000, > > Manivannan Sadhasivam <mani@xxxxxxxxxx> 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@xxxxxxxxxx/ > > > > > https://lore.kernel.org/all/874k0bf7f7.wl-maz@xxxxxxxxxx/ > > > > > > > > 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). > > > > Apologies for not catching up with the MAINTAINERS update. Since you were pretty > much involved in the affinity discussion, I thought about asking your help. > > Regarding looping you in, I thought you only wanted to avoid reviewing the new > driver changes that were deviating from the spec too much. > > But anyway, now it is clear to me that you are not maintaining the irqchip > drivers, so I will not bother you anymore. Sorry about that. > > - Mani > > -- > மணிவண்ணன் சதாசிவம்
