linux-kernel - Re: [PATCH 20/24] irqchip/gic-v5: Add GICv5 LPI/IPI 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <mcyioyevok6tixna2xwk5q3d6x5b5spyucc4fiiy3h4v5jwxbj@bw6ewonqm2ks>
Date: Sat, 12 Apr 2025 09:01:18 -0400
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Lorenzo Pieralisi <lpieralisi@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Marc Zyngier <maz@...nel.org>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Sascha Bischoff <sascha.bischoff@....com>,
        Timothy Hayes <timothy.hayes@....com>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, ast@...nel.org
Subject: Re: [PATCH 20/24] irqchip/gic-v5: Add GICv5 LPI/IPI support

* Lorenzo Pieralisi <lpieralisi@...nel.org> [250411 08:37]:

Thanks for the Cc.

> On Fri, Apr 11, 2025 at 11:55:22AM +0200, Thomas Gleixner wrote:
> > On Fri, Apr 11 2025 at 11:26, Lorenzo Pieralisi wrote:
> > > On Tue, Apr 08, 2025 at 12:50:19PM +0200, Lorenzo Pieralisi wrote:
> > >> Maple tree entries are not used by the driver, only the range tracking
> > >> is required - therefore the driver first finds an empty area large
> > >> enough to contain the required number of LPIs then checks the
> > >> adjacent (and possibly occupied) LPI ranges and try to merge them
> > >> together, reducing maple tree slots usage.
> > >
> > > The maple tree usage for this purpose is an RFC at this stage.
> > >
> > > Added Alexei because I know BPF arena used the maple tree in
> > > a similar way in the past and moved to a range tree because
> > > the BPF arena requires a special purpose mem allocator.
> > >
> > > As Thomas already pointed out a plain bitmap could do even though
> > > it requires preallocating memory up to 2MB (or we can grow it
> > > dynamically).
> > >
> > > We could allocate IDs using an IDA as well, though that's 1 by 1,
> > > we allocate LPI INTIDs 1 by 1 - mostly, upon MSI allocation, so
> > > using an IDA could do (AFAIU it works for 0..INT_MAX we need
> > > 0..2^24 worst case).
> > 
> > The point is that you really only need a 1-bit storage per entry,
> > i.e. used/unused. You won't use any of the storage functions of maple
> > tree, idr or whatever.
> 
> IDA does use the XArray entries (i.e. the pointers) to store bitmaps,
> the only drawback I see is that it allocates IDs one by one (but that's
> not really a problem).
> 
> I wonder if it is used in the kernel for IDs larger than 16 bits, it
> should work for 0..INT_MAX.
> 
> > So the obvious choice is a bitmap and as you said, it's trivial to start
> > with a reasonably sized one and reallocate during runtime if the need
> > arises.

I think the IDA or the bitmap for space saving would be better - the
xarray does do something under the hood for IDA space savings.

If you want to compare, I can suggest some changes to your maple tree
code (mas_{next/prev}_range might help).

> 
> Yes I can do that too but to avoid fiddling with alloc/free ranges crossing
> bitmap chunks we need a single bitmap, AFAICS that may require realloc+copy,
> if the need arises.

That is the advantage of the IDA or maple tree, the expansion is handled
for you. I'd be inclined to suggest using the IDA, but I'm not sure how
important storing an entire range is for your usecase?

Are there other reasons you want to use the maple tree besides the range
support?

Thanks,
Liam