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

Message-Id: <DDD13PUEPSZO.ALDND33ZFFC7@kernel.org>
Date: Wed, 08 Oct 2025 17:00:01 +0200
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Yury Norov" <yury.norov@...il.com>
Cc: "Joel Fernandes" <joelagnelf@...dia.com>, "Alexandre Courbot"
 <acourbot@...dia.com>, <linux-kernel@...r.kernel.org>,
 <rust-for-linux@...r.kernel.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>, "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>, "Elle Rhumsaa" <elle@...thered-steel.dev>,
 "Daniel Almeida" <daniel.almeida@...labora.com>, "Andrea Righi"
 <arighi@...dia.com>, <nouveau@...ts.freedesktop.org>
Subject: Re: [PATCH v6 0/5] Introduce bitfield and move register macro to
 rust/kernel/

On Wed Oct 8, 2025 at 4:28 PM CEST, Yury Norov wrote:
> On Wed, Oct 08, 2025 at 12:08:59AM +0200, Danilo Krummrich wrote:
>
>> Regarding the bitfields for page table management: Are we
>> sure that we can use raw bitfields for this?
>
> As per my current understanding we can't. Bitfields are not suitable for
> direct I/O and considered as a data storage. In the current scheme:
>
>         regs::NV_PFALCON_FALCON_DMATRFBASE::default()
>             .set_base((dma_start >> 8) as u32)
>             .write(bar, &E::ID);
>
> we account for endianess in the .write() method, which would be a part
> of register API, not bitfields.

I know, I proposed this register API design about a year ago, and Alex came up
with an awesome implementation for it. :)

And yes, your understanding is correct, the idea is that the I/O backend that
knows about the underlying bus, etc. takes care of the endianess.

However, we might still be able to use bitfields natively for page table
management structures: In [1] I asked for the NV_PMC_BOOT_1 register, which
might provide some endianess switch to ensure that we always match CPU
endianess.

> FYI: ARM64 is in process of dropping BE, and Linus announced the end
> of BE support for RISC-V:

Yeah, I'm aware of the thread. Also note that for RISC-V it was also clarified
that if it turns out that BE for RISC-V becomes relevant it would also find its
way into the kernel. If that's likely is of course a different question.

However, there are still architectures such as s390x that could be supported.

So, long story short, my question from above is more meant to challenge if we
can really always guarantee that CPU and GPU endianess match for nova-core.

[1] https://lore.kernel.org/lkml/DDCV84IJHUML.126CB1CT0XMX5@kernel.org/