On Wed, Sep 25, 2024 at 08:52:32AM +1000, Dave Airlie wrote: > On Wed, 25 Sept 2024 at 05:57, Danilo Krummrich <dakr@xxxxxxxxxx> wrote: > > > > On Tue, Sep 24, 2024 at 01:41:51PM -0300, Jason Gunthorpe wrote: > > > On Tue, Sep 24, 2024 at 12:50:55AM +0200, Danilo Krummrich wrote: > > > > > > > > From the VFIO side I would like to see something like this merged in > > > > > nearish future as it would bring a previously out of tree approach to > > > > > be fully intree using our modern infrastructure. This is a big win for > > > > > the VFIO world. > > > > > > > > > > As a commercial product this will be backported extensively to many > > > > > old kernels and that is harder/impossible if it isn't exclusively in > > > > > C. So, I think nova needs to co-exist in some way. > > > > > > > > We'll surely not support two drivers for the same thing in the long term, > > > > neither does it make sense, nor is it sustainable. > > > > > > What is being done here is the normal correct kernel thing to > > > do. Refactor the shared core code into a module and stick higher level > > > stuff on top of it. Ideally Nova/Nouveau would exist as peers > > > implementing DRM subsystem on this shared core infrastructure. We've > > > done this sort of thing before in other places in the kernel. It has > > > been proven to work well. > > > > So, that's where you have the wrong understanding of what we're > > working on: You seem to think that Nova is just another DRM > > subsystem layer on top of the NVKM parts (what you call the core > > driver) of Nouveau. Well, no, I am calling a core driver to be the very minimal parts that are actually shared between vfio and drm. It should definitely not include key parts you want to work on in rust, like the command marshaling. I expect there is more work to do in order to make this kind of split, but this is what I'm thinking/expecting. > > But the whole point of Nova is to replace the NVKM parts of Nouveau, since > > that's where the problems we want to solve reside in. > > Just to re-emphasise for Jason who might not be as across this stuff, > > NVKM replacement with rust is the main reason for the nova project, > 100% the driving force for nova is the unstable NVIDIA firmware API. > The ability to use rust proc-macros to hide the NVIDIA instability > instead of trying to do it in C by either generators or abusing C > macros (which I don't think are sufficient). I would not include any of this in the very core most driver. My thinking is informed by what we've done in RDMA, particularly mlx5 which has a pretty thin PCI driver and each of the drivers stacked on top form their own command buffers directly. The PCI driver primarily just does some device bootup, command execution and interrupts because those are all shared by the subsystem drivers. We have a lot of experiance now building these kinds of multi-subsystem structures and this pattern works very well. So, broadly, build your rust proc macros on the DRM Nova driver and call a core function to submit a command buffer to the device and get back a response. VFIO will make it's command buffers with C and call the same core function. > I think the idea of a nova drm and nova core driver architecture is > acceptable to most of us, but long term trying to main a nouveau based > nvkm is definitely not acceptable due to the unstable firmware APIs. ? nova core, meaning nova rust, meaning vfio depends on rust, doesn't seem acceptable ? We need to keep rust isolated to DRM for the foreseeable future. Just need to find a separation that can do that. Jason
