Nouveau - Oct 2025 - [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/

> On Oct 7, 2025, at 6:09?PM, Danilo Krummrich <dakr at kernel.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

On Wed Oct 8, 2025 at 1:37 AM CEST, Joel Fernandes
wrote:
> The Nvidia GPU architecture is little-endian (including MMU structures in
VRAM).
Yes, I'm aware (and I'd assume that there is no reason to ever change
that).

Just for the complete picture, there's also some endianness switch in the
NV_PMC_BOOT_1 register I think?
> All the CPU architectures our drivers support are expected to be
little-endian.
Technically, all Rust supported architectures are indeed little-endian.

However, the only constraint for the Nova project as by now is 64-bit only.