linux-kernel - Re: [PATCH v3 00/25] Arm GICv5: Host driver implementation

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: <86frhhhm18.wl-maz@kernel.org>
Date: Tue, 06 May 2025 15:05:39 +0100
From: Marc Zyngier <maz@...nel.org>
To: Lorenzo Pieralisi <lpieralisi@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
	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>,
	Arnd Bergmann <arnd@...db.de>,
	Sascha Bischoff <sascha.bischoff@....com>,
	Timothy Hayes <timothy.hayes@....com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Mark Rutland <mark.rutland@....com>,
	Jiri Slaby <jirislaby@...nel.org>,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v3 00/25] Arm GICv5: Host driver implementation

On Tue, 06 May 2025 13:23:29 +0100,
Lorenzo Pieralisi <lpieralisi@...nel.org> wrote:
> 
> =============
> 2.5 GICv5 IWB
> =============
> 
> The IWB driver has been dropped owing to issues encountered with
> core code DOMAIN_BUS_WIRED_TO_MSI bus token handling:
> 
> https://lore.kernel.org/lkml/87tt6310hu.wl-maz@kernel.org/

This problem does not have much to do with DOMAIN_BUS_WIRED_TO_MSI.

The issues are that:

- the core code calls into the .prepare domain on a per-interrupt
  basis instead of on a per *device* basis. This is a complete
  violation of the MSI API, because .prepare is when you are supposed
  to perform resource reservation (in the GICv3 parlance, that's ITT
  allocation + MAPD command).

- the same function calls .prepare for a *single* interrupt,
  effectively telling the irqchip "my device has only one interrupt".
  Because I'm super generous (and don't like wasting precious bytes),
  I allocate 32 LPIs at the minimum. Only snag is that I could do with
  300+ interrupts, and calling repeatedly doesn't help at all, since
  we cannot *grow* an ITT.

So this code needs to be taken to the backyard and beaten into shape
before we can make use of it. My D05 (with its collection of MBIGENs)
only works by accident at the moment, as I found out yesterday, and
GICv5 IWB is in the same boat, since it reuses the msi-parent thing,
and therefore the same heuristic.

I guess not having the IWB immediately isn't too big a deal, but I
really didn't expect to find this...

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.