rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/
@ 2025-10-03 15:47 Joel Fernandes
  2025-10-03 15:47 ` [PATCH v6 1/5] nova-core: bitfield: Move bitfield-specific code from register! into new macro Joel Fernandes
                   ` (6 more replies)
  0 siblings, 7 replies; 48+ messages in thread
From: Joel Fernandes @ 2025-10-03 15:47 UTC (permalink / raw)
  To: linux-kernel, rust-for-linux, dri-devel, dakr, acourbot
  Cc: Alistair Popple, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	bjorn3_gh, Benno Lossin, Andreas Hindborg, Alice Ryhl,
	Trevor Gross, David Airlie, Simona Vetter, Maarten Lankhorst,
	Maxime Ripard, Thomas Zimmermann, John Hubbard, Joel Fernandes,
	Timur Tabi, joel, Elle Rhumsaa, Yury Norov, Daniel Almeida,
	Andrea Righi, nouveau

Hello!

These patches extract and enhance the bitfield support in the register macro in
nova to define Rust structures with bitfields. It then moves out the bitfield
support into the kenrel crate.

Since v5, I dropped several patches and only kept the simple ones that do code
movement, added a few features and added a KUNIT test. After Alex's bounded
integer [1] support is in, we can rewrite the dropped patches.

I also dropped the MAINTAINER entry for now, pending more clarity around that.
I am happy to maintain it, but I need more input on who all will co-maintain,
now that the last 4 patches were dropped. Perhaps we can maintain it was a part
of the core rust-for-linux? I suggest let us create the maintainer entry once
Alex's bounded integer support is integrated but I am open to suggestions.

Here are the v5 patches [2].

[1] https://lore.kernel.org/all/20251002-bounded_ints-v1-0-dd60f5804ea4@nvidia.com/
[2] https://lore.kernel.org/all/20250930144537.3559207-1-joelagnelf@nvidia.com/

Joel Fernandes (5):
  nova-core: bitfield: Move bitfield-specific code from register! into
    new macro
  nova-core: bitfield: Add support for different storage widths
  nova-core: bitfield: Add support for custom visiblity
  rust: Move register and bitfield macros out of Nova
  rust: bitfield: Add KUNIT tests for bitfield

 drivers/gpu/nova-core/falcon.rs               |   2 +-
 drivers/gpu/nova-core/falcon/gsp.rs           |   4 +-
 drivers/gpu/nova-core/falcon/sec2.rs          |   2 +-
 drivers/gpu/nova-core/regs.rs                 |   6 +-
 rust/kernel/bitfield.rs                       | 654 ++++++++++++++++++
 rust/kernel/io.rs                             |   1 +
 .../macros.rs => rust/kernel/io/register.rs   | 301 +-------
 rust/kernel/lib.rs                            |   1 +
 8 files changed, 696 insertions(+), 275 deletions(-)
 create mode 100644 rust/kernel/bitfield.rs
 rename drivers/gpu/nova-core/regs/macros.rs => rust/kernel/io/register.rs (73%)


base-commit: 299eb32863e584cfff7c6b667c3e92ae7d4d2bf9
-- 
2.34.1


^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/
@ 2025-10-07 23:37 Joel Fernandes
  2025-10-08 10:23 ` Danilo Krummrich
  0 siblings, 1 reply; 48+ messages in thread
From: Joel Fernandes @ 2025-10-07 23:37 UTC (permalink / raw)
  To: Danilo Krummrich
  Cc: Alexandre Courbot, Yury Norov, linux-kernel@vger.kernel.org,
	rust-for-linux@vger.kernel.org, dri-devel@lists.freedesktop.org,
	Alistair Popple, Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	bjorn3_gh@protonmail.com, Benno Lossin, Andreas Hindborg,
	Alice Ryhl, Trevor Gross, David Airlie, Simona Vetter,
	Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, John Hubbard,
	Timur Tabi, joel@joelfernandes.org, Elle Rhumsaa, Daniel Almeida,
	Andrea Righi, nouveau@lists.freedesktop.org




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

^ permalink raw reply	[flat|nested] 48+ messages in thread
* Re: [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/
@ 2025-10-08 19:56 Joel Fernandes
  0 siblings, 0 replies; 48+ messages in thread
From: Joel Fernandes @ 2025-10-08 19:56 UTC (permalink / raw)
  To: Yury Norov
  Cc: Daniel Almeida, Alexandre Courbot, linux-kernel@vger.kernel.org,
	rust-for-linux@vger.kernel.org, dri-devel@lists.freedesktop.org,
	dakr@kernel.org, Alistair Popple, Miguel Ojeda, Alex Gaynor,
	Boqun Feng, Gary Guo, bjorn3_gh@protonmail.com, Benno Lossin,
	Andreas Hindborg, Alice Ryhl, Trevor Gross, David Airlie,
	Simona Vetter, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, John Hubbard, Timur Tabi,
	joel@joelfernandes.org, Elle Rhumsaa, Andrea Righi,
	nouveau@lists.freedesktop.org




> On Oct 8, 2025, at 11:50 AM, Yury Norov <yury.norov@gmail.com> wrote:
> On Tue, Oct 07, 2025 at 06:41:58PM -0300, Daniel Almeida wrote:
>> Hi,
>> 
>> First and foremost I’d like to say sorry for not having the bandwidth to
>> chime in here earlier. I’ve been pretty consumed by Tyr itself lately.
>> 
>>> On 7 Oct 2025, at 12:41, Yury Norov <yury.norov@gmail.com> wrote:
>>> On Tue, Oct 07, 2025 at 07:36:21PM +0900, Alexandre Courbot wrote:
>>>> Hi Yuri,
>>>> On Tue Oct 7, 2025 at 7:29 AM JST, Yury Norov wrote:
>>>> <snip>
>>>>> Regardless, I don't think that this is the right path to move the
>>>>> bitfields into the core. The natural path for a feature that has
>>>>> been originally developed on driver side is to mature in there and
>>>>> get merged to core libraries after a while. Resctrl from Intel is one
>>>>> recent example.
>>>>> With that said, I'm OK if you move the bitfields as a whole, like you
>>>>> do in v5, and I'm also OK if you split out the part essential for nova
>>>>> and take it into the driver. In that case the bitfields will stay in
>>>>> drivers and you'll be able to focus on the features that _you_ need,
>>>>> not on generic considerations.
>>>>> I'm not OK to move bitfields in their current (v6) incomplete form in
>>>>> rust/kernel. We still have no solid understanding on the API and
>>>>> implementation that we've been all agreed on.
>>>> Initially the plan was indeed to give this code some more time to mature
>>>> in nova-core before moving it out.
>>>> The reason for the early move is that we have another driver (Tyr) who
>>>> wants to start using the register macro. Without it, they would be left
>>>> with the option of either reinventing the wheel, or poking at registers
>>>> the old-fashioned way, which I think we can agree is not going to be any
>>>> safer than the current macro. :)
>> 
>> Tyr could use both register!() and bitfield!() today FYI. If you move it out, I can
>> follow with an actual patch to do so.
> 
> Not sure I understand this. Does it mean that you have use cases
> for bitfields unrelated to I/O registers? Can you please share
> details on what you need and sketch some examples? Particularly,
> do you have arrays of bitfields in mind?
> 
> If my understanding is correct, then I think the strategy that
> meets your interests at best would be moving the registers out of
> Nova earlier. After that both Tyr and Nova people will get equally
> involved in bitfields (and possible BoundedInt) development.

Yes, but how would that help Nova? There does not seem to be much reason to not move it out together - did you see my email where I enlisted all the issues? Daniel was suggesting moving it out together, so he can use both, which afaics everyone here is agreeing on as well.

> 
> This is what Danilo proposed in the other email, and I agree that it's
> the most structured path.
> 
> Regarding timeline, I think 2-stage approach will eventually become
> faster.

Not really. Essentially that means duplicating the bitfield code both within nova and outside nova for no good reason. Nova needs bitfield and register both. Moving register out without bitfield means duplicating bitfield code within nova. We definitely do not want that. Also the work to move it out is already done.

I think I do not understand what are the technical reasons to hold it up any further? If you have a concern about being moved out together, please participate in the discussion where I sent a long email enlisting all the issues and we can discuss each issue there. We would want only technical reasons, not hypotheticals. As Alex said, there is a greater chance of badly written code if people reinvent these features themselves. Out of those issues in the long email, only the bounded integer is the open issue. But even that is not something that should be holding this up IMO since Alex already has RFC to fix it, and it does not really effect the API usage much. I think Alex had some very good reasons to move the code out as well and we can improve on the bounded integer issue further perhaps even before the next merge window.

Tyr will use both right away as Daniel mentioned, and I can say the same for Nova. So what is the problem?

No doubt there will be incremental improvements to both macros. They are in pretty good shape and there is no need to wait for them to be perfect. Let us not make perfection the enemy of progress :)

Thanks!

Joel


> 
> Thanks,
> Yury

^ permalink raw reply	[flat|nested] 48+ messages in thread

end of thread, other threads:[~2025-10-27 15:05 UTC | newest]

Thread overview: 48+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-03 15:47 [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/ Joel Fernandes
2025-10-03 15:47 ` [PATCH v6 1/5] nova-core: bitfield: Move bitfield-specific code from register! into new macro Joel Fernandes
2025-10-06 17:56   ` Edwin Peer
2025-10-07  6:49     ` Alexandre Courbot
2025-10-03 15:47 ` [PATCH v6 2/5] nova-core: bitfield: Add support for different storage widths Joel Fernandes
2025-10-03 15:47 ` [PATCH v6 3/5] nova-core: bitfield: Add support for custom visiblity Joel Fernandes
2025-10-03 15:47 ` [PATCH v6 4/5] rust: Move register and bitfield macros out of Nova Joel Fernandes
2025-10-06 10:38   ` Alexandre Courbot
2025-10-09  6:59   ` Dirk Behme
2025-10-09 11:16     ` Danilo Krummrich
2025-10-09 11:28       ` Alexandre Courbot
2025-10-09 12:54         ` Danilo Krummrich
2025-10-10  7:28       ` Dirk Behme
2025-10-22 18:40   ` Beata Michalska
2025-10-22 19:37     ` Joel Fernandes
2025-10-23 13:55       ` Beata Michalska
2025-10-23 14:07         ` Danilo Krummrich
2025-10-23 21:47         ` Joel Fernandes
2025-10-23 21:50           ` Joel Fernandes
2025-10-27  9:06           ` Beata Michalska
2025-10-27  9:56             ` Danilo Krummrich
2025-10-27 15:05               ` Beata Michalska
2025-10-03 15:47 ` [PATCH v6 5/5] rust: bitfield: Add KUNIT tests for bitfield Joel Fernandes
2025-10-06 10:37   ` Alexandre Courbot
2025-10-06 19:38     ` Joel Fernandes
2025-10-06 20:36   ` [PATCH v7] " Joel Fernandes
2025-10-06 18:05 ` [PATCH v6 0/5] Introduce bitfield and move register macro to rust/kernel/ Edwin Peer
2025-10-06 22:29 ` Yury Norov
2025-10-07 10:36   ` Alexandre Courbot
2025-10-07 10:42     ` Miguel Ojeda
2025-10-07 13:20       ` Alexandre Courbot
2025-10-07 16:06         ` Yury Norov
2025-10-07 16:12         ` Miguel Ojeda
2025-10-07 13:16     ` Danilo Krummrich
2025-10-07 21:08       ` Joel Fernandes
2025-10-07 22:08         ` Danilo Krummrich
2025-10-08 14:28           ` Yury Norov
2025-10-08 15:00             ` Danilo Krummrich
2025-10-07 15:41     ` Yury Norov
2025-10-07 21:41       ` Daniel Almeida
2025-10-08 15:49         ` Yury Norov
  -- strict thread matches above, loose matches on Subject: below --
2025-10-07 23:37 Joel Fernandes
2025-10-08 10:23 ` Danilo Krummrich
2025-10-08 10:47   ` Greg KH
2025-10-08 10:49     ` Danilo Krummrich
2025-10-09  0:24   ` Joel Fernandes
2025-10-09 13:02     ` Danilo Krummrich
2025-10-08 19:56 Joel Fernandes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).