On Tue, 25 Nov 2025 at 18:11, Christian König <[email protected]> wrote: > > On 11/25/25 08:59, John Hubbard wrote: > > On 11/24/25 11:54 PM, Christian König wrote: > >> On 11/25/25 08:49, Dave Airlie wrote: > >>> On Tue, 25 Nov 2025 at 17:45, Christian König <[email protected]> > >>> wrote: > > ... > >> My question is why exactly is nova separated into nova-core and nova-drm? > >> That doesn't seem to be necessary in the first place. > >> > > The idea is that nova-core allows building up a separate software stack for > > VFIO, without pulling in any DRM-specific code that a hypervisor (for > > example) > > wouldn't need. That makes for a smaller, more security-auditable set of code > > for that case. > > Well that is the same argument used by some AMD team to maintain a separate > out of tree hypervisor for nearly a decade. > > Additional to that the same argument has also been used to justify the KFD > node as alternative API to DRM for compute. > > Both cases have proven to be extremely bad ideas. > > Background is that except for all the legacy stuff the DRM API is actually > very well thought through and it is actually quite hard to come up with > something similarly well. >
Well you just answered your own question, why is AMD maintaining GIM instead of solving this upstream with a split model? the nova-core/drm split would be perfect for GIM. kfd was a terrible idea, and we don't intend to offer userspace multiple APIs with nova, nova-drm will be the primary userspace API provider. nova-core will not provide userspace API, it will provide an API to nova-drm and an API to the vgpu driver which will provide it's own userspace API without graphics or compute, just enough to setup VFs. Dave.
