> On Oct 7, 2025, at 6:09 PM, Danilo Krummrich <[email protected]> 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
