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 <christian.koenig at amd.com> 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. Regards, Christian.> > thanks,
On Tue, 25 Nov 2025 at 18:11, Christian K?nig <christian.koenig at amd.com> 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 <christian.koenig at amd.com> 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.
On Tue, 25 Nov 2025 09:10:54 +0100 Christian K?nig <christian.koenig at amd.com> 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 > >>> <christian.koenig at amd.com> 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. >I guess you mean the VFIO driver? [1] In the code, it is bascially to support the migration, which is simiar as any other in-tree VFIO drivers. The questionable parts might be how to clean up those callbacks supporting migration and get them into mainline. Those callbacks stays in the PF driver, either talks to HW or firmware interface to control VF states, obtain the bitstream, which contains VF states and data. IMO, they should be quite self-contained and userspace shouldn't be invovled. Userspace (QEMU) only talks to VFIO. This is just my initial impression from briefly looking at the code. :) [1] https://github.com/amd/MxGPU-Virtualization/blob/staging/amd-vfio-pci/amd-vfio.c> 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. > > Regards, > Christian. > > > > > thanks, > >