linux-kernel - Re: [PATCH v3 00/13] gpu: nova-core: Boot GSP to RISC-V active

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: <mvp3knyp6ls2mk5jjgzef7jis3uwjjxdm2wmuno22r6h5zue5z@ph4gsisqw2aq>
Date: Wed, 1 Oct 2025 12:02:13 +1000
From: Alistair Popple <apopple@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: rust-for-linux@...r.kernel.org, dri-devel@...ts.freedesktop.org, 
	acourbot@...dia.com, Miguel Ojeda <ojeda@...nel.org>, 
	Alex Gaynor <alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, 
	Trevor Gross <tmgross@...ch.edu>, David Airlie <airlied@...il.com>, 
	Simona Vetter <simona@...ll.ch>, Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, 
	Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, 
	John Hubbard <jhubbard@...dia.com>, Joel Fernandes <joelagnelf@...dia.com>, 
	Timur Tabi <ttabi@...dia.com>, linux-kernel@...r.kernel.org, nouveau@...ts.freedesktop.org
Subject: Re: [PATCH v3 00/13] gpu: nova-core: Boot GSP to RISC-V active

On 2025-09-30 at 23:26 +1000, Danilo Krummrich <dakr@...nel.org> wrote...
> On 9/30/25 3:16 PM, Alistair Popple wrote:
> > Changes since v2:
> > 
> > The main change since v2 has been to make all firmware bindings
> > completely opaque. It has been made clear this is a pre-requisite for
> > this series to progress upstream as it should make supporting
> > different firmware versions easier in future.
> > 
> > Overall the extra constructors and accessors add a couple of hundred
> > lines of code and a few extra unsafe statements.
> 
> A bit of additional code is expected, but it's not clear to me why this would
> require additional unsafe blocks.
> 
> Can you please elaborate?

See patch 5 and 6 and specifically cpu_read_ptr(), etc. The message
headers are embedded in a structure within a DMA coherent mapping, `struct
DmaGspMem(CoherentAllocation<GspMem>)`, in cmdq.rs. Obviously we can't
call `dma_write!()` on them because we can't get to the opaque fields,
and even getting to the methods requires accessing the GspMem within the
CoherentAllocation which requires some unsafe code to get the CPU pointer.

I'm open to suggestions though, maybe I missed something as it was late when I
was trying to pull this all togeather.