linux-kernel - Re: [GIT PULL] irqchip: Add GICv5 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: <87y0slur4t.ffs@tglx>
Date: Fri, 18 Jul 2025 23:26:58 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Marc Zyngier <maz@...nel.org>
Cc: Breno Leitao <leitao@...ian.org>, Catalin Marinas
 <catalin.marinas@....com>, Conor Dooley <conor+dt@...nel.org>, Jonathan
 Cameron <Jonathan.Cameron@...wei.com>, Krzysztof Kozlowski
 <krzk+dt@...nel.org>, Lorenzo Pieralisi <lpieralisi@...nel.org>, Mark
 Rutland <mark.rutland@....com>, Rob Herring <robh@...nel.org>, Sascha
 Bischoff <sascha.bischoff@....com>, Timothy Hayes <timothy.hayes@....com>,
 Will Deacon <will@...nel.org>, Oliver Upton <oliver.upton@...ux.dev>,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 kvmarm@...ts.linux.dev
Subject: Re: [GIT PULL] irqchip: Add GICv5 support

Marc!

On Thu, Jul 17 2025 at 13:23, Marc Zyngier wrote:

> Thomas,
>
> After some time simmering in -next without much catching fire (only a
> single regression has been reported, which was promptly fixed), here's
> the pull request for the GICv5 core infrastructure.
>
> There are still a couple of patches on the list (mostly addressing
> error paths, and actively being reviewed), but I don't see anything
> that would warrant holding this any longer, and these fixes can be
> added down the line. If anything, this work has allowed us to
> pipe-clean a number of issues in the tree.
>
> Please note that the kvmarm tree also carries this branch, as this is
> a dependency for enabling GICv3 compatibility for guests on a GICv5
> host.

I'm fine with keeping this in the kvmarm tree only if that is intended
to hit the next merge window. There is no point to carry this
redundantly in two trees, unless there is some conflict to resolve in my
tree.

If the kvmarm stuff is not ready yet, then please let me know and I
happily pull in the pile.

Thanks,

        tglx