Am 10.11.23 um 17:57 schrieb Danilo Krummrich:
On 11/10/23 09:50, Christian König wrote:
[SNIP]
Another issue Christian brought up is that something intended to
be embeddable (a base class) shouldn't really have its own
refcount. I think that's a valid point. If you at some point need
to derive from multiple such structs each having its own refcount,
things will start to get weird. One way to resolve that would be
to have the driver's subclass provide get() and put() ops, and
export a destructor for the base-class, rather than to have the
base-class provide the refcount and a destructor ops.
GPUVM simply follows the same pattern we have with drm_gem_objects.
And I think it makes
sense. Why would we want to embed two struct drm_gpuvm in a single
driver structure?
Because you need one drm_gpuvm structure for each application using
the driver? Or am I missing something?
Right, *one*, but not more than one. Wasn't that the concern? Maybe I
misunderstood something. :)
Well, there is the use case of native context with XEN/KVM. In that
situation QEMU opens tons of driver file descriptors on behalves of the
virtual environment clients.
In this use case you have many drm_gpuvm instances for a single
application. So you can't assume that you only have one VM per PID/TGID
or something like that.
AMD already made that mistake with KFD and I strongly suggest not to
repeat it :)
Regards,
Christian.
