lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251125143339.361cc3bb.zhiw@nvidia.com>
Date: Tue, 25 Nov 2025 14:36:59 +0200
From: Zhi Wang <zhiw@...dia.com>
To: Christian König <christian.koenig@....com>
CC: John Hubbard <jhubbard@...dia.com>, Dave Airlie <airlied@...il.com>, "Joel
 Fernandes" <joelagnelf@...dia.com>, <linux-kernel@...r.kernel.org>, "Maarten
 Lankhorst" <maarten.lankhorst@...ux.intel.com>, Maxime Ripard
	<mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>, "Simona
 Vetter" <simona@...ll.ch>, Jonathan Corbet <corbet@....net>, Alex Deucher
	<alexander.deucher@....com>, Jani Nikula <jani.nikula@...ux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>, Rodrigo Vivi
	<rodrigo.vivi@...el.com>, Tvrtko Ursulin <tursulin@...ulin.net>, Huang Rui
	<ray.huang@....com>, Matthew Auld <matthew.auld@...el.com>, Matthew Brost
	<matthew.brost@...el.com>, Lucas De Marchi <lucas.demarchi@...el.com>, Thomas
 Hellström <thomas.hellstrom@...ux.intel.com>, Helge Deller
	<deller@....de>, Danilo Krummrich <dakr@...nel.org>, Alice Ryhl
	<aliceryhl@...gle.com>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor
	<alex.gaynor@...il.com>, Boqun Feng <boqun.feng@...il.com>, Gary Guo
	<gary@...yguo.net>, Björn Roy Baron
	<bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>, "Andreas
 Hindborg" <a.hindborg@...nel.org>, Trevor Gross <tmgross@...ch.edu>,
	"Alistair Popple" <apopple@...dia.com>, Timur Tabi <ttabi@...dia.com>, Edwin
 Peer <epeer@...dia.com>, Alexandre Courbot <acourbot@...dia.com>,
	<nouveau@...ts.freedesktop.org>, <dri-devel@...ts.freedesktop.org>,
	<rust-for-linux@...r.kernel.org>, <linux-doc@...r.kernel.org>,
	<amd-gfx@...ts.freedesktop.org>, <intel-gfx@...ts.freedesktop.org>,
	<intel-xe@...ts.freedesktop.org>, <linux-fbdev@...r.kernel.org>
Subject: Re: [PATCH] gpu: Move DRM buddy allocator one level up

On Tue, 25 Nov 2025 09:10:54 +0100
Christian König <christian.koenig@....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@....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,
> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ