linux-kernel - Re: [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/

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-next>] [day] [month] [year] [list]

Message-ID: <695CCDCE-A205-4557-AA15-6F102B8CCF0C@nvidia.com>
Date: Tue, 7 Oct 2025 23:37:49 +0000
From: Joel Fernandes <joelagnelf@...dia.com>
To: Danilo Krummrich <dakr@...nel.org>
CC: Alexandre Courbot <acourbot@...dia.com>, Yury Norov
	<yury.norov@...il.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "rust-for-linux@...r.kernel.org"
	<rust-for-linux@...r.kernel.org>, "dri-devel@...ts.freedesktop.org"
	<dri-devel@...ts.freedesktop.org>, Alistair Popple <apopple@...dia.com>,
	Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, Boqun
 Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	"bjorn3_gh@...tonmail.com" <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>,
	Timur Tabi <ttabi@...dia.com>, "joel@...lfernandes.org"
	<joel@...lfernandes.org>, Elle Rhumsaa <elle@...thered-steel.dev>, Daniel
 Almeida <daniel.almeida@...labora.com>, Andrea Righi <arighi@...dia.com>,
	"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH v6 0/5] Introduce bitfield and move register macro to
 rust/kernel/




> On Oct 7, 2025, at 6:09 PM, Danilo Krummrich <dakr@...nel.org> wrote:
> On Tue Oct 7, 2025 at 11:08 PM CEST, Joel Fernandes wrote:
>> Danilo, Yuri, Miguel, John, all,
>> 
>> On 10/7/2025 9:16 AM, Danilo Krummrich wrote:
>>> On Tue Oct 7, 2025 at 12:36 PM CEST, Alexandre Courbot wrote:
>>>> Because letting it fully mature within nova-core also has the drawback
>>>> that we might miss the perspective of other potential users, which may
>>>> make us draw ourselves into a corner that will make the macro less
>>>> useful generally speaking. We are at a stage where we can still make
>>>> design changes if needed, but we need to hear from other users, and
>>>> these won't come as long as the macro is in nova-core.
>>> There are two different things here that are getting mixed up a bit.
>>>  (1) Moving the register!() code out of nova-core to make it accessible for
>>>      other drivers.
>>>  (2) Generalize the bitfield implementation that so far is baked into the
>>>      register!() code.
>>> Both of those make sense, but they don't have to happen at the same time
>>> necessarily.
>>> Now, I'm not saying that we necessarily have to change the approach here. The
>>> current merge window isn't even closed, so we have plently of time left, i.e.
>>> there's no rush with with patch series.
>>> However, if it helps, I'm perfectly fine to take the register!() implementation
>>> into the I/O entry in a first step and in a second step generalize the bitfield
>>> implementation and move it out of the register!() code.
>>> Again, there's no rush as far as I'm concerned, yet the latter approach might
>>> add a bit more structure and hence run a bit smoother.
>> 
>> In my view it is better to move both bitfield and register macros together
>> because if we only moved register, it means we would have no bitfield support
>> for the page table / mm use case I just posted a patch for (which is why I
>> started looking into Bitfield support initially) unless we create a copy of just
>> the bitfield code within nova which we definitely shouldn't I think. So I think
>> it is best to move both.
> 
> Again, fine for me either way, but I wanted to open the possibility.
> 
> Typically, things run more smoothly when focusing on one thing at a time.
> Especially when one thing is done to unblock something else, while the other
> things needs some more discussion and might require a more slow-paced approach.)
> 
> (Slightly off-topic: Regarding the bitfields for page table management: Are we
> sure that we can use raw bitfields for this? I.e. will we always be able to
> configure the GPU to match CPU endianness?)

The Nvidia GPU architecture is little-endian (including MMU structures in VRAM).
All the CPU architectures our drivers support are expected to be little-endian.

>> For the IO (register macro) change, I can add add an entry to the existing IO
>> record.
> 
> I don't think any changes are needed, it should be covered by just moving it to
> rust/kernel/io/register.rs.

Ok, thanks.

- Joel


> 
> Thanks,
> Danilo