linux-kernel - Re: [PATCH 1/2] cxl/pci: Add generic MSI-X/MSI irq support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Y1Idsv0Nuu+V9aMj@iweiny-desk3>
Date:   Thu, 20 Oct 2022 21:18:58 -0700
From:   Ira Weiny <ira.weiny@...el.com>
To:     Davidlohr Bueso <dave@...olabs.net>
CC:     Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        <dan.j.williams@...el.com>, <dave.jiang@...el.com>,
        <alison.schofield@...el.com>, <bwidawsk@...nel.org>,
        <vishal.l.verma@...el.com>, <a.manzanares@...sung.com>,
        <linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] cxl/pci: Add generic MSI-X/MSI irq support

On Thu, Oct 20, 2022 at 03:31:25PM -0700, Davidlohr Bueso wrote:
> On Tue, 18 Oct 2022, Jonathan Cameron wrote:
> 
> > Reality is that it is cleaner to more or less ignore the infrastructure
> > proposed in this patch.
> > 
> > 1. Query how many CPMU devices there are. Whilst there stash the maximim
> >   cpmu vector number in the cxlds.
> > 2. Run a stub in this infrastructure that does max(irq, cxlds->irq_num);
> > 3. Carry on as before.
> > 
> > Thus destroying the point of this infrastructure for that usecase at least
> > and leaving an extra bit of state in the cxl_dev_state that is just
> > to squirt a value into the callback...
> 
> If it doesn't fit, then it doesn't fit.
> 
> However, while I was expecting pass one to be in the callback, I wasn't
> expecting that both pass 1 and 2 shared the cpmu_regs_array. If the array
> could be reconstructed during pass 2, then it would fit a bit better;
> albeit the extra allocation, cycles etc., but this is probing phase, so
> overhead isn't that important (and cpmu_count isn't big enough to matter).
> 
> But if we're going to go with a free-for-all approach, can we establish
> who goes for the initial pci_alloc_irq_vectors()? I think perhaps mbox
> since it's the most straightforward and with least requirements, I'm
> also unsure of the status yet to merge events and pmu, but regardless
> they are still larger patchsets. If folks agree I can send a new mbox-only
> patch.

I think there needs to be some mechanism for all of the sub-device-functions to
report their max required vectors.

I don't think that the mbox code is necessarily the code which should need to
know about all those other sub-device-thingys.  But it could certainly take
some 'max vectors' value that probe passed to it.

I'm still not sure how dropping this infrastructure makes Jonathan's code
cleaner.  I still think there will need to be 2 passes over the number of
CPMU's.

Ira

> 
> Thanks,
> Davidlohr