Re: [PATCH 01/13] drm/amdgpu: introduce and honour DRM_FORCE_AUTH workaround

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 4, 2019 at 1:24 PM Koenig, Christian
<Christian.Koenig@xxxxxxx> wrote:
>
> Am 04.06.19 um 12:50 schrieb Michel Dänzer:
> > On 2019-05-28 10:03 a.m., Koenig, Christian wrote:
> >> I rather think that we should go down the route of completely dropping
> >> command submission and buffer allocation through the primary node for
> >> non master clients. And then as next step at some point drop support for
> >> authentication/flink.
> > Keep in mind that even display servers aren't DRM master while their VT
> > isn't active, so this might be problematic if a display server needs to
> > do some command submission / buffer allocation during that time.
>
> If I understand it correctly the DRM fd stays master even when the VT is
> switched away, it's just not the current master any more.
>
> So in this case fpriv->is_master stays true, but
> drm_is_current_master(fpriv) returns false.
>
> And yes we mixed that up in amdgpu, i915 and vmwgfx. Somebody should
> probably write patches to fix this.

master should always be authenticated, so should be able to continue
rendering. Well ... except on drivers who do take isolation somewhat
serious, but don't have full per-client isolation. Those actually
refuse rendering/gpu access for any authenticated client if their
corresponding master isn't the current master. But I think only vmwgfx
does that.

Per-client isolation has taken over anyway, so all a bit moot, at
least on modern hw.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux