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

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?)
> 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.

Thanks,
Danilo

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.

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

https://lore.kernel.org/all/CAHk-=wgYcOiFvsJzFb+HfB4n6Wj6zM5H5EghUMfpXSCzyQVSfA
at mail.gmail.com/

Thanks,
Yury

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 at kernel.org/