[PATCH] drm/doc: device hot-unplug for userspace

[PATCH] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

From: Pekka Paalanen <pekka.paalanen@collabora.com>

Set up the expectations on how hot-unplugging a DRM device should look like to
userspace.

Written by Daniel Vetter's request and largely based on his comments in IRC and
from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Sean Paul <sean@poorly.run>

---

Disclaimer: I am a userspace developer writing for other userspace developers.
I took some liberties in defining what should happen without knowing what is
actually possible or what existing drivers already implement.
---
 Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
 1 file changed, 75 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 56fec6ed1ad8..80db4abd2cbd 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -1,3 +1,5 @@
+.. Copyright 2020 DisplayLink (UK) Ltd.
+
 ===================
 Userland interfaces
 ===================
@@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
 visible to user-space and accessible beyond open-file boundaries, they
 cannot support render nodes.
 
+Device Hot-Unplug
+=================
+
+.. note::
+   The following is the plan. Implementation is not there yet
+   (2020 May 13).
+
+Graphics devices (display and/or render) may be connected via USB (e.g.
+display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
+user is able to hot-unplug this kind of devices while they are being
+used, and expects that the very least the machine does not crash. Any
+damage from hot-unplugging a DRM device needs to be limited as much as
+possible and userspace must be given the chance to handle it if it wants
+to. Ideally, unplugging a DRM device still lets a desktop to continue
+running, but that is going to need explicit support throughout the whole
+graphics stack: from kernel and userspace drivers, through display
+servers, via window system protocols, and in applications and libraries.
+
+Other scenarios that should lead to the same are: unrecoverable GPU
+crash, PCI device disappearing off the bus, or forced unbind of a driver
+from the physical device.
+
+In other words, from userspace perspective everything needs to keep on
+working more or less, until userspace stops using the disappeared DRM
+device and closes it completely. Userspace will learn of the device
+disappearance from the device removed uevent or in some cases specific
+ioctls returning EIO.
+
+This goal raises at least the following requirements for the kernel and
+drivers:
+
+- The kernel must not hang, crash or oops, no matter what userspace was
+  in the middle of doing when the device disappeared.
+
+- All GPU jobs that can no longer run must have their fences
+  force-signalled to avoid inflicting hangs to userspace.
+
+- KMS connectors must change their status to disconnected.
+
+- Legacy modesets and pageflips fake success.
+
+- Atomic commits, both real and TEST_ONLY, fake success.
+
+- Pending non-blocking KMS operations deliver the DRM events userspace
+  is expecting.
+
+- If underlying memory disappears, the mmaps are replaced with harmless
+  zero pages where access does not raise SIGBUS. Reads return zeros,
+  writes are ignored.
+
+- dmabuf which point to memory that has disappeared are rewritten to
+  point to harmless zero pages, similar to mmaps. Imports still succeed
+  both ways: an existing device importing a dmabuf pointing to
+  disappeared memory, and a disappeared device importing any dmabuf.
+
+- Render ioctls return EIO which is then handled in userspace drivers,
+  e.g. Mesa, to have the device disappearance handled in the way
+  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
+  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
+
+Raising SIGBUS is not an option, because userspace cannot realistically
+handle it.  Signal handlers are global, which makes them extremely
+difficult to use correctly from libraries like Mesa produces. Signal
+handlers are not composable, you can't have different handlers for GPU1
+and GPU2 from different vendors, and a third handler for mmapped regular
+files.  Threads cause additional pain with signal handling as well.
+
+Only after userspace has closed all relevant DRM device and dmabuf file
+descriptors and removed all mmaps, the DRM driver can tear down its
+instance for the device that no longer exists. If the same physical
+device somehow comes back in the mean time, it shall be a new DRM
+device.
+
 .. _drm_driver_ioctl:
 
 IOCTL Support on Device Nodes
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Andrey Grodzovsky]

Thanks for the summary, does put things in order and makes it easier to 
comprehend all the TODOs, some questions bellow

On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783&amp;sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3D&amp;reserved=0 .
>
> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Sean Paul <sean@poorly.run>
>
> ---
>
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>   Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
>   1 file changed, 75 insertions(+)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..80db4abd2cbd 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -1,3 +1,5 @@
> +.. Copyright 2020 DisplayLink (UK) Ltd.
> +
>   ===================
>   Userland interfaces
>   ===================
> @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
>   visible to user-space and accessible beyond open-file boundaries, they
>   cannot support render nodes.
>   
> +Device Hot-Unplug
> +=================
> +
> +.. note::
> +   The following is the plan. Implementation is not there yet
> +   (2020 May 13).
> +
> +Graphics devices (display and/or render) may be connected via USB (e.g.
> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> +user is able to hot-unplug this kind of devices while they are being
> +used, and expects that the very least the machine does not crash. Any
> +damage from hot-unplugging a DRM device needs to be limited as much as
> +possible and userspace must be given the chance to handle it if it wants
> +to. Ideally, unplugging a DRM device still lets a desktop to continue
> +running, but that is going to need explicit support throughout the whole
> +graphics stack: from kernel and userspace drivers, through display
> +servers, via window system protocols, and in applications and libraries.
> +
> +Other scenarios that should lead to the same are: unrecoverable GPU
> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> +from the physical device.
> +
> +In other words, from userspace perspective everything needs to keep on
> +working more or less, until userspace stops using the disappeared DRM
> +device and closes it completely. Userspace will learn of the device
> +disappearance from the device removed uevent or in some cases specific
> +ioctls returning EIO.
> +
> +This goal raises at least the following requirements for the kernel and
> +drivers:
> +
> +- The kernel must not hang, crash or oops, no matter what userspace was
> +  in the middle of doing when the device disappeared.
> +
> +- All GPU jobs that can no longer run must have their fences
> +  force-signalled to avoid inflicting hangs to userspace.
> +
> +- KMS connectors must change their status to disconnected.
> +
> +- Legacy modesets and pageflips fake success.
> +
> +- Atomic commits, both real and TEST_ONLY, fake success.


Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip 
and modeset ioctls here same way as you suggested returning -EIO for 
render ioctl ?

> +
> +- Pending non-blocking KMS operations deliver the DRM events userspace
> +  is expecting.
> +
> +- If underlying memory disappears, the mmaps are replaced with harmless
> +  zero pages where access does not raise SIGBUS. Reads return zeros,
> +  writes are ignored.
> +
> +- dmabuf which point to memory that has disappeared are rewritten to
> +  point to harmless zero pages, similar to mmaps. Imports still succeed
> +  both ways: an existing device importing a dmabuf pointing to
> +  disappeared memory, and a disappeared device importing any dmabuf.


Same as above, I would expect drmPrimeHandleToFD and drmPrimeFDToHandle 
to return -EIO in case device is detached


> +
> +- Render ioctls return EIO which is then handled in userspace drivers,
> +  e.g. Mesa, to have the device disappearance handled in the way
> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)


As far as I understood from our discussion we would reject any IOCTL 
aimed at a device which is gone and not only render ioctls.

Andrey


> +
> +Raising SIGBUS is not an option, because userspace cannot realistically
> +handle it.  Signal handlers are global, which makes them extremely
> +difficult to use correctly from libraries like Mesa produces. Signal
> +handlers are not composable, you can't have different handlers for GPU1
> +and GPU2 from different vendors, and a third handler for mmapped regular
> +files.  Threads cause additional pain with signal handling as well.
> +
> +Only after userspace has closed all relevant DRM device and dmabuf file
> +descriptors and removed all mmaps, the DRM driver can tear down its
> +instance for the device that no longer exists. If the same physical
> +device somehow comes back in the mean time, it shall be a new DRM
> +device.
> +
>   .. _drm_driver_ioctl:
>   
>   IOCTL Support on Device Nodes
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 10240 bytes --]

On Tue, 19 May 2020 10:37:12 -0400
Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:

> Thanks for the summary, does put things in order and makes it easier to 
> comprehend all the TODOs, some questions bellow
> 
> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> >
> > Set up the expectations on how hot-unplugging a DRM device should look like to
> > userspace.
> >
> > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783&amp;sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3D&amp;reserved=0 .
> >
> > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Sean Paul <sean@poorly.run>
> >
> > ---
> >
> > Disclaimer: I am a userspace developer writing for other userspace developers.
> > I took some liberties in defining what should happen without knowing what is
> > actually possible or what existing drivers already implement.
> > ---
> >   Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
> >   1 file changed, 75 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index 56fec6ed1ad8..80db4abd2cbd 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -1,3 +1,5 @@
> > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > +
> >   ===================
> >   Userland interfaces
> >   ===================
> > @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
> >   visible to user-space and accessible beyond open-file boundaries, they
> >   cannot support render nodes.
> >   
> > +Device Hot-Unplug
> > +=================
> > +
> > +.. note::
> > +   The following is the plan. Implementation is not there yet
> > +   (2020 May 13).
> > +
> > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > +user is able to hot-unplug this kind of devices while they are being
> > +used, and expects that the very least the machine does not crash. Any
> > +damage from hot-unplugging a DRM device needs to be limited as much as
> > +possible and userspace must be given the chance to handle it if it wants
> > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > +running, but that is going to need explicit support throughout the whole
> > +graphics stack: from kernel and userspace drivers, through display
> > +servers, via window system protocols, and in applications and libraries.
> > +
> > +Other scenarios that should lead to the same are: unrecoverable GPU
> > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > +from the physical device.
> > +
> > +In other words, from userspace perspective everything needs to keep on
> > +working more or less, until userspace stops using the disappeared DRM
> > +device and closes it completely. Userspace will learn of the device
> > +disappearance from the device removed uevent or in some cases specific
> > +ioctls returning EIO.
> > +
> > +This goal raises at least the following requirements for the kernel and
> > +drivers:
> > +
> > +- The kernel must not hang, crash or oops, no matter what userspace was
> > +  in the middle of doing when the device disappeared.
> > +
> > +- All GPU jobs that can no longer run must have their fences
> > +  force-signalled to avoid inflicting hangs to userspace.
> > +
> > +- KMS connectors must change their status to disconnected.
> > +
> > +- Legacy modesets and pageflips fake success.
> > +
> > +- Atomic commits, both real and TEST_ONLY, fake success.  
> 
> 
> Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip 
> and modeset ioctls here same way as you suggested returning -EIO for 
> render ioctl ?

Hi,

that is more of a question for Daniel Vetter than me. I believe he is
worried that userspace will get the error handling horribly wrong
anyway, because it needs to be handled in every single display server
project. Render ioctl errors OTOH need to be handled only in the
corresponding Mesa or other userspace driver, and for render there are
API (OpenGL/EGL, Vulkan) specs that say how it must be handled to fill
the API contract. Because of the API contract, those are more likely to
have reasonable error handling in place already.

I first thought it would be obvious for at least atomic commits to fail
appropriately, but then thinking again, it will only introduce new
failures that are currently very hard to test for (VKMS to the rescue),
and userspace would need to have code to correctly bail out for EIO
rather than attempt fallbacks. The uevent telling the device is gone is
going to come anyway. In between the device disappearance and uevent
handling, it doesn't matter much what happens: the device is abruptly
gone and the user will see a glitch anyway - he knows, he just yanked
out the cable.

To me this decision is just to make life in userspace easier by not
introducing a whole new type of error. However, if the kernel did
return EIO instead, it would be impossible for me to see that as a
kernel regression because the old behaviour was probably explosions
everywhere anyway.

I heard that UDL and maybe some other drivers in the kernel already
handle hot-unplug somehow. Maybe those are what would regress if the
kernel returned EIO?


> > +
> > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > +  is expecting.
> > +
> > +- If underlying memory disappears, the mmaps are replaced with harmless
> > +  zero pages where access does not raise SIGBUS. Reads return zeros,
> > +  writes are ignored.
> > +
> > +- dmabuf which point to memory that has disappeared are rewritten to
> > +  point to harmless zero pages, similar to mmaps. Imports still succeed
> > +  both ways: an existing device importing a dmabuf pointing to
> > +  disappeared memory, and a disappeared device importing any dmabuf.  
> 
> 
> Same as above, I would expect drmPrimeHandleToFD and drmPrimeFDToHandle 
> to return -EIO in case device is detached

I imagined a use case behind this: a Wayland compositor attempting to
import a client's dmabuf. The GPU the client was using is
hot-unplugged, meaning the dmabufs lose their storage. It is up to the
client to handle its rendering GPU disappearance on its own, but also
the compositor should not disconnect it because the GPU disappeared.
It's not the client's fault the GPU disappeared.

In Wayland, failure to use a wl_buffer is considered a protocol error,
and protocol errors are always fatal: the client is disconnected. The
rationale is that the compositor must always be able to present the
client buffer somehow. If the compositor cannot, then the client did
not obey the protocol.

The fallback presentation path in a compositor is usually importing the
dmabuf to EGL, to be sampled from OpenGL. Normally the protocol
guarantees that this works, so any failure to do so is a protocol
violation. But if the GPU used by the client suddenly disappears and
the imports start to fail, that is interpreted as a protocol violation
unless the compositor can see why the import failed. Since the import
is done via EGL, getting the right error code plumbed through from
libdrm functions to the EGL caller would be a hassle. I don't see any
error code in EGL_EXT_image_dma_buf_import reserved for "the dmabuf
storage was hot-unplugged", and I doubt there is anything exclusively
for only that in the EGL base spec either.

The cost of lying that the import worked is that the compositor will
paint black or transparent where the window was supposed to be. It's a
graphical glitch that is contrary to the Wayland design principles, but
in this case a glitch is unavoidable: even if the compositor knew this
buffer is now bad, what would it paint instead? It has nothing else to
paint from. I'm assuming the compositor is using a different GPU than
what disappeared.

Ideally, the client will eventually react to losing the GPU and either
crash, quit, or switch its rendering to something that works which
simply gives the compositor a new, working buffer without losing any
window state in the process. If we risk the compositor disconnecting
the client, then the client might not recover even if it wanted to.

> > +
> > +- Render ioctls return EIO which is then handled in userspace drivers,
> > +  e.g. Mesa, to have the device disappearance handled in the way
> > +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> > +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)  
> 
> 
> As far as I understood from our discussion we would reject any IOCTL 
> aimed at a device which is gone and not only render ioctls.

Daniel?


Thanks,
pq

> 
> Andrey
> 
> 
> > +
> > +Raising SIGBUS is not an option, because userspace cannot realistically
> > +handle it.  Signal handlers are global, which makes them extremely
> > +difficult to use correctly from libraries like Mesa produces. Signal
> > +handlers are not composable, you can't have different handlers for GPU1
> > +and GPU2 from different vendors, and a third handler for mmapped regular
> > +files.  Threads cause additional pain with signal handling as well.
> > +
> > +Only after userspace has closed all relevant DRM device and dmabuf file
> > +descriptors and removed all mmaps, the DRM driver can tear down its
> > +instance for the device that no longer exists. If the same physical
> > +device somehow comes back in the mean time, it shall be a new DRM
> > +device.
> > +
> >   .. _drm_driver_ioctl:
> >   
> >   IOCTL Support on Device Nodes  


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote:
> On Tue, 19 May 2020 10:37:12 -0400
> Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
> 
> > Thanks for the summary, does put things in order and makes it easier to 
> > comprehend all the TODOs, some questions bellow
> > 
> > On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> > > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> > >
> > > Set up the expectations on how hot-unplugging a DRM device should look like to
> > > userspace.
> > >
> > > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > > from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783&amp;sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3D&amp;reserved=0 .
> > >
> > > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > > Cc: Dave Airlie <airlied@redhat.com>
> > > Cc: Sean Paul <sean@poorly.run>
> > >
> > > ---
> > >
> > > Disclaimer: I am a userspace developer writing for other userspace developers.
> > > I took some liberties in defining what should happen without knowing what is
> > > actually possible or what existing drivers already implement.
> > > ---
> > >   Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
> > >   1 file changed, 75 insertions(+)
> > >
> > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > > index 56fec6ed1ad8..80db4abd2cbd 100644
> > > --- a/Documentation/gpu/drm-uapi.rst
> > > +++ b/Documentation/gpu/drm-uapi.rst
> > > @@ -1,3 +1,5 @@
> > > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > > +
> > >   ===================
> > >   Userland interfaces
> > >   ===================
> > > @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
> > >   visible to user-space and accessible beyond open-file boundaries, they
> > >   cannot support render nodes.
> > >   
> > > +Device Hot-Unplug
> > > +=================
> > > +
> > > +.. note::
> > > +   The following is the plan. Implementation is not there yet
> > > +   (2020 May 13).
> > > +
> > > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > > +user is able to hot-unplug this kind of devices while they are being
> > > +used, and expects that the very least the machine does not crash. Any
> > > +damage from hot-unplugging a DRM device needs to be limited as much as
> > > +possible and userspace must be given the chance to handle it if it wants
> > > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > > +running, but that is going to need explicit support throughout the whole
> > > +graphics stack: from kernel and userspace drivers, through display
> > > +servers, via window system protocols, and in applications and libraries.
> > > +
> > > +Other scenarios that should lead to the same are: unrecoverable GPU
> > > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > > +from the physical device.
> > > +
> > > +In other words, from userspace perspective everything needs to keep on
> > > +working more or less, until userspace stops using the disappeared DRM
> > > +device and closes it completely. Userspace will learn of the device
> > > +disappearance from the device removed uevent or in some cases specific
> > > +ioctls returning EIO.
> > > +
> > > +This goal raises at least the following requirements for the kernel and
> > > +drivers:
> > > +
> > > +- The kernel must not hang, crash or oops, no matter what userspace was
> > > +  in the middle of doing when the device disappeared.
> > > +
> > > +- All GPU jobs that can no longer run must have their fences
> > > +  force-signalled to avoid inflicting hangs to userspace.
> > > +
> > > +- KMS connectors must change their status to disconnected.
> > > +
> > > +- Legacy modesets and pageflips fake success.
> > > +
> > > +- Atomic commits, both real and TEST_ONLY, fake success.  
> > 
> > 
> > Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip 
> > and modeset ioctls here same way as you suggested returning -EIO for 
> > render ioctl ?
> 
> Hi,
> 
> that is more of a question for Daniel Vetter than me. I believe he is
> worried that userspace will get the error handling horribly wrong
> anyway, because it needs to be handled in every single display server
> project. Render ioctl errors OTOH need to be handled only in the
> corresponding Mesa or other userspace driver, and for render there are
> API (OpenGL/EGL, Vulkan) specs that say how it must be handled to fill
> the API contract. Because of the API contract, those are more likely to
> have reasonable error handling in place already.

Yup pretty much. Atm compositors expect an -EINVAL (especially for
TEST_ONLY), some cope with the semi-spurious -EBUSY we still throw around,
but I expect most will just die if the get an -ENOMEM or -EIO or really
anything.

I think one area where we've historically thrown some spurious errors is
also vblank ioctls, since they don't take full locks and sometimes the
kernel needs to sneak in a modeset for some reason (gpu recovery, dp link
recovery, ...).

Either way I don't think there's anything the compositor can do than just
ignore the error and carry on.

> I first thought it would be obvious for at least atomic commits to fail
> appropriately, but then thinking again, it will only introduce new
> failures that are currently very hard to test for (VKMS to the rescue),
> and userspace would need to have code to correctly bail out for EIO
> rather than attempt fallbacks. The uevent telling the device is gone is
> going to come anyway. In between the device disappearance and uevent
> handling, it doesn't matter much what happens: the device is abruptly
> gone and the user will see a glitch anyway - he knows, he just yanked
> out the cable.
> 
> To me this decision is just to make life in userspace easier by not
> introducing a whole new type of error. However, if the kernel did
> return EIO instead, it would be impossible for me to see that as a
> kernel regression because the old behaviour was probably explosions
> everywhere anyway.
> 
> I heard that UDL and maybe some other drivers in the kernel already
> handle hot-unplug somehow. Maybe those are what would regress if the
> kernel returned EIO?

I think most of the not-explodey drivers currently just (mostly?) it all
hw errors. You kinda have to if you actually want to deal with hotunplug,
stuff can disappear for any moment without warning anyway. Starting to
just skip everything is the simplest approach, plus in large parts of the
modeset helpers we don't even return values - kernel drivers suck as much
at handling the unexpected errors as userspace :-)
-Daniel

> 
> 
> > > +
> > > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > > +  is expecting.
> > > +
> > > +- If underlying memory disappears, the mmaps are replaced with harmless
> > > +  zero pages where access does not raise SIGBUS. Reads return zeros,
> > > +  writes are ignored.
> > > +
> > > +- dmabuf which point to memory that has disappeared are rewritten to
> > > +  point to harmless zero pages, similar to mmaps. Imports still succeed
> > > +  both ways: an existing device importing a dmabuf pointing to
> > > +  disappeared memory, and a disappeared device importing any dmabuf.  
> > 
> > 
> > Same as above, I would expect drmPrimeHandleToFD and drmPrimeFDToHandle 
> > to return -EIO in case device is detached
> 
> I imagined a use case behind this: a Wayland compositor attempting to
> import a client's dmabuf. The GPU the client was using is
> hot-unplugged, meaning the dmabufs lose their storage. It is up to the
> client to handle its rendering GPU disappearance on its own, but also
> the compositor should not disconnect it because the GPU disappeared.
> It's not the client's fault the GPU disappeared.
> 
> In Wayland, failure to use a wl_buffer is considered a protocol error,
> and protocol errors are always fatal: the client is disconnected. The
> rationale is that the compositor must always be able to present the
> client buffer somehow. If the compositor cannot, then the client did
> not obey the protocol.
> 
> The fallback presentation path in a compositor is usually importing the
> dmabuf to EGL, to be sampled from OpenGL. Normally the protocol
> guarantees that this works, so any failure to do so is a protocol
> violation. But if the GPU used by the client suddenly disappears and
> the imports start to fail, that is interpreted as a protocol violation
> unless the compositor can see why the import failed. Since the import
> is done via EGL, getting the right error code plumbed through from
> libdrm functions to the EGL caller would be a hassle. I don't see any
> error code in EGL_EXT_image_dma_buf_import reserved for "the dmabuf
> storage was hot-unplugged", and I doubt there is anything exclusively
> for only that in the EGL base spec either.
> 
> The cost of lying that the import worked is that the compositor will
> paint black or transparent where the window was supposed to be. It's a
> graphical glitch that is contrary to the Wayland design principles, but
> in this case a glitch is unavoidable: even if the compositor knew this
> buffer is now bad, what would it paint instead? It has nothing else to
> paint from. I'm assuming the compositor is using a different GPU than
> what disappeared.
> 
> Ideally, the client will eventually react to losing the GPU and either
> crash, quit, or switch its rendering to something that works which
> simply gives the compositor a new, working buffer without losing any
> window state in the process. If we risk the compositor disconnecting
> the client, then the client might not recover even if it wanted to.
> 
> > > +
> > > +- Render ioctls return EIO which is then handled in userspace drivers,
> > > +  e.g. Mesa, to have the device disappearance handled in the way
> > > +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> > > +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)  
> > 
> > 
> > As far as I understood from our discussion we would reject any IOCTL 
> > aimed at a device which is gone and not only render ioctls.
> 
> Daniel?
> 
> 
> Thanks,
> pq
> 
> > 
> > Andrey
> > 
> > 
> > > +
> > > +Raising SIGBUS is not an option, because userspace cannot realistically
> > > +handle it.  Signal handlers are global, which makes them extremely
> > > +difficult to use correctly from libraries like Mesa produces. Signal
> > > +handlers are not composable, you can't have different handlers for GPU1
> > > +and GPU2 from different vendors, and a third handler for mmapped regular
> > > +files.  Threads cause additional pain with signal handling as well.
> > > +
> > > +Only after userspace has closed all relevant DRM device and dmabuf file
> > > +descriptors and removed all mmaps, the DRM driver can tear down its
> > > +instance for the device that no longer exists. If the same physical
> > > +device somehow comes back in the mean time, it shall be a new DRM
> > > +device.
> > > +
> > >   .. _drm_driver_ioctl:
> > >   
> > >   IOCTL Support on Device Nodes  
> 



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Tue, May 19, 2020 at 01:06:49PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen <pekka.paalanen@collabora.com>
> 
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
> 
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
> 
> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Sean Paul <sean@poorly.run>
> 
> ---
> 
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>  Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
>  1 file changed, 75 insertions(+)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..80db4abd2cbd 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -1,3 +1,5 @@
> +.. Copyright 2020 DisplayLink (UK) Ltd.
> +
>  ===================
>  Userland interfaces
>  ===================
> @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
>  visible to user-space and accessible beyond open-file boundaries, they
>  cannot support render nodes.
>  
> +Device Hot-Unplug
> +=================
> +
> +.. note::
> +   The following is the plan. Implementation is not there yet
> +   (2020 May 13).
> +
> +Graphics devices (display and/or render) may be connected via USB (e.g.
> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> +user is able to hot-unplug this kind of devices while they are being
> +used, and expects that the very least the machine does not crash. Any
> +damage from hot-unplugging a DRM device needs to be limited as much as
> +possible and userspace must be given the chance to handle it if it wants
> +to. Ideally, unplugging a DRM device still lets a desktop to continue
> +running, but that is going to need explicit support throughout the whole
> +graphics stack: from kernel and userspace drivers, through display
> +servers, via window system protocols, and in applications and libraries.
> +
> +Other scenarios that should lead to the same are: unrecoverable GPU
> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> +from the physical device.
> +
> +In other words, from userspace perspective everything needs to keep on
> +working more or less, until userspace stops using the disappeared DRM
> +device and closes it completely. Userspace will learn of the device
> +disappearance from the device removed uevent or in some cases specific
> +ioctls returning EIO.
> +
> +This goal raises at least the following requirements for the kernel and
> +drivers:
> +
> +- The kernel must not hang, crash or oops, no matter what userspace was
> +  in the middle of doing when the device disappeared.
> +
> +- All GPU jobs that can no longer run must have their fences
> +  force-signalled to avoid inflicting hangs to userspace.
> +
> +- KMS connectors must change their status to disconnected.
> +
> +- Legacy modesets and pageflips fake success.
> +
> +- Atomic commits, both real and TEST_ONLY, fake success.
> +
> +- Pending non-blocking KMS operations deliver the DRM events userspace
> +  is expecting.
> +
> +- If underlying memory disappears, the mmaps are replaced with harmless
> +  zero pages where access does not raise SIGBUS. Reads return zeros,
> +  writes are ignored.

Hm this is going to be expensive to implement, every write access would
cause a minor fault to catch it and throw it away. That's not going to be
fast is someone is caught trying to upload a giant texture at that moment
:-/

Could we go with just "Reads and writes will still completely without
errors, but have otherwise undefined behaviour". Then we could go with a
"single shared page for every drmfd" (to avoid leaks), set up with rw
permissions. That's dirt cheap, should be easy to implement and everything
stays fast.

> +
> +- dmabuf which point to memory that has disappeared are rewritten to
> +  point to harmless zero pages, similar to mmaps. Imports still succeed
> +  both ways: an existing device importing a dmabuf pointing to
> +  disappeared memory, and a disappeared device importing any dmabuf.

Same here about mmaps.

> +
> +- Render ioctls return EIO which is then handled in userspace drivers,
> +  e.g. Mesa, to have the device disappearance handled in the way
> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)

I'd go further and spec that driver-specific render ioctl have driver
specific behaviour, but overall must not result in crashes and failures
expect as specified in the client apis you already list.

Some drivers might just go with an uevent and have no errors from ioctls,
some might only want to have an error on a very specific ioctl, some maybe
on all of them. Since no one except the hw specific userspace drivers will
have to deal with that I think best to only specify the outcome we want.

> +
> +Raising SIGBUS is not an option, because userspace cannot realistically
> +handle it.  Signal handlers are global, which makes them extremely
> +difficult to use correctly from libraries like Mesa produces. Signal
> +handlers are not composable, you can't have different handlers for GPU1
> +and GPU2 from different vendors, and a third handler for mmapped regular
> +files.  Threads cause additional pain with signal handling as well.

Hm maybe move that to the entire mmap discussion and why SIGBUS is a
really bad idea?

> +
> +Only after userspace has closed all relevant DRM device and dmabuf file
> +descriptors and removed all mmaps, the DRM driver can tear down its
> +instance for the device that no longer exists. If the same physical
> +device somehow comes back in the mean time, it shall be a new DRM
> +device.

Maybe we should add an explicit note that there's no guarantee about the
new chardev minor this new device will get, it could both inherit the
existing one (you can't open the old one anymore anyway) or get a new one?

Or does userspace want a guarantee, i.e. as long as there's still a handle
open kernel guarantees to not recycle the chardev minor (which is what we
currently do). In that case better to add that to your list of guarantees
above.

I think overall a good start for documenting the uapi expectations of
hotunplug, we'll definitely have to refine this as we go.

Cheers, Daniel

> +
>  .. _drm_driver_ioctl:
>  
>  IOCTL Support on Device Nodes
> -- 
> 2.20.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Simon Ser]

On Wednesday, May 20, 2020 2:55 PM, Daniel Vetter <daniel@ffwll.ch> wrote:

> Maybe we should add an explicit note that there's no guarantee about the
> new chardev minor this new device will get, it could both inherit the
> existing one (you can't open the old one anymore anyway) or get a new one?
>
> Or does userspace want a guarantee, i.e. as long as there's still a handle
> open kernel guarantees to not recycle the chardev minor (which is what we
> currently do). In that case better to add that to your list of guarantees
> above.

The are race conditions to consider too, e.g.

- Compositor sends /dev/dri/card0 to a client
- card0 goes away
- Another device takes card0
- Client receives /dev/dri/card0 and then starts using it, but it's the
  wrong device

At first glance these seem like edge-cases that almost never happen.
However I've seen these happen in practice with connectors, especially
with docks.

One solution would be to number minor numbers like PIDs: don't recycle
card0 before we've reached the upper minor number limit.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Wed, May 20, 2020 at 3:20 PM Simon Ser <contact@emersion.fr> wrote:
>
> On Wednesday, May 20, 2020 2:55 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
>
> > Maybe we should add an explicit note that there's no guarantee about the
> > new chardev minor this new device will get, it could both inherit the
> > existing one (you can't open the old one anymore anyway) or get a new one?
> >
> > Or does userspace want a guarantee, i.e. as long as there's still a handle
> > open kernel guarantees to not recycle the chardev minor (which is what we
> > currently do). In that case better to add that to your list of guarantees
> > above.
>
> The are race conditions to consider too, e.g.
>
> - Compositor sends /dev/dri/card0 to a client
> - card0 goes away
> - Another device takes card0
> - Client receives /dev/dri/card0 and then starts using it, but it's the
>   wrong device

Oh reminds me, what should we do about open() - that one will fail,
the chardev is going away after all, not failing kinda doesn't make
sense. And more tricky, about creating new leases?

I think reasonable semantics here would be that both of these "create
a new open drm fd" operations can fail as soon as the device is
unplugged. Userspace needs to be able to deal with that.
-Daniel

>
> At first glance these seem like edge-cases that almost never happen.
> However I've seen these happen in practice with connectors, especially
> with docks.
>
> One solution would be to number minor numbers like PIDs: don't recycle
> card0 before we've reached the upper minor number limit.



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Andrey Grodzovsky]

On 5/20/20 8:46 AM, Daniel Vetter wrote:
> On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote:
>> On Tue, 19 May 2020 10:37:12 -0400
>> Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
>>
>>> Thanks for the summary, does put things in order and makes it easier to
>>> comprehend all the TODOs, some questions bellow
>>>
>>> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
>>>> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>>
>>>> Set up the expectations on how hot-unplugging a DRM device should look like to
>>>> userspace.
>>>>
>>>> Written by Daniel Vetter's request and largely based on his comments in IRC and
>>>> from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7Ca4da241ff1e54610d95508d7fcbbcc11%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255755828209496&amp;sdata=YDFoP2g3z3IiB77sRvAmPB%2Fix%2FV0Mh78YcCSAAlhXdg%3D&amp;reserved=0 .
>>>>
>>>> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>> Cc: Daniel Vetter <daniel@ffwll.ch>
>>>> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>> Cc: Sean Paul <sean@poorly.run>
>>>>
>>>> ---
>>>>
>>>> Disclaimer: I am a userspace developer writing for other userspace developers.
>>>> I took some liberties in defining what should happen without knowing what is
>>>> actually possible or what existing drivers already implement.
>>>> ---
>>>>    Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
>>>>    1 file changed, 75 insertions(+)
>>>>
>>>> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
>>>> index 56fec6ed1ad8..80db4abd2cbd 100644
>>>> --- a/Documentation/gpu/drm-uapi.rst
>>>> +++ b/Documentation/gpu/drm-uapi.rst
>>>> @@ -1,3 +1,5 @@
>>>> +.. Copyright 2020 DisplayLink (UK) Ltd.
>>>> +
>>>>    ===================
>>>>    Userland interfaces
>>>>    ===================
>>>> @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
>>>>    visible to user-space and accessible beyond open-file boundaries, they
>>>>    cannot support render nodes.
>>>>    
>>>> +Device Hot-Unplug
>>>> +=================
>>>> +
>>>> +.. note::
>>>> +   The following is the plan. Implementation is not there yet
>>>> +   (2020 May 13).
>>>> +
>>>> +Graphics devices (display and/or render) may be connected via USB (e.g.
>>>> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
>>>> +user is able to hot-unplug this kind of devices while they are being
>>>> +used, and expects that the very least the machine does not crash. Any
>>>> +damage from hot-unplugging a DRM device needs to be limited as much as
>>>> +possible and userspace must be given the chance to handle it if it wants
>>>> +to. Ideally, unplugging a DRM device still lets a desktop to continue
>>>> +running, but that is going to need explicit support throughout the whole
>>>> +graphics stack: from kernel and userspace drivers, through display
>>>> +servers, via window system protocols, and in applications and libraries.
>>>> +
>>>> +Other scenarios that should lead to the same are: unrecoverable GPU
>>>> +crash, PCI device disappearing off the bus, or forced unbind of a driver
>>>> +from the physical device.
>>>> +
>>>> +In other words, from userspace perspective everything needs to keep on
>>>> +working more or less, until userspace stops using the disappeared DRM
>>>> +device and closes it completely. Userspace will learn of the device
>>>> +disappearance from the device removed uevent or in some cases specific
>>>> +ioctls returning EIO.
>>>> +
>>>> +This goal raises at least the following requirements for the kernel and
>>>> +drivers:
>>>> +
>>>> +- The kernel must not hang, crash or oops, no matter what userspace was
>>>> +  in the middle of doing when the device disappeared.
>>>> +
>>>> +- All GPU jobs that can no longer run must have their fences
>>>> +  force-signalled to avoid inflicting hangs to userspace.
>>>> +
>>>> +- KMS connectors must change their status to disconnected.
>>>> +
>>>> +- Legacy modesets and pageflips fake success.
>>>> +
>>>> +- Atomic commits, both real and TEST_ONLY, fake success.
>>>
>>> Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip
>>> and modeset ioctls here same way as you suggested returning -EIO for
>>> render ioctl ?
>> Hi,
>>
>> that is more of a question for Daniel Vetter than me. I believe he is
>> worried that userspace will get the error handling horribly wrong
>> anyway, because it needs to be handled in every single display server
>> project. Render ioctl errors OTOH need to be handled only in the
>> corresponding Mesa or other userspace driver, and for render there are
>> API (OpenGL/EGL, Vulkan) specs that say how it must be handled to fill
>> the API contract. Because of the API contract, those are more likely to
>> have reasonable error handling in place already.
> Yup pretty much. Atm compositors expect an -EINVAL (especially for
> TEST_ONLY), some cope with the semi-spurious -EBUSY we still throw around,
> but I expect most will just die if the get an -ENOMEM or -EIO or really
> anything.
>
> I think one area where we've historically thrown some spurious errors is
> also vblank ioctls, since they don't take full locks and sometimes the
> kernel needs to sneak in a modeset for some reason (gpu recovery, dp link
> recovery, ...).
>
> Either way I don't think there's anything the compositor can do than just
> ignore the error and carry on.


So currently drm_ioctl will just check for drm_dev_is_unplugged and 
return -ENODEV at the very beginning of the function 
(https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_ioctl.c#L825) 
meaning that currently we blanket failure any IOCTL in case the device 
is unplagued (ignoring the race condition if the device unplugged after 
the check). So do we want to remove this check and put it only for 
render ioctls (which are those ? e.g. for amdgpu there is  AMDGPU_CS 
ioctl) but not for mode setting/dma_buf_import/dma_buf_export ioctls ? 
What about other types of ioctls which are non of the listed above ?

Andrey


>
>> I first thought it would be obvious for at least atomic commits to fail
>> appropriately, but then thinking again, it will only introduce new
>> failures that are currently very hard to test for (VKMS to the rescue),
>> and userspace would need to have code to correctly bail out for EIO
>> rather than attempt fallbacks. The uevent telling the device is gone is
>> going to come anyway. In between the device disappearance and uevent
>> handling, it doesn't matter much what happens: the device is abruptly
>> gone and the user will see a glitch anyway - he knows, he just yanked
>> out the cable.
>>
>> To me this decision is just to make life in userspace easier by not
>> introducing a whole new type of error. However, if the kernel did
>> return EIO instead, it would be impossible for me to see that as a
>> kernel regression because the old behaviour was probably explosions
>> everywhere anyway.
>>
>> I heard that UDL and maybe some other drivers in the kernel already
>> handle hot-unplug somehow. Maybe those are what would regress if the
>> kernel returned EIO?
> I think most of the not-explodey drivers currently just (mostly?) it all
> hw errors. You kinda have to if you actually want to deal with hotunplug,
> stuff can disappear for any moment without warning anyway. Starting to
> just skip everything is the simplest approach, plus in large parts of the
> modeset helpers we don't even return values - kernel drivers suck as much
> at handling the unexpected errors as userspace :-)
> -Daniel
>
>>
>>>> +
>>>> +- Pending non-blocking KMS operations deliver the DRM events userspace
>>>> +  is expecting.
>>>> +
>>>> +- If underlying memory disappears, the mmaps are replaced with harmless
>>>> +  zero pages where access does not raise SIGBUS. Reads return zeros,
>>>> +  writes are ignored.
>>>> +
>>>> +- dmabuf which point to memory that has disappeared are rewritten to
>>>> +  point to harmless zero pages, similar to mmaps. Imports still succeed
>>>> +  both ways: an existing device importing a dmabuf pointing to
>>>> +  disappeared memory, and a disappeared device importing any dmabuf.
>>>
>>> Same as above, I would expect drmPrimeHandleToFD and drmPrimeFDToHandle
>>> to return -EIO in case device is detached
>> I imagined a use case behind this: a Wayland compositor attempting to
>> import a client's dmabuf. The GPU the client was using is
>> hot-unplugged, meaning the dmabufs lose their storage. It is up to the
>> client to handle its rendering GPU disappearance on its own, but also
>> the compositor should not disconnect it because the GPU disappeared.
>> It's not the client's fault the GPU disappeared.
>>
>> In Wayland, failure to use a wl_buffer is considered a protocol error,
>> and protocol errors are always fatal: the client is disconnected. The
>> rationale is that the compositor must always be able to present the
>> client buffer somehow. If the compositor cannot, then the client did
>> not obey the protocol.
>>
>> The fallback presentation path in a compositor is usually importing the
>> dmabuf to EGL, to be sampled from OpenGL. Normally the protocol
>> guarantees that this works, so any failure to do so is a protocol
>> violation. But if the GPU used by the client suddenly disappears and
>> the imports start to fail, that is interpreted as a protocol violation
>> unless the compositor can see why the import failed. Since the import
>> is done via EGL, getting the right error code plumbed through from
>> libdrm functions to the EGL caller would be a hassle. I don't see any
>> error code in EGL_EXT_image_dma_buf_import reserved for "the dmabuf
>> storage was hot-unplugged", and I doubt there is anything exclusively
>> for only that in the EGL base spec either.
>>
>> The cost of lying that the import worked is that the compositor will
>> paint black or transparent where the window was supposed to be. It's a
>> graphical glitch that is contrary to the Wayland design principles, but
>> in this case a glitch is unavoidable: even if the compositor knew this
>> buffer is now bad, what would it paint instead? It has nothing else to
>> paint from. I'm assuming the compositor is using a different GPU than
>> what disappeared.
>>
>> Ideally, the client will eventually react to losing the GPU and either
>> crash, quit, or switch its rendering to something that works which
>> simply gives the compositor a new, working buffer without losing any
>> window state in the process. If we risk the compositor disconnecting
>> the client, then the client might not recover even if it wanted to.
>>
>>>> +
>>>> +- Render ioctls return EIO which is then handled in userspace drivers,
>>>> +  e.g. Mesa, to have the device disappearance handled in the way
>>>> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
>>>> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
>>>
>>> As far as I understood from our discussion we would reject any IOCTL
>>> aimed at a device which is gone and not only render ioctls.
>> Daniel?
>>
>>
>> Thanks,
>> pq
>>
>>> Andrey
>>>
>>>
>>>> +
>>>> +Raising SIGBUS is not an option, because userspace cannot realistically
>>>> +handle it.  Signal handlers are global, which makes them extremely
>>>> +difficult to use correctly from libraries like Mesa produces. Signal
>>>> +handlers are not composable, you can't have different handlers for GPU1
>>>> +and GPU2 from different vendors, and a third handler for mmapped regular
>>>> +files.  Threads cause additional pain with signal handling as well.
>>>> +
>>>> +Only after userspace has closed all relevant DRM device and dmabuf file
>>>> +descriptors and removed all mmaps, the DRM driver can tear down its
>>>> +instance for the device that no longer exists. If the same physical
>>>> +device somehow comes back in the mean time, it shall be a new DRM
>>>> +device.
>>>> +
>>>>    .. _drm_driver_ioctl:
>>>>    
>>>>    IOCTL Support on Device Nodes
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 1738 bytes --]

On Wed, 20 May 2020 16:19:00 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Wed, May 20, 2020 at 3:20 PM Simon Ser <contact@emersion.fr> wrote:
> >
> > On Wednesday, May 20, 2020 2:55 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> >  
> > > Maybe we should add an explicit note that there's no guarantee about the
> > > new chardev minor this new device will get, it could both inherit the
> > > existing one (you can't open the old one anymore anyway) or get a new one?
> > >
> > > Or does userspace want a guarantee, i.e. as long as there's still a handle
> > > open kernel guarantees to not recycle the chardev minor (which is what we
> > > currently do). In that case better to add that to your list of guarantees
> > > above.  
> >
> > The are race conditions to consider too, e.g.
> >
> > - Compositor sends /dev/dri/card0 to a client
> > - card0 goes away
> > - Another device takes card0
> > - Client receives /dev/dri/card0 and then starts using it, but it's the
> >   wrong device  
> 
> Oh reminds me, what should we do about open() - that one will fail,
> the chardev is going away after all, not failing kinda doesn't make
> sense. And more tricky, about creating new leases?
> 
> I think reasonable semantics here would be that both of these "create
> a new open drm fd" operations can fail as soon as the device is
> unplugged. Userspace needs to be able to deal with that.

Hi,

yeah, we can make mmap read/write end result undefined, recycle char
minors like pids, and let new open()s and new leases fail. Pretty much
everything Daniel and Simon said make sense to me.

I'll spin a v2, but maybe next week.

What about the drm_ioctl() issue Andrey pointed out?


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Andrey Grodzovsky]

Ping on the question bellow

Andrey

On 5/20/20 10:50 AM, Andrey Grodzovsky wrote:
>
> On 5/20/20 8:46 AM, Daniel Vetter wrote:
>> On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote:
>>> On Tue, 19 May 2020 10:37:12 -0400
>>> Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
>>>
>>>> Thanks for the summary, does put things in order and makes it 
>>>> easier to
>>>> comprehend all the TODOs, some questions bellow
>>>>
>>>> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
>>>>> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>>>
>>>>> Set up the expectations on how hot-unplugging a DRM device should 
>>>>> look like to
>>>>> userspace.
>>>>>
>>>>> Written by Daniel Vetter's request and largely based on his 
>>>>> comments in IRC and
>>>>> from 
>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7Ca4da241ff1e54610d95508d7fcbbcc11%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255755828209496&amp;sdata=YDFoP2g3z3IiB77sRvAmPB%2Fix%2FV0Mh78YcCSAAlhXdg%3D&amp;reserved=0 
>>>>> .
>>>>>
>>>>> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>>> Cc: Daniel Vetter <daniel@ffwll.ch>
>>>>> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>> Cc: Sean Paul <sean@poorly.run>
>>>>>
>>>>> ---
>>>>>
>>>>> Disclaimer: I am a userspace developer writing for other userspace 
>>>>> developers.
>>>>> I took some liberties in defining what should happen without 
>>>>> knowing what is
>>>>> actually possible or what existing drivers already implement.
>>>>> ---
>>>>>    Documentation/gpu/drm-uapi.rst | 75 
>>>>> ++++++++++++++++++++++++++++++++++
>>>>>    1 file changed, 75 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/gpu/drm-uapi.rst 
>>>>> b/Documentation/gpu/drm-uapi.rst
>>>>> index 56fec6ed1ad8..80db4abd2cbd 100644
>>>>> --- a/Documentation/gpu/drm-uapi.rst
>>>>> +++ b/Documentation/gpu/drm-uapi.rst
>>>>> @@ -1,3 +1,5 @@
>>>>> +.. Copyright 2020 DisplayLink (UK) Ltd.
>>>>> +
>>>>>    ===================
>>>>>    Userland interfaces
>>>>>    ===================
>>>>> @@ -162,6 +164,79 @@ other hand, a driver requires shared state 
>>>>> between clients which is
>>>>>    visible to user-space and accessible beyond open-file 
>>>>> boundaries, they
>>>>>    cannot support render nodes.
>>>>>    +Device Hot-Unplug
>>>>> +=================
>>>>> +
>>>>> +.. note::
>>>>> +   The following is the plan. Implementation is not there yet
>>>>> +   (2020 May 13).
>>>>> +
>>>>> +Graphics devices (display and/or render) may be connected via USB 
>>>>> (e.g.
>>>>> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). 
>>>>> An end
>>>>> +user is able to hot-unplug this kind of devices while they are being
>>>>> +used, and expects that the very least the machine does not crash. 
>>>>> Any
>>>>> +damage from hot-unplugging a DRM device needs to be limited as 
>>>>> much as
>>>>> +possible and userspace must be given the chance to handle it if 
>>>>> it wants
>>>>> +to. Ideally, unplugging a DRM device still lets a desktop to 
>>>>> continue
>>>>> +running, but that is going to need explicit support throughout 
>>>>> the whole
>>>>> +graphics stack: from kernel and userspace drivers, through display
>>>>> +servers, via window system protocols, and in applications and 
>>>>> libraries.
>>>>> +
>>>>> +Other scenarios that should lead to the same are: unrecoverable GPU
>>>>> +crash, PCI device disappearing off the bus, or forced unbind of a 
>>>>> driver
>>>>> +from the physical device.
>>>>> +
>>>>> +In other words, from userspace perspective everything needs to 
>>>>> keep on
>>>>> +working more or less, until userspace stops using the disappeared 
>>>>> DRM
>>>>> +device and closes it completely. Userspace will learn of the device
>>>>> +disappearance from the device removed uevent or in some cases 
>>>>> specific
>>>>> +ioctls returning EIO.
>>>>> +
>>>>> +This goal raises at least the following requirements for the 
>>>>> kernel and
>>>>> +drivers:
>>>>> +
>>>>> +- The kernel must not hang, crash or oops, no matter what 
>>>>> userspace was
>>>>> +  in the middle of doing when the device disappeared.
>>>>> +
>>>>> +- All GPU jobs that can no longer run must have their fences
>>>>> +  force-signalled to avoid inflicting hangs to userspace.
>>>>> +
>>>>> +- KMS connectors must change their status to disconnected.
>>>>> +
>>>>> +- Legacy modesets and pageflips fake success.
>>>>> +
>>>>> +- Atomic commits, both real and TEST_ONLY, fake success.
>>>>
>>>> Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip
>>>> and modeset ioctls here same way as you suggested returning -EIO for
>>>> render ioctl ?
>>> Hi,
>>>
>>> that is more of a question for Daniel Vetter than me. I believe he is
>>> worried that userspace will get the error handling horribly wrong
>>> anyway, because it needs to be handled in every single display server
>>> project. Render ioctl errors OTOH need to be handled only in the
>>> corresponding Mesa or other userspace driver, and for render there are
>>> API (OpenGL/EGL, Vulkan) specs that say how it must be handled to fill
>>> the API contract. Because of the API contract, those are more likely to
>>> have reasonable error handling in place already.
>> Yup pretty much. Atm compositors expect an -EINVAL (especially for
>> TEST_ONLY), some cope with the semi-spurious -EBUSY we still throw 
>> around,
>> but I expect most will just die if the get an -ENOMEM or -EIO or really
>> anything.
>>
>> I think one area where we've historically thrown some spurious errors is
>> also vblank ioctls, since they don't take full locks and sometimes the
>> kernel needs to sneak in a modeset for some reason (gpu recovery, dp 
>> link
>> recovery, ...).
>>
>> Either way I don't think there's anything the compositor can do than 
>> just
>> ignore the error and carry on.
>
>
> So currently drm_ioctl will just check for drm_dev_is_unplugged and 
> return -ENODEV at the very beginning of the function 
> (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_ioctl.c#L825) 
> meaning that currently we blanket failure any IOCTL in case the device 
> is unplagued (ignoring the race condition if the device unplugged 
> after the check). So do we want to remove this check and put it only 
> for render ioctls (which are those ? e.g. for amdgpu there is  
> AMDGPU_CS ioctl) but not for mode 
> setting/dma_buf_import/dma_buf_export ioctls ? What about other types 
> of ioctls which are non of the listed above ?
>
> Andrey
>
>
>>
>>> I first thought it would be obvious for at least atomic commits to fail
>>> appropriately, but then thinking again, it will only introduce new
>>> failures that are currently very hard to test for (VKMS to the rescue),
>>> and userspace would need to have code to correctly bail out for EIO
>>> rather than attempt fallbacks. The uevent telling the device is gone is
>>> going to come anyway. In between the device disappearance and uevent
>>> handling, it doesn't matter much what happens: the device is abruptly
>>> gone and the user will see a glitch anyway - he knows, he just yanked
>>> out the cable.
>>>
>>> To me this decision is just to make life in userspace easier by not
>>> introducing a whole new type of error. However, if the kernel did
>>> return EIO instead, it would be impossible for me to see that as a
>>> kernel regression because the old behaviour was probably explosions
>>> everywhere anyway.
>>>
>>> I heard that UDL and maybe some other drivers in the kernel already
>>> handle hot-unplug somehow. Maybe those are what would regress if the
>>> kernel returned EIO?
>> I think most of the not-explodey drivers currently just (mostly?) it all
>> hw errors. You kinda have to if you actually want to deal with 
>> hotunplug,
>> stuff can disappear for any moment without warning anyway. Starting to
>> just skip everything is the simplest approach, plus in large parts of 
>> the
>> modeset helpers we don't even return values - kernel drivers suck as 
>> much
>> at handling the unexpected errors as userspace :-)
>> -Daniel
>>
>>>
>>>>> +
>>>>> +- Pending non-blocking KMS operations deliver the DRM events 
>>>>> userspace
>>>>> +  is expecting.
>>>>> +
>>>>> +- If underlying memory disappears, the mmaps are replaced with 
>>>>> harmless
>>>>> +  zero pages where access does not raise SIGBUS. Reads return zeros,
>>>>> +  writes are ignored.
>>>>> +
>>>>> +- dmabuf which point to memory that has disappeared are rewritten to
>>>>> +  point to harmless zero pages, similar to mmaps. Imports still 
>>>>> succeed
>>>>> +  both ways: an existing device importing a dmabuf pointing to
>>>>> +  disappeared memory, and a disappeared device importing any dmabuf.
>>>>
>>>> Same as above, I would expect drmPrimeHandleToFD and 
>>>> drmPrimeFDToHandle
>>>> to return -EIO in case device is detached
>>> I imagined a use case behind this: a Wayland compositor attempting to
>>> import a client's dmabuf. The GPU the client was using is
>>> hot-unplugged, meaning the dmabufs lose their storage. It is up to the
>>> client to handle its rendering GPU disappearance on its own, but also
>>> the compositor should not disconnect it because the GPU disappeared.
>>> It's not the client's fault the GPU disappeared.
>>>
>>> In Wayland, failure to use a wl_buffer is considered a protocol error,
>>> and protocol errors are always fatal: the client is disconnected. The
>>> rationale is that the compositor must always be able to present the
>>> client buffer somehow. If the compositor cannot, then the client did
>>> not obey the protocol.
>>>
>>> The fallback presentation path in a compositor is usually importing the
>>> dmabuf to EGL, to be sampled from OpenGL. Normally the protocol
>>> guarantees that this works, so any failure to do so is a protocol
>>> violation. But if the GPU used by the client suddenly disappears and
>>> the imports start to fail, that is interpreted as a protocol violation
>>> unless the compositor can see why the import failed. Since the import
>>> is done via EGL, getting the right error code plumbed through from
>>> libdrm functions to the EGL caller would be a hassle. I don't see any
>>> error code in EGL_EXT_image_dma_buf_import reserved for "the dmabuf
>>> storage was hot-unplugged", and I doubt there is anything exclusively
>>> for only that in the EGL base spec either.
>>>
>>> The cost of lying that the import worked is that the compositor will
>>> paint black or transparent where the window was supposed to be. It's a
>>> graphical glitch that is contrary to the Wayland design principles, but
>>> in this case a glitch is unavoidable: even if the compositor knew this
>>> buffer is now bad, what would it paint instead? It has nothing else to
>>> paint from. I'm assuming the compositor is using a different GPU than
>>> what disappeared.
>>>
>>> Ideally, the client will eventually react to losing the GPU and either
>>> crash, quit, or switch its rendering to something that works which
>>> simply gives the compositor a new, working buffer without losing any
>>> window state in the process. If we risk the compositor disconnecting
>>> the client, then the client might not recover even if it wanted to.
>>>
>>>>> +
>>>>> +- Render ioctls return EIO which is then handled in userspace 
>>>>> drivers,
>>>>> +  e.g. Mesa, to have the device disappearance handled in the way
>>>>> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
>>>>> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
>>>>
>>>> As far as I understood from our discussion we would reject any IOCTL
>>>> aimed at a device which is gone and not only render ioctls.
>>> Daniel?
>>>
>>>
>>> Thanks,
>>> pq
>>>
>>>> Andrey
>>>>
>>>>
>>>>> +
>>>>> +Raising SIGBUS is not an option, because userspace cannot 
>>>>> realistically
>>>>> +handle it.  Signal handlers are global, which makes them extremely
>>>>> +difficult to use correctly from libraries like Mesa produces. Signal
>>>>> +handlers are not composable, you can't have different handlers 
>>>>> for GPU1
>>>>> +and GPU2 from different vendors, and a third handler for mmapped 
>>>>> regular
>>>>> +files.  Threads cause additional pain with signal handling as well.
>>>>> +
>>>>> +Only after userspace has closed all relevant DRM device and 
>>>>> dmabuf file
>>>>> +descriptors and removed all mmaps, the DRM driver can tear down its
>>>>> +instance for the device that no longer exists. If the same physical
>>>>> +device somehow comes back in the mean time, it shall be a new DRM
>>>>> +device.
>>>>> +
>>>>>    .. _drm_driver_ioctl:
>>>>>       IOCTL Support on Device Nodes
>>
>>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

From: Pekka Paalanen <pekka.paalanen@collabora.com>

Set up the expectations on how hot-unplugging a DRM device should look like to
userspace.

Written by Daniel Vetter's request and largely based on his comments in IRC and
from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Simon Ser <contact@emersion.fr>

---

v2:
- mmap reads/writes undefined (danvet)
- make render ioctl behaviour driver-specific (danvet)
- restructure the mmap paragraphs (danvet)
- chardev minor notes (Simon)
- open behaviour (danvet)
- DRM leasing behaviour (danvet)
- added links

Disclaimer: I am a userspace developer writing for other userspace developers.
I took some liberties in defining what should happen without knowing what is
actually possible or what existing drivers already implement.
---
 Documentation/gpu/drm-uapi.rst | 102 +++++++++++++++++++++++++++++++++
 1 file changed, 102 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 56fec6ed1ad8..520b8e640ad1 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -1,3 +1,5 @@
+.. Copyright 2020 DisplayLink (UK) Ltd.
+
 ===================
 Userland interfaces
 ===================
@@ -162,6 +164,106 @@ other hand, a driver requires shared state between clients which is
 visible to user-space and accessible beyond open-file boundaries, they
 cannot support render nodes.
 
+Device Hot-Unplug
+=================
+
+.. note::
+   The following is the plan. Implementation is not there yet
+   (2020 May).
+
+Graphics devices (display and/or render) may be connected via USB (e.g.
+display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
+user is able to hot-unplug this kind of devices while they are being
+used, and expects that the very least the machine does not crash. Any
+damage from hot-unplugging a DRM device needs to be limited as much as
+possible and userspace must be given the chance to handle it if it wants
+to. Ideally, unplugging a DRM device still lets a desktop to continue
+running, but that is going to need explicit support throughout the whole
+graphics stack: from kernel and userspace drivers, through display
+servers, via window system protocols, and in applications and libraries.
+
+Other scenarios that should lead to the same are: unrecoverable GPU
+crash, PCI device disappearing off the bus, or forced unbind of a driver
+from the physical device.
+
+In other words, from userspace perspective everything needs to keep on
+working more or less, until userspace stops using the disappeared DRM
+device and closes it completely. Userspace will learn of the device
+disappearance from the device removed uevent or in some cases
+driver-specific ioctls returning EIO.
+
+Only after userspace has closed all relevant DRM device and dmabuf file
+descriptors and removed all mmaps, the DRM driver can tear down its
+instance for the device that no longer exists. If the same physical
+device somehow comes back in the mean time, it shall be a new DRM
+device.
+
+Similar to PIDs, chardev minor numbers are not recycled immediately. A
+new DRM device always picks the next free minor number compared to the
+previous one allocated, and wraps around when minor numbers are
+exhausted.
+
+Requirements for UAPI
+---------------------
+
+The goal raises at least the following requirements for the kernel and
+drivers:
+
+- The kernel must not hang, crash or oops, no matter what userspace was
+  in the middle of doing when the device disappeared.
+
+- All GPU jobs that can no longer run must have their fences
+  force-signalled to avoid inflicting hangs to userspace.
+
+- KMS connectors must change their status to disconnected.
+
+- Legacy modesets and pageflips fake success.
+
+- Atomic commits, both real and TEST_ONLY, fake success.
+
+- Pending non-blocking KMS operations deliver the DRM events userspace
+  is expecting.
+
+- dmabuf which point to memory that has disappeared will continue to
+  be successfully imported if it would have succeeded before the
+  disappearance.
+
+- Attempting to import a dmabuf to a disappeared device will succeed if
+  it would have succeeded without the disappearance.
+
+- Some userspace APIs already define what should happen when the device
+  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
+  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
+  behaviour the way they see best, e.g. returning failures in
+  driver-specific ioctls and handling those in userspace drivers, or
+  rely on uevents, and so on.
+
+- open() on a device node whose underlying device has disappeared will
+  fail.
+
+- Attempting to create a DRM lease on a disappeared DRM device will
+  fail. Existing DRM leases remain.
+
+.. _GL_KHR_robustness: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt
+.. _Vulkan: https://www.khronos.org/vulkan/
+
+Requirements for memory maps
+----------------------------
+
+Memory maps have further requirements. If the underlying memory
+disappears, the mmap is modified such that reads and writes will still
+complete successfully but the result is undefined. This applies to both
+userspace mmap()'d memory and memory pointed to by dmabuf which might be
+mapped to other devices.
+
+Raising SIGBUS is not an option, because userspace cannot realistically
+handle it.  Signal handlers are global, which makes them extremely
+difficult to use correctly from libraries like those that Mesa produces.
+Signal handlers are not composable, you can't have different handlers
+for GPU1 and GPU2 from different vendors, and a third handler for
+mmapped regular files.  Threads cause additional pain with signal
+handling as well.
+
 .. _drm_driver_ioctl:
 
 IOCTL Support on Device Nodes
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/doc: device hot-unplug for userspace

[Andrey Grodzovsky]

On 5/25/20 8:46 AM, Pekka Paalanen wrote:

> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cc9676f35bbdf4d5a052808d800a9b517%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260076178891269&amp;sdata=tbOTr7TfESohEgWspomM1sbMq4U4n7bOvdS6JlYifmM%3D&amp;reserved=0 .
>
> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Simon Ser <contact@emersion.fr>
>
> ---
>
> v2:
> - mmap reads/writes undefined (danvet)
> - make render ioctl behaviour driver-specific (danvet)
> - restructure the mmap paragraphs (danvet)
> - chardev minor notes (Simon)
> - open behaviour (danvet)
> - DRM leasing behaviour (danvet)
> - added links
>
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>   Documentation/gpu/drm-uapi.rst | 102 +++++++++++++++++++++++++++++++++
>   1 file changed, 102 insertions(+)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..520b8e640ad1 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -1,3 +1,5 @@
> +.. Copyright 2020 DisplayLink (UK) Ltd.
> +
>   ===================
>   Userland interfaces
>   ===================
> @@ -162,6 +164,106 @@ other hand, a driver requires shared state between clients which is
>   visible to user-space and accessible beyond open-file boundaries, they
>   cannot support render nodes.
>   
> +Device Hot-Unplug
> +=================
> +
> +.. note::
> +   The following is the plan. Implementation is not there yet
> +   (2020 May).
> +
> +Graphics devices (display and/or render) may be connected via USB (e.g.
> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> +user is able to hot-unplug this kind of devices while they are being
> +used, and expects that the very least the machine does not crash. Any
> +damage from hot-unplugging a DRM device needs to be limited as much as
> +possible and userspace must be given the chance to handle it if it wants
> +to. Ideally, unplugging a DRM device still lets a desktop to continue
> +running, but that is going to need explicit support throughout the whole
> +graphics stack: from kernel and userspace drivers, through display
> +servers, via window system protocols, and in applications and libraries.

So to support all the requirements in this document only kernel changes 
should be enough and no changes are required from user mode part of the 
stack ?

> +
> +Other scenarios that should lead to the same are: unrecoverable GPU
> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> +from the physical device.
> +
> +In other words, from userspace perspective everything needs to keep on
> +working more or less, until userspace stops using the disappeared DRM
> +device and closes it completely. Userspace will learn of the device
> +disappearance from the device removed uevent


Is this uevent already implemented ? Can you point me to the code ?


> or in some cases
> +driver-specific ioctls returning EIO.
> +
> +Only after userspace has closed all relevant DRM device and dmabuf file
> +descriptors and removed all mmaps, the DRM driver can tear down its
> +instance for the device that no longer exists. If the same physical
> +device somehow comes back in the mean time, it shall be a new DRM
> +device.
> +
> +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> +new DRM device always picks the next free minor number compared to the
> +previous one allocated, and wraps around when minor numbers are
> +exhausted.
> +
> +Requirements for UAPI
> +---------------------
> +
> +The goal raises at least the following requirements for the kernel and
> +drivers:
> +
> +- The kernel must not hang, crash or oops, no matter what userspace was
> +  in the middle of doing when the device disappeared.
> +
> +- All GPU jobs that can no longer run must have their fences
> +  force-signalled to avoid inflicting hangs to userspace.
> +
> +- KMS connectors must change their status to disconnected.
> +
> +- Legacy modesets and pageflips fake success.
> +
> +- Atomic commits, both real and TEST_ONLY, fake success.
> +
> +- Pending non-blocking KMS operations deliver the DRM events userspace
> +  is expecting.


The 4 points above refer to mode setting/display attached card and are 
irrelevant for secondary GPU (e.g. DRI-PRIME scenario) or no display 
system in general. Maybe we can somehow highlight this in the document 
and I on the implementing side can then decide as a first step to 
concentrate on implementing the non display case as a first step or the 
only step. In general and correct me if I am wrong, render only GPUs (or 
compute only) are the majority of cases where you would want to be able 
to detach/attach GPU on the fly (e.g attach stronger secondary graphic 
card to a laptop to get high performance in a game or add/remove a GPU 
to/from a compute cluster)

Andrey


> +
> +- dmabuf which point to memory that has disappeared will continue to
> +  be successfully imported if it would have succeeded before the
> +  disappearance.
> +
> +- Attempting to import a dmabuf to a disappeared device will succeed if
> +  it would have succeeded without the disappearance.
> +
> +- Some userspace APIs already define what should happen when the device
> +  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
> +  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
> +  behaviour the way they see best, e.g. returning failures in
> +  driver-specific ioctls and handling those in userspace drivers, or
> +  rely on uevents, and so on.
> +
> +- open() on a device node whose underlying device has disappeared will
> +  fail.
> +
> +- Attempting to create a DRM lease on a disappeared DRM device will
> +  fail. Existing DRM leases remain.
> +
> +.. _GL_KHR_robustness: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fregistry%2FOpenGL%2Fextensions%2FKHR%2FKHR_robustness.txt&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cc9676f35bbdf4d5a052808d800a9b517%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260076178891269&amp;sdata=m%2FneRusoe6qGVU8Edk%2FncaD7eSJZXtPnA1IqLr7k%2Bos%3D&amp;reserved=0
> +.. _Vulkan: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fvulkan%2F&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cc9676f35bbdf4d5a052808d800a9b517%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260076178901265&amp;sdata=WsfLduUBzRKlybOJb5PQViBWYu5DgleEeycmf76l3UU%3D&amp;reserved=0
> +
> +Requirements for memory maps
> +----------------------------
> +
> +Memory maps have further requirements. If the underlying memory
> +disappears, the mmap is modified such that reads and writes will still
> +complete successfully but the result is undefined. This applies to both
> +userspace mmap()'d memory and memory pointed to by dmabuf which might be
> +mapped to other devices.
> +
> +Raising SIGBUS is not an option, because userspace cannot realistically
> +handle it.  Signal handlers are global, which makes them extremely
> +difficult to use correctly from libraries like those that Mesa produces.
> +Signal handlers are not composable, you can't have different handlers
> +for GPU1 and GPU2 from different vendors, and a third handler for
> +mmapped regular files.  Threads cause additional pain with signal
> +handling as well.
> +
>   .. _drm_driver_ioctl:
>   
>   IOCTL Support on Device Nodes
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Wed, May 20, 2020 at 10:50:41AM -0400, Andrey Grodzovsky wrote:
> 
> On 5/20/20 8:46 AM, Daniel Vetter wrote:
> > On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote:
> > > On Tue, 19 May 2020 10:37:12 -0400
> > > Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
> > > 
> > > > Thanks for the summary, does put things in order and makes it easier to
> > > > comprehend all the TODOs, some questions bellow
> > > > 
> > > > On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> > > > > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > > > 
> > > > > Set up the expectations on how hot-unplugging a DRM device should look like to
> > > > > userspace.
> > > > > 
> > > > > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > > > > from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7Ca4da241ff1e54610d95508d7fcbbcc11%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255755828209496&amp;sdata=YDFoP2g3z3IiB77sRvAmPB%2Fix%2FV0Mh78YcCSAAlhXdg%3D&amp;reserved=0 .
> > > > > 
> > > > > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > > > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > Cc: Sean Paul <sean@poorly.run>
> > > > > 
> > > > > ---
> > > > > 
> > > > > Disclaimer: I am a userspace developer writing for other userspace developers.
> > > > > I took some liberties in defining what should happen without knowing what is
> > > > > actually possible or what existing drivers already implement.
> > > > > ---
> > > > >    Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
> > > > >    1 file changed, 75 insertions(+)
> > > > > 
> > > > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > > > > index 56fec6ed1ad8..80db4abd2cbd 100644
> > > > > --- a/Documentation/gpu/drm-uapi.rst
> > > > > +++ b/Documentation/gpu/drm-uapi.rst
> > > > > @@ -1,3 +1,5 @@
> > > > > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > > > > +
> > > > >    ===================
> > > > >    Userland interfaces
> > > > >    ===================
> > > > > @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
> > > > >    visible to user-space and accessible beyond open-file boundaries, they
> > > > >    cannot support render nodes.
> > > > > +Device Hot-Unplug
> > > > > +=================
> > > > > +
> > > > > +.. note::
> > > > > +   The following is the plan. Implementation is not there yet
> > > > > +   (2020 May 13).
> > > > > +
> > > > > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > > > > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > > > > +user is able to hot-unplug this kind of devices while they are being
> > > > > +used, and expects that the very least the machine does not crash. Any
> > > > > +damage from hot-unplugging a DRM device needs to be limited as much as
> > > > > +possible and userspace must be given the chance to handle it if it wants
> > > > > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > > > > +running, but that is going to need explicit support throughout the whole
> > > > > +graphics stack: from kernel and userspace drivers, through display
> > > > > +servers, via window system protocols, and in applications and libraries.
> > > > > +
> > > > > +Other scenarios that should lead to the same are: unrecoverable GPU
> > > > > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > > > > +from the physical device.
> > > > > +
> > > > > +In other words, from userspace perspective everything needs to keep on
> > > > > +working more or less, until userspace stops using the disappeared DRM
> > > > > +device and closes it completely. Userspace will learn of the device
> > > > > +disappearance from the device removed uevent or in some cases specific
> > > > > +ioctls returning EIO.
> > > > > +
> > > > > +This goal raises at least the following requirements for the kernel and
> > > > > +drivers:
> > > > > +
> > > > > +- The kernel must not hang, crash or oops, no matter what userspace was
> > > > > +  in the middle of doing when the device disappeared.
> > > > > +
> > > > > +- All GPU jobs that can no longer run must have their fences
> > > > > +  force-signalled to avoid inflicting hangs to userspace.
> > > > > +
> > > > > +- KMS connectors must change their status to disconnected.
> > > > > +
> > > > > +- Legacy modesets and pageflips fake success.
> > > > > +
> > > > > +- Atomic commits, both real and TEST_ONLY, fake success.
> > > > 
> > > > Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip
> > > > and modeset ioctls here same way as you suggested returning -EIO for
> > > > render ioctl ?
> > > Hi,
> > > 
> > > that is more of a question for Daniel Vetter than me. I believe he is
> > > worried that userspace will get the error handling horribly wrong
> > > anyway, because it needs to be handled in every single display server
> > > project. Render ioctl errors OTOH need to be handled only in the
> > > corresponding Mesa or other userspace driver, and for render there are
> > > API (OpenGL/EGL, Vulkan) specs that say how it must be handled to fill
> > > the API contract. Because of the API contract, those are more likely to
> > > have reasonable error handling in place already.
> > Yup pretty much. Atm compositors expect an -EINVAL (especially for
> > TEST_ONLY), some cope with the semi-spurious -EBUSY we still throw around,
> > but I expect most will just die if the get an -ENOMEM or -EIO or really
> > anything.
> > 
> > I think one area where we've historically thrown some spurious errors is
> > also vblank ioctls, since they don't take full locks and sometimes the
> > kernel needs to sneak in a modeset for some reason (gpu recovery, dp link
> > recovery, ...).
> > 
> > Either way I don't think there's anything the compositor can do than just
> > ignore the error and carry on.
> 
> 
> So currently drm_ioctl will just check for drm_dev_is_unplugged and return
> -ENODEV at the very beginning of the function (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_ioctl.c#L825)
> meaning that currently we blanket failure any IOCTL in case the device is
> unplagued (ignoring the race condition if the device unplugged after the
> check). So do we want to remove this check and put it only for render ioctls
> (which are those ? e.g. for amdgpu there is  AMDGPU_CS ioctl) but not for
> mode setting/dma_buf_import/dma_buf_export ioctls ? What about other types
> of ioctls which are non of the listed above ?

Hm right, and this goes back all the way to first usb udl support:

commit 2c07a21d6fb0be47fda696a618b726ea258ed1dd
Author: Dave Airlie <airlied@redhat.com>
Date:   Mon Feb 20 14:18:07 2012 +0000

    drm: add core support for unplugging a device (v2)

So I guess we need to change the uapi docs to explain that. Not sure
everyone can cope, but I guess they better do. Since the use-case back
then was just udl, so simple legacy kms only, the damage was probably
rather limited. I'm not sure we can get away with that now, where kms code
has spread to funny places likey vulkan winsys code.

Or maybe we want a file priv flag you can set along the lines of "give me
less shitty hotunplug semantics for ioctls". Or maybe we can just change
the semantics, not crashing&burning shouldn't cause a regression :-)

For everything else (mmap, dma-buf fd, sync_file fd, syncobj fd) I think
the discussion is still more or less accurate.

Pekka, any thoughts?
-Daniel

> 
> Andrey
> 
> 
> > 
> > > I first thought it would be obvious for at least atomic commits to fail
> > > appropriately, but then thinking again, it will only introduce new
> > > failures that are currently very hard to test for (VKMS to the rescue),
> > > and userspace would need to have code to correctly bail out for EIO
> > > rather than attempt fallbacks. The uevent telling the device is gone is
> > > going to come anyway. In between the device disappearance and uevent
> > > handling, it doesn't matter much what happens: the device is abruptly
> > > gone and the user will see a glitch anyway - he knows, he just yanked
> > > out the cable.
> > > 
> > > To me this decision is just to make life in userspace easier by not
> > > introducing a whole new type of error. However, if the kernel did
> > > return EIO instead, it would be impossible for me to see that as a
> > > kernel regression because the old behaviour was probably explosions
> > > everywhere anyway.
> > > 
> > > I heard that UDL and maybe some other drivers in the kernel already
> > > handle hot-unplug somehow. Maybe those are what would regress if the
> > > kernel returned EIO?
> > I think most of the not-explodey drivers currently just (mostly?) it all
> > hw errors. You kinda have to if you actually want to deal with hotunplug,
> > stuff can disappear for any moment without warning anyway. Starting to
> > just skip everything is the simplest approach, plus in large parts of the
> > modeset helpers we don't even return values - kernel drivers suck as much
> > at handling the unexpected errors as userspace :-)
> > -Daniel
> > 
> > > 
> > > > > +
> > > > > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > > > > +  is expecting.
> > > > > +
> > > > > +- If underlying memory disappears, the mmaps are replaced with harmless
> > > > > +  zero pages where access does not raise SIGBUS. Reads return zeros,
> > > > > +  writes are ignored.
> > > > > +
> > > > > +- dmabuf which point to memory that has disappeared are rewritten to
> > > > > +  point to harmless zero pages, similar to mmaps. Imports still succeed
> > > > > +  both ways: an existing device importing a dmabuf pointing to
> > > > > +  disappeared memory, and a disappeared device importing any dmabuf.
> > > > 
> > > > Same as above, I would expect drmPrimeHandleToFD and drmPrimeFDToHandle
> > > > to return -EIO in case device is detached
> > > I imagined a use case behind this: a Wayland compositor attempting to
> > > import a client's dmabuf. The GPU the client was using is
> > > hot-unplugged, meaning the dmabufs lose their storage. It is up to the
> > > client to handle its rendering GPU disappearance on its own, but also
> > > the compositor should not disconnect it because the GPU disappeared.
> > > It's not the client's fault the GPU disappeared.
> > > 
> > > In Wayland, failure to use a wl_buffer is considered a protocol error,
> > > and protocol errors are always fatal: the client is disconnected. The
> > > rationale is that the compositor must always be able to present the
> > > client buffer somehow. If the compositor cannot, then the client did
> > > not obey the protocol.
> > > 
> > > The fallback presentation path in a compositor is usually importing the
> > > dmabuf to EGL, to be sampled from OpenGL. Normally the protocol
> > > guarantees that this works, so any failure to do so is a protocol
> > > violation. But if the GPU used by the client suddenly disappears and
> > > the imports start to fail, that is interpreted as a protocol violation
> > > unless the compositor can see why the import failed. Since the import
> > > is done via EGL, getting the right error code plumbed through from
> > > libdrm functions to the EGL caller would be a hassle. I don't see any
> > > error code in EGL_EXT_image_dma_buf_import reserved for "the dmabuf
> > > storage was hot-unplugged", and I doubt there is anything exclusively
> > > for only that in the EGL base spec either.
> > > 
> > > The cost of lying that the import worked is that the compositor will
> > > paint black or transparent where the window was supposed to be. It's a
> > > graphical glitch that is contrary to the Wayland design principles, but
> > > in this case a glitch is unavoidable: even if the compositor knew this
> > > buffer is now bad, what would it paint instead? It has nothing else to
> > > paint from. I'm assuming the compositor is using a different GPU than
> > > what disappeared.
> > > 
> > > Ideally, the client will eventually react to losing the GPU and either
> > > crash, quit, or switch its rendering to something that works which
> > > simply gives the compositor a new, working buffer without losing any
> > > window state in the process. If we risk the compositor disconnecting
> > > the client, then the client might not recover even if it wanted to.
> > > 
> > > > > +
> > > > > +- Render ioctls return EIO which is then handled in userspace drivers,
> > > > > +  e.g. Mesa, to have the device disappearance handled in the way
> > > > > +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> > > > > +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
> > > > 
> > > > As far as I understood from our discussion we would reject any IOCTL
> > > > aimed at a device which is gone and not only render ioctls.
> > > Daniel?
> > > 
> > > 
> > > Thanks,
> > > pq
> > > 
> > > > Andrey
> > > > 
> > > > 
> > > > > +
> > > > > +Raising SIGBUS is not an option, because userspace cannot realistically
> > > > > +handle it.  Signal handlers are global, which makes them extremely
> > > > > +difficult to use correctly from libraries like Mesa produces. Signal
> > > > > +handlers are not composable, you can't have different handlers for GPU1
> > > > > +and GPU2 from different vendors, and a third handler for mmapped regular
> > > > > +files.  Threads cause additional pain with signal handling as well.
> > > > > +
> > > > > +Only after userspace has closed all relevant DRM device and dmabuf file
> > > > > +descriptors and removed all mmaps, the DRM driver can tear down its
> > > > > +instance for the device that no longer exists. If the same physical
> > > > > +device somehow comes back in the mean time, it shall be a new DRM
> > > > > +device.
> > > > > +
> > > > >    .. _drm_driver_ioctl:
> > > > >    IOCTL Support on Device Nodes
> > 
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Fri, May 22, 2020 at 12:54:32PM +0300, Pekka Paalanen wrote:
> On Wed, 20 May 2020 16:19:00 +0200
> Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Wed, May 20, 2020 at 3:20 PM Simon Ser <contact@emersion.fr> wrote:
> > >
> > > On Wednesday, May 20, 2020 2:55 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > >  
> > > > Maybe we should add an explicit note that there's no guarantee about the
> > > > new chardev minor this new device will get, it could both inherit the
> > > > existing one (you can't open the old one anymore anyway) or get a new one?
> > > >
> > > > Or does userspace want a guarantee, i.e. as long as there's still a handle
> > > > open kernel guarantees to not recycle the chardev minor (which is what we
> > > > currently do). In that case better to add that to your list of guarantees
> > > > above.  
> > >
> > > The are race conditions to consider too, e.g.
> > >
> > > - Compositor sends /dev/dri/card0 to a client
> > > - card0 goes away
> > > - Another device takes card0
> > > - Client receives /dev/dri/card0 and then starts using it, but it's the
> > >   wrong device  
> > 
> > Oh reminds me, what should we do about open() - that one will fail,
> > the chardev is going away after all, not failing kinda doesn't make
> > sense. And more tricky, about creating new leases?
> > 
> > I think reasonable semantics here would be that both of these "create
> > a new open drm fd" operations can fail as soon as the device is
> > unplugged. Userspace needs to be able to deal with that.
> 
> Hi,
> 
> yeah, we can make mmap read/write end result undefined, recycle char
> minors like pids, and let new open()s and new leases fail. Pretty much
> everything Daniel and Simon said make sense to me.
> 
> I'll spin a v2, but maybe next week.
> 
> What about the drm_ioctl() issue Andrey pointed out?

Dropped some thoughts there, tbh dunno, need some more discussions?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Mon, May 25, 2020 at 09:51:30AM -0400, Andrey Grodzovsky wrote:
> On 5/25/20 8:46 AM, Pekka Paalanen wrote:
> 
> > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> > 
> > Set up the expectations on how hot-unplugging a DRM device should look like to
> > userspace.
> > 
> > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cc9676f35bbdf4d5a052808d800a9b517%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260076178891269&amp;sdata=tbOTr7TfESohEgWspomM1sbMq4U4n7bOvdS6JlYifmM%3D&amp;reserved=0 .
> > 
> > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: Simon Ser <contact@emersion.fr>
> > 
> > ---
> > 
> > v2:
> > - mmap reads/writes undefined (danvet)
> > - make render ioctl behaviour driver-specific (danvet)
> > - restructure the mmap paragraphs (danvet)
> > - chardev minor notes (Simon)
> > - open behaviour (danvet)
> > - DRM leasing behaviour (danvet)
> > - added links
> > 
> > Disclaimer: I am a userspace developer writing for other userspace developers.
> > I took some liberties in defining what should happen without knowing what is
> > actually possible or what existing drivers already implement.
> > ---
> >   Documentation/gpu/drm-uapi.rst | 102 +++++++++++++++++++++++++++++++++
> >   1 file changed, 102 insertions(+)
> > 
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index 56fec6ed1ad8..520b8e640ad1 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -1,3 +1,5 @@
> > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > +
> >   ===================
> >   Userland interfaces
> >   ===================
> > @@ -162,6 +164,106 @@ other hand, a driver requires shared state between clients which is
> >   visible to user-space and accessible beyond open-file boundaries, they
> >   cannot support render nodes.
> > +Device Hot-Unplug
> > +=================
> > +
> > +.. note::
> > +   The following is the plan. Implementation is not there yet
> > +   (2020 May).
> > +
> > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > +user is able to hot-unplug this kind of devices while they are being
> > +used, and expects that the very least the machine does not crash. Any
> > +damage from hot-unplugging a DRM device needs to be limited as much as
> > +possible and userspace must be given the chance to handle it if it wants
> > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > +running, but that is going to need explicit support throughout the whole
> > +graphics stack: from kernel and userspace drivers, through display
> > +servers, via window system protocols, and in applications and libraries.
> 
> So to support all the requirements in this document only kernel changes
> should be enough and no changes are required from user mode part of the
> stack ?
> 
> > +
> > +Other scenarios that should lead to the same are: unrecoverable GPU
> > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > +from the physical device.
> > +
> > +In other words, from userspace perspective everything needs to keep on
> > +working more or less, until userspace stops using the disappeared DRM
> > +device and closes it completely. Userspace will learn of the device
> > +disappearance from the device removed uevent
> 
> 
> Is this uevent already implemented ? Can you point me to the code ?
> 
> 
> > or in some cases
> > +driver-specific ioctls returning EIO.
> > +
> > +Only after userspace has closed all relevant DRM device and dmabuf file
> > +descriptors and removed all mmaps, the DRM driver can tear down its
> > +instance for the device that no longer exists. If the same physical
> > +device somehow comes back in the mean time, it shall be a new DRM
> > +device.
> > +
> > +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> > +new DRM device always picks the next free minor number compared to the
> > +previous one allocated, and wraps around when minor numbers are
> > +exhausted.
> > +
> > +Requirements for UAPI
> > +---------------------
> > +
> > +The goal raises at least the following requirements for the kernel and
> > +drivers:
> > +
> > +- The kernel must not hang, crash or oops, no matter what userspace was
> > +  in the middle of doing when the device disappeared.
> > +
> > +- All GPU jobs that can no longer run must have their fences
> > +  force-signalled to avoid inflicting hangs to userspace.
> > +
> > +- KMS connectors must change their status to disconnected.
> > +
> > +- Legacy modesets and pageflips fake success.
> > +
> > +- Atomic commits, both real and TEST_ONLY, fake success.
> > +
> > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > +  is expecting.
> 
> 
> The 4 points above refer to mode setting/display attached card and are
> irrelevant for secondary GPU (e.g. DRI-PRIME scenario) or no display system
> in general. Maybe we can somehow highlight this in the document and I on the
> implementing side can then decide as a first step to concentrate on
> implementing the non display case as a first step or the only step. In
> general and correct me if I am wrong, render only GPUs (or compute only) are
> the majority of cases where you would want to be able to detach/attach GPU
> on the fly (e.g attach stronger secondary graphic card to a laptop to get
> high performance in a game or add/remove a GPU to/from a compute cluster)

Yeah maybe splitting this up into kms section, and rendering/cross driver
section (the dma-buf/fence stuff is relevant for both display and
rendering) would make some sense.
-Daniel

> 
> Andrey
> 
> 
> > +
> > +- dmabuf which point to memory that has disappeared will continue to
> > +  be successfully imported if it would have succeeded before the
> > +  disappearance.
> > +
> > +- Attempting to import a dmabuf to a disappeared device will succeed if
> > +  it would have succeeded without the disappearance.
> > +
> > +- Some userspace APIs already define what should happen when the device
> > +  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
> > +  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
> > +  behaviour the way they see best, e.g. returning failures in
> > +  driver-specific ioctls and handling those in userspace drivers, or
> > +  rely on uevents, and so on.
> > +
> > +- open() on a device node whose underlying device has disappeared will
> > +  fail.
> > +
> > +- Attempting to create a DRM lease on a disappeared DRM device will
> > +  fail. Existing DRM leases remain.
> > +
> > +.. _GL_KHR_robustness: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fregistry%2FOpenGL%2Fextensions%2FKHR%2FKHR_robustness.txt&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cc9676f35bbdf4d5a052808d800a9b517%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260076178891269&amp;sdata=m%2FneRusoe6qGVU8Edk%2FncaD7eSJZXtPnA1IqLr7k%2Bos%3D&amp;reserved=0
> > +.. _Vulkan: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fvulkan%2F&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cc9676f35bbdf4d5a052808d800a9b517%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260076178901265&amp;sdata=WsfLduUBzRKlybOJb5PQViBWYu5DgleEeycmf76l3UU%3D&amp;reserved=0
> > +
> > +Requirements for memory maps
> > +----------------------------
> > +
> > +Memory maps have further requirements. If the underlying memory
> > +disappears, the mmap is modified such that reads and writes will still
> > +complete successfully but the result is undefined. This applies to both
> > +userspace mmap()'d memory and memory pointed to by dmabuf which might be
> > +mapped to other devices.
> > +
> > +Raising SIGBUS is not an option, because userspace cannot realistically
> > +handle it.  Signal handlers are global, which makes them extremely
> > +difficult to use correctly from libraries like those that Mesa produces.
> > +Signal handlers are not composable, you can't have different handlers
> > +for GPU1 and GPU2 from different vendors, and a third handler for
> > +mmapped regular files.  Threads cause additional pain with signal
> > +handling as well.
> > +
> >   .. _drm_driver_ioctl:
> >   IOCTL Support on Device Nodes

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 9029 bytes --]

On Mon, 25 May 2020 09:51:30 -0400
Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:

> On 5/25/20 8:46 AM, Pekka Paalanen wrote:
> 
> > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> >
> > Set up the expectations on how hot-unplugging a DRM device should look like to
> > userspace.
> >
> > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cc9676f35bbdf4d5a052808d800a9b517%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260076178891269&amp;sdata=tbOTr7TfESohEgWspomM1sbMq4U4n7bOvdS6JlYifmM%3D&amp;reserved=0 .
> >
> > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: Simon Ser <contact@emersion.fr>
> >
> > ---
> >
> > v2:
> > - mmap reads/writes undefined (danvet)
> > - make render ioctl behaviour driver-specific (danvet)
> > - restructure the mmap paragraphs (danvet)
> > - chardev minor notes (Simon)
> > - open behaviour (danvet)
> > - DRM leasing behaviour (danvet)
> > - added links
> >
> > Disclaimer: I am a userspace developer writing for other userspace developers.
> > I took some liberties in defining what should happen without knowing what is
> > actually possible or what existing drivers already implement.
> > ---
> >   Documentation/gpu/drm-uapi.rst | 102 +++++++++++++++++++++++++++++++++
> >   1 file changed, 102 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index 56fec6ed1ad8..520b8e640ad1 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -1,3 +1,5 @@
> > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > +
> >   ===================
> >   Userland interfaces
> >   ===================
> > @@ -162,6 +164,106 @@ other hand, a driver requires shared state between clients which is
> >   visible to user-space and accessible beyond open-file boundaries, they
> >   cannot support render nodes.
> >   
> > +Device Hot-Unplug
> > +=================
> > +
> > +.. note::
> > +   The following is the plan. Implementation is not there yet
> > +   (2020 May).
> > +
> > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > +user is able to hot-unplug this kind of devices while they are being
> > +used, and expects that the very least the machine does not crash. Any
> > +damage from hot-unplugging a DRM device needs to be limited as much as
> > +possible and userspace must be given the chance to handle it if it wants
> > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > +running, but that is going to need explicit support throughout the whole
> > +graphics stack: from kernel and userspace drivers, through display
> > +servers, via window system protocols, and in applications and libraries.  
> 
> So to support all the requirements in this document only kernel changes 
> should be enough and no changes are required from user mode part of the 
> stack ?

Hi,

my intention is that this document describes what the kernel delivers,
or should deliver, to allow userspace to cope with hot-unplug if
userspace wishes to do so. "Userspace" here includes userspace part of
GPU drivers.

Userspace has a lot to develop to actually recover instead of just sit
in the dark after the device disappears. Handling the uevent for DRM
device removal or errors from GL/Vulkan is just the beginning of it. I
would assume that userspace drivers have things to implement as well,
before GL or Vulkan apps can recover instead of get stuck or crash.

Unplugging "secondary" DRM devices (mostly used for KMS to have more
monitors lit) should be relatively easy to implement in display
servers. Unplugging the GPU that a display server is using for
rendering is going to be really difficult and will need client
(application toolkit) support the very least, and perhaps even new
window system protocol.

I imagine this will be incremental development: first the kernel stops
crashing. Then display servers stop crashing. At some point userspace
GPU drivers stop crashing. Then display servers learn to recover
instead of sit in the dark, but disconnect most of their clients. Then
maybe with the help of window system protocol additions, some major
toolkits learn to not get killed. And so on.

Once all that works, the follow-up step could be some protocol to
switch applications from one GPU to another in flight. That's off-topic
here, but being able to handle GPU unplug is half of the switch.

> > +
> > +Other scenarios that should lead to the same are: unrecoverable GPU
> > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > +from the physical device.
> > +
> > +In other words, from userspace perspective everything needs to keep on
> > +working more or less, until userspace stops using the disappeared DRM
> > +device and closes it completely. Userspace will learn of the device
> > +disappearance from the device removed uevent  
> 
> 
> Is this uevent already implemented ? Can you point me to the code ?

I can't point to any kernel code, I'm just not familiar with it. But
it's the same uevent all Linux devices emit. You unplug a USB mouse,
this is the event that gets sent.

You can emulate it with 'udevadm trigger -c remove' IIRC, and it is the
"remove" event you can match in udev rules.

KMS hotplug event is also a uevent, but I think it is "change" rather
than "remove". Otherwise the same mechanism. Display servers already
watch for uevents to learn about monitor hotplug, and some watch for
DRM device added events too. But I don't think any really watch for DRM
device removed events, because usually everything explodes first. I
don't know, maybe X.org handles UDL unplugs?

> > or in some cases
> > +driver-specific ioctls returning EIO.
> > +
> > +Only after userspace has closed all relevant DRM device and dmabuf file
> > +descriptors and removed all mmaps, the DRM driver can tear down its
> > +instance for the device that no longer exists. If the same physical
> > +device somehow comes back in the mean time, it shall be a new DRM
> > +device.
> > +
> > +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> > +new DRM device always picks the next free minor number compared to the
> > +previous one allocated, and wraps around when minor numbers are
> > +exhausted.
> > +
> > +Requirements for UAPI
> > +---------------------
> > +
> > +The goal raises at least the following requirements for the kernel and
> > +drivers:
> > +
> > +- The kernel must not hang, crash or oops, no matter what userspace was
> > +  in the middle of doing when the device disappeared.
> > +
> > +- All GPU jobs that can no longer run must have their fences
> > +  force-signalled to avoid inflicting hangs to userspace.
> > +
> > +- KMS connectors must change their status to disconnected.
> > +
> > +- Legacy modesets and pageflips fake success.
> > +
> > +- Atomic commits, both real and TEST_ONLY, fake success.
> > +
> > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > +  is expecting.  
> 
> 
> The 4 points above refer to mode setting/display attached card and are 
> irrelevant for secondary GPU (e.g. DRI-PRIME scenario) or no display 
> system in general. Maybe we can somehow highlight this in the document 
> and I on the implementing side can then decide as a first step to 
> concentrate on implementing the non display case as a first step or the 
> only step. In general and correct me if I am wrong, render only GPUs (or 
> compute only) are the majority of cases where you would want to be able 
> to detach/attach GPU on the fly (e.g attach stronger secondary graphic 
> card to a laptop to get high performance in a game or add/remove a GPU 
> to/from a compute cluster)

I do think KMS-only (not rendering) devices are a major use case for
hot-unplug: docks, USB-display-adapters etc. I wrote this patch on
behalf of DisplayLink after all.

Render-only GPUs are another important use case like you describe. And
a dock might perhaps have both: a powerful GPU and a big screen
connected.

Personally, I have no expectations other than a hope that some day at
least the drivers that support hot-unpluggable hardware would implement
all of this. :-)

I would assume it's fine to work piece by piece towards the goal on
your own pace. This patch here is just for setting up the goal without
a deadline. I'm no DRM maintainer or even a DRM developer.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 16141 bytes --]

On Mon, 25 May 2020 16:28:04 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Wed, May 20, 2020 at 10:50:41AM -0400, Andrey Grodzovsky wrote:
> > 
> > On 5/20/20 8:46 AM, Daniel Vetter wrote:  
> > > On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote:  
> > > > On Tue, 19 May 2020 10:37:12 -0400
> > > > Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
> > > >   
> > > > > Thanks for the summary, does put things in order and makes it easier to
> > > > > comprehend all the TODOs, some questions bellow
> > > > > 
> > > > > On 5/19/20 6:06 AM, Pekka Paalanen wrote:  
> > > > > > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > > > > 
> > > > > > Set up the expectations on how hot-unplugging a DRM device should look like to
> > > > > > userspace.
> > > > > > 
> > > > > > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > > > > > from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7Ca4da241ff1e54610d95508d7fcbbcc11%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255755828209496&amp;sdata=YDFoP2g3z3IiB77sRvAmPB%2Fix%2FV0Mh78YcCSAAlhXdg%3D&amp;reserved=0 .
> > > > > > 
> > > > > > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > > > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > > > > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > > Cc: Sean Paul <sean@poorly.run>
> > > > > > 
> > > > > > ---
> > > > > > 
> > > > > > Disclaimer: I am a userspace developer writing for other userspace developers.
> > > > > > I took some liberties in defining what should happen without knowing what is
> > > > > > actually possible or what existing drivers already implement.
> > > > > > ---
> > > > > >    Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
> > > > > >    1 file changed, 75 insertions(+)
> > > > > > 
> > > > > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > > > > > index 56fec6ed1ad8..80db4abd2cbd 100644
> > > > > > --- a/Documentation/gpu/drm-uapi.rst
> > > > > > +++ b/Documentation/gpu/drm-uapi.rst
> > > > > > @@ -1,3 +1,5 @@
> > > > > > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > > > > > +
> > > > > >    ===================
> > > > > >    Userland interfaces
> > > > > >    ===================
> > > > > > @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
> > > > > >    visible to user-space and accessible beyond open-file boundaries, they
> > > > > >    cannot support render nodes.
> > > > > > +Device Hot-Unplug
> > > > > > +=================
> > > > > > +
> > > > > > +.. note::
> > > > > > +   The following is the plan. Implementation is not there yet
> > > > > > +   (2020 May 13).
> > > > > > +
> > > > > > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > > > > > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > > > > > +user is able to hot-unplug this kind of devices while they are being
> > > > > > +used, and expects that the very least the machine does not crash. Any
> > > > > > +damage from hot-unplugging a DRM device needs to be limited as much as
> > > > > > +possible and userspace must be given the chance to handle it if it wants
> > > > > > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > > > > > +running, but that is going to need explicit support throughout the whole
> > > > > > +graphics stack: from kernel and userspace drivers, through display
> > > > > > +servers, via window system protocols, and in applications and libraries.
> > > > > > +
> > > > > > +Other scenarios that should lead to the same are: unrecoverable GPU
> > > > > > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > > > > > +from the physical device.
> > > > > > +
> > > > > > +In other words, from userspace perspective everything needs to keep on
> > > > > > +working more or less, until userspace stops using the disappeared DRM
> > > > > > +device and closes it completely. Userspace will learn of the device
> > > > > > +disappearance from the device removed uevent or in some cases specific
> > > > > > +ioctls returning EIO.
> > > > > > +
> > > > > > +This goal raises at least the following requirements for the kernel and
> > > > > > +drivers:
> > > > > > +
> > > > > > +- The kernel must not hang, crash or oops, no matter what userspace was
> > > > > > +  in the middle of doing when the device disappeared.
> > > > > > +
> > > > > > +- All GPU jobs that can no longer run must have their fences
> > > > > > +  force-signalled to avoid inflicting hangs to userspace.
> > > > > > +
> > > > > > +- KMS connectors must change their status to disconnected.
> > > > > > +
> > > > > > +- Legacy modesets and pageflips fake success.
> > > > > > +
> > > > > > +- Atomic commits, both real and TEST_ONLY, fake success.  
> > > > > 
> > > > > Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip
> > > > > and modeset ioctls here same way as you suggested returning -EIO for
> > > > > render ioctl ?  
> > > > Hi,
> > > > 
> > > > that is more of a question for Daniel Vetter than me. I believe he is
> > > > worried that userspace will get the error handling horribly wrong
> > > > anyway, because it needs to be handled in every single display server
> > > > project. Render ioctl errors OTOH need to be handled only in the
> > > > corresponding Mesa or other userspace driver, and for render there are
> > > > API (OpenGL/EGL, Vulkan) specs that say how it must be handled to fill
> > > > the API contract. Because of the API contract, those are more likely to
> > > > have reasonable error handling in place already.  
> > > Yup pretty much. Atm compositors expect an -EINVAL (especially for
> > > TEST_ONLY), some cope with the semi-spurious -EBUSY we still throw around,
> > > but I expect most will just die if the get an -ENOMEM or -EIO or really
> > > anything.
> > > 
> > > I think one area where we've historically thrown some spurious errors is
> > > also vblank ioctls, since they don't take full locks and sometimes the
> > > kernel needs to sneak in a modeset for some reason (gpu recovery, dp link
> > > recovery, ...).
> > > 
> > > Either way I don't think there's anything the compositor can do than just
> > > ignore the error and carry on.  
> > 
> > 
> > So currently drm_ioctl will just check for drm_dev_is_unplugged and return
> > -ENODEV at the very beginning of the function (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_ioctl.c#L825)
> > meaning that currently we blanket failure any IOCTL in case the device is
> > unplagued (ignoring the race condition if the device unplugged after the
> > check). So do we want to remove this check and put it only for render ioctls
> > (which are those ? e.g. for amdgpu there is  AMDGPU_CS ioctl) but not for
> > mode setting/dma_buf_import/dma_buf_export ioctls ? What about other types
> > of ioctls which are non of the listed above ?  
> 
> Hm right, and this goes back all the way to first usb udl support:
> 
> commit 2c07a21d6fb0be47fda696a618b726ea258ed1dd
> Author: Dave Airlie <airlied@redhat.com>
> Date:   Mon Feb 20 14:18:07 2012 +0000
> 
>     drm: add core support for unplugging a device (v2)
> 
> So I guess we need to change the uapi docs to explain that. Not sure
> everyone can cope, but I guess they better do. Since the use-case back
> then was just udl, so simple legacy kms only, the damage was probably
> rather limited. I'm not sure we can get away with that now, where kms code
> has spread to funny places likey vulkan winsys code.
> 
> Or maybe we want a file priv flag you can set along the lines of "give me
> less shitty hotunplug semantics for ioctls". Or maybe we can just change
> the semantics, not crashing&burning shouldn't cause a regression :-)
> 
> For everything else (mmap, dma-buf fd, sync_file fd, syncobj fd) I think
> the discussion is still more or less accurate.
> 
> Pekka, any thoughts?

Hi,

is ENODEV unique to this particular failure?

Returning errors instead of faking success was my first idea, but you
already convinced me that faking is at least as good if not better. :-)

So as long as the error code returned is unique to hot-unplug or other
"oops, the device is gone" conditions, I think I'm fine. Weston does
not handle ENODEV any way, it never did, and it certainly cannot be
called a kernel regression.

As a Weston developer, I don't mind adding checks for ENODEV. But if I
don't have to, even better. Weston is going to need more code to handle
DRM device unplug in any case.

Sorry, no preference from me. ;-)

I do agree that replacing ENODEV with fake success is hard to imagine
regressing anything. It's something you can do in the kernel at any
time easily, but going from fake success to error is going to be
painful. Maybe don't change things until there is a good reason to?

We need a kernel that doesn't crash before we can properly test what
would be best for userspace, fake or error.


Thanks,
pq


> -Daniel
> 
> > 
> > Andrey
> > 
> >   
> > >   
> > > > I first thought it would be obvious for at least atomic commits to fail
> > > > appropriately, but then thinking again, it will only introduce new
> > > > failures that are currently very hard to test for (VKMS to the rescue),
> > > > and userspace would need to have code to correctly bail out for EIO
> > > > rather than attempt fallbacks. The uevent telling the device is gone is
> > > > going to come anyway. In between the device disappearance and uevent
> > > > handling, it doesn't matter much what happens: the device is abruptly
> > > > gone and the user will see a glitch anyway - he knows, he just yanked
> > > > out the cable.
> > > > 
> > > > To me this decision is just to make life in userspace easier by not
> > > > introducing a whole new type of error. However, if the kernel did
> > > > return EIO instead, it would be impossible for me to see that as a
> > > > kernel regression because the old behaviour was probably explosions
> > > > everywhere anyway.
> > > > 
> > > > I heard that UDL and maybe some other drivers in the kernel already
> > > > handle hot-unplug somehow. Maybe those are what would regress if the
> > > > kernel returned EIO?  
> > > I think most of the not-explodey drivers currently just (mostly?) it all
> > > hw errors. You kinda have to if you actually want to deal with hotunplug,
> > > stuff can disappear for any moment without warning anyway. Starting to
> > > just skip everything is the simplest approach, plus in large parts of the
> > > modeset helpers we don't even return values - kernel drivers suck as much
> > > at handling the unexpected errors as userspace :-)
> > > -Daniel
> > >   
> > > >   
> > > > > > +
> > > > > > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > > > > > +  is expecting.
> > > > > > +
> > > > > > +- If underlying memory disappears, the mmaps are replaced with harmless
> > > > > > +  zero pages where access does not raise SIGBUS. Reads return zeros,
> > > > > > +  writes are ignored.
> > > > > > +
> > > > > > +- dmabuf which point to memory that has disappeared are rewritten to
> > > > > > +  point to harmless zero pages, similar to mmaps. Imports still succeed
> > > > > > +  both ways: an existing device importing a dmabuf pointing to
> > > > > > +  disappeared memory, and a disappeared device importing any dmabuf.  
> > > > > 
> > > > > Same as above, I would expect drmPrimeHandleToFD and drmPrimeFDToHandle
> > > > > to return -EIO in case device is detached  
> > > > I imagined a use case behind this: a Wayland compositor attempting to
> > > > import a client's dmabuf. The GPU the client was using is
> > > > hot-unplugged, meaning the dmabufs lose their storage. It is up to the
> > > > client to handle its rendering GPU disappearance on its own, but also
> > > > the compositor should not disconnect it because the GPU disappeared.
> > > > It's not the client's fault the GPU disappeared.
> > > > 
> > > > In Wayland, failure to use a wl_buffer is considered a protocol error,
> > > > and protocol errors are always fatal: the client is disconnected. The
> > > > rationale is that the compositor must always be able to present the
> > > > client buffer somehow. If the compositor cannot, then the client did
> > > > not obey the protocol.
> > > > 
> > > > The fallback presentation path in a compositor is usually importing the
> > > > dmabuf to EGL, to be sampled from OpenGL. Normally the protocol
> > > > guarantees that this works, so any failure to do so is a protocol
> > > > violation. But if the GPU used by the client suddenly disappears and
> > > > the imports start to fail, that is interpreted as a protocol violation
> > > > unless the compositor can see why the import failed. Since the import
> > > > is done via EGL, getting the right error code plumbed through from
> > > > libdrm functions to the EGL caller would be a hassle. I don't see any
> > > > error code in EGL_EXT_image_dma_buf_import reserved for "the dmabuf
> > > > storage was hot-unplugged", and I doubt there is anything exclusively
> > > > for only that in the EGL base spec either.
> > > > 
> > > > The cost of lying that the import worked is that the compositor will
> > > > paint black or transparent where the window was supposed to be. It's a
> > > > graphical glitch that is contrary to the Wayland design principles, but
> > > > in this case a glitch is unavoidable: even if the compositor knew this
> > > > buffer is now bad, what would it paint instead? It has nothing else to
> > > > paint from. I'm assuming the compositor is using a different GPU than
> > > > what disappeared.
> > > > 
> > > > Ideally, the client will eventually react to losing the GPU and either
> > > > crash, quit, or switch its rendering to something that works which
> > > > simply gives the compositor a new, working buffer without losing any
> > > > window state in the process. If we risk the compositor disconnecting
> > > > the client, then the client might not recover even if it wanted to.
> > > >   
> > > > > > +
> > > > > > +- Render ioctls return EIO which is then handled in userspace drivers,
> > > > > > +  e.g. Mesa, to have the device disappearance handled in the way
> > > > > > +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> > > > > > +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)  
> > > > > 
> > > > > As far as I understood from our discussion we would reject any IOCTL
> > > > > aimed at a device which is gone and not only render ioctls.  
> > > > Daniel?
> > > > 
> > > > 
> > > > Thanks,
> > > > pq
> > > >   
> > > > > Andrey
> > > > > 
> > > > >   
> > > > > > +
> > > > > > +Raising SIGBUS is not an option, because userspace cannot realistically
> > > > > > +handle it.  Signal handlers are global, which makes them extremely
> > > > > > +difficult to use correctly from libraries like Mesa produces. Signal
> > > > > > +handlers are not composable, you can't have different handlers for GPU1
> > > > > > +and GPU2 from different vendors, and a third handler for mmapped regular
> > > > > > +files.  Threads cause additional pain with signal handling as well.
> > > > > > +
> > > > > > +Only after userspace has closed all relevant DRM device and dmabuf file
> > > > > > +descriptors and removed all mmaps, the DRM driver can tear down its
> > > > > > +instance for the device that no longer exists. If the same physical
> > > > > > +device somehow comes back in the mean time, it shall be a new DRM
> > > > > > +device.
> > > > > > +
> > > > > >    .. _drm_driver_ioctl:
> > > > > >    IOCTL Support on Device Nodes  
> > > 
> > >   
> 


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 10005 bytes --]

On Mon, 25 May 2020 16:30:17 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Mon, May 25, 2020 at 09:51:30AM -0400, Andrey Grodzovsky wrote:
> > On 5/25/20 8:46 AM, Pekka Paalanen wrote:
> >   
> > > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > 
> > > Set up the expectations on how hot-unplugging a DRM device should look like to
> > > userspace.
> > > 
> > > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > > from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cc9676f35bbdf4d5a052808d800a9b517%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260076178891269&amp;sdata=tbOTr7TfESohEgWspomM1sbMq4U4n7bOvdS6JlYifmM%3D&amp;reserved=0 .
> > > 
> > > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > > Cc: Dave Airlie <airlied@redhat.com>
> > > Cc: Sean Paul <sean@poorly.run>
> > > Cc: Simon Ser <contact@emersion.fr>
> > > 
> > > ---
> > > 
> > > v2:
> > > - mmap reads/writes undefined (danvet)
> > > - make render ioctl behaviour driver-specific (danvet)
> > > - restructure the mmap paragraphs (danvet)
> > > - chardev minor notes (Simon)
> > > - open behaviour (danvet)
> > > - DRM leasing behaviour (danvet)
> > > - added links
> > > 
> > > Disclaimer: I am a userspace developer writing for other userspace developers.
> > > I took some liberties in defining what should happen without knowing what is
> > > actually possible or what existing drivers already implement.
> > > ---
> > >   Documentation/gpu/drm-uapi.rst | 102 +++++++++++++++++++++++++++++++++
> > >   1 file changed, 102 insertions(+)
> > > 
> > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > > index 56fec6ed1ad8..520b8e640ad1 100644
> > > --- a/Documentation/gpu/drm-uapi.rst
> > > +++ b/Documentation/gpu/drm-uapi.rst
> > > @@ -1,3 +1,5 @@
> > > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > > +
> > >   ===================
> > >   Userland interfaces
> > >   ===================
> > > @@ -162,6 +164,106 @@ other hand, a driver requires shared state between clients which is
> > >   visible to user-space and accessible beyond open-file boundaries, they
> > >   cannot support render nodes.
> > > +Device Hot-Unplug
> > > +=================
> > > +
> > > +.. note::
> > > +   The following is the plan. Implementation is not there yet
> > > +   (2020 May).
> > > +
> > > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > > +user is able to hot-unplug this kind of devices while they are being
> > > +used, and expects that the very least the machine does not crash. Any
> > > +damage from hot-unplugging a DRM device needs to be limited as much as
> > > +possible and userspace must be given the chance to handle it if it wants
> > > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > > +running, but that is going to need explicit support throughout the whole
> > > +graphics stack: from kernel and userspace drivers, through display
> > > +servers, via window system protocols, and in applications and libraries.  
> > 
> > So to support all the requirements in this document only kernel changes
> > should be enough and no changes are required from user mode part of the
> > stack ?
> >   
> > > +
> > > +Other scenarios that should lead to the same are: unrecoverable GPU
> > > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > > +from the physical device.
> > > +
> > > +In other words, from userspace perspective everything needs to keep on
> > > +working more or less, until userspace stops using the disappeared DRM
> > > +device and closes it completely. Userspace will learn of the device
> > > +disappearance from the device removed uevent  
> > 
> > 
> > Is this uevent already implemented ? Can you point me to the code ?
> > 
> >   
> > > or in some cases
> > > +driver-specific ioctls returning EIO.
> > > +
> > > +Only after userspace has closed all relevant DRM device and dmabuf file
> > > +descriptors and removed all mmaps, the DRM driver can tear down its
> > > +instance for the device that no longer exists. If the same physical
> > > +device somehow comes back in the mean time, it shall be a new DRM
> > > +device.
> > > +
> > > +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> > > +new DRM device always picks the next free minor number compared to the
> > > +previous one allocated, and wraps around when minor numbers are
> > > +exhausted.
> > > +
> > > +Requirements for UAPI
> > > +---------------------
> > > +
> > > +The goal raises at least the following requirements for the kernel and
> > > +drivers:
> > > +
> > > +- The kernel must not hang, crash or oops, no matter what userspace was
> > > +  in the middle of doing when the device disappeared.
> > > +
> > > +- All GPU jobs that can no longer run must have their fences
> > > +  force-signalled to avoid inflicting hangs to userspace.
> > > +
> > > +- KMS connectors must change their status to disconnected.
> > > +
> > > +- Legacy modesets and pageflips fake success.
> > > +
> > > +- Atomic commits, both real and TEST_ONLY, fake success.
> > > +
> > > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > > +  is expecting.  
> > 
> > 
> > The 4 points above refer to mode setting/display attached card and are
> > irrelevant for secondary GPU (e.g. DRI-PRIME scenario) or no display system
> > in general. Maybe we can somehow highlight this in the document and I on the
> > implementing side can then decide as a first step to concentrate on
> > implementing the non display case as a first step or the only step. In
> > general and correct me if I am wrong, render only GPUs (or compute only) are
> > the majority of cases where you would want to be able to detach/attach GPU
> > on the fly (e.g attach stronger secondary graphic card to a laptop to get
> > high performance in a game or add/remove a GPU to/from a compute cluster)  
> 
> Yeah maybe splitting this up into kms section, and rendering/cross driver
> section (the dma-buf/fence stuff is relevant for both display and
> rendering) would make some sense.

Is that really something that needs spelling out?

Hmm. I guess the unwritten assumption on every "fake success" is the
condition that it would have succeeded if the device was not unplugged.

Is the problem here that one might read this as needing to fake success
for things that could never have worked at all? Like KMS on render-only
device.

The dmabuf items below have the wording.

I think splitting stuff into KMS stuff, render stuff, KMS-and-render
stuff, cross-device stuff, and mmaps gets a bit far. Or do you expect a
lot more text in here? Maybe expanding each bullet point to a paragraph?


Thanks,
pq


> -Daniel
> 
> > 
> > Andrey
> > 
> >   
> > > +
> > > +- dmabuf which point to memory that has disappeared will continue to
> > > +  be successfully imported if it would have succeeded before the
> > > +  disappearance.
> > > +
> > > +- Attempting to import a dmabuf to a disappeared device will succeed if
> > > +  it would have succeeded without the disappearance.
> > > +
> > > +- Some userspace APIs already define what should happen when the device
> > > +  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
> > > +  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
> > > +  behaviour the way they see best, e.g. returning failures in
> > > +  driver-specific ioctls and handling those in userspace drivers, or
> > > +  rely on uevents, and so on.
> > > +
> > > +- open() on a device node whose underlying device has disappeared will
> > > +  fail.
> > > +
> > > +- Attempting to create a DRM lease on a disappeared DRM device will
> > > +  fail. Existing DRM leases remain.
> > > +
> > > +.. _GL_KHR_robustness: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fregistry%2FOpenGL%2Fextensions%2FKHR%2FKHR_robustness.txt&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cc9676f35bbdf4d5a052808d800a9b517%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260076178891269&amp;sdata=m%2FneRusoe6qGVU8Edk%2FncaD7eSJZXtPnA1IqLr7k%2Bos%3D&amp;reserved=0
> > > +.. _Vulkan: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fvulkan%2F&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cc9676f35bbdf4d5a052808d800a9b517%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637260076178901265&amp;sdata=WsfLduUBzRKlybOJb5PQViBWYu5DgleEeycmf76l3UU%3D&amp;reserved=0
> > > +
> > > +Requirements for memory maps
> > > +----------------------------
> > > +
> > > +Memory maps have further requirements. If the underlying memory
> > > +disappears, the mmap is modified such that reads and writes will still
> > > +complete successfully but the result is undefined. This applies to both
> > > +userspace mmap()'d memory and memory pointed to by dmabuf which might be
> > > +mapped to other devices.
> > > +
> > > +Raising SIGBUS is not an option, because userspace cannot realistically
> > > +handle it.  Signal handlers are global, which makes them extremely
> > > +difficult to use correctly from libraries like those that Mesa produces.
> > > +Signal handlers are not composable, you can't have different handlers
> > > +for GPU1 and GPU2 from different vendors, and a third handler for
> > > +mmapped regular files.  Threads cause additional pain with signal
> > > +handling as well.
> > > +
> > >   .. _drm_driver_ioctl:
> > >   IOCTL Support on Device Nodes  
> 


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Mon, May 25, 2020 at 05:55:19PM +0300, Pekka Paalanen wrote:
> On Mon, 25 May 2020 16:28:04 +0200
> Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Wed, May 20, 2020 at 10:50:41AM -0400, Andrey Grodzovsky wrote:
> > > 
> > > On 5/20/20 8:46 AM, Daniel Vetter wrote:  
> > > > On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote:  
> > > > > On Tue, 19 May 2020 10:37:12 -0400
> > > > > Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
> > > > >   
> > > > > > Thanks for the summary, does put things in order and makes it easier to
> > > > > > comprehend all the TODOs, some questions bellow
> > > > > > 
> > > > > > On 5/19/20 6:06 AM, Pekka Paalanen wrote:  
> > > > > > > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > > > > > 
> > > > > > > Set up the expectations on how hot-unplugging a DRM device should look like to
> > > > > > > userspace.
> > > > > > > 
> > > > > > > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > > > > > > from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7Ca4da241ff1e54610d95508d7fcbbcc11%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637255755828209496&amp;sdata=YDFoP2g3z3IiB77sRvAmPB%2Fix%2FV0Mh78YcCSAAlhXdg%3D&amp;reserved=0 .
> > > > > > > 
> > > > > > > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > > > > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > > > > > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > > > > > > Cc: Dave Airlie <airlied@redhat.com>
> > > > > > > Cc: Sean Paul <sean@poorly.run>
> > > > > > > 
> > > > > > > ---
> > > > > > > 
> > > > > > > Disclaimer: I am a userspace developer writing for other userspace developers.
> > > > > > > I took some liberties in defining what should happen without knowing what is
> > > > > > > actually possible or what existing drivers already implement.
> > > > > > > ---
> > > > > > >    Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
> > > > > > >    1 file changed, 75 insertions(+)
> > > > > > > 
> > > > > > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > > > > > > index 56fec6ed1ad8..80db4abd2cbd 100644
> > > > > > > --- a/Documentation/gpu/drm-uapi.rst
> > > > > > > +++ b/Documentation/gpu/drm-uapi.rst
> > > > > > > @@ -1,3 +1,5 @@
> > > > > > > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > > > > > > +
> > > > > > >    ===================
> > > > > > >    Userland interfaces
> > > > > > >    ===================
> > > > > > > @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
> > > > > > >    visible to user-space and accessible beyond open-file boundaries, they
> > > > > > >    cannot support render nodes.
> > > > > > > +Device Hot-Unplug
> > > > > > > +=================
> > > > > > > +
> > > > > > > +.. note::
> > > > > > > +   The following is the plan. Implementation is not there yet
> > > > > > > +   (2020 May 13).
> > > > > > > +
> > > > > > > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > > > > > > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > > > > > > +user is able to hot-unplug this kind of devices while they are being
> > > > > > > +used, and expects that the very least the machine does not crash. Any
> > > > > > > +damage from hot-unplugging a DRM device needs to be limited as much as
> > > > > > > +possible and userspace must be given the chance to handle it if it wants
> > > > > > > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > > > > > > +running, but that is going to need explicit support throughout the whole
> > > > > > > +graphics stack: from kernel and userspace drivers, through display
> > > > > > > +servers, via window system protocols, and in applications and libraries.
> > > > > > > +
> > > > > > > +Other scenarios that should lead to the same are: unrecoverable GPU
> > > > > > > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > > > > > > +from the physical device.
> > > > > > > +
> > > > > > > +In other words, from userspace perspective everything needs to keep on
> > > > > > > +working more or less, until userspace stops using the disappeared DRM
> > > > > > > +device and closes it completely. Userspace will learn of the device
> > > > > > > +disappearance from the device removed uevent or in some cases specific
> > > > > > > +ioctls returning EIO.
> > > > > > > +
> > > > > > > +This goal raises at least the following requirements for the kernel and
> > > > > > > +drivers:
> > > > > > > +
> > > > > > > +- The kernel must not hang, crash or oops, no matter what userspace was
> > > > > > > +  in the middle of doing when the device disappeared.
> > > > > > > +
> > > > > > > +- All GPU jobs that can no longer run must have their fences
> > > > > > > +  force-signalled to avoid inflicting hangs to userspace.
> > > > > > > +
> > > > > > > +- KMS connectors must change their status to disconnected.
> > > > > > > +
> > > > > > > +- Legacy modesets and pageflips fake success.
> > > > > > > +
> > > > > > > +- Atomic commits, both real and TEST_ONLY, fake success.  
> > > > > > 
> > > > > > Why wouldn't we return -EIO for the atommic commit IOTCL/legasy pflip
> > > > > > and modeset ioctls here same way as you suggested returning -EIO for
> > > > > > render ioctl ?  
> > > > > Hi,
> > > > > 
> > > > > that is more of a question for Daniel Vetter than me. I believe he is
> > > > > worried that userspace will get the error handling horribly wrong
> > > > > anyway, because it needs to be handled in every single display server
> > > > > project. Render ioctl errors OTOH need to be handled only in the
> > > > > corresponding Mesa or other userspace driver, and for render there are
> > > > > API (OpenGL/EGL, Vulkan) specs that say how it must be handled to fill
> > > > > the API contract. Because of the API contract, those are more likely to
> > > > > have reasonable error handling in place already.  
> > > > Yup pretty much. Atm compositors expect an -EINVAL (especially for
> > > > TEST_ONLY), some cope with the semi-spurious -EBUSY we still throw around,
> > > > but I expect most will just die if the get an -ENOMEM or -EIO or really
> > > > anything.
> > > > 
> > > > I think one area where we've historically thrown some spurious errors is
> > > > also vblank ioctls, since they don't take full locks and sometimes the
> > > > kernel needs to sneak in a modeset for some reason (gpu recovery, dp link
> > > > recovery, ...).
> > > > 
> > > > Either way I don't think there's anything the compositor can do than just
> > > > ignore the error and carry on.  
> > > 
> > > 
> > > So currently drm_ioctl will just check for drm_dev_is_unplugged and return
> > > -ENODEV at the very beginning of the function (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_ioctl.c#L825)
> > > meaning that currently we blanket failure any IOCTL in case the device is
> > > unplagued (ignoring the race condition if the device unplugged after the
> > > check). So do we want to remove this check and put it only for render ioctls
> > > (which are those ? e.g. for amdgpu there is  AMDGPU_CS ioctl) but not for
> > > mode setting/dma_buf_import/dma_buf_export ioctls ? What about other types
> > > of ioctls which are non of the listed above ?  
> > 
> > Hm right, and this goes back all the way to first usb udl support:
> > 
> > commit 2c07a21d6fb0be47fda696a618b726ea258ed1dd
> > Author: Dave Airlie <airlied@redhat.com>
> > Date:   Mon Feb 20 14:18:07 2012 +0000
> > 
> >     drm: add core support for unplugging a device (v2)
> > 
> > So I guess we need to change the uapi docs to explain that. Not sure
> > everyone can cope, but I guess they better do. Since the use-case back
> > then was just udl, so simple legacy kms only, the damage was probably
> > rather limited. I'm not sure we can get away with that now, where kms code
> > has spread to funny places likey vulkan winsys code.
> > 
> > Or maybe we want a file priv flag you can set along the lines of "give me
> > less shitty hotunplug semantics for ioctls". Or maybe we can just change
> > the semantics, not crashing&burning shouldn't cause a regression :-)
> > 
> > For everything else (mmap, dma-buf fd, sync_file fd, syncobj fd) I think
> > the discussion is still more or less accurate.
> > 
> > Pekka, any thoughts?
> 
> Hi,
> 
> is ENODEV unique to this particular failure?

Not really sure, we'd need to audit all of drm ...

> Returning errors instead of faking success was my first idea, but you
> already convinced me that faking is at least as good if not better. :-)
> 
> So as long as the error code returned is unique to hot-unplug or other
> "oops, the device is gone" conditions, I think I'm fine. Weston does
> not handle ENODEV any way, it never did, and it certainly cannot be
> called a kernel regression.
> 
> As a Weston developer, I don't mind adding checks for ENODEV. But if I
> don't have to, even better. Weston is going to need more code to handle
> DRM device unplug in any case.
> 
> Sorry, no preference from me. ;-)
> 
> I do agree that replacing ENODEV with fake success is hard to imagine
> regressing anything. It's something you can do in the kernel at any
> time easily, but going from fake success to error is going to be
> painful. Maybe don't change things until there is a good reason to?
> 
> We need a kernel that doesn't crash before we can properly test what
> would be best for userspace, fake or error.

One upshot of faking stuff and only bailing in low-level hw code is that
it makes validating the races when you hotunplug easier - if we remove the
early bail-out check even an ioctl later on will look like it raced with
the hotunplug path in the kernel. So better assurance that things won't
blow up badly.

Otoh the early bail out in the top-level ioctl code increases the odds
that you'll survive even on a driver that's totally buggy.

So yeah I guess maybe we should just document that currently you get an
-ENODEV and maybe have the option mentioned that we might change this
going forward. See also

https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values

I think that needs an update, at least clarify that "not present" includes
"no longer present".
-Daniel

> 
> 
> Thanks,
> pq
> 
> 
> > -Daniel
> > 
> > > 
> > > Andrey
> > > 
> > >   
> > > >   
> > > > > I first thought it would be obvious for at least atomic commits to fail
> > > > > appropriately, but then thinking again, it will only introduce new
> > > > > failures that are currently very hard to test for (VKMS to the rescue),
> > > > > and userspace would need to have code to correctly bail out for EIO
> > > > > rather than attempt fallbacks. The uevent telling the device is gone is
> > > > > going to come anyway. In between the device disappearance and uevent
> > > > > handling, it doesn't matter much what happens: the device is abruptly
> > > > > gone and the user will see a glitch anyway - he knows, he just yanked
> > > > > out the cable.
> > > > > 
> > > > > To me this decision is just to make life in userspace easier by not
> > > > > introducing a whole new type of error. However, if the kernel did
> > > > > return EIO instead, it would be impossible for me to see that as a
> > > > > kernel regression because the old behaviour was probably explosions
> > > > > everywhere anyway.
> > > > > 
> > > > > I heard that UDL and maybe some other drivers in the kernel already
> > > > > handle hot-unplug somehow. Maybe those are what would regress if the
> > > > > kernel returned EIO?  
> > > > I think most of the not-explodey drivers currently just (mostly?) it all
> > > > hw errors. You kinda have to if you actually want to deal with hotunplug,
> > > > stuff can disappear for any moment without warning anyway. Starting to
> > > > just skip everything is the simplest approach, plus in large parts of the
> > > > modeset helpers we don't even return values - kernel drivers suck as much
> > > > at handling the unexpected errors as userspace :-)
> > > > -Daniel
> > > >   
> > > > >   
> > > > > > > +
> > > > > > > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > > > > > > +  is expecting.
> > > > > > > +
> > > > > > > +- If underlying memory disappears, the mmaps are replaced with harmless
> > > > > > > +  zero pages where access does not raise SIGBUS. Reads return zeros,
> > > > > > > +  writes are ignored.
> > > > > > > +
> > > > > > > +- dmabuf which point to memory that has disappeared are rewritten to
> > > > > > > +  point to harmless zero pages, similar to mmaps. Imports still succeed
> > > > > > > +  both ways: an existing device importing a dmabuf pointing to
> > > > > > > +  disappeared memory, and a disappeared device importing any dmabuf.  
> > > > > > 
> > > > > > Same as above, I would expect drmPrimeHandleToFD and drmPrimeFDToHandle
> > > > > > to return -EIO in case device is detached  
> > > > > I imagined a use case behind this: a Wayland compositor attempting to
> > > > > import a client's dmabuf. The GPU the client was using is
> > > > > hot-unplugged, meaning the dmabufs lose their storage. It is up to the
> > > > > client to handle its rendering GPU disappearance on its own, but also
> > > > > the compositor should not disconnect it because the GPU disappeared.
> > > > > It's not the client's fault the GPU disappeared.
> > > > > 
> > > > > In Wayland, failure to use a wl_buffer is considered a protocol error,
> > > > > and protocol errors are always fatal: the client is disconnected. The
> > > > > rationale is that the compositor must always be able to present the
> > > > > client buffer somehow. If the compositor cannot, then the client did
> > > > > not obey the protocol.
> > > > > 
> > > > > The fallback presentation path in a compositor is usually importing the
> > > > > dmabuf to EGL, to be sampled from OpenGL. Normally the protocol
> > > > > guarantees that this works, so any failure to do so is a protocol
> > > > > violation. But if the GPU used by the client suddenly disappears and
> > > > > the imports start to fail, that is interpreted as a protocol violation
> > > > > unless the compositor can see why the import failed. Since the import
> > > > > is done via EGL, getting the right error code plumbed through from
> > > > > libdrm functions to the EGL caller would be a hassle. I don't see any
> > > > > error code in EGL_EXT_image_dma_buf_import reserved for "the dmabuf
> > > > > storage was hot-unplugged", and I doubt there is anything exclusively
> > > > > for only that in the EGL base spec either.
> > > > > 
> > > > > The cost of lying that the import worked is that the compositor will
> > > > > paint black or transparent where the window was supposed to be. It's a
> > > > > graphical glitch that is contrary to the Wayland design principles, but
> > > > > in this case a glitch is unavoidable: even if the compositor knew this
> > > > > buffer is now bad, what would it paint instead? It has nothing else to
> > > > > paint from. I'm assuming the compositor is using a different GPU than
> > > > > what disappeared.
> > > > > 
> > > > > Ideally, the client will eventually react to losing the GPU and either
> > > > > crash, quit, or switch its rendering to something that works which
> > > > > simply gives the compositor a new, working buffer without losing any
> > > > > window state in the process. If we risk the compositor disconnecting
> > > > > the client, then the client might not recover even if it wanted to.
> > > > >   
> > > > > > > +
> > > > > > > +- Render ioctls return EIO which is then handled in userspace drivers,
> > > > > > > +  e.g. Mesa, to have the device disappearance handled in the way
> > > > > > > +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> > > > > > > +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)  
> > > > > > 
> > > > > > As far as I understood from our discussion we would reject any IOCTL
> > > > > > aimed at a device which is gone and not only render ioctls.  
> > > > > Daniel?
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > pq
> > > > >   
> > > > > > Andrey
> > > > > > 
> > > > > >   
> > > > > > > +
> > > > > > > +Raising SIGBUS is not an option, because userspace cannot realistically
> > > > > > > +handle it.  Signal handlers are global, which makes them extremely
> > > > > > > +difficult to use correctly from libraries like Mesa produces. Signal
> > > > > > > +handlers are not composable, you can't have different handlers for GPU1
> > > > > > > +and GPU2 from different vendors, and a third handler for mmapped regular
> > > > > > > +files.  Threads cause additional pain with signal handling as well.
> > > > > > > +
> > > > > > > +Only after userspace has closed all relevant DRM device and dmabuf file
> > > > > > > +descriptors and removed all mmaps, the DRM driver can tear down its
> > > > > > > +instance for the device that no longer exists. If the same physical
> > > > > > > +device somehow comes back in the mean time, it shall be a new DRM
> > > > > > > +device.
> > > > > > > +
> > > > > > >    .. _drm_driver_ioctl:
> > > > > > >    IOCTL Support on Device Nodes  
> > > > 
> > > >   
> > 
> 



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Andrey Grodzovsky]

On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783&amp;sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3D&amp;reserved=0 .
>
> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Sean Paul <sean@poorly.run>
>
> ---
>
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>   Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
>   1 file changed, 75 insertions(+)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..80db4abd2cbd 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -1,3 +1,5 @@
> +.. Copyright 2020 DisplayLink (UK) Ltd.
> +
>   ===================
>   Userland interfaces
>   ===================
> @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
>   visible to user-space and accessible beyond open-file boundaries, they
>   cannot support render nodes.
>   
> +Device Hot-Unplug
> +=================
> +
> +.. note::
> +   The following is the plan. Implementation is not there yet
> +   (2020 May 13).
> +
> +Graphics devices (display and/or render) may be connected via USB (e.g.
> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> +user is able to hot-unplug this kind of devices while they are being
> +used, and expects that the very least the machine does not crash. Any
> +damage from hot-unplugging a DRM device needs to be limited as much as
> +possible and userspace must be given the chance to handle it if it wants
> +to. Ideally, unplugging a DRM device still lets a desktop to continue
> +running, but that is going to need explicit support throughout the whole
> +graphics stack: from kernel and userspace drivers, through display
> +servers, via window system protocols, and in applications and libraries.
> +
> +Other scenarios that should lead to the same are: unrecoverable GPU
> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> +from the physical device.
> +
> +In other words, from userspace perspective everything needs to keep on
> +working more or less, until userspace stops using the disappeared DRM
> +device and closes it completely. Userspace will learn of the device
> +disappearance from the device removed uevent or in some cases specific
> +ioctls returning EIO.
> +
> +This goal raises at least the following requirements for the kernel and
> +drivers:
> +
> +- The kernel must not hang, crash or oops, no matter what userspace was
> +  in the middle of doing when the device disappeared.
> +
> +- All GPU jobs that can no longer run must have their fences
> +  force-signalled to avoid inflicting hangs to userspace.
> +
> +- KMS connectors must change their status to disconnected.
> +
> +- Legacy modesets and pageflips fake success.
> +
> +- Atomic commits, both real and TEST_ONLY, fake success.
> +
> +- Pending non-blocking KMS operations deliver the DRM events userspace
> +  is expecting.
> +
> +- If underlying memory disappears, the mmaps are replaced with harmless
> +  zero pages where access does not raise SIGBUS. Reads return zeros,
> +  writes are ignored.


Regarding this paragraph - what about exiting mappings ? In the first 
patchset we would actively invalidate all the existing CPU mappings to 
device memory and i think we still should do it otherwise we will see 
random crashes in applications as was before. I guess it's because TLBs 
and page tables are not updated to reflect the fact the device is gone.

Andrey


> +
> +- dmabuf which point to memory that has disappeared are rewritten to
> +  point to harmless zero pages, similar to mmaps. Imports still succeed
> +  both ways: an existing device importing a dmabuf pointing to
> +  disappeared memory, and a disappeared device importing any dmabuf.
> +
> +- Render ioctls return EIO which is then handled in userspace drivers,
> +  e.g. Mesa, to have the device disappearance handled in the way
> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
> +
> +Raising SIGBUS is not an option, because userspace cannot realistically
> +handle it.  Signal handlers are global, which makes them extremely
> +difficult to use correctly from libraries like Mesa produces. Signal
> +handlers are not composable, you can't have different handlers for GPU1
> +and GPU2 from different vendors, and a third handler for mmapped regular
> +files.  Threads cause additional pain with signal handling as well.
> +
> +Only after userspace has closed all relevant DRM device and dmabuf file
> +descriptors and removed all mmaps, the DRM driver can tear down its
> +instance for the device that no longer exists. If the same physical
> +device somehow comes back in the mean time, it shall be a new DRM
> +device.
> +
>   .. _drm_driver_ioctl:
>   
>   IOCTL Support on Device Nodes
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 6403 bytes --]

On Tue, 26 May 2020 10:30:20 -0400
Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:

> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> >
> > Set up the expectations on how hot-unplugging a DRM device should look like to
> > userspace.
> >
> > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783&amp;sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3D&amp;reserved=0 .
> >
> > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Sean Paul <sean@poorly.run>
> >
> > ---
> >
> > Disclaimer: I am a userspace developer writing for other userspace developers.
> > I took some liberties in defining what should happen without knowing what is
> > actually possible or what existing drivers already implement.
> > ---
> >   Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
> >   1 file changed, 75 insertions(+)
> >
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index 56fec6ed1ad8..80db4abd2cbd 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -1,3 +1,5 @@
> > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > +
> >   ===================
> >   Userland interfaces
> >   ===================
> > @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
> >   visible to user-space and accessible beyond open-file boundaries, they
> >   cannot support render nodes.
> >   
> > +Device Hot-Unplug
> > +=================
> > +
> > +.. note::
> > +   The following is the plan. Implementation is not there yet
> > +   (2020 May 13).
> > +
> > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > +user is able to hot-unplug this kind of devices while they are being
> > +used, and expects that the very least the machine does not crash. Any
> > +damage from hot-unplugging a DRM device needs to be limited as much as
> > +possible and userspace must be given the chance to handle it if it wants
> > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > +running, but that is going to need explicit support throughout the whole
> > +graphics stack: from kernel and userspace drivers, through display
> > +servers, via window system protocols, and in applications and libraries.
> > +
> > +Other scenarios that should lead to the same are: unrecoverable GPU
> > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > +from the physical device.
> > +
> > +In other words, from userspace perspective everything needs to keep on
> > +working more or less, until userspace stops using the disappeared DRM
> > +device and closes it completely. Userspace will learn of the device
> > +disappearance from the device removed uevent or in some cases specific
> > +ioctls returning EIO.
> > +
> > +This goal raises at least the following requirements for the kernel and
> > +drivers:
> > +
> > +- The kernel must not hang, crash or oops, no matter what userspace was
> > +  in the middle of doing when the device disappeared.
> > +
> > +- All GPU jobs that can no longer run must have their fences
> > +  force-signalled to avoid inflicting hangs to userspace.
> > +
> > +- KMS connectors must change their status to disconnected.
> > +
> > +- Legacy modesets and pageflips fake success.
> > +
> > +- Atomic commits, both real and TEST_ONLY, fake success.
> > +
> > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > +  is expecting.
> > +
> > +- If underlying memory disappears, the mmaps are replaced with harmless
> > +  zero pages where access does not raise SIGBUS. Reads return zeros,
> > +  writes are ignored.  
> 
> 
> Regarding this paragraph - what about exiting mappings ? In the first 
> patchset we would actively invalidate all the existing CPU mappings to 
> device memory and i think we still should do it otherwise we will see 
> random crashes in applications as was before. I guess it's because TLBs 
> and page tables are not updated to reflect the fact the device is gone.

Hi,

I was talking about existing mappings. What I forgot to specify is how
new mmap() calls after the device disappearance should work (the end
result should be the same still, not failure).

I'll clarify this in the next revision.


Thanks,
pq


> > +
> > +- dmabuf which point to memory that has disappeared are rewritten to
> > +  point to harmless zero pages, similar to mmaps. Imports still succeed
> > +  both ways: an existing device importing a dmabuf pointing to
> > +  disappeared memory, and a disappeared device importing any dmabuf.
> > +
> > +- Render ioctls return EIO which is then handled in userspace drivers,
> > +  e.g. Mesa, to have the device disappearance handled in the way
> > +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> > +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
> > +
> > +Raising SIGBUS is not an option, because userspace cannot realistically
> > +handle it.  Signal handlers are global, which makes them extremely
> > +difficult to use correctly from libraries like Mesa produces. Signal
> > +handlers are not composable, you can't have different handlers for GPU1
> > +and GPU2 from different vendors, and a third handler for mmapped regular
> > +files.  Threads cause additional pain with signal handling as well.
> > +
> > +Only after userspace has closed all relevant DRM device and dmabuf file
> > +descriptors and removed all mmaps, the DRM driver can tear down its
> > +instance for the device that no longer exists. If the same physical
> > +device somehow comes back in the mean time, it shall be a new DRM
> > +device.
> > +
> >   .. _drm_driver_ioctl:
> >   
> >   IOCTL Support on Device Nodes  


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Andrey Grodzovsky]

On 5/27/20 2:44 AM, Pekka Paalanen wrote:
> On Tue, 26 May 2020 10:30:20 -0400
> Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
>
>> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
>>> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>
>>> Set up the expectations on how hot-unplugging a DRM device should look like to
>>> userspace.
>>>
>>> Written by Daniel Vetter's request and largely based on his comments in IRC and
>>> from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783&amp;sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3D&amp;reserved=0 .
>>>
>>> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
>>> Cc: Daniel Vetter <daniel@ffwll.ch>
>>> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>> Cc: Dave Airlie <airlied@redhat.com>
>>> Cc: Sean Paul <sean@poorly.run>
>>>
>>> ---
>>>
>>> Disclaimer: I am a userspace developer writing for other userspace developers.
>>> I took some liberties in defining what should happen without knowing what is
>>> actually possible or what existing drivers already implement.
>>> ---
>>>    Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
>>>    1 file changed, 75 insertions(+)
>>>
>>> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
>>> index 56fec6ed1ad8..80db4abd2cbd 100644
>>> --- a/Documentation/gpu/drm-uapi.rst
>>> +++ b/Documentation/gpu/drm-uapi.rst
>>> @@ -1,3 +1,5 @@
>>> +.. Copyright 2020 DisplayLink (UK) Ltd.
>>> +
>>>    ===================
>>>    Userland interfaces
>>>    ===================
>>> @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
>>>    visible to user-space and accessible beyond open-file boundaries, they
>>>    cannot support render nodes.
>>>    
>>> +Device Hot-Unplug
>>> +=================
>>> +
>>> +.. note::
>>> +   The following is the plan. Implementation is not there yet
>>> +   (2020 May 13).
>>> +
>>> +Graphics devices (display and/or render) may be connected via USB (e.g.
>>> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
>>> +user is able to hot-unplug this kind of devices while they are being
>>> +used, and expects that the very least the machine does not crash. Any
>>> +damage from hot-unplugging a DRM device needs to be limited as much as
>>> +possible and userspace must be given the chance to handle it if it wants
>>> +to. Ideally, unplugging a DRM device still lets a desktop to continue
>>> +running, but that is going to need explicit support throughout the whole
>>> +graphics stack: from kernel and userspace drivers, through display
>>> +servers, via window system protocols, and in applications and libraries.
>>> +
>>> +Other scenarios that should lead to the same are: unrecoverable GPU
>>> +crash, PCI device disappearing off the bus, or forced unbind of a driver
>>> +from the physical device.
>>> +
>>> +In other words, from userspace perspective everything needs to keep on
>>> +working more or less, until userspace stops using the disappeared DRM
>>> +device and closes it completely. Userspace will learn of the device
>>> +disappearance from the device removed uevent or in some cases specific
>>> +ioctls returning EIO.
>>> +
>>> +This goal raises at least the following requirements for the kernel and
>>> +drivers:
>>> +
>>> +- The kernel must not hang, crash or oops, no matter what userspace was
>>> +  in the middle of doing when the device disappeared.
>>> +
>>> +- All GPU jobs that can no longer run must have their fences
>>> +  force-signalled to avoid inflicting hangs to userspace.
>>> +
>>> +- KMS connectors must change their status to disconnected.
>>> +
>>> +- Legacy modesets and pageflips fake success.
>>> +
>>> +- Atomic commits, both real and TEST_ONLY, fake success.
>>> +
>>> +- Pending non-blocking KMS operations deliver the DRM events userspace
>>> +  is expecting.
>>> +
>>> +- If underlying memory disappears, the mmaps are replaced with harmless
>>> +  zero pages where access does not raise SIGBUS. Reads return zeros,
>>> +  writes are ignored.
>>
>> Regarding this paragraph - what about exiting mappings ? In the first
>> patchset we would actively invalidate all the existing CPU mappings to
>> device memory and i think we still should do it otherwise we will see
>> random crashes in applications as was before. I guess it's because TLBs
>> and page tables are not updated to reflect the fact the device is gone.
> Hi,
>
> I was talking about existing mappings. What I forgot to specify is how
> new mmap() calls after the device disappearance should work (the end
> result should be the same still, not failure).
>
> I'll clarify this in the next revision.
>
>
> Thanks,
> pq


I see, that ok.

Next related question is more for Daniel/Christian - about the 
implementation of this paragraph, I was thinking about something like 
checking for device disconnect in ttm_bo_vm_fault_reserved and if so 
remap the entire VA range for the VMA where the fault address belongs to 
the global zero page (i.e. (remap_pfn_range(vma, vma->vm_start, 
page_to_pfn(ZERO_PAGE(vma->vm_start), vma->vm_end - vma->vm_start, 
vma->vm_page_prot)). Question is, when the doc says 'writes are ignored' 
does it mean i should use copy on write for the vma->vm_page_prot and if 
so how i actually do it as i was not able to find what flags to set into 
vm_page_prot to force copy on write behavior.

Andrey




>
>
>>> +
>>> +- dmabuf which point to memory that has disappeared are rewritten to
>>> +  point to harmless zero pages, similar to mmaps. Imports still succeed
>>> +  both ways: an existing device importing a dmabuf pointing to
>>> +  disappeared memory, and a disappeared device importing any dmabuf.
>>> +
>>> +- Render ioctls return EIO which is then handled in userspace drivers,
>>> +  e.g. Mesa, to have the device disappearance handled in the way
>>> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
>>> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
>>> +
>>> +Raising SIGBUS is not an option, because userspace cannot realistically
>>> +handle it.  Signal handlers are global, which makes them extremely
>>> +difficult to use correctly from libraries like Mesa produces. Signal
>>> +handlers are not composable, you can't have different handlers for GPU1
>>> +and GPU2 from different vendors, and a third handler for mmapped regular
>>> +files.  Threads cause additional pain with signal handling as well.
>>> +
>>> +Only after userspace has closed all relevant DRM device and dmabuf file
>>> +descriptors and removed all mmaps, the DRM driver can tear down its
>>> +instance for the device that no longer exists. If the same physical
>>> +device somehow comes back in the mean time, it shall be a new DRM
>>> +device.
>>> +
>>>    .. _drm_driver_ioctl:
>>>    
>>>    IOCTL Support on Device Nodes
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Wed, May 27, 2020 at 3:51 PM Andrey Grodzovsky
<Andrey.Grodzovsky@amd.com> wrote:
>
>
> On 5/27/20 2:44 AM, Pekka Paalanen wrote:
> > On Tue, 26 May 2020 10:30:20 -0400
> > Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
> >
> >> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> >>> From: Pekka Paalanen <pekka.paalanen@collabora.com>
> >>>
> >>> Set up the expectations on how hot-unplugging a DRM device should look like to
> >>> userspace.
> >>>
> >>> Written by Daniel Vetter's request and largely based on his comments in IRC and
> >>> from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Ce8e13dc4c85648e5fcd408d7fbdc5f2b%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637254796242596783&amp;sdata=bA%2FAy3VGvzNqmV1kGigNROSZQEws2E98JibDxvEICNs%3D&amp;reserved=0 .
> >>>
> >>> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> >>> Cc: Daniel Vetter <daniel@ffwll.ch>
> >>> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> >>> Cc: Dave Airlie <airlied@redhat.com>
> >>> Cc: Sean Paul <sean@poorly.run>
> >>>
> >>> ---
> >>>
> >>> Disclaimer: I am a userspace developer writing for other userspace developers.
> >>> I took some liberties in defining what should happen without knowing what is
> >>> actually possible or what existing drivers already implement.
> >>> ---
> >>>    Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
> >>>    1 file changed, 75 insertions(+)
> >>>
> >>> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> >>> index 56fec6ed1ad8..80db4abd2cbd 100644
> >>> --- a/Documentation/gpu/drm-uapi.rst
> >>> +++ b/Documentation/gpu/drm-uapi.rst
> >>> @@ -1,3 +1,5 @@
> >>> +.. Copyright 2020 DisplayLink (UK) Ltd.
> >>> +
> >>>    ===================
> >>>    Userland interfaces
> >>>    ===================
> >>> @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
> >>>    visible to user-space and accessible beyond open-file boundaries, they
> >>>    cannot support render nodes.
> >>>
> >>> +Device Hot-Unplug
> >>> +=================
> >>> +
> >>> +.. note::
> >>> +   The following is the plan. Implementation is not there yet
> >>> +   (2020 May 13).
> >>> +
> >>> +Graphics devices (display and/or render) may be connected via USB (e.g.
> >>> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> >>> +user is able to hot-unplug this kind of devices while they are being
> >>> +used, and expects that the very least the machine does not crash. Any
> >>> +damage from hot-unplugging a DRM device needs to be limited as much as
> >>> +possible and userspace must be given the chance to handle it if it wants
> >>> +to. Ideally, unplugging a DRM device still lets a desktop to continue
> >>> +running, but that is going to need explicit support throughout the whole
> >>> +graphics stack: from kernel and userspace drivers, through display
> >>> +servers, via window system protocols, and in applications and libraries.
> >>> +
> >>> +Other scenarios that should lead to the same are: unrecoverable GPU
> >>> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> >>> +from the physical device.
> >>> +
> >>> +In other words, from userspace perspective everything needs to keep on
> >>> +working more or less, until userspace stops using the disappeared DRM
> >>> +device and closes it completely. Userspace will learn of the device
> >>> +disappearance from the device removed uevent or in some cases specific
> >>> +ioctls returning EIO.
> >>> +
> >>> +This goal raises at least the following requirements for the kernel and
> >>> +drivers:
> >>> +
> >>> +- The kernel must not hang, crash or oops, no matter what userspace was
> >>> +  in the middle of doing when the device disappeared.
> >>> +
> >>> +- All GPU jobs that can no longer run must have their fences
> >>> +  force-signalled to avoid inflicting hangs to userspace.
> >>> +
> >>> +- KMS connectors must change their status to disconnected.
> >>> +
> >>> +- Legacy modesets and pageflips fake success.
> >>> +
> >>> +- Atomic commits, both real and TEST_ONLY, fake success.
> >>> +
> >>> +- Pending non-blocking KMS operations deliver the DRM events userspace
> >>> +  is expecting.
> >>> +
> >>> +- If underlying memory disappears, the mmaps are replaced with harmless
> >>> +  zero pages where access does not raise SIGBUS. Reads return zeros,
> >>> +  writes are ignored.
> >>
> >> Regarding this paragraph - what about exiting mappings ? In the first
> >> patchset we would actively invalidate all the existing CPU mappings to
> >> device memory and i think we still should do it otherwise we will see
> >> random crashes in applications as was before. I guess it's because TLBs
> >> and page tables are not updated to reflect the fact the device is gone.
> > Hi,
> >
> > I was talking about existing mappings. What I forgot to specify is how
> > new mmap() calls after the device disappearance should work (the end
> > result should be the same still, not failure).
> >
> > I'll clarify this in the next revision.
> >
> >
> > Thanks,
> > pq
>
>
> I see, that ok.
>
> Next related question is more for Daniel/Christian - about the
> implementation of this paragraph, I was thinking about something like
> checking for device disconnect in ttm_bo_vm_fault_reserved and if so
> remap the entire VA range for the VMA where the fault address belongs to
> the global zero page (i.e. (remap_pfn_range(vma, vma->vm_start,
> page_to_pfn(ZERO_PAGE(vma->vm_start), vma->vm_end - vma->vm_start,
> vma->vm_page_prot)). Question is, when the doc says 'writes are ignored'
> does it mean i should use copy on write for the vma->vm_page_prot and if
> so how i actually do it as i was not able to find what flags to set into
> vm_page_prot to force copy on write behavior.

Already discussed this with Pekka on irc, I think simply a private
page (per gpu ctx to avoid leaks) is good enough. Otherwise we need to
catch write faults and throw the writes away, and that's a) a bit
tricky to implement and b) slow, which we kinda don't want to. If the
desktop is stuck for a few seconds because we're trapping every write
of a 4k buffer that's getting uploaded, the user is going to have a
bad time :-/
-Daniel

>
> Andrey
>
>
>
>
> >
> >
> >>> +
> >>> +- dmabuf which point to memory that has disappeared are rewritten to
> >>> +  point to harmless zero pages, similar to mmaps. Imports still succeed
> >>> +  both ways: an existing device importing a dmabuf pointing to
> >>> +  disappeared memory, and a disappeared device importing any dmabuf.
> >>> +
> >>> +- Render ioctls return EIO which is then handled in userspace drivers,
> >>> +  e.g. Mesa, to have the device disappearance handled in the way
> >>> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> >>> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
> >>> +
> >>> +Raising SIGBUS is not an option, because userspace cannot realistically
> >>> +handle it.  Signal handlers are global, which makes them extremely
> >>> +difficult to use correctly from libraries like Mesa produces. Signal
> >>> +handlers are not composable, you can't have different handlers for GPU1
> >>> +and GPU2 from different vendors, and a third handler for mmapped regular
> >>> +files.  Threads cause additional pain with signal handling as well.
> >>> +
> >>> +Only after userspace has closed all relevant DRM device and dmabuf file
> >>> +descriptors and removed all mmaps, the DRM driver can tear down its
> >>> +instance for the device that no longer exists. If the same physical
> >>> +device somehow comes back in the mean time, it shall be a new DRM
> >>> +device.
> >>> +
> >>>    .. _drm_driver_ioctl:
> >>>
> >>>    IOCTL Support on Device Nodes



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Andrey Grodzovsky]

On 5/27/20 10:39 AM, Daniel Vetter wrote:
> On Wed, May 27, 2020 at 3:51 PM Andrey Grodzovsky
> <Andrey.Grodzovsky@amd.com> wrote:
>>
>> On 5/27/20 2:44 AM, Pekka Paalanen wrote:
>>> On Tue, 26 May 2020 10:30:20 -0400
>>> Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
>>>
>>>> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
>>>>> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>>>
>>>>> Set up the expectations on how hot-unplugging a DRM device should look like to
>>>>> userspace.
>>>>>
>>>>> Written by Daniel Vetter's request and largely based on his comments in IRC and
>>>>> from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7C3c671803b2ba41b2ceac08d8024bcc9a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637261871869742519&amp;sdata=ZnhylRubOM0%2BjoreSSYMqVDzZuUdybEsoyBVcTKgxWE%3D&amp;reserved=0 .
>>>>>
>>>>> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>>> Cc: Daniel Vetter <daniel@ffwll.ch>
>>>>> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>> Cc: Sean Paul <sean@poorly.run>
>>>>>
>>>>> ---
>>>>>
>>>>> Disclaimer: I am a userspace developer writing for other userspace developers.
>>>>> I took some liberties in defining what should happen without knowing what is
>>>>> actually possible or what existing drivers already implement.
>>>>> ---
>>>>>     Documentation/gpu/drm-uapi.rst | 75 ++++++++++++++++++++++++++++++++++
>>>>>     1 file changed, 75 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
>>>>> index 56fec6ed1ad8..80db4abd2cbd 100644
>>>>> --- a/Documentation/gpu/drm-uapi.rst
>>>>> +++ b/Documentation/gpu/drm-uapi.rst
>>>>> @@ -1,3 +1,5 @@
>>>>> +.. Copyright 2020 DisplayLink (UK) Ltd.
>>>>> +
>>>>>     ===================
>>>>>     Userland interfaces
>>>>>     ===================
>>>>> @@ -162,6 +164,79 @@ other hand, a driver requires shared state between clients which is
>>>>>     visible to user-space and accessible beyond open-file boundaries, they
>>>>>     cannot support render nodes.
>>>>>
>>>>> +Device Hot-Unplug
>>>>> +=================
>>>>> +
>>>>> +.. note::
>>>>> +   The following is the plan. Implementation is not there yet
>>>>> +   (2020 May 13).
>>>>> +
>>>>> +Graphics devices (display and/or render) may be connected via USB (e.g.
>>>>> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
>>>>> +user is able to hot-unplug this kind of devices while they are being
>>>>> +used, and expects that the very least the machine does not crash. Any
>>>>> +damage from hot-unplugging a DRM device needs to be limited as much as
>>>>> +possible and userspace must be given the chance to handle it if it wants
>>>>> +to. Ideally, unplugging a DRM device still lets a desktop to continue
>>>>> +running, but that is going to need explicit support throughout the whole
>>>>> +graphics stack: from kernel and userspace drivers, through display
>>>>> +servers, via window system protocols, and in applications and libraries.
>>>>> +
>>>>> +Other scenarios that should lead to the same are: unrecoverable GPU
>>>>> +crash, PCI device disappearing off the bus, or forced unbind of a driver
>>>>> +from the physical device.
>>>>> +
>>>>> +In other words, from userspace perspective everything needs to keep on
>>>>> +working more or less, until userspace stops using the disappeared DRM
>>>>> +device and closes it completely. Userspace will learn of the device
>>>>> +disappearance from the device removed uevent or in some cases specific
>>>>> +ioctls returning EIO.
>>>>> +
>>>>> +This goal raises at least the following requirements for the kernel and
>>>>> +drivers:
>>>>> +
>>>>> +- The kernel must not hang, crash or oops, no matter what userspace was
>>>>> +  in the middle of doing when the device disappeared.
>>>>> +
>>>>> +- All GPU jobs that can no longer run must have their fences
>>>>> +  force-signalled to avoid inflicting hangs to userspace.
>>>>> +
>>>>> +- KMS connectors must change their status to disconnected.
>>>>> +
>>>>> +- Legacy modesets and pageflips fake success.
>>>>> +
>>>>> +- Atomic commits, both real and TEST_ONLY, fake success.
>>>>> +
>>>>> +- Pending non-blocking KMS operations deliver the DRM events userspace
>>>>> +  is expecting.
>>>>> +
>>>>> +- If underlying memory disappears, the mmaps are replaced with harmless
>>>>> +  zero pages where access does not raise SIGBUS. Reads return zeros,
>>>>> +  writes are ignored.
>>>> Regarding this paragraph - what about exiting mappings ? In the first
>>>> patchset we would actively invalidate all the existing CPU mappings to
>>>> device memory and i think we still should do it otherwise we will see
>>>> random crashes in applications as was before. I guess it's because TLBs
>>>> and page tables are not updated to reflect the fact the device is gone.
>>> Hi,
>>>
>>> I was talking about existing mappings. What I forgot to specify is how
>>> new mmap() calls after the device disappearance should work (the end
>>> result should be the same still, not failure).
>>>
>>> I'll clarify this in the next revision.
>>>
>>>
>>> Thanks,
>>> pq
>>
>> I see, that ok.
>>
>> Next related question is more for Daniel/Christian - about the
>> implementation of this paragraph, I was thinking about something like
>> checking for device disconnect in ttm_bo_vm_fault_reserved and if so
>> remap the entire VA range for the VMA where the fault address belongs to
>> the global zero page (i.e. (remap_pfn_range(vma, vma->vm_start,
>> page_to_pfn(ZERO_PAGE(vma->vm_start), vma->vm_end - vma->vm_start,
>> vma->vm_page_prot)). Question is, when the doc says 'writes are ignored'
>> does it mean i should use copy on write for the vma->vm_page_prot and if
>> so how i actually do it as i was not able to find what flags to set into
>> vm_page_prot to force copy on write behavior.
> Already discussed this with Pekka on irc, I think simply a private
> page (per gpu ctx to avoid leaks) is good enough. Otherwise we need to
> catch write faults and throw the writes away, and that's a) a bit
> tricky to implement and b) slow, which we kinda don't want to. If the
> desktop is stuck for a few seconds because we're trapping every write
> of a 4k buffer that's getting uploaded, the user is going to have a
> bad time :-/
> -Daniel


So like allocating a page per process context in the driver (struct 
amdgpu_ctx in amdgpu) and mapping this page into the faulting VMAs  for 
when device is disconnected ? I am still not clear how i make the 
mapping ignore writes without catching write faults and ignoring them. I 
cannot just make it read only obviously and i can't make it writable as 
then reading back will start returning non 0's. My question is what set 
of flags in vm_area_struct.vm_flags can (if at all) give me 'ignore 
writes' behavior for the mapping of that page.

Andrey


>
>> Andrey
>>
>>
>>
>>
>>>
>>>>> +
>>>>> +- dmabuf which point to memory that has disappeared are rewritten to
>>>>> +  point to harmless zero pages, similar to mmaps. Imports still succeed
>>>>> +  both ways: an existing device importing a dmabuf pointing to
>>>>> +  disappeared memory, and a disappeared device importing any dmabuf.
>>>>> +
>>>>> +- Render ioctls return EIO which is then handled in userspace drivers,
>>>>> +  e.g. Mesa, to have the device disappearance handled in the way
>>>>> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
>>>>> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
>>>>> +
>>>>> +Raising SIGBUS is not an option, because userspace cannot realistically
>>>>> +handle it.  Signal handlers are global, which makes them extremely
>>>>> +difficult to use correctly from libraries like Mesa produces. Signal
>>>>> +handlers are not composable, you can't have different handlers for GPU1
>>>>> +and GPU2 from different vendors, and a third handler for mmapped regular
>>>>> +files.  Threads cause additional pain with signal handling as well.
>>>>> +
>>>>> +Only after userspace has closed all relevant DRM device and dmabuf file
>>>>> +descriptors and removed all mmaps, the DRM driver can tear down its
>>>>> +instance for the device that no longer exists. If the same physical
>>>>> +device somehow comes back in the mean time, it shall be a new DRM
>>>>> +device.
>>>>> +
>>>>>     .. _drm_driver_ioctl:
>>>>>
>>>>>     IOCTL Support on Device Nodes
>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Christian König]

Am 27.05.20 um 17:23 schrieb Andrey Grodzovsky:
>
> On 5/27/20 10:39 AM, Daniel Vetter wrote:
>> On Wed, May 27, 2020 at 3:51 PM Andrey Grodzovsky
>> <Andrey.Grodzovsky@amd.com> wrote:
>>>
>>> On 5/27/20 2:44 AM, Pekka Paalanen wrote:
>>>> On Tue, 26 May 2020 10:30:20 -0400
>>>> Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
>>>>
>>>>> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
>>>>>> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>>>>
>>>>>> Set up the expectations on how hot-unplugging a DRM device should 
>>>>>> look like to
>>>>>> userspace.
>>>>>>
>>>>>> Written by Daniel Vetter's request and largely based on his 
>>>>>> comments in IRC and
>>>>>> from 
>>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7C3c671803b2ba41b2ceac08d8024bcc9a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637261871869742519&amp;sdata=ZnhylRubOM0%2BjoreSSYMqVDzZuUdybEsoyBVcTKgxWE%3D&amp;reserved=0 
>>>>>> .
>>>>>>
>>>>>> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>>>> Cc: Daniel Vetter <daniel@ffwll.ch>
>>>>>> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>>> Cc: Sean Paul <sean@poorly.run>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> Disclaimer: I am a userspace developer writing for other 
>>>>>> userspace developers.
>>>>>> I took some liberties in defining what should happen without 
>>>>>> knowing what is
>>>>>> actually possible or what existing drivers already implement.
>>>>>> ---
>>>>>>     Documentation/gpu/drm-uapi.rst | 75 
>>>>>> ++++++++++++++++++++++++++++++++++
>>>>>>     1 file changed, 75 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/gpu/drm-uapi.rst 
>>>>>> b/Documentation/gpu/drm-uapi.rst
>>>>>> index 56fec6ed1ad8..80db4abd2cbd 100644
>>>>>> --- a/Documentation/gpu/drm-uapi.rst
>>>>>> +++ b/Documentation/gpu/drm-uapi.rst
>>>>>> @@ -1,3 +1,5 @@
>>>>>> +.. Copyright 2020 DisplayLink (UK) Ltd.
>>>>>> +
>>>>>>     ===================
>>>>>>     Userland interfaces
>>>>>>     ===================
>>>>>> @@ -162,6 +164,79 @@ other hand, a driver requires shared state 
>>>>>> between clients which is
>>>>>>     visible to user-space and accessible beyond open-file 
>>>>>> boundaries, they
>>>>>>     cannot support render nodes.
>>>>>>
>>>>>> +Device Hot-Unplug
>>>>>> +=================
>>>>>> +
>>>>>> +.. note::
>>>>>> +   The following is the plan. Implementation is not there yet
>>>>>> +   (2020 May 13).
>>>>>> +
>>>>>> +Graphics devices (display and/or render) may be connected via 
>>>>>> USB (e.g.
>>>>>> +display adapters or docking stations) or Thunderbolt (e.g. 
>>>>>> eGPU). An end
>>>>>> +user is able to hot-unplug this kind of devices while they are 
>>>>>> being
>>>>>> +used, and expects that the very least the machine does not 
>>>>>> crash. Any
>>>>>> +damage from hot-unplugging a DRM device needs to be limited as 
>>>>>> much as
>>>>>> +possible and userspace must be given the chance to handle it if 
>>>>>> it wants
>>>>>> +to. Ideally, unplugging a DRM device still lets a desktop to 
>>>>>> continue
>>>>>> +running, but that is going to need explicit support throughout 
>>>>>> the whole
>>>>>> +graphics stack: from kernel and userspace drivers, through display
>>>>>> +servers, via window system protocols, and in applications and 
>>>>>> libraries.
>>>>>> +
>>>>>> +Other scenarios that should lead to the same are: unrecoverable GPU
>>>>>> +crash, PCI device disappearing off the bus, or forced unbind of 
>>>>>> a driver
>>>>>> +from the physical device.
>>>>>> +
>>>>>> +In other words, from userspace perspective everything needs to 
>>>>>> keep on
>>>>>> +working more or less, until userspace stops using the 
>>>>>> disappeared DRM
>>>>>> +device and closes it completely. Userspace will learn of the device
>>>>>> +disappearance from the device removed uevent or in some cases 
>>>>>> specific
>>>>>> +ioctls returning EIO.
>>>>>> +
>>>>>> +This goal raises at least the following requirements for the 
>>>>>> kernel and
>>>>>> +drivers:
>>>>>> +
>>>>>> +- The kernel must not hang, crash or oops, no matter what 
>>>>>> userspace was
>>>>>> +  in the middle of doing when the device disappeared.
>>>>>> +
>>>>>> +- All GPU jobs that can no longer run must have their fences
>>>>>> +  force-signalled to avoid inflicting hangs to userspace.
>>>>>> +
>>>>>> +- KMS connectors must change their status to disconnected.
>>>>>> +
>>>>>> +- Legacy modesets and pageflips fake success.
>>>>>> +
>>>>>> +- Atomic commits, both real and TEST_ONLY, fake success.
>>>>>> +
>>>>>> +- Pending non-blocking KMS operations deliver the DRM events 
>>>>>> userspace
>>>>>> +  is expecting.
>>>>>> +
>>>>>> +- If underlying memory disappears, the mmaps are replaced with 
>>>>>> harmless
>>>>>> +  zero pages where access does not raise SIGBUS. Reads return 
>>>>>> zeros,
>>>>>> +  writes are ignored.
>>>>> Regarding this paragraph - what about exiting mappings ? In the first
>>>>> patchset we would actively invalidate all the existing CPU 
>>>>> mappings to
>>>>> device memory and i think we still should do it otherwise we will see
>>>>> random crashes in applications as was before. I guess it's because 
>>>>> TLBs
>>>>> and page tables are not updated to reflect the fact the device is 
>>>>> gone.
>>>> Hi,
>>>>
>>>> I was talking about existing mappings. What I forgot to specify is how
>>>> new mmap() calls after the device disappearance should work (the end
>>>> result should be the same still, not failure).
>>>>
>>>> I'll clarify this in the next revision.
>>>>
>>>>
>>>> Thanks,
>>>> pq
>>>
>>> I see, that ok.
>>>
>>> Next related question is more for Daniel/Christian - about the
>>> implementation of this paragraph, I was thinking about something like
>>> checking for device disconnect in ttm_bo_vm_fault_reserved and if so
>>> remap the entire VA range for the VMA where the fault address 
>>> belongs to
>>> the global zero page (i.e. (remap_pfn_range(vma, vma->vm_start,
>>> page_to_pfn(ZERO_PAGE(vma->vm_start), vma->vm_end - vma->vm_start,
>>> vma->vm_page_prot)). Question is, when the doc says 'writes are 
>>> ignored'
>>> does it mean i should use copy on write for the vma->vm_page_prot 
>>> and if
>>> so how i actually do it as i was not able to find what flags to set 
>>> into
>>> vm_page_prot to force copy on write behavior.
>> Already discussed this with Pekka on irc, I think simply a private
>> page (per gpu ctx to avoid leaks) is good enough. Otherwise we need to
>> catch write faults and throw the writes away, and that's a) a bit
>> tricky to implement and b) slow, which we kinda don't want to. If the
>> desktop is stuck for a few seconds because we're trapping every write
>> of a 4k buffer that's getting uploaded, the user is going to have a
>> bad time :-/
>> -Daniel
>
>
> So like allocating a page per process context in the driver (struct 
> amdgpu_ctx in amdgpu) and mapping this page into the faulting VMAs  
> for when device is disconnected ? I am still not clear how i make the 
> mapping ignore writes without catching write faults and ignoring them. 
> I cannot just make it read only obviously and i can't make it writable 
> as then reading back will start returning non 0's. My question is what 
> set of flags in vm_area_struct.vm_flags can (if at all) give me 
> 'ignore writes' behavior for the mapping of that page.

I'm not aware of a possibility like that on x86 CPUs. As far as I know 
we only have something like an ignore write functionality on our GPUs 
for PRTs.

Could we use an address which points to a non allocated MMIO space or 
something like this? We would might get 0xffffffff on reads instead of 
0x0, but writes would be certainly ignored.

Christian.

>
> Andrey
>
>
>>
>>> Andrey
>>>
>>>
>>>
>>>
>>>>
>>>>>> +
>>>>>> +- dmabuf which point to memory that has disappeared are 
>>>>>> rewritten to
>>>>>> +  point to harmless zero pages, similar to mmaps. Imports still 
>>>>>> succeed
>>>>>> +  both ways: an existing device importing a dmabuf pointing to
>>>>>> +  disappeared memory, and a disappeared device importing any 
>>>>>> dmabuf.
>>>>>> +
>>>>>> +- Render ioctls return EIO which is then handled in userspace 
>>>>>> drivers,
>>>>>> +  e.g. Mesa, to have the device disappearance handled in the way
>>>>>> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
>>>>>> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
>>>>>> +
>>>>>> +Raising SIGBUS is not an option, because userspace cannot 
>>>>>> realistically
>>>>>> +handle it.  Signal handlers are global, which makes them extremely
>>>>>> +difficult to use correctly from libraries like Mesa produces. 
>>>>>> Signal
>>>>>> +handlers are not composable, you can't have different handlers 
>>>>>> for GPU1
>>>>>> +and GPU2 from different vendors, and a third handler for mmapped 
>>>>>> regular
>>>>>> +files.  Threads cause additional pain with signal handling as well.
>>>>>> +
>>>>>> +Only after userspace has closed all relevant DRM device and 
>>>>>> dmabuf file
>>>>>> +descriptors and removed all mmaps, the DRM driver can tear down its
>>>>>> +instance for the device that no longer exists. If the same physical
>>>>>> +device somehow comes back in the mean time, it shall be a new DRM
>>>>>> +device.
>>>>>> +
>>>>>>     .. _drm_driver_ioctl:
>>>>>>
>>>>>>     IOCTL Support on Device Nodes
>>
>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Wed, May 27, 2020 at 9:44 PM Christian König
<christian.koenig@amd.com> wrote:
>
> Am 27.05.20 um 17:23 schrieb Andrey Grodzovsky:
> >
> > On 5/27/20 10:39 AM, Daniel Vetter wrote:
> >> On Wed, May 27, 2020 at 3:51 PM Andrey Grodzovsky
> >> <Andrey.Grodzovsky@amd.com> wrote:
> >>>
> >>> On 5/27/20 2:44 AM, Pekka Paalanen wrote:
> >>>> On Tue, 26 May 2020 10:30:20 -0400
> >>>> Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
> >>>>
> >>>>> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
> >>>>>> From: Pekka Paalanen <pekka.paalanen@collabora.com>
> >>>>>>
> >>>>>> Set up the expectations on how hot-unplugging a DRM device should
> >>>>>> look like to
> >>>>>> userspace.
> >>>>>>
> >>>>>> Written by Daniel Vetter's request and largely based on his
> >>>>>> comments in IRC and
> >>>>>> from
> >>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7C3c671803b2ba41b2ceac08d8024bcc9a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637261871869742519&amp;sdata=ZnhylRubOM0%2BjoreSSYMqVDzZuUdybEsoyBVcTKgxWE%3D&amp;reserved=0
> >>>>>> .
> >>>>>>
> >>>>>> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> >>>>>> Cc: Daniel Vetter <daniel@ffwll.ch>
> >>>>>> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> >>>>>> Cc: Dave Airlie <airlied@redhat.com>
> >>>>>> Cc: Sean Paul <sean@poorly.run>
> >>>>>>
> >>>>>> ---
> >>>>>>
> >>>>>> Disclaimer: I am a userspace developer writing for other
> >>>>>> userspace developers.
> >>>>>> I took some liberties in defining what should happen without
> >>>>>> knowing what is
> >>>>>> actually possible or what existing drivers already implement.
> >>>>>> ---
> >>>>>>     Documentation/gpu/drm-uapi.rst | 75
> >>>>>> ++++++++++++++++++++++++++++++++++
> >>>>>>     1 file changed, 75 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/gpu/drm-uapi.rst
> >>>>>> b/Documentation/gpu/drm-uapi.rst
> >>>>>> index 56fec6ed1ad8..80db4abd2cbd 100644
> >>>>>> --- a/Documentation/gpu/drm-uapi.rst
> >>>>>> +++ b/Documentation/gpu/drm-uapi.rst
> >>>>>> @@ -1,3 +1,5 @@
> >>>>>> +.. Copyright 2020 DisplayLink (UK) Ltd.
> >>>>>> +
> >>>>>>     ===================
> >>>>>>     Userland interfaces
> >>>>>>     ===================
> >>>>>> @@ -162,6 +164,79 @@ other hand, a driver requires shared state
> >>>>>> between clients which is
> >>>>>>     visible to user-space and accessible beyond open-file
> >>>>>> boundaries, they
> >>>>>>     cannot support render nodes.
> >>>>>>
> >>>>>> +Device Hot-Unplug
> >>>>>> +=================
> >>>>>> +
> >>>>>> +.. note::
> >>>>>> +   The following is the plan. Implementation is not there yet
> >>>>>> +   (2020 May 13).
> >>>>>> +
> >>>>>> +Graphics devices (display and/or render) may be connected via
> >>>>>> USB (e.g.
> >>>>>> +display adapters or docking stations) or Thunderbolt (e.g.
> >>>>>> eGPU). An end
> >>>>>> +user is able to hot-unplug this kind of devices while they are
> >>>>>> being
> >>>>>> +used, and expects that the very least the machine does not
> >>>>>> crash. Any
> >>>>>> +damage from hot-unplugging a DRM device needs to be limited as
> >>>>>> much as
> >>>>>> +possible and userspace must be given the chance to handle it if
> >>>>>> it wants
> >>>>>> +to. Ideally, unplugging a DRM device still lets a desktop to
> >>>>>> continue
> >>>>>> +running, but that is going to need explicit support throughout
> >>>>>> the whole
> >>>>>> +graphics stack: from kernel and userspace drivers, through display
> >>>>>> +servers, via window system protocols, and in applications and
> >>>>>> libraries.
> >>>>>> +
> >>>>>> +Other scenarios that should lead to the same are: unrecoverable GPU
> >>>>>> +crash, PCI device disappearing off the bus, or forced unbind of
> >>>>>> a driver
> >>>>>> +from the physical device.
> >>>>>> +
> >>>>>> +In other words, from userspace perspective everything needs to
> >>>>>> keep on
> >>>>>> +working more or less, until userspace stops using the
> >>>>>> disappeared DRM
> >>>>>> +device and closes it completely. Userspace will learn of the device
> >>>>>> +disappearance from the device removed uevent or in some cases
> >>>>>> specific
> >>>>>> +ioctls returning EIO.
> >>>>>> +
> >>>>>> +This goal raises at least the following requirements for the
> >>>>>> kernel and
> >>>>>> +drivers:
> >>>>>> +
> >>>>>> +- The kernel must not hang, crash or oops, no matter what
> >>>>>> userspace was
> >>>>>> +  in the middle of doing when the device disappeared.
> >>>>>> +
> >>>>>> +- All GPU jobs that can no longer run must have their fences
> >>>>>> +  force-signalled to avoid inflicting hangs to userspace.
> >>>>>> +
> >>>>>> +- KMS connectors must change their status to disconnected.
> >>>>>> +
> >>>>>> +- Legacy modesets and pageflips fake success.
> >>>>>> +
> >>>>>> +- Atomic commits, both real and TEST_ONLY, fake success.
> >>>>>> +
> >>>>>> +- Pending non-blocking KMS operations deliver the DRM events
> >>>>>> userspace
> >>>>>> +  is expecting.
> >>>>>> +
> >>>>>> +- If underlying memory disappears, the mmaps are replaced with
> >>>>>> harmless
> >>>>>> +  zero pages where access does not raise SIGBUS. Reads return
> >>>>>> zeros,
> >>>>>> +  writes are ignored.
> >>>>> Regarding this paragraph - what about exiting mappings ? In the first
> >>>>> patchset we would actively invalidate all the existing CPU
> >>>>> mappings to
> >>>>> device memory and i think we still should do it otherwise we will see
> >>>>> random crashes in applications as was before. I guess it's because
> >>>>> TLBs
> >>>>> and page tables are not updated to reflect the fact the device is
> >>>>> gone.
> >>>> Hi,
> >>>>
> >>>> I was talking about existing mappings. What I forgot to specify is how
> >>>> new mmap() calls after the device disappearance should work (the end
> >>>> result should be the same still, not failure).
> >>>>
> >>>> I'll clarify this in the next revision.
> >>>>
> >>>>
> >>>> Thanks,
> >>>> pq
> >>>
> >>> I see, that ok.
> >>>
> >>> Next related question is more for Daniel/Christian - about the
> >>> implementation of this paragraph, I was thinking about something like
> >>> checking for device disconnect in ttm_bo_vm_fault_reserved and if so
> >>> remap the entire VA range for the VMA where the fault address
> >>> belongs to
> >>> the global zero page (i.e. (remap_pfn_range(vma, vma->vm_start,
> >>> page_to_pfn(ZERO_PAGE(vma->vm_start), vma->vm_end - vma->vm_start,
> >>> vma->vm_page_prot)). Question is, when the doc says 'writes are
> >>> ignored'
> >>> does it mean i should use copy on write for the vma->vm_page_prot
> >>> and if
> >>> so how i actually do it as i was not able to find what flags to set
> >>> into
> >>> vm_page_prot to force copy on write behavior.
> >> Already discussed this with Pekka on irc, I think simply a private
> >> page (per gpu ctx to avoid leaks) is good enough. Otherwise we need to
> >> catch write faults and throw the writes away, and that's a) a bit
> >> tricky to implement and b) slow, which we kinda don't want to. If the
> >> desktop is stuck for a few seconds because we're trapping every write
> >> of a 4k buffer that's getting uploaded, the user is going to have a
> >> bad time :-/
> >> -Daniel
> >
> >
> > So like allocating a page per process context in the driver (struct
> > amdgpu_ctx in amdgpu) and mapping this page into the faulting VMAs
> > for when device is disconnected ? I am still not clear how i make the
> > mapping ignore writes without catching write faults and ignoring them.
> > I cannot just make it read only obviously and i can't make it writable
> > as then reading back will start returning non 0's. My question is what
> > set of flags in vm_area_struct.vm_flags can (if at all) give me
> > 'ignore writes' behavior for the mapping of that page.
>
> I'm not aware of a possibility like that on x86 CPUs. As far as I know
> we only have something like an ignore write functionality on our GPUs
> for PRTs.
>
> Could we use an address which points to a non allocated MMIO space or
> something like this? We would might get 0xffffffff on reads instead of
> 0x0, but writes would be certainly ignored.

I think just a page with garbage in, garbage out semantics is going to
be ok. I think pretty much anything has a chance to upset userspace,
so whether it's 0 or all 1s or anything else doesn't really matter.

Only thing that does matter a bit is that we have a page per fd, so
that we don't accidentally leak something between processes where we
shouldn't. I think as long as we don't crash&burn in a SIGBUS it's
good enough.
-Daniel

>
> Christian.
>
> >
> > Andrey
> >
> >
> >>
> >>> Andrey
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>>>> +
> >>>>>> +- dmabuf which point to memory that has disappeared are
> >>>>>> rewritten to
> >>>>>> +  point to harmless zero pages, similar to mmaps. Imports still
> >>>>>> succeed
> >>>>>> +  both ways: an existing device importing a dmabuf pointing to
> >>>>>> +  disappeared memory, and a disappeared device importing any
> >>>>>> dmabuf.
> >>>>>> +
> >>>>>> +- Render ioctls return EIO which is then handled in userspace
> >>>>>> drivers,
> >>>>>> +  e.g. Mesa, to have the device disappearance handled in the way
> >>>>>> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
> >>>>>> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
> >>>>>> +
> >>>>>> +Raising SIGBUS is not an option, because userspace cannot
> >>>>>> realistically
> >>>>>> +handle it.  Signal handlers are global, which makes them extremely
> >>>>>> +difficult to use correctly from libraries like Mesa produces.
> >>>>>> Signal
> >>>>>> +handlers are not composable, you can't have different handlers
> >>>>>> for GPU1
> >>>>>> +and GPU2 from different vendors, and a third handler for mmapped
> >>>>>> regular
> >>>>>> +files.  Threads cause additional pain with signal handling as well.
> >>>>>> +
> >>>>>> +Only after userspace has closed all relevant DRM device and
> >>>>>> dmabuf file
> >>>>>> +descriptors and removed all mmaps, the DRM driver can tear down its
> >>>>>> +instance for the device that no longer exists. If the same physical
> >>>>>> +device somehow comes back in the mean time, it shall be a new DRM
> >>>>>> +device.
> >>>>>> +
> >>>>>>     .. _drm_driver_ioctl:
> >>>>>>
> >>>>>>     IOCTL Support on Device Nodes
> >>
> >>
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 5022 bytes --]

On Wed, 27 May 2020 22:25:00 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Wed, May 27, 2020 at 9:44 PM Christian König
> <christian.koenig@amd.com> wrote:
> >
> > Am 27.05.20 um 17:23 schrieb Andrey Grodzovsky:  
> > >
> > > On 5/27/20 10:39 AM, Daniel Vetter wrote:  
> > >> On Wed, May 27, 2020 at 3:51 PM Andrey Grodzovsky
> > >> <Andrey.Grodzovsky@amd.com> wrote:  
> > >>>
> > >>> On 5/27/20 2:44 AM, Pekka Paalanen wrote:  
> > >>>> On Tue, 26 May 2020 10:30:20 -0400
> > >>>> Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
> > >>>>  
> > >>>>> On 5/19/20 6:06 AM, Pekka Paalanen wrote:  
> > >>>>>> From: Pekka Paalanen <pekka.paalanen@collabora.com>
> > >>>>>>
> > >>>>>> Set up the expectations on how hot-unplugging a DRM device should
> > >>>>>> look like to
> > >>>>>> userspace.
> > >>>>>>
> > >>>>>> Written by Daniel Vetter's request and largely based on his
> > >>>>>> comments in IRC and
> > >>>>>> from
> > >>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7C3c671803b2ba41b2ceac08d8024bcc9a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637261871869742519&amp;sdata=ZnhylRubOM0%2BjoreSSYMqVDzZuUdybEsoyBVcTKgxWE%3D&amp;reserved=0
> > >>>>>> .
> > >>>>>>
> > >>>>>> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > >>>>>> Cc: Daniel Vetter <daniel@ffwll.ch>
> > >>>>>> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > >>>>>> Cc: Dave Airlie <airlied@redhat.com>
> > >>>>>> Cc: Sean Paul <sean@poorly.run>
> > >>>>>>
> > >>>>>> ---
> > >>>>>>
> > >>>>>> Disclaimer: I am a userspace developer writing for other
> > >>>>>> userspace developers.
> > >>>>>> I took some liberties in defining what should happen without
> > >>>>>> knowing what is
> > >>>>>> actually possible or what existing drivers already implement.
> > >>>>>> ---
> > >>>>>>     Documentation/gpu/drm-uapi.rst | 75
> > >>>>>> ++++++++++++++++++++++++++++++++++
> > >>>>>>     1 file changed, 75 insertions(+)

...

> > >>> Next related question is more for Daniel/Christian - about the
> > >>> implementation of this paragraph, I was thinking about something like
> > >>> checking for device disconnect in ttm_bo_vm_fault_reserved and if so
> > >>> remap the entire VA range for the VMA where the fault address
> > >>> belongs to
> > >>> the global zero page (i.e. (remap_pfn_range(vma, vma->vm_start,
> > >>> page_to_pfn(ZERO_PAGE(vma->vm_start), vma->vm_end - vma->vm_start,
> > >>> vma->vm_page_prot)). Question is, when the doc says 'writes are
> > >>> ignored'
> > >>> does it mean i should use copy on write for the vma->vm_page_prot
> > >>> and if
> > >>> so how i actually do it as i was not able to find what flags to set
> > >>> into
> > >>> vm_page_prot to force copy on write behavior.  
> > >> Already discussed this with Pekka on irc, I think simply a private
> > >> page (per gpu ctx to avoid leaks) is good enough. Otherwise we need to
> > >> catch write faults and throw the writes away, and that's a) a bit
> > >> tricky to implement and b) slow, which we kinda don't want to. If the
> > >> desktop is stuck for a few seconds because we're trapping every write
> > >> of a 4k buffer that's getting uploaded, the user is going to have a
> > >> bad time :-/
> > >> -Daniel  
> > >
> > >
> > > So like allocating a page per process context in the driver (struct
> > > amdgpu_ctx in amdgpu) and mapping this page into the faulting VMAs
> > > for when device is disconnected ? I am still not clear how i make the
> > > mapping ignore writes without catching write faults and ignoring them.
> > > I cannot just make it read only obviously and i can't make it writable
> > > as then reading back will start returning non 0's. My question is what
> > > set of flags in vm_area_struct.vm_flags can (if at all) give me
> > > 'ignore writes' behavior for the mapping of that page.  
> >
> > I'm not aware of a possibility like that on x86 CPUs. As far as I know
> > we only have something like an ignore write functionality on our GPUs
> > for PRTs.
> >
> > Could we use an address which points to a non allocated MMIO space or
> > something like this? We would might get 0xffffffff on reads instead of
> > 0x0, but writes would be certainly ignored.  
> 
> I think just a page with garbage in, garbage out semantics is going to
> be ok. I think pretty much anything has a chance to upset userspace,
> so whether it's 0 or all 1s or anything else doesn't really matter.
> 
> Only thing that does matter a bit is that we have a page per fd, so
> that we don't accidentally leak something between processes where we
> shouldn't. I think as long as we don't crash&burn in a SIGBUS it's
> good enough.

Hi,

the v2 I sent on Monday already changed the wording to have undefined
reads/writes instead of read zero / ignore write. v3 is coming.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 9423 bytes --]

On Mon, 25 May 2020 17:09:55 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Mon, May 25, 2020 at 05:55:19PM +0300, Pekka Paalanen wrote:
> > On Mon, 25 May 2020 16:28:04 +0200
> > Daniel Vetter <daniel@ffwll.ch> wrote:
> >   
> > > On Wed, May 20, 2020 at 10:50:41AM -0400, Andrey Grodzovsky wrote:  
> > > > 
> > > > On 5/20/20 8:46 AM, Daniel Vetter wrote:    
> > > > > On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote:    
> > > > > > On Tue, 19 May 2020 10:37:12 -0400
> > > > > > Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
> > > > > >     
> > > > > > > Thanks for the summary, does put things in order and makes it easier to
> > > > > > > comprehend all the TODOs, some questions bellow
> > > > > > > 
> > > > > > > On 5/19/20 6:06 AM, Pekka Paalanen wrote:    
> > > > > > > > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > > > > > > 
> > > > > > > > Set up the expectations on how hot-unplugging a DRM device should look like to
> > > > > > > > userspace.

...

> > > > So currently drm_ioctl will just check for drm_dev_is_unplugged and return
> > > > -ENODEV at the very beginning of the function (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_ioctl.c#L825)
> > > > meaning that currently we blanket failure any IOCTL in case the device is
> > > > unplagued (ignoring the race condition if the device unplugged after the
> > > > check). So do we want to remove this check and put it only for render ioctls
> > > > (which are those ? e.g. for amdgpu there is  AMDGPU_CS ioctl) but not for
> > > > mode setting/dma_buf_import/dma_buf_export ioctls ? What about other types
> > > > of ioctls which are non of the listed above ?    
> > > 
> > > Hm right, and this goes back all the way to first usb udl support:
> > > 
> > > commit 2c07a21d6fb0be47fda696a618b726ea258ed1dd
> > > Author: Dave Airlie <airlied@redhat.com>
> > > Date:   Mon Feb 20 14:18:07 2012 +0000
> > > 
> > >     drm: add core support for unplugging a device (v2)
> > > 
> > > So I guess we need to change the uapi docs to explain that. Not sure
> > > everyone can cope, but I guess they better do. Since the use-case back
> > > then was just udl, so simple legacy kms only, the damage was probably
> > > rather limited. I'm not sure we can get away with that now, where kms code
> > > has spread to funny places likey vulkan winsys code.
> > > 
> > > Or maybe we want a file priv flag you can set along the lines of "give me
> > > less shitty hotunplug semantics for ioctls". Or maybe we can just change
> > > the semantics, not crashing&burning shouldn't cause a regression :-)
> > > 
> > > For everything else (mmap, dma-buf fd, sync_file fd, syncobj fd) I think
> > > the discussion is still more or less accurate.
> > > 
> > > Pekka, any thoughts?  
> > 
> > Hi,
> > 
> > is ENODEV unique to this particular failure?  
> 
> Not really sure, we'd need to audit all of drm ...

$ git ngrep ENODEV -- drivers/gpu/drm | wc -l
762

Yeah, grep is not enough.

> > Returning errors instead of faking success was my first idea, but you
> > already convinced me that faking is at least as good if not better. :-)
> > 
> > So as long as the error code returned is unique to hot-unplug or other
> > "oops, the device is gone" conditions, I think I'm fine. Weston does
> > not handle ENODEV any way, it never did, and it certainly cannot be
> > called a kernel regression.
> > 
> > As a Weston developer, I don't mind adding checks for ENODEV. But if I
> > don't have to, even better. Weston is going to need more code to handle
> > DRM device unplug in any case.
> > 
> > Sorry, no preference from me. ;-)
> > 
> > I do agree that replacing ENODEV with fake success is hard to imagine
> > regressing anything. It's something you can do in the kernel at any
> > time easily, but going from fake success to error is going to be
> > painful. Maybe don't change things until there is a good reason to?
> > 
> > We need a kernel that doesn't crash before we can properly test what
> > would be best for userspace, fake or error.  
> 
> One upshot of faking stuff and only bailing in low-level hw code is that
> it makes validating the races when you hotunplug easier - if we remove the
> early bail-out check even an ioctl later on will look like it raced with
> the hotunplug path in the kernel. So better assurance that things won't
> blow up badly.
> 
> Otoh the early bail out in the top-level ioctl code increases the odds
> that you'll survive even on a driver that's totally buggy.
> 
> So yeah I guess maybe we should just document that currently you get an
> -ENODEV and maybe have the option mentioned that we might change this
> going forward. See also
> 
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
> 
> I think that needs an update, at least clarify that "not present" includes
> "no longer present".

So if dmabuf import related ioctl returns ENODEV, it means a Wayland
compositor should not punish the client for giving a bad buffer.

If a compositor uses EGL to import a dmabuf, then the EGL
implementation will be calling dmabuf import related ioctls, does it
not? But I'm fairly sure that EGL has no way to signal this particular
condition to the caller uniquely. That means that either a compositor
accepts buffers it never should have, or that it punishes clients for
the DRM device disappearing.

See the below quote for a reminder:

> > > > > > > > +- dmabuf which point to memory that has disappeared are rewritten to
> > > > > > > > +  point to harmless zero pages, similar to mmaps. Imports still succeed
> > > > > > > > +  both ways: an existing device importing a dmabuf pointing to
> > > > > > > > +  disappeared memory, and a disappeared device importing any dmabuf.    
> > > > > > > 
> > > > > > > Same as above, I would expect drmPrimeHandleToFD and drmPrimeFDToHandle
> > > > > > > to return -EIO in case device is detached    
> > > > > > I imagined a use case behind this: a Wayland compositor attempting to
> > > > > > import a client's dmabuf. The GPU the client was using is
> > > > > > hot-unplugged, meaning the dmabufs lose their storage. It is up to the
> > > > > > client to handle its rendering GPU disappearance on its own, but also
> > > > > > the compositor should not disconnect it because the GPU disappeared.
> > > > > > It's not the client's fault the GPU disappeared.
> > > > > > 
> > > > > > In Wayland, failure to use a wl_buffer is considered a protocol error,
> > > > > > and protocol errors are always fatal: the client is disconnected. The
> > > > > > rationale is that the compositor must always be able to present the
> > > > > > client buffer somehow. If the compositor cannot, then the client did
> > > > > > not obey the protocol.
> > > > > > 
> > > > > > The fallback presentation path in a compositor is usually importing the
> > > > > > dmabuf to EGL, to be sampled from OpenGL. Normally the protocol
> > > > > > guarantees that this works, so any failure to do so is a protocol
> > > > > > violation. But if the GPU used by the client suddenly disappears and
> > > > > > the imports start to fail, that is interpreted as a protocol violation
> > > > > > unless the compositor can see why the import failed. Since the import
> > > > > > is done via EGL, getting the right error code plumbed through from
> > > > > > libdrm functions to the EGL caller would be a hassle. I don't see any
> > > > > > error code in EGL_EXT_image_dma_buf_import reserved for "the dmabuf
> > > > > > storage was hot-unplugged", and I doubt there is anything exclusively
> > > > > > for only that in the EGL base spec either.
> > > > > > 
> > > > > > The cost of lying that the import worked is that the compositor will
> > > > > > paint black or transparent where the window was supposed to be. It's a
> > > > > > graphical glitch that is contrary to the Wayland design principles, but
> > > > > > in this case a glitch is unavoidable: even if the compositor knew this
> > > > > > buffer is now bad, what would it paint instead? It has nothing else to
> > > > > > paint from. I'm assuming the compositor is using a different GPU than
> > > > > > what disappeared.
> > > > > > 
> > > > > > Ideally, the client will eventually react to losing the GPU and either
> > > > > > crash, quit, or switch its rendering to something that works which
> > > > > > simply gives the compositor a new, working buffer without losing any
> > > > > > window state in the process. If we risk the compositor disconnecting
> > > > > > the client, then the client might not recover even if it wanted to.

This goes for both ways: importing a good dmabuf to a bad device, and a
bad dmabuf to a good device. In neither case there should be a risk of
erroneously disconnecting the Wayland client.

Hmm. Maybe Wayland compositors should ignore all EGL import failures
that happen after the wl_buffer has been created (which implies that
the dmabuf has been validated to work initially). When import fails at
a later time, the compositor should just paint some error pattern
instead of the window. That would let the kernel keep on returning
errors.

Yeah, ok. I'll keep the ENODEV there in my next version. Let's see how
that looks then.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Thu, May 28, 2020 at 03:27:57PM +0300, Pekka Paalanen wrote:
> On Mon, 25 May 2020 17:09:55 +0200
> Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > On Mon, May 25, 2020 at 05:55:19PM +0300, Pekka Paalanen wrote:
> > > On Mon, 25 May 2020 16:28:04 +0200
> > > Daniel Vetter <daniel@ffwll.ch> wrote:
> > >   
> > > > On Wed, May 20, 2020 at 10:50:41AM -0400, Andrey Grodzovsky wrote:  
> > > > > 
> > > > > On 5/20/20 8:46 AM, Daniel Vetter wrote:    
> > > > > > On Wed, May 20, 2020 at 02:19:08PM +0300, Pekka Paalanen wrote:    
> > > > > > > On Tue, 19 May 2020 10:37:12 -0400
> > > > > > > Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
> > > > > > >     
> > > > > > > > Thanks for the summary, does put things in order and makes it easier to
> > > > > > > > comprehend all the TODOs, some questions bellow
> > > > > > > > 
> > > > > > > > On 5/19/20 6:06 AM, Pekka Paalanen wrote:    
> > > > > > > > > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> > > > > > > > > 
> > > > > > > > > Set up the expectations on how hot-unplugging a DRM device should look like to
> > > > > > > > > userspace.
> 
> ...
> 
> > > > > So currently drm_ioctl will just check for drm_dev_is_unplugged and return
> > > > > -ENODEV at the very beginning of the function (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_ioctl.c#L825)
> > > > > meaning that currently we blanket failure any IOCTL in case the device is
> > > > > unplagued (ignoring the race condition if the device unplugged after the
> > > > > check). So do we want to remove this check and put it only for render ioctls
> > > > > (which are those ? e.g. for amdgpu there is  AMDGPU_CS ioctl) but not for
> > > > > mode setting/dma_buf_import/dma_buf_export ioctls ? What about other types
> > > > > of ioctls which are non of the listed above ?    
> > > > 
> > > > Hm right, and this goes back all the way to first usb udl support:
> > > > 
> > > > commit 2c07a21d6fb0be47fda696a618b726ea258ed1dd
> > > > Author: Dave Airlie <airlied@redhat.com>
> > > > Date:   Mon Feb 20 14:18:07 2012 +0000
> > > > 
> > > >     drm: add core support for unplugging a device (v2)
> > > > 
> > > > So I guess we need to change the uapi docs to explain that. Not sure
> > > > everyone can cope, but I guess they better do. Since the use-case back
> > > > then was just udl, so simple legacy kms only, the damage was probably
> > > > rather limited. I'm not sure we can get away with that now, where kms code
> > > > has spread to funny places likey vulkan winsys code.
> > > > 
> > > > Or maybe we want a file priv flag you can set along the lines of "give me
> > > > less shitty hotunplug semantics for ioctls". Or maybe we can just change
> > > > the semantics, not crashing&burning shouldn't cause a regression :-)
> > > > 
> > > > For everything else (mmap, dma-buf fd, sync_file fd, syncobj fd) I think
> > > > the discussion is still more or less accurate.
> > > > 
> > > > Pekka, any thoughts?  
> > > 
> > > Hi,
> > > 
> > > is ENODEV unique to this particular failure?  
> > 
> > Not really sure, we'd need to audit all of drm ...
> 
> $ git ngrep ENODEV -- drivers/gpu/drm | wc -l
> 762
> 
> Yeah, grep is not enough.
> 
> > > Returning errors instead of faking success was my first idea, but you
> > > already convinced me that faking is at least as good if not better. :-)
> > > 
> > > So as long as the error code returned is unique to hot-unplug or other
> > > "oops, the device is gone" conditions, I think I'm fine. Weston does
> > > not handle ENODEV any way, it never did, and it certainly cannot be
> > > called a kernel regression.
> > > 
> > > As a Weston developer, I don't mind adding checks for ENODEV. But if I
> > > don't have to, even better. Weston is going to need more code to handle
> > > DRM device unplug in any case.
> > > 
> > > Sorry, no preference from me. ;-)
> > > 
> > > I do agree that replacing ENODEV with fake success is hard to imagine
> > > regressing anything. It's something you can do in the kernel at any
> > > time easily, but going from fake success to error is going to be
> > > painful. Maybe don't change things until there is a good reason to?
> > > 
> > > We need a kernel that doesn't crash before we can properly test what
> > > would be best for userspace, fake or error.  
> > 
> > One upshot of faking stuff and only bailing in low-level hw code is that
> > it makes validating the races when you hotunplug easier - if we remove the
> > early bail-out check even an ioctl later on will look like it raced with
> > the hotunplug path in the kernel. So better assurance that things won't
> > blow up badly.
> > 
> > Otoh the early bail out in the top-level ioctl code increases the odds
> > that you'll survive even on a driver that's totally buggy.
> > 
> > So yeah I guess maybe we should just document that currently you get an
> > -ENODEV and maybe have the option mentioned that we might change this
> > going forward. See also
> > 
> > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
> > 
> > I think that needs an update, at least clarify that "not present" includes
> > "no longer present".
> 
> So if dmabuf import related ioctl returns ENODEV, it means a Wayland
> compositor should not punish the client for giving a bad buffer.

Atm this is only for the drm fd. I think right now dma-buf keep "working",
where "working" = "probably results in some oopses". So maybe for dma-buf
we need to put down the rule that they're not allowed to go boom, and then
figure out how to do that, see below.

> If a compositor uses EGL to import a dmabuf, then the EGL
> implementation will be calling dmabuf import related ioctls, does it
> not? But I'm fairly sure that EGL has no way to signal this particular
> condition to the caller uniquely. That means that either a compositor
> accepts buffers it never should have, or that it punishes clients for
> the DRM device disappearing.
> 
> See the below quote for a reminder:
> 
> > > > > > > > > +- dmabuf which point to memory that has disappeared are rewritten to
> > > > > > > > > +  point to harmless zero pages, similar to mmaps. Imports still succeed
> > > > > > > > > +  both ways: an existing device importing a dmabuf pointing to
> > > > > > > > > +  disappeared memory, and a disappeared device importing any dmabuf.    
> > > > > > > > 
> > > > > > > > Same as above, I would expect drmPrimeHandleToFD and drmPrimeFDToHandle
> > > > > > > > to return -EIO in case device is detached    
> > > > > > > I imagined a use case behind this: a Wayland compositor attempting to
> > > > > > > import a client's dmabuf. The GPU the client was using is
> > > > > > > hot-unplugged, meaning the dmabufs lose their storage. It is up to the
> > > > > > > client to handle its rendering GPU disappearance on its own, but also
> > > > > > > the compositor should not disconnect it because the GPU disappeared.
> > > > > > > It's not the client's fault the GPU disappeared.
> > > > > > > 
> > > > > > > In Wayland, failure to use a wl_buffer is considered a protocol error,
> > > > > > > and protocol errors are always fatal: the client is disconnected. The
> > > > > > > rationale is that the compositor must always be able to present the
> > > > > > > client buffer somehow. If the compositor cannot, then the client did
> > > > > > > not obey the protocol.
> > > > > > > 
> > > > > > > The fallback presentation path in a compositor is usually importing the
> > > > > > > dmabuf to EGL, to be sampled from OpenGL. Normally the protocol
> > > > > > > guarantees that this works, so any failure to do so is a protocol
> > > > > > > violation. But if the GPU used by the client suddenly disappears and
> > > > > > > the imports start to fail, that is interpreted as a protocol violation
> > > > > > > unless the compositor can see why the import failed. Since the import
> > > > > > > is done via EGL, getting the right error code plumbed through from
> > > > > > > libdrm functions to the EGL caller would be a hassle. I don't see any
> > > > > > > error code in EGL_EXT_image_dma_buf_import reserved for "the dmabuf
> > > > > > > storage was hot-unplugged", and I doubt there is anything exclusively
> > > > > > > for only that in the EGL base spec either.
> > > > > > > 
> > > > > > > The cost of lying that the import worked is that the compositor will
> > > > > > > paint black or transparent where the window was supposed to be. It's a
> > > > > > > graphical glitch that is contrary to the Wayland design principles, but
> > > > > > > in this case a glitch is unavoidable: even if the compositor knew this
> > > > > > > buffer is now bad, what would it paint instead? It has nothing else to
> > > > > > > paint from. I'm assuming the compositor is using a different GPU than
> > > > > > > what disappeared.
> > > > > > > 
> > > > > > > Ideally, the client will eventually react to losing the GPU and either
> > > > > > > crash, quit, or switch its rendering to something that works which
> > > > > > > simply gives the compositor a new, working buffer without losing any
> > > > > > > window state in the process. If we risk the compositor disconnecting
> > > > > > > the client, then the client might not recover even if it wanted to.
> 
> This goes for both ways: importing a good dmabuf to a bad device, and a
> bad dmabuf to a good device. In neither case there should be a risk of
> erroneously disconnecting the Wayland client.
> 
> Hmm. Maybe Wayland compositors should ignore all EGL import failures
> that happen after the wl_buffer has been created (which implies that
> the dmabuf has been validated to work initially). When import fails at
> a later time, the compositor should just paint some error pattern
> instead of the window. That would let the kernel keep on returning
> errors.
> 
> Yeah, ok. I'll keep the ENODEV there in my next version. Let's see how
> that looks then.

tbh I have no idea what to do with dma-buf shared across drivers.

For dma-fence it's fairly simple: Force-complete them all, with an error
code of ENODEV. But for dma-buf I have no idea. As long as the dma-buf
sits in system memory it should keep working, plus/minus bugs in the
exporter where it tries to look at device state that might no longer be
there.

The real fun starts when the buffer is in vram, or when the mmap somehow
goes through the device (but that's more a case for integrated gpu, and
it's a bit hard to hotunplug those and consider that a real use-case).
-Daniel

> 
> 
> Thanks,
> pq



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Andrey Grodzovsky]

On 5/27/20 4:25 PM, Daniel Vetter wrote:
> On Wed, May 27, 2020 at 9:44 PM Christian König
> <christian.koenig@amd.com> wrote:
>> Am 27.05.20 um 17:23 schrieb Andrey Grodzovsky:
>>> On 5/27/20 10:39 AM, Daniel Vetter wrote:
>>>> On Wed, May 27, 2020 at 3:51 PM Andrey Grodzovsky
>>>> <Andrey.Grodzovsky@amd.com> wrote:
>>>>> On 5/27/20 2:44 AM, Pekka Paalanen wrote:
>>>>>> On Tue, 26 May 2020 10:30:20 -0400
>>>>>> Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> wrote:
>>>>>>
>>>>>>> On 5/19/20 6:06 AM, Pekka Paalanen wrote:
>>>>>>>> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>>>>>>
>>>>>>>> Set up the expectations on how hot-unplugging a DRM device should
>>>>>>>> look like to
>>>>>>>> userspace.
>>>>>>>>
>>>>>>>> Written by Daniel Vetter's request and largely based on his
>>>>>>>> comments in IRC and
>>>>>>>> from
>>>>>>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7CAndrey.Grodzovsky%40amd.com%7Cd1aab2c6fe71407a287708d8027c0f3c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637262079143242123&amp;sdata=krqBSHMfzl%2F4TMaAgEPDq8Y%2BPYWJATZyeDPfhtWQmeg%3D&amp;reserved=0
>>>>>>>> .
>>>>>>>>
>>>>>>>> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
>>>>>>>> Cc: Daniel Vetter <daniel@ffwll.ch>
>>>>>>>> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
>>>>>>>> Cc: Dave Airlie <airlied@redhat.com>
>>>>>>>> Cc: Sean Paul <sean@poorly.run>
>>>>>>>>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Disclaimer: I am a userspace developer writing for other
>>>>>>>> userspace developers.
>>>>>>>> I took some liberties in defining what should happen without
>>>>>>>> knowing what is
>>>>>>>> actually possible or what existing drivers already implement.
>>>>>>>> ---
>>>>>>>>      Documentation/gpu/drm-uapi.rst | 75
>>>>>>>> ++++++++++++++++++++++++++++++++++
>>>>>>>>      1 file changed, 75 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/gpu/drm-uapi.rst
>>>>>>>> b/Documentation/gpu/drm-uapi.rst
>>>>>>>> index 56fec6ed1ad8..80db4abd2cbd 100644
>>>>>>>> --- a/Documentation/gpu/drm-uapi.rst
>>>>>>>> +++ b/Documentation/gpu/drm-uapi.rst
>>>>>>>> @@ -1,3 +1,5 @@
>>>>>>>> +.. Copyright 2020 DisplayLink (UK) Ltd.
>>>>>>>> +
>>>>>>>>      ===================
>>>>>>>>      Userland interfaces
>>>>>>>>      ===================
>>>>>>>> @@ -162,6 +164,79 @@ other hand, a driver requires shared state
>>>>>>>> between clients which is
>>>>>>>>      visible to user-space and accessible beyond open-file
>>>>>>>> boundaries, they
>>>>>>>>      cannot support render nodes.
>>>>>>>>
>>>>>>>> +Device Hot-Unplug
>>>>>>>> +=================
>>>>>>>> +
>>>>>>>> +.. note::
>>>>>>>> +   The following is the plan. Implementation is not there yet
>>>>>>>> +   (2020 May 13).
>>>>>>>> +
>>>>>>>> +Graphics devices (display and/or render) may be connected via
>>>>>>>> USB (e.g.
>>>>>>>> +display adapters or docking stations) or Thunderbolt (e.g.
>>>>>>>> eGPU). An end
>>>>>>>> +user is able to hot-unplug this kind of devices while they are
>>>>>>>> being
>>>>>>>> +used, and expects that the very least the machine does not
>>>>>>>> crash. Any
>>>>>>>> +damage from hot-unplugging a DRM device needs to be limited as
>>>>>>>> much as
>>>>>>>> +possible and userspace must be given the chance to handle it if
>>>>>>>> it wants
>>>>>>>> +to. Ideally, unplugging a DRM device still lets a desktop to
>>>>>>>> continue
>>>>>>>> +running, but that is going to need explicit support throughout
>>>>>>>> the whole
>>>>>>>> +graphics stack: from kernel and userspace drivers, through display
>>>>>>>> +servers, via window system protocols, and in applications and
>>>>>>>> libraries.
>>>>>>>> +
>>>>>>>> +Other scenarios that should lead to the same are: unrecoverable GPU
>>>>>>>> +crash, PCI device disappearing off the bus, or forced unbind of
>>>>>>>> a driver
>>>>>>>> +from the physical device.
>>>>>>>> +
>>>>>>>> +In other words, from userspace perspective everything needs to
>>>>>>>> keep on
>>>>>>>> +working more or less, until userspace stops using the
>>>>>>>> disappeared DRM
>>>>>>>> +device and closes it completely. Userspace will learn of the device
>>>>>>>> +disappearance from the device removed uevent or in some cases
>>>>>>>> specific
>>>>>>>> +ioctls returning EIO.
>>>>>>>> +
>>>>>>>> +This goal raises at least the following requirements for the
>>>>>>>> kernel and
>>>>>>>> +drivers:
>>>>>>>> +
>>>>>>>> +- The kernel must not hang, crash or oops, no matter what
>>>>>>>> userspace was
>>>>>>>> +  in the middle of doing when the device disappeared.
>>>>>>>> +
>>>>>>>> +- All GPU jobs that can no longer run must have their fences
>>>>>>>> +  force-signalled to avoid inflicting hangs to userspace.
>>>>>>>> +
>>>>>>>> +- KMS connectors must change their status to disconnected.
>>>>>>>> +
>>>>>>>> +- Legacy modesets and pageflips fake success.
>>>>>>>> +
>>>>>>>> +- Atomic commits, both real and TEST_ONLY, fake success.
>>>>>>>> +
>>>>>>>> +- Pending non-blocking KMS operations deliver the DRM events
>>>>>>>> userspace
>>>>>>>> +  is expecting.
>>>>>>>> +
>>>>>>>> +- If underlying memory disappears, the mmaps are replaced with
>>>>>>>> harmless
>>>>>>>> +  zero pages where access does not raise SIGBUS. Reads return
>>>>>>>> zeros,
>>>>>>>> +  writes are ignored.
>>>>>>> Regarding this paragraph - what about exiting mappings ? In the first
>>>>>>> patchset we would actively invalidate all the existing CPU
>>>>>>> mappings to
>>>>>>> device memory and i think we still should do it otherwise we will see
>>>>>>> random crashes in applications as was before. I guess it's because
>>>>>>> TLBs
>>>>>>> and page tables are not updated to reflect the fact the device is
>>>>>>> gone.
>>>>>> Hi,
>>>>>>
>>>>>> I was talking about existing mappings. What I forgot to specify is how
>>>>>> new mmap() calls after the device disappearance should work (the end
>>>>>> result should be the same still, not failure).
>>>>>>
>>>>>> I'll clarify this in the next revision.
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> pq
>>>>> I see, that ok.
>>>>>
>>>>> Next related question is more for Daniel/Christian - about the
>>>>> implementation of this paragraph, I was thinking about something like
>>>>> checking for device disconnect in ttm_bo_vm_fault_reserved and if so
>>>>> remap the entire VA range for the VMA where the fault address
>>>>> belongs to
>>>>> the global zero page (i.e. (remap_pfn_range(vma, vma->vm_start,
>>>>> page_to_pfn(ZERO_PAGE(vma->vm_start), vma->vm_end - vma->vm_start,
>>>>> vma->vm_page_prot)). Question is, when the doc says 'writes are
>>>>> ignored'
>>>>> does it mean i should use copy on write for the vma->vm_page_prot
>>>>> and if
>>>>> so how i actually do it as i was not able to find what flags to set
>>>>> into
>>>>> vm_page_prot to force copy on write behavior.
>>>> Already discussed this with Pekka on irc, I think simply a private
>>>> page (per gpu ctx to avoid leaks) is good enough. Otherwise we need to
>>>> catch write faults and throw the writes away, and that's a) a bit
>>>> tricky to implement and b) slow, which we kinda don't want to. If the
>>>> desktop is stuck for a few seconds because we're trapping every write
>>>> of a 4k buffer that's getting uploaded, the user is going to have a
>>>> bad time :-/
>>>> -Daniel
>>>
>>> So like allocating a page per process context in the driver (struct
>>> amdgpu_ctx in amdgpu) and mapping this page into the faulting VMAs
>>> for when device is disconnected ? I am still not clear how i make the
>>> mapping ignore writes without catching write faults and ignoring them.
>>> I cannot just make it read only obviously and i can't make it writable
>>> as then reading back will start returning non 0's. My question is what
>>> set of flags in vm_area_struct.vm_flags can (if at all) give me
>>> 'ignore writes' behavior for the mapping of that page.
>> I'm not aware of a possibility like that on x86 CPUs. As far as I know
>> we only have something like an ignore write functionality on our GPUs
>> for PRTs.
>>
>> Could we use an address which points to a non allocated MMIO space or
>> something like this? We would might get 0xffffffff on reads instead of
>> 0x0, but writes would be certainly ignored.
> I think just a page with garbage in, garbage out semantics is going to
> be ok. I think pretty much anything has a chance to upset userspace,
> so whether it's 0 or all 1s or anything else doesn't really matter.
>
> Only thing that does matter a bit is that we have a page per fd, so
> that we don't accidentally leak something between processes where we
> shouldn't. I think as long as we don't crash&burn in a SIGBUS it's
> good enough.
> -Daniel


To use non allocated MMIO space i would need first to know which range 
is currently not used (how ?) and then reserve it (and free later) to 
avoid other devices start using it. I think the interface for this is 
https://elixir.bootlin.com/linux/v5.7-rc7/source/include/linux/ioport.h#L233. 
But still i like the zero page approach more where we map the zero page 
during new page faults into the faulting process page table with setting 
adding ~(VM_SHARED | VM_MAYSHARE) to vma->vm_flags or at least to 
pgprot_t for this particular maping which i think makes the mapping copy 
on write and so each process (each FD) will also not leak data to other 
processes.

Andrey


>
>> Christian.
>>
>>> Andrey
>>>
>>>
>>>>> Andrey
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>>> +
>>>>>>>> +- dmabuf which point to memory that has disappeared are
>>>>>>>> rewritten to
>>>>>>>> +  point to harmless zero pages, similar to mmaps. Imports still
>>>>>>>> succeed
>>>>>>>> +  both ways: an existing device importing a dmabuf pointing to
>>>>>>>> +  disappeared memory, and a disappeared device importing any
>>>>>>>> dmabuf.
>>>>>>>> +
>>>>>>>> +- Render ioctls return EIO which is then handled in userspace
>>>>>>>> drivers,
>>>>>>>> +  e.g. Mesa, to have the device disappearance handled in the way
>>>>>>>> +  specified for each API (OpenGL, GL ES: GL_KHR_robustness;
>>>>>>>> +  Vulkan: VK_ERROR_DEVICE_LOST; etc.)
>>>>>>>> +
>>>>>>>> +Raising SIGBUS is not an option, because userspace cannot
>>>>>>>> realistically
>>>>>>>> +handle it.  Signal handlers are global, which makes them extremely
>>>>>>>> +difficult to use correctly from libraries like Mesa produces.
>>>>>>>> Signal
>>>>>>>> +handlers are not composable, you can't have different handlers
>>>>>>>> for GPU1
>>>>>>>> +and GPU2 from different vendors, and a third handler for mmapped
>>>>>>>> regular
>>>>>>>> +files.  Threads cause additional pain with signal handling as well.
>>>>>>>> +
>>>>>>>> +Only after userspace has closed all relevant DRM device and
>>>>>>>> dmabuf file
>>>>>>>> +descriptors and removed all mmaps, the DRM driver can tear down its
>>>>>>>> +instance for the device that no longer exists. If the same physical
>>>>>>>> +device somehow comes back in the mean time, it shall be a new DRM
>>>>>>>> +device.
>>>>>>>> +
>>>>>>>>      .. _drm_driver_ioctl:
>>>>>>>>
>>>>>>>>      IOCTL Support on Device Nodes
>>>>
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 1759 bytes --]

On Thu, 28 May 2020 16:45:45 +0200
Daniel Vetter <daniel@ffwll.ch> wrote:

> On Thu, May 28, 2020 at 03:27:57PM +0300, Pekka Paalanen wrote:

...

> > Hmm. Maybe Wayland compositors should ignore all EGL import failures
> > that happen after the wl_buffer has been created (which implies that
> > the dmabuf has been validated to work initially). When import fails at
> > a later time, the compositor should just paint some error pattern
> > instead of the window. That would let the kernel keep on returning
> > errors.
> > 
> > Yeah, ok. I'll keep the ENODEV there in my next version. Let's see how
> > that looks then.  
> 
> tbh I have no idea what to do with dma-buf shared across drivers.
> 
> For dma-fence it's fairly simple: Force-complete them all, with an error
> code of ENODEV. But for dma-buf I have no idea. As long as the dma-buf
> sits in system memory it should keep working, plus/minus bugs in the
> exporter where it tries to look at device state that might no longer be
> there.
> 
> The real fun starts when the buffer is in vram, or when the mmap somehow
> goes through the device (but that's more a case for integrated gpu, and
> it's a bit hard to hotunplug those and consider that a real use-case).

Is forced driver unbind not a real use-case, or would it not invalidate
the memory references wrapped in a dmabuf?

In the proposal, I listed driver unbind as a use-case.

I don't mind if cross-driver shared dmabuf needed ten years of kernel
internals development to reach a state where it won't explode anymore,
but that's the goal I want to set today. I don't think we can tell
userspace to never share dmabufs cross-device if the exporter device is
hot-unpluggable, can we?


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

From: Pekka Paalanen <pekka.paalanen@collabora.com>

Set up the expectations on how hot-unplugging a DRM device should look like to
userspace.

Written by Daniel Vetter's request and largely based on his comments in IRC and
from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .

A related Wayland protocol change proposal is at
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Simon Ser <contact@emersion.fr>

---

v3:
- update ENODEV doc (Daniel)
- clarify existing vs. new mmaps (Andrey)
- split into KMS and render/cross sections (Andrey, Daniel)
- open() returns ENXIO (open(2) man page)
- ioctls may return ENODEV (Andrey, Daniel)
- new wayland-protocols MR

v2:
- mmap reads/writes undefined (Daniel)
- make render ioctl behaviour driver-specific (Daniel)
- restructure the mmap paragraphs (Daniel)
- chardev minor notes (Simon)
- open behaviour (Daniel)
- DRM leasing behaviour (Daniel)
- added links

Disclaimer: I am a userspace developer writing for other userspace developers.
I took some liberties in defining what should happen without knowing what is
actually possible or what existing drivers already implement.
---
 Documentation/gpu/drm-uapi.rst | 114 ++++++++++++++++++++++++++++++++-
 1 file changed, 113 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 56fec6ed1ad8..db56c681b648 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -1,3 +1,5 @@
+.. Copyright 2020 DisplayLink (UK) Ltd.
+
 ===================
 Userland interfaces
 ===================
@@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is
 visible to user-space and accessible beyond open-file boundaries, they
 cannot support render nodes.
 
+Device Hot-Unplug
+=================
+
+.. note::
+   The following is the plan. Implementation is not there yet
+   (2020 May).
+
+Graphics devices (display and/or render) may be connected via USB (e.g.
+display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
+user is able to hot-unplug this kind of devices while they are being
+used, and expects that the very least the machine does not crash. Any
+damage from hot-unplugging a DRM device needs to be limited as much as
+possible and userspace must be given the chance to handle it if it wants
+to. Ideally, unplugging a DRM device still lets a desktop to continue
+running, but that is going to need explicit support throughout the whole
+graphics stack: from kernel and userspace drivers, through display
+servers, via window system protocols, and in applications and libraries.
+
+Other scenarios that should lead to the same are: unrecoverable GPU
+crash, PCI device disappearing off the bus, or forced unbind of a driver
+from the physical device.
+
+In other words, from userspace perspective everything needs to keep on
+working more or less, until userspace stops using the disappeared DRM
+device and closes it completely. Userspace will learn of the device
+disappearance from the device removed uevent, ioctls returning ENODEV
+(or driver-specific ioctls returning driver-specific things), or open()
+returning ENXIO.
+
+Only after userspace has closed all relevant DRM device and dmabuf file
+descriptors and removed all mmaps, the DRM driver can tear down its
+instance for the device that no longer exists. If the same physical
+device somehow comes back in the mean time, it shall be a new DRM
+device.
+
+Similar to PIDs, chardev minor numbers are not recycled immediately. A
+new DRM device always picks the next free minor number compared to the
+previous one allocated, and wraps around when minor numbers are
+exhausted.
+
+The goal raises at least the following requirements for the kernel and
+drivers.
+
+Requirements for KMS UAPI
+-------------------------
+
+- KMS connectors must change their status to disconnected.
+
+- Legacy modesets and pageflips, and atomic commits, both real and
+  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
+  success.
+
+- Pending non-blocking KMS operations deliver the DRM events userspace
+  is expecting. This applies also to ioctls that faked success.
+
+- open() on a device node whose underlying device has disappeared will
+  fail with ENXIO.
+
+- Attempting to create a DRM lease on a disappeared DRM device will
+  fail with ENODEV. Existing DRM leases remain and work as listed
+  above.
+
+Requirements for Render and Cross-Device UAPI
+---------------------------------------------
+
+- All GPU jobs that can no longer run must have their fences
+  force-signalled to avoid inflicting hangs to userspace.
+  The associated error code is ENODEV.
+
+- Some userspace APIs already define what should happen when the device
+  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
+  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
+  behaviour the way they see best, e.g. returning failures in
+  driver-specific ioctls and handling those in userspace drivers, or
+  rely on uevents, and so on.
+
+- dmabuf which point to memory that has disappeared will either fail to
+  import with ENODEV or continue to be successfully imported if it would
+  have succeeded before the disappearance. See also about memory maps
+  below for already imported dmabufs.
+
+- Attempting to import a dmabuf to a disappeared device will either fail
+  with ENODEV or succeed if it would have succeeded without the
+  disappearance.
+
+- open() on a device node whose underlying device has disappeared will
+  fail with ENXIO.
+
+.. _GL_KHR_robustness: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt
+.. _Vulkan: https://www.khronos.org/vulkan/
+
+Requirements for Memory Maps
+----------------------------
+
+Memory maps have further requirements that apply to both existing maps
+and maps created after the device has disappeared. If the underlying
+memory disappeared, the map is created or modified such that reads and
+writes will still complete successfully but the result is undefined.
+This applies to both userspace mmap()'d memory and memory pointed to by
+dmabuf which might be mapped to other devices (cross-device dmabuf
+imports).
+
+Raising SIGBUS is not an option, because userspace cannot realistically
+handle it. Signal handlers are global, which makes them extremely
+difficult to use correctly from libraries like those that Mesa produces.
+Signal handlers are not composable, you can't have different handlers
+for GPU1 and GPU2 from different vendors, and a third handler for
+mmapped regular files. Threads cause additional pain with signal
+handling as well.
+
 .. _drm_driver_ioctl:
 
 IOCTL Support on Device Nodes
@@ -199,7 +311,7 @@ EPERM/EACCES:
         difference between EACCES and EPERM.
 
 ENODEV:
-        The device is not (yet) present or fully initialized.
+        The device is not anymore present or is not yet fully initialized.
 
 EOPNOTSUPP:
         Feature (like PRIME, modesetting, GEM) is not supported by the driver.
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/doc: device hot-unplug for userspace

[Andrey Grodzovsky]

On 6/1/20 10:32 AM, Pekka Paalanen wrote:
> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cfc4392da89ea4fc4281b08d806389835%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266187434486889&amp;sdata=Mbsx6qBXN9MBnDDJi4shRZobf7tjcClvNUlUCPsiVtw%3D&amp;reserved=0 .
>
> A related Wayland protocol change proposal is at
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fwayland%2Fwayland-protocols%2F-%2Fmerge_requests%2F35&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cfc4392da89ea4fc4281b08d806389835%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266187434486889&amp;sdata=5j%2FNQFW0C1wvdnR%2BC0WgGU0JcNCb8fIYBPXFOmp36Ck%3D&amp;reserved=0
>
> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Simon Ser <contact@emersion.fr>
>
> ---
>
> v3:
> - update ENODEV doc (Daniel)
> - clarify existing vs. new mmaps (Andrey)
> - split into KMS and render/cross sections (Andrey, Daniel)
> - open() returns ENXIO (open(2) man page)
> - ioctls may return ENODEV (Andrey, Daniel)
> - new wayland-protocols MR
>
> v2:
> - mmap reads/writes undefined (Daniel)
> - make render ioctl behaviour driver-specific (Daniel)
> - restructure the mmap paragraphs (Daniel)
> - chardev minor notes (Simon)
> - open behaviour (Daniel)
> - DRM leasing behaviour (Daniel)
> - added links
>
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>   Documentation/gpu/drm-uapi.rst | 114 ++++++++++++++++++++++++++++++++-
>   1 file changed, 113 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..db56c681b648 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -1,3 +1,5 @@
> +.. Copyright 2020 DisplayLink (UK) Ltd.
> +
>   ===================
>   Userland interfaces
>   ===================
> @@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is
>   visible to user-space and accessible beyond open-file boundaries, they
>   cannot support render nodes.
>   
> +Device Hot-Unplug
> +=================
> +
> +.. note::
> +   The following is the plan. Implementation is not there yet
> +   (2020 May).
> +
> +Graphics devices (display and/or render) may be connected via USB (e.g.
> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> +user is able to hot-unplug this kind of devices while they are being
> +used, and expects that the very least the machine does not crash. Any
> +damage from hot-unplugging a DRM device needs to be limited as much as
> +possible and userspace must be given the chance to handle it if it wants
> +to. Ideally, unplugging a DRM device still lets a desktop to continue
> +running, but that is going to need explicit support throughout the whole
> +graphics stack: from kernel and userspace drivers, through display
> +servers, via window system protocols, and in applications and libraries.
> +
> +Other scenarios that should lead to the same are: unrecoverable GPU
> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> +from the physical device.
> +
> +In other words, from userspace perspective everything needs to keep on
> +working more or less, until userspace stops using the disappeared DRM
> +device and closes it completely. Userspace will learn of the device
> +disappearance from the device removed uevent, ioctls returning ENODEV
> +(or driver-specific ioctls returning driver-specific things), or open()
> +returning ENXIO.
> +
> +Only after userspace has closed all relevant DRM device and dmabuf file
> +descriptors and removed all mmaps, the DRM driver can tear down its
> +instance for the device that no longer exists. If the same physical
> +device somehow comes back in the mean time, it shall be a new DRM
> +device.
> +
> +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> +new DRM device always picks the next free minor number compared to the
> +previous one allocated, and wraps around when minor numbers are
> +exhausted.
> +
> +The goal raises at least the following requirements for the kernel and
> +drivers.
> +
> +Requirements for KMS UAPI
> +-------------------------
> +
> +- KMS connectors must change their status to disconnected.
> +
> +- Legacy modesets and pageflips, and atomic commits, both real and
> +  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
> +  success.
> +
> +- Pending non-blocking KMS operations deliver the DRM events userspace
> +  is expecting. This applies also to ioctls that faked success.
> +
> +- open() on a device node whose underlying device has disappeared will
> +  fail with ENXIO.
> +
> +- Attempting to create a DRM lease on a disappeared DRM device will
> +  fail with ENODEV. Existing DRM leases remain and work as listed
> +  above.
> +
> +Requirements for Render and Cross-Device UAPI
> +---------------------------------------------
> +
> +- All GPU jobs that can no longer run must have their fences
> +  force-signalled to avoid inflicting hangs to userspace.
> +  The associated error code is ENODEV.
> +
> +- Some userspace APIs already define what should happen when the device
> +  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
> +  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
> +  behaviour the way they see best, e.g. returning failures in
> +  driver-specific ioctls and handling those in userspace drivers, or
> +  rely on uevents, and so on.
> +
> +- dmabuf which point to memory that has disappeared will either fail to
> +  import with ENODEV or continue to be successfully imported if it would
> +  have succeeded before the disappearance. See also about memory maps
> +  below for already imported dmabufs.
> +
> +- Attempting to import a dmabuf to a disappeared device will either fail
> +  with ENODEV or succeed if it would have succeeded without the
> +  disappearance.
> +
> +- open() on a device node whose underlying device has disappeared will
> +  fail with ENXIO.
> +
> +.. _GL_KHR_robustness: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fregistry%2FOpenGL%2Fextensions%2FKHR%2FKHR_robustness.txt&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cfc4392da89ea4fc4281b08d806389835%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266187434486889&amp;sdata=69J%2FRk9%2BX4Hew4UVZCvnVvBUFtKjU3lDz5DthyEvaR4%3D&amp;reserved=0
> +.. _Vulkan: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fvulkan%2F&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cfc4392da89ea4fc4281b08d806389835%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266187434486889&amp;sdata=g%2F8ITu9GYokOr%2FgrwoDOKEWMcOV0EZGZDI4quRkjrVQ%3D&amp;reserved=0
> +
> +Requirements for Memory Maps
> +----------------------------
> +
> +Memory maps have further requirements that apply to both existing maps
> +and maps created after the device has disappeared. If the underlying
> +memory disappeared, the map is created or modified such that reads and
> +writes will still complete successfully but the result is undefined.
> +This applies to both userspace mmap()'d memory and memory pointed to by
> +dmabuf which might be mapped to other devices (cross-device dmabuf
> +imports).


I haven't actually tested this yet but my guess is that for existing 
mappings nothing needs to be done as the result returned from 
reading/writing to pages backed by removed card will not fail since the 
page tables are in place but rather will return all 1s or just some 
undefined value for reads and nothing will happen for right - does this 
assumption makes sense ?

Andrey


> +
> +Raising SIGBUS is not an option, because userspace cannot realistically
> +handle it. Signal handlers are global, which makes them extremely
> +difficult to use correctly from libraries like those that Mesa produces.
> +Signal handlers are not composable, you can't have different handlers
> +for GPU1 and GPU2 from different vendors, and a third handler for
> +mmapped regular files. Threads cause additional pain with signal
> +handling as well.
> +
>   .. _drm_driver_ioctl:
>   
>   IOCTL Support on Device Nodes
> @@ -199,7 +311,7 @@ EPERM/EACCES:
>           difference between EACCES and EPERM.
>   
>   ENODEV:
> -        The device is not (yet) present or fully initialized.
> +        The device is not anymore present or is not yet fully initialized.
>   
>   EOPNOTSUPP:
>           Feature (like PRIME, modesetting, GEM) is not supported by the driver.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Tue, Jun 02, 2020 at 10:00:10AM -0400, Andrey Grodzovsky wrote:
> 
> On 6/1/20 10:32 AM, Pekka Paalanen wrote:
> > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> > 
> > Set up the expectations on how hot-unplugging a DRM device should look like to
> > userspace.
> > 
> > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > from https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Farchives%2Fdri-devel%2F2020-May%2F265484.html&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cfc4392da89ea4fc4281b08d806389835%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266187434486889&amp;sdata=Mbsx6qBXN9MBnDDJi4shRZobf7tjcClvNUlUCPsiVtw%3D&amp;reserved=0 .
> > 
> > A related Wayland protocol change proposal is at
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fwayland%2Fwayland-protocols%2F-%2Fmerge_requests%2F35&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cfc4392da89ea4fc4281b08d806389835%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266187434486889&amp;sdata=5j%2FNQFW0C1wvdnR%2BC0WgGU0JcNCb8fIYBPXFOmp36Ck%3D&amp;reserved=0
> > 
> > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: Simon Ser <contact@emersion.fr>
> > 
> > ---
> > 
> > v3:
> > - update ENODEV doc (Daniel)
> > - clarify existing vs. new mmaps (Andrey)
> > - split into KMS and render/cross sections (Andrey, Daniel)
> > - open() returns ENXIO (open(2) man page)
> > - ioctls may return ENODEV (Andrey, Daniel)
> > - new wayland-protocols MR
> > 
> > v2:
> > - mmap reads/writes undefined (Daniel)
> > - make render ioctl behaviour driver-specific (Daniel)
> > - restructure the mmap paragraphs (Daniel)
> > - chardev minor notes (Simon)
> > - open behaviour (Daniel)
> > - DRM leasing behaviour (Daniel)
> > - added links
> > 
> > Disclaimer: I am a userspace developer writing for other userspace developers.
> > I took some liberties in defining what should happen without knowing what is
> > actually possible or what existing drivers already implement.
> > ---
> >   Documentation/gpu/drm-uapi.rst | 114 ++++++++++++++++++++++++++++++++-
> >   1 file changed, 113 insertions(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index 56fec6ed1ad8..db56c681b648 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -1,3 +1,5 @@
> > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > +
> >   ===================
> >   Userland interfaces
> >   ===================
> > @@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is
> >   visible to user-space and accessible beyond open-file boundaries, they
> >   cannot support render nodes.
> > +Device Hot-Unplug
> > +=================
> > +
> > +.. note::
> > +   The following is the plan. Implementation is not there yet
> > +   (2020 May).
> > +
> > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > +user is able to hot-unplug this kind of devices while they are being
> > +used, and expects that the very least the machine does not crash. Any
> > +damage from hot-unplugging a DRM device needs to be limited as much as
> > +possible and userspace must be given the chance to handle it if it wants
> > +to. Ideally, unplugging a DRM device still lets a desktop to continue
> > +running, but that is going to need explicit support throughout the whole
> > +graphics stack: from kernel and userspace drivers, through display
> > +servers, via window system protocols, and in applications and libraries.
> > +
> > +Other scenarios that should lead to the same are: unrecoverable GPU
> > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > +from the physical device.
> > +
> > +In other words, from userspace perspective everything needs to keep on
> > +working more or less, until userspace stops using the disappeared DRM
> > +device and closes it completely. Userspace will learn of the device
> > +disappearance from the device removed uevent, ioctls returning ENODEV
> > +(or driver-specific ioctls returning driver-specific things), or open()
> > +returning ENXIO.
> > +
> > +Only after userspace has closed all relevant DRM device and dmabuf file
> > +descriptors and removed all mmaps, the DRM driver can tear down its
> > +instance for the device that no longer exists. If the same physical
> > +device somehow comes back in the mean time, it shall be a new DRM
> > +device.
> > +
> > +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> > +new DRM device always picks the next free minor number compared to the
> > +previous one allocated, and wraps around when minor numbers are
> > +exhausted.
> > +
> > +The goal raises at least the following requirements for the kernel and
> > +drivers.
> > +
> > +Requirements for KMS UAPI
> > +-------------------------
> > +
> > +- KMS connectors must change their status to disconnected.
> > +
> > +- Legacy modesets and pageflips, and atomic commits, both real and
> > +  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
> > +  success.
> > +
> > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > +  is expecting. This applies also to ioctls that faked success.
> > +
> > +- open() on a device node whose underlying device has disappeared will
> > +  fail with ENXIO.
> > +
> > +- Attempting to create a DRM lease on a disappeared DRM device will
> > +  fail with ENODEV. Existing DRM leases remain and work as listed
> > +  above.
> > +
> > +Requirements for Render and Cross-Device UAPI
> > +---------------------------------------------
> > +
> > +- All GPU jobs that can no longer run must have their fences
> > +  force-signalled to avoid inflicting hangs to userspace.
> > +  The associated error code is ENODEV.
> > +
> > +- Some userspace APIs already define what should happen when the device
> > +  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
> > +  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
> > +  behaviour the way they see best, e.g. returning failures in
> > +  driver-specific ioctls and handling those in userspace drivers, or
> > +  rely on uevents, and so on.
> > +
> > +- dmabuf which point to memory that has disappeared will either fail to
> > +  import with ENODEV or continue to be successfully imported if it would
> > +  have succeeded before the disappearance. See also about memory maps
> > +  below for already imported dmabufs.
> > +
> > +- Attempting to import a dmabuf to a disappeared device will either fail
> > +  with ENODEV or succeed if it would have succeeded without the
> > +  disappearance.
> > +
> > +- open() on a device node whose underlying device has disappeared will
> > +  fail with ENXIO.
> > +
> > +.. _GL_KHR_robustness: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fregistry%2FOpenGL%2Fextensions%2FKHR%2FKHR_robustness.txt&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cfc4392da89ea4fc4281b08d806389835%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266187434486889&amp;sdata=69J%2FRk9%2BX4Hew4UVZCvnVvBUFtKjU3lDz5DthyEvaR4%3D&amp;reserved=0
> > +.. _Vulkan: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.khronos.org%2Fvulkan%2F&amp;data=02%7C01%7Candrey.grodzovsky%40amd.com%7Cfc4392da89ea4fc4281b08d806389835%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637266187434486889&amp;sdata=g%2F8ITu9GYokOr%2FgrwoDOKEWMcOV0EZGZDI4quRkjrVQ%3D&amp;reserved=0
> > +
> > +Requirements for Memory Maps
> > +----------------------------
> > +
> > +Memory maps have further requirements that apply to both existing maps
> > +and maps created after the device has disappeared. If the underlying
> > +memory disappeared, the map is created or modified such that reads and
> > +writes will still complete successfully but the result is undefined.
> > +This applies to both userspace mmap()'d memory and memory pointed to by
> > +dmabuf which might be mapped to other devices (cross-device dmabuf
> > +imports).
> 
> 
> I haven't actually tested this yet but my guess is that for existing
> mappings nothing needs to be done as the result returned from
> reading/writing to pages backed by removed card will not fail since the page
> tables are in place but rather will return all 1s or just some undefined
> value for reads and nothing will happen for right - does this assumption
> makes sense ?

I'm not sure that works with the pci core's assumption of routing pci bar
in the mmio space ... E.g. if you plug in something else in the same
thunderbolt port or pcie hotplug slot, then there might be something
important at those addresses now. While userspace might still be busy
hammer the same addresses through the old mappings.

So for perfect implemenation I think we need to remap these too, but for
first cut probably not needed. Given that status quo is "kernel oopses".
-Daniel

> 
> Andrey
> 
> 
> > +
> > +Raising SIGBUS is not an option, because userspace cannot realistically
> > +handle it. Signal handlers are global, which makes them extremely
> > +difficult to use correctly from libraries like those that Mesa produces.
> > +Signal handlers are not composable, you can't have different handlers
> > +for GPU1 and GPU2 from different vendors, and a third handler for
> > +mmapped regular files. Threads cause additional pain with signal
> > +handling as well.
> > +
> >   .. _drm_driver_ioctl:
> >   IOCTL Support on Device Nodes
> > @@ -199,7 +311,7 @@ EPERM/EACCES:
> >           difference between EACCES and EPERM.
> >   ENODEV:
> > -        The device is not (yet) present or fully initialized.
> > +        The device is not anymore present or is not yet fully initialized.
> >   EOPNOTSUPP:
> >           Feature (like PRIME, modesetting, GEM) is not supported by the driver.

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

[-- Attachment #1.1: Type: text/plain, Size: 1622 bytes --]

On Mon,  1 Jun 2020 17:32:03 +0300
Pekka Paalanen <ppaalanen@gmail.com> wrote:

> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
> 
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
> 
> A related Wayland protocol change proposal is at
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35
> 
> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>

Hi,

how's this version looking? Anything to fix?


Thanks,
pq


> 
> ---
> 
> v3:
> - update ENODEV doc (Daniel)
> - clarify existing vs. new mmaps (Andrey)
> - split into KMS and render/cross sections (Andrey, Daniel)
> - open() returns ENXIO (open(2) man page)
> - ioctls may return ENODEV (Andrey, Daniel)
> - new wayland-protocols MR
> 
> v2:
> - mmap reads/writes undefined (Daniel)
> - make render ioctl behaviour driver-specific (Daniel)
> - restructure the mmap paragraphs (Daniel)
> - chardev minor notes (Simon)
> - open behaviour (Daniel)
> - DRM leasing behaviour (Daniel)
> - added links
> 
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>  Documentation/gpu/drm-uapi.rst | 114 ++++++++++++++++++++++++++++++++-
>  1 file changed, 113 insertions(+), 1 deletion(-)

Sorry to trim like this, but gmail refuses to send my email otherwise.

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Mon, Jun 01, 2020 at 05:32:03PM +0300, Pekka Paalanen wrote:
> From: Pekka Paalanen <pekka.paalanen@collabora.com>
> 
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
> 
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
> 
> A related Wayland protocol change proposal is at
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35
> 
> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Simon Ser <contact@emersion.fr>
> 
> ---
> 
> v3:
> - update ENODEV doc (Daniel)
> - clarify existing vs. new mmaps (Andrey)
> - split into KMS and render/cross sections (Andrey, Daniel)
> - open() returns ENXIO (open(2) man page)
> - ioctls may return ENODEV (Andrey, Daniel)
> - new wayland-protocols MR
> 
> v2:
> - mmap reads/writes undefined (Daniel)
> - make render ioctl behaviour driver-specific (Daniel)
> - restructure the mmap paragraphs (Daniel)
> - chardev minor notes (Simon)
> - open behaviour (Daniel)
> - DRM leasing behaviour (Daniel)
> - added links
> 
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>  Documentation/gpu/drm-uapi.rst | 114 ++++++++++++++++++++++++++++++++-
>  1 file changed, 113 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..db56c681b648 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -1,3 +1,5 @@
> +.. Copyright 2020 DisplayLink (UK) Ltd.
> +
>  ===================
>  Userland interfaces
>  ===================
> @@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is
>  visible to user-space and accessible beyond open-file boundaries, they
>  cannot support render nodes.
>  
> +Device Hot-Unplug
> +=================
> +
> +.. note::
> +   The following is the plan. Implementation is not there yet
> +   (2020 May).
> +
> +Graphics devices (display and/or render) may be connected via USB (e.g.
> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> +user is able to hot-unplug this kind of devices while they are being
> +used, and expects that the very least the machine does not crash. Any
> +damage from hot-unplugging a DRM device needs to be limited as much as
> +possible and userspace must be given the chance to handle it if it wants
> +to. Ideally, unplugging a DRM device still lets a desktop to continue

I think it's "continue to run" not "to continue running". But not native
speaker either.

> +running, but that is going to need explicit support throughout the whole
> +graphics stack: from kernel and userspace drivers, through display
> +servers, via window system protocols, and in applications and libraries.
> +
> +Other scenarios that should lead to the same are: unrecoverable GPU
> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> +from the physical device.
> +
> +In other words, from userspace perspective everything needs to keep on
> +working more or less, until userspace stops using the disappeared DRM
> +device and closes it completely. Userspace will learn of the device
> +disappearance from the device removed uevent, ioctls returning ENODEV
> +(or driver-specific ioctls returning driver-specific things), or open()
> +returning ENXIO.
> +
> +Only after userspace has closed all relevant DRM device and dmabuf file
> +descriptors and removed all mmaps, the DRM driver can tear down its
> +instance for the device that no longer exists. If the same physical
> +device somehow comes back in the mean time, it shall be a new DRM
> +device.
> +
> +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> +new DRM device always picks the next free minor number compared to the
> +previous one allocated, and wraps around when minor numbers are
> +exhausted.
> +
> +The goal raises at least the following requirements for the kernel and
> +drivers.
> +
> +Requirements for KMS UAPI
> +-------------------------
> +
> +- KMS connectors must change their status to disconnected.
> +
> +- Legacy modesets and pageflips, and atomic commits, both real and
> +  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
> +  success.
> +
> +- Pending non-blocking KMS operations deliver the DRM events userspace
> +  is expecting. This applies also to ioctls that faked success.
> +
> +- open() on a device node whose underlying device has disappeared will
> +  fail with ENXIO.
> +
> +- Attempting to create a DRM lease on a disappeared DRM device will
> +  fail with ENODEV. Existing DRM leases remain and work as listed
> +  above.
> +
> +Requirements for Render and Cross-Device UAPI
> +---------------------------------------------
> +
> +- All GPU jobs that can no longer run must have their fences
> +  force-signalled to avoid inflicting hangs to userspace.

I think "on userspace" not "to userspace"

> +  The associated error code is ENODEV.
> +
> +- Some userspace APIs already define what should happen when the device
> +  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
> +  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
> +  behaviour the way they see best, e.g. returning failures in
> +  driver-specific ioctls and handling those in userspace drivers, or
> +  rely on uevents, and so on.
> +
> +- dmabuf which point to memory that has disappeared will either fail to
> +  import with ENODEV or continue to be successfully imported if it would
> +  have succeeded before the disappearance. See also about memory maps
> +  below for already imported dmabufs.
> +
> +- Attempting to import a dmabuf to a disappeared device will either fail
> +  with ENODEV or succeed if it would have succeeded without the
> +  disappearance.
> +
> +- open() on a device node whose underlying device has disappeared will
> +  fail with ENXIO.
> +
> +.. _GL_KHR_robustness: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt
> +.. _Vulkan: https://www.khronos.org/vulkan/
> +
> +Requirements for Memory Maps
> +----------------------------
> +
> +Memory maps have further requirements that apply to both existing maps
> +and maps created after the device has disappeared. If the underlying
> +memory disappeared, the map is created or modified such that reads and
> +writes will still complete successfully but the result is undefined.
> +This applies to both userspace mmap()'d memory and memory pointed to by
> +dmabuf which might be mapped to other devices (cross-device dmabuf
> +imports).
> +
> +Raising SIGBUS is not an option, because userspace cannot realistically
> +handle it. Signal handlers are global, which makes them extremely
> +difficult to use correctly from libraries like those that Mesa produces.
> +Signal handlers are not composable, you can't have different handlers
> +for GPU1 and GPU2 from different vendors, and a third handler for
> +mmapped regular files. Threads cause additional pain with signal
> +handling as well.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Only gap I could spot is additional other fd that float around, like
dma-buf, sync_file, drm_syncobj and stuff like that. I guess we can figure
these out as we go, which shouldn't be a big problem since this entire
document is very much work in progres.

Thanks for pushing this forward.
-Daniel


> +
>  .. _drm_driver_ioctl:
>  
>  IOCTL Support on Device Nodes
> @@ -199,7 +311,7 @@ EPERM/EACCES:
>          difference between EACCES and EPERM.
>  
>  ENODEV:
> -        The device is not (yet) present or fully initialized.
> +        The device is not anymore present or is not yet fully initialized.
>  
>  EOPNOTSUPP:
>          Feature (like PRIME, modesetting, GEM) is not supported by the driver.
> -- 
> 2.20.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

From: Pekka Paalanen <pekka.paalanen@collabora.com>

Set up the expectations on how hot-unplugging a DRM device should look like to
userspace.

Written by Daniel Vetter's request and largely based on his comments in IRC and
from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .

A related Wayland protocol change proposal is at
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Simon Ser <contact@emersion.fr>
Cc: Noralf Trønnes <noralf@tronnes.org>
Cc: Ben Skeggs <skeggsb@gmail.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Harry Wentland <hwentlan@amd.com>
Cc: Karol Herbst <kherbst@redhat.com>

---

Harry and Christian, could one of you ack this on behalf of AMD
drivers?

Ben or Karol, could you ack on behalf of Nouveau?

Noralf, would this work for the tiny drivers etc.?

This is only about laying out plans for the future, not about what
drivers do today. We'd just like to be sure the goals are reasonable and
everyone is aware of the idea.

Thanks,
pq

v4:
- two typo fixes (Daniel)

v3:
- update ENODEV doc (Daniel)
- clarify existing vs. new mmaps (Andrey)
- split into KMS and render/cross sections (Andrey, Daniel)
- open() returns ENXIO (open(2) man page)
- ioctls may return ENODEV (Andrey, Daniel)
- new wayland-protocols MR

v2:
- mmap reads/writes undefined (Daniel)
- make render ioctl behaviour driver-specific (Daniel)
- restructure the mmap paragraphs (Daniel)
- chardev minor notes (Simon)
- open behaviour (Daniel)
- DRM leasing behaviour (Daniel)
- added links

Disclaimer: I am a userspace developer writing for other userspace developers.
I took some liberties in defining what should happen without knowing what is
actually possible or what existing drivers already implement.
---
 Documentation/gpu/drm-uapi.rst | 114 ++++++++++++++++++++++++++++++++-
 1 file changed, 113 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 56fec6ed1ad8..b2585ea6a83e 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -1,3 +1,5 @@
+.. Copyright 2020 DisplayLink (UK) Ltd.
+
 ===================
 Userland interfaces
 ===================
@@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is
 visible to user-space and accessible beyond open-file boundaries, they
 cannot support render nodes.
 
+Device Hot-Unplug
+=================
+
+.. note::
+   The following is the plan. Implementation is not there yet
+   (2020 May).
+
+Graphics devices (display and/or render) may be connected via USB (e.g.
+display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
+user is able to hot-unplug this kind of devices while they are being
+used, and expects that the very least the machine does not crash. Any
+damage from hot-unplugging a DRM device needs to be limited as much as
+possible and userspace must be given the chance to handle it if it wants
+to. Ideally, unplugging a DRM device still lets a desktop continue to
+run, but that is going to need explicit support throughout the whole
+graphics stack: from kernel and userspace drivers, through display
+servers, via window system protocols, and in applications and libraries.
+
+Other scenarios that should lead to the same are: unrecoverable GPU
+crash, PCI device disappearing off the bus, or forced unbind of a driver
+from the physical device.
+
+In other words, from userspace perspective everything needs to keep on
+working more or less, until userspace stops using the disappeared DRM
+device and closes it completely. Userspace will learn of the device
+disappearance from the device removed uevent, ioctls returning ENODEV
+(or driver-specific ioctls returning driver-specific things), or open()
+returning ENXIO.
+
+Only after userspace has closed all relevant DRM device and dmabuf file
+descriptors and removed all mmaps, the DRM driver can tear down its
+instance for the device that no longer exists. If the same physical
+device somehow comes back in the mean time, it shall be a new DRM
+device.
+
+Similar to PIDs, chardev minor numbers are not recycled immediately. A
+new DRM device always picks the next free minor number compared to the
+previous one allocated, and wraps around when minor numbers are
+exhausted.
+
+The goal raises at least the following requirements for the kernel and
+drivers.
+
+Requirements for KMS UAPI
+-------------------------
+
+- KMS connectors must change their status to disconnected.
+
+- Legacy modesets and pageflips, and atomic commits, both real and
+  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
+  success.
+
+- Pending non-blocking KMS operations deliver the DRM events userspace
+  is expecting. This applies also to ioctls that faked success.
+
+- open() on a device node whose underlying device has disappeared will
+  fail with ENXIO.
+
+- Attempting to create a DRM lease on a disappeared DRM device will
+  fail with ENODEV. Existing DRM leases remain and work as listed
+  above.
+
+Requirements for Render and Cross-Device UAPI
+---------------------------------------------
+
+- All GPU jobs that can no longer run must have their fences
+  force-signalled to avoid inflicting hangs on userspace.
+  The associated error code is ENODEV.
+
+- Some userspace APIs already define what should happen when the device
+  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
+  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
+  behaviour the way they see best, e.g. returning failures in
+  driver-specific ioctls and handling those in userspace drivers, or
+  rely on uevents, and so on.
+
+- dmabuf which point to memory that has disappeared will either fail to
+  import with ENODEV or continue to be successfully imported if it would
+  have succeeded before the disappearance. See also about memory maps
+  below for already imported dmabufs.
+
+- Attempting to import a dmabuf to a disappeared device will either fail
+  with ENODEV or succeed if it would have succeeded without the
+  disappearance.
+
+- open() on a device node whose underlying device has disappeared will
+  fail with ENXIO.
+
+.. _GL_KHR_robustness: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt
+.. _Vulkan: https://www.khronos.org/vulkan/
+
+Requirements for Memory Maps
+----------------------------
+
+Memory maps have further requirements that apply to both existing maps
+and maps created after the device has disappeared. If the underlying
+memory disappeared, the map is created or modified such that reads and
+writes will still complete successfully but the result is undefined.
+This applies to both userspace mmap()'d memory and memory pointed to by
+dmabuf which might be mapped to other devices (cross-device dmabuf
+imports).
+
+Raising SIGBUS is not an option, because userspace cannot realistically
+handle it. Signal handlers are global, which makes them extremely
+difficult to use correctly from libraries like those that Mesa produces.
+Signal handlers are not composable, you can't have different handlers
+for GPU1 and GPU2 from different vendors, and a third handler for
+mmapped regular files. Threads cause additional pain with signal
+handling as well.
+
 .. _drm_driver_ioctl:
 
 IOCTL Support on Device Nodes
@@ -199,7 +311,7 @@ EPERM/EACCES:
         difference between EACCES and EPERM.
 
 ENODEV:
-        The device is not (yet) present or fully initialized.
+        The device is not anymore present or is not yet fully initialized.
 
 EOPNOTSUPP:
         Feature (like PRIME, modesetting, GEM) is not supported by the driver.
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/doc: device hot-unplug for userspace

[Alex Deucher]

On Mon, Jun 22, 2020 at 10:06 AM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
>
> A related Wayland protocol change proposal is at
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35
>
> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Simon Ser <contact@emersion.fr>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Cc: Ben Skeggs <skeggsb@gmail.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Harry Wentland <hwentlan@amd.com>
> Cc: Karol Herbst <kherbst@redhat.com>
>
> ---
>
> Harry and Christian, could one of you ack this on behalf of AMD
> drivers?
>
> Ben or Karol, could you ack on behalf of Nouveau?
>
> Noralf, would this work for the tiny drivers etc.?
>
> This is only about laying out plans for the future, not about what
> drivers do today. We'd just like to be sure the goals are reasonable and
> everyone is aware of the idea.
>
> Thanks,
> pq
>
> v4:
> - two typo fixes (Daniel)
>
> v3:
> - update ENODEV doc (Daniel)
> - clarify existing vs. new mmaps (Andrey)
> - split into KMS and render/cross sections (Andrey, Daniel)
> - open() returns ENXIO (open(2) man page)
> - ioctls may return ENODEV (Andrey, Daniel)
> - new wayland-protocols MR
>
> v2:
> - mmap reads/writes undefined (Daniel)
> - make render ioctl behaviour driver-specific (Daniel)
> - restructure the mmap paragraphs (Daniel)
> - chardev minor notes (Simon)
> - open behaviour (Daniel)
> - DRM leasing behaviour (Daniel)
> - added links
>
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>  Documentation/gpu/drm-uapi.rst | 114 ++++++++++++++++++++++++++++++++-
>  1 file changed, 113 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..b2585ea6a83e 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -1,3 +1,5 @@
> +.. Copyright 2020 DisplayLink (UK) Ltd.
> +
>  ===================
>  Userland interfaces
>  ===================
> @@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is
>  visible to user-space and accessible beyond open-file boundaries, they
>  cannot support render nodes.
>
> +Device Hot-Unplug
> +=================
> +
> +.. note::
> +   The following is the plan. Implementation is not there yet
> +   (2020 May).
> +
> +Graphics devices (display and/or render) may be connected via USB (e.g.
> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> +user is able to hot-unplug this kind of devices while they are being
> +used, and expects that the very least the machine does not crash. Any
> +damage from hot-unplugging a DRM device needs to be limited as much as
> +possible and userspace must be given the chance to handle it if it wants
> +to. Ideally, unplugging a DRM device still lets a desktop continue to
> +run, but that is going to need explicit support throughout the whole
> +graphics stack: from kernel and userspace drivers, through display
> +servers, via window system protocols, and in applications and libraries.
> +
> +Other scenarios that should lead to the same are: unrecoverable GPU
> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> +from the physical device.
> +
> +In other words, from userspace perspective everything needs to keep on
> +working more or less, until userspace stops using the disappeared DRM
> +device and closes it completely. Userspace will learn of the device
> +disappearance from the device removed uevent, ioctls returning ENODEV
> +(or driver-specific ioctls returning driver-specific things), or open()
> +returning ENXIO.
> +
> +Only after userspace has closed all relevant DRM device and dmabuf file
> +descriptors and removed all mmaps, the DRM driver can tear down its
> +instance for the device that no longer exists. If the same physical
> +device somehow comes back in the mean time, it shall be a new DRM
> +device.
> +
> +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> +new DRM device always picks the next free minor number compared to the
> +previous one allocated, and wraps around when minor numbers are
> +exhausted.
> +
> +The goal raises at least the following requirements for the kernel and
> +drivers.
> +
> +Requirements for KMS UAPI
> +-------------------------
> +
> +- KMS connectors must change their status to disconnected.
> +
> +- Legacy modesets and pageflips, and atomic commits, both real and
> +  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
> +  success.
> +
> +- Pending non-blocking KMS operations deliver the DRM events userspace
> +  is expecting. This applies also to ioctls that faked success.
> +
> +- open() on a device node whose underlying device has disappeared will
> +  fail with ENXIO.
> +
> +- Attempting to create a DRM lease on a disappeared DRM device will
> +  fail with ENODEV. Existing DRM leases remain and work as listed
> +  above.
> +
> +Requirements for Render and Cross-Device UAPI
> +---------------------------------------------
> +
> +- All GPU jobs that can no longer run must have their fences
> +  force-signalled to avoid inflicting hangs on userspace.
> +  The associated error code is ENODEV.
> +
> +- Some userspace APIs already define what should happen when the device
> +  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
> +  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
> +  behaviour the way they see best, e.g. returning failures in
> +  driver-specific ioctls and handling those in userspace drivers, or
> +  rely on uevents, and so on.
> +
> +- dmabuf which point to memory that has disappeared will either fail to
> +  import with ENODEV or continue to be successfully imported if it would
> +  have succeeded before the disappearance. See also about memory maps
> +  below for already imported dmabufs.
> +
> +- Attempting to import a dmabuf to a disappeared device will either fail
> +  with ENODEV or succeed if it would have succeeded without the
> +  disappearance.
> +
> +- open() on a device node whose underlying device has disappeared will
> +  fail with ENXIO.
> +
> +.. _GL_KHR_robustness: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt
> +.. _Vulkan: https://www.khronos.org/vulkan/
> +
> +Requirements for Memory Maps
> +----------------------------
> +
> +Memory maps have further requirements that apply to both existing maps
> +and maps created after the device has disappeared. If the underlying
> +memory disappeared, the map is created or modified such that reads and

disappeared -> disappears

> +writes will still complete successfully but the result is undefined.
> +This applies to both userspace mmap()'d memory and memory pointed to by
> +dmabuf which might be mapped to other devices (cross-device dmabuf
> +imports).
> +
> +Raising SIGBUS is not an option, because userspace cannot realistically
> +handle it. Signal handlers are global, which makes them extremely
> +difficult to use correctly from libraries like those that Mesa produces.
> +Signal handlers are not composable, you can't have different handlers
> +for GPU1 and GPU2 from different vendors, and a third handler for
> +mmapped regular files. Threads cause additional pain with signal
> +handling as well.
> +
>  .. _drm_driver_ioctl:
>
>  IOCTL Support on Device Nodes
> @@ -199,7 +311,7 @@ EPERM/EACCES:
>          difference between EACCES and EPERM.
>
>  ENODEV:
> -        The device is not (yet) present or fully initialized.
> +        The device is not anymore present or is not yet fully initialized.

The ordering of this sentence should be fixed up like so:
The device is not present anymore or is not yet fully initialized.

With those fixed the patch is:
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>

Alex

>
>  EOPNOTSUPP:
>          Feature (like PRIME, modesetting, GEM) is not supported by the driver.
> --
> 2.20.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm/doc: device hot-unplug for userspace

[Noralf Trønnes]

Den 22.06.2020 16.05, skrev Pekka Paalanen:
> From: Pekka Paalanen <pekka.paalanen@collabora.com>
> 
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
> 
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
> 
> A related Wayland protocol change proposal is at
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35
> 
> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Simon Ser <contact@emersion.fr>
> Cc: Noralf Trønnes <noralf@tronnes.org>
> Cc: Ben Skeggs <skeggsb@gmail.com>
> Cc: Christian König <christian.koenig@amd.com>
> Cc: Harry Wentland <hwentlan@amd.com>
> Cc: Karol Herbst <kherbst@redhat.com>
> 
> ---
> 
> Harry and Christian, could one of you ack this on behalf of AMD
> drivers?
> 
> Ben or Karol, could you ack on behalf of Nouveau?
> 
> Noralf, would this work for the tiny drivers etc.?
> 

Looks good to me:

Acked-by: Noralf Trønnes <noralf@tronnes.org>

> This is only about laying out plans for the future, not about what
> drivers do today. We'd just like to be sure the goals are reasonable and
> everyone is aware of the idea.
> 
> Thanks,
> pq
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v5] drm/doc: device hot-unplug for userspace

[Pekka Paalanen]

From: Pekka Paalanen <pekka.paalanen@collabora.com>

Set up the expectations on how hot-unplugging a DRM device should look like to
userspace.

Written by Daniel Vetter's request and largely based on his comments in IRC and
from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .

A related Wayland protocol change proposal is at
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35

Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Sean Paul <sean@poorly.run>
Cc: Simon Ser <contact@emersion.fr>
Cc: Ben Skeggs <skeggsb@gmail.com>
Cc: Karol Herbst <kherbst@redhat.com>

---

This is only about laying out plans for the future, not about what
drivers do today. We'd just like to be sure the goals are reasonable and
everyone is aware of the idea.

Thanks,
pq

v5:
- two grammar fixes (Alex)
- added R-b/A-b, dropped extra Cc

v4:
- two typo fixes (Daniel)

v3:
- update ENODEV doc (Daniel)
- clarify existing vs. new mmaps (Andrey)
- split into KMS and render/cross sections (Andrey, Daniel)
- open() returns ENXIO (open(2) man page)
- ioctls may return ENODEV (Andrey, Daniel)
- new wayland-protocols MR

v2:
- mmap reads/writes undefined (Daniel)
- make render ioctl behaviour driver-specific (Daniel)
- restructure the mmap paragraphs (Daniel)
- chardev minor notes (Simon)
- open behaviour (Daniel)
- DRM leasing behaviour (Daniel)
- added links

Disclaimer: I am a userspace developer writing for other userspace developers.
I took some liberties in defining what should happen without knowing what is
actually possible or what existing drivers already implement.
---
 Documentation/gpu/drm-uapi.rst | 114 ++++++++++++++++++++++++++++++++-
 1 file changed, 113 insertions(+), 1 deletion(-)

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 56fec6ed1ad8..9ce51e4f98f4 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -1,3 +1,5 @@
+.. Copyright 2020 DisplayLink (UK) Ltd.
+
 ===================
 Userland interfaces
 ===================
@@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is
 visible to user-space and accessible beyond open-file boundaries, they
 cannot support render nodes.
 
+Device Hot-Unplug
+=================
+
+.. note::
+   The following is the plan. Implementation is not there yet
+   (2020 May).
+
+Graphics devices (display and/or render) may be connected via USB (e.g.
+display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
+user is able to hot-unplug this kind of devices while they are being
+used, and expects that the very least the machine does not crash. Any
+damage from hot-unplugging a DRM device needs to be limited as much as
+possible and userspace must be given the chance to handle it if it wants
+to. Ideally, unplugging a DRM device still lets a desktop continue to
+run, but that is going to need explicit support throughout the whole
+graphics stack: from kernel and userspace drivers, through display
+servers, via window system protocols, and in applications and libraries.
+
+Other scenarios that should lead to the same are: unrecoverable GPU
+crash, PCI device disappearing off the bus, or forced unbind of a driver
+from the physical device.
+
+In other words, from userspace perspective everything needs to keep on
+working more or less, until userspace stops using the disappeared DRM
+device and closes it completely. Userspace will learn of the device
+disappearance from the device removed uevent, ioctls returning ENODEV
+(or driver-specific ioctls returning driver-specific things), or open()
+returning ENXIO.
+
+Only after userspace has closed all relevant DRM device and dmabuf file
+descriptors and removed all mmaps, the DRM driver can tear down its
+instance for the device that no longer exists. If the same physical
+device somehow comes back in the mean time, it shall be a new DRM
+device.
+
+Similar to PIDs, chardev minor numbers are not recycled immediately. A
+new DRM device always picks the next free minor number compared to the
+previous one allocated, and wraps around when minor numbers are
+exhausted.
+
+The goal raises at least the following requirements for the kernel and
+drivers.
+
+Requirements for KMS UAPI
+-------------------------
+
+- KMS connectors must change their status to disconnected.
+
+- Legacy modesets and pageflips, and atomic commits, both real and
+  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
+  success.
+
+- Pending non-blocking KMS operations deliver the DRM events userspace
+  is expecting. This applies also to ioctls that faked success.
+
+- open() on a device node whose underlying device has disappeared will
+  fail with ENXIO.
+
+- Attempting to create a DRM lease on a disappeared DRM device will
+  fail with ENODEV. Existing DRM leases remain and work as listed
+  above.
+
+Requirements for Render and Cross-Device UAPI
+---------------------------------------------
+
+- All GPU jobs that can no longer run must have their fences
+  force-signalled to avoid inflicting hangs on userspace.
+  The associated error code is ENODEV.
+
+- Some userspace APIs already define what should happen when the device
+  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
+  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
+  behaviour the way they see best, e.g. returning failures in
+  driver-specific ioctls and handling those in userspace drivers, or
+  rely on uevents, and so on.
+
+- dmabuf which point to memory that has disappeared will either fail to
+  import with ENODEV or continue to be successfully imported if it would
+  have succeeded before the disappearance. See also about memory maps
+  below for already imported dmabufs.
+
+- Attempting to import a dmabuf to a disappeared device will either fail
+  with ENODEV or succeed if it would have succeeded without the
+  disappearance.
+
+- open() on a device node whose underlying device has disappeared will
+  fail with ENXIO.
+
+.. _GL_KHR_robustness: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt
+.. _Vulkan: https://www.khronos.org/vulkan/
+
+Requirements for Memory Maps
+----------------------------
+
+Memory maps have further requirements that apply to both existing maps
+and maps created after the device has disappeared. If the underlying
+memory disappears, the map is created or modified such that reads and
+writes will still complete successfully but the result is undefined.
+This applies to both userspace mmap()'d memory and memory pointed to by
+dmabuf which might be mapped to other devices (cross-device dmabuf
+imports).
+
+Raising SIGBUS is not an option, because userspace cannot realistically
+handle it. Signal handlers are global, which makes them extremely
+difficult to use correctly from libraries like those that Mesa produces.
+Signal handlers are not composable, you can't have different handlers
+for GPU1 and GPU2 from different vendors, and a third handler for
+mmapped regular files. Threads cause additional pain with signal
+handling as well.
+
 .. _drm_driver_ioctl:
 
 IOCTL Support on Device Nodes
@@ -199,7 +311,7 @@ EPERM/EACCES:
         difference between EACCES and EPERM.
 
 ENODEV:
-        The device is not (yet) present or fully initialized.
+        The device is not present anymore or is not yet fully initialized.
 
 EOPNOTSUPP:
         Feature (like PRIME, modesetting, GEM) is not supported by the driver.
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/doc: device hot-unplug for userspace

[Karol Herbst]

On Tue, Jul 7, 2020 at 1:38 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
>
> From: Pekka Paalanen <pekka.paalanen@collabora.com>
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
>
> A related Wayland protocol change proposal is at
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35
>
> Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> Acked-by: Noralf Trønnes <noralf@tronnes.org>
> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> Cc: Dave Airlie <airlied@redhat.com>
> Cc: Sean Paul <sean@poorly.run>
> Cc: Simon Ser <contact@emersion.fr>
> Cc: Ben Skeggs <skeggsb@gmail.com>
> Cc: Karol Herbst <kherbst@redhat.com>
>
> ---
>
> This is only about laying out plans for the future, not about what
> drivers do today. We'd just like to be sure the goals are reasonable and
> everyone is aware of the idea.
>
> Thanks,
> pq
>
> v5:
> - two grammar fixes (Alex)
> - added R-b/A-b, dropped extra Cc
>
> v4:
> - two typo fixes (Daniel)
>
> v3:
> - update ENODEV doc (Daniel)
> - clarify existing vs. new mmaps (Andrey)
> - split into KMS and render/cross sections (Andrey, Daniel)
> - open() returns ENXIO (open(2) man page)
> - ioctls may return ENODEV (Andrey, Daniel)
> - new wayland-protocols MR
>
> v2:
> - mmap reads/writes undefined (Daniel)
> - make render ioctl behaviour driver-specific (Daniel)
> - restructure the mmap paragraphs (Daniel)
> - chardev minor notes (Simon)
> - open behaviour (Daniel)
> - DRM leasing behaviour (Daniel)
> - added links
>
> Disclaimer: I am a userspace developer writing for other userspace developers.
> I took some liberties in defining what should happen without knowing what is
> actually possible or what existing drivers already implement.
> ---
>  Documentation/gpu/drm-uapi.rst | 114 ++++++++++++++++++++++++++++++++-
>  1 file changed, 113 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 56fec6ed1ad8..9ce51e4f98f4 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -1,3 +1,5 @@
> +.. Copyright 2020 DisplayLink (UK) Ltd.
> +
>  ===================
>  Userland interfaces
>  ===================
> @@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is
>  visible to user-space and accessible beyond open-file boundaries, they
>  cannot support render nodes.
>
> +Device Hot-Unplug
> +=================
> +
> +.. note::
> +   The following is the plan. Implementation is not there yet
> +   (2020 May).
> +
> +Graphics devices (display and/or render) may be connected via USB (e.g.
> +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> +user is able to hot-unplug this kind of devices while they are being
> +used, and expects that the very least the machine does not crash. Any
> +damage from hot-unplugging a DRM device needs to be limited as much as
> +possible and userspace must be given the chance to handle it if it wants
> +to. Ideally, unplugging a DRM device still lets a desktop continue to
> +run, but that is going to need explicit support throughout the whole
> +graphics stack: from kernel and userspace drivers, through display
> +servers, via window system protocols, and in applications and libraries.
> +
> +Other scenarios that should lead to the same are: unrecoverable GPU
> +crash, PCI device disappearing off the bus, or forced unbind of a driver
> +from the physical device.
> +
> +In other words, from userspace perspective everything needs to keep on
> +working more or less, until userspace stops using the disappeared DRM
> +device and closes it completely. Userspace will learn of the device
> +disappearance from the device removed uevent, ioctls returning ENODEV
> +(or driver-specific ioctls returning driver-specific things), or open()
> +returning ENXIO.
> +
> +Only after userspace has closed all relevant DRM device and dmabuf file
> +descriptors and removed all mmaps, the DRM driver can tear down its
> +instance for the device that no longer exists. If the same physical
> +device somehow comes back in the mean time, it shall be a new DRM
> +device.
> +

I don't think we can make a general statement like this. Drivers might
have kworker polling on the device or other asynchronous or repeating
jobs it might want to get rid of as soon as possible. I think it
should be fine for the kernel driver to tear down the instance as long
as it doesn't conflict with the goal of system stability. And usually
drivers have some kernel side state for clients anyway, so it could be
handled in this layer instead.

Or maybe I am overlooking something and we really can't do that :/

> +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> +new DRM device always picks the next free minor number compared to the
> +previous one allocated, and wraps around when minor numbers are
> +exhausted.
> +
> +The goal raises at least the following requirements for the kernel and
> +drivers.
> +
> +Requirements for KMS UAPI
> +-------------------------
> +
> +- KMS connectors must change their status to disconnected.
> +
> +- Legacy modesets and pageflips, and atomic commits, both real and
> +  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
> +  success.
> +
> +- Pending non-blocking KMS operations deliver the DRM events userspace
> +  is expecting. This applies also to ioctls that faked success.
> +
> +- open() on a device node whose underlying device has disappeared will
> +  fail with ENXIO.
> +
> +- Attempting to create a DRM lease on a disappeared DRM device will
> +  fail with ENODEV. Existing DRM leases remain and work as listed
> +  above.
> +
> +Requirements for Render and Cross-Device UAPI
> +---------------------------------------------
> +
> +- All GPU jobs that can no longer run must have their fences
> +  force-signalled to avoid inflicting hangs on userspace.
> +  The associated error code is ENODEV.
> +
> +- Some userspace APIs already define what should happen when the device
> +  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
> +  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
> +  behaviour the way they see best, e.g. returning failures in
> +  driver-specific ioctls and handling those in userspace drivers, or
> +  rely on uevents, and so on.
> +
> +- dmabuf which point to memory that has disappeared will either fail to
> +  import with ENODEV or continue to be successfully imported if it would
> +  have succeeded before the disappearance. See also about memory maps
> +  below for already imported dmabufs.
> +
> +- Attempting to import a dmabuf to a disappeared device will either fail
> +  with ENODEV or succeed if it would have succeeded without the
> +  disappearance.
> +
> +- open() on a device node whose underlying device has disappeared will
> +  fail with ENXIO.
> +
> +.. _GL_KHR_robustness: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt
> +.. _Vulkan: https://www.khronos.org/vulkan/
> +
> +Requirements for Memory Maps
> +----------------------------
> +
> +Memory maps have further requirements that apply to both existing maps
> +and maps created after the device has disappeared. If the underlying
> +memory disappears, the map is created or modified such that reads and
> +writes will still complete successfully but the result is undefined.
> +This applies to both userspace mmap()'d memory and memory pointed to by
> +dmabuf which might be mapped to other devices (cross-device dmabuf
> +imports).
> +
> +Raising SIGBUS is not an option, because userspace cannot realistically
> +handle it. Signal handlers are global, which makes them extremely
> +difficult to use correctly from libraries like those that Mesa produces.
> +Signal handlers are not composable, you can't have different handlers
> +for GPU1 and GPU2 from different vendors, and a third handler for
> +mmapped regular files. Threads cause additional pain with signal
> +handling as well.
> +
>  .. _drm_driver_ioctl:
>
>  IOCTL Support on Device Nodes
> @@ -199,7 +311,7 @@ EPERM/EACCES:
>          difference between EACCES and EPERM.
>
>  ENODEV:
> -        The device is not (yet) present or fully initialized.
> +        The device is not present anymore or is not yet fully initialized.
>
>  EOPNOTSUPP:
>          Feature (like PRIME, modesetting, GEM) is not supported by the driver.
> --
> 2.20.1
>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/doc: device hot-unplug for userspace

[Daniel Vetter]

On Tue, Jul 7, 2020 at 1:49 PM Karol Herbst <kherbst@redhat.com> wrote:
>
> On Tue, Jul 7, 2020 at 1:38 PM Pekka Paalanen <ppaalanen@gmail.com> wrote:
> >
> > From: Pekka Paalanen <pekka.paalanen@collabora.com>
> >
> > Set up the expectations on how hot-unplugging a DRM device should look like to
> > userspace.
> >
> > Written by Daniel Vetter's request and largely based on his comments in IRC and
> > from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
> >
> > A related Wayland protocol change proposal is at
> > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35
> >
> > Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
> > Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> > Acked-by: Noralf Trønnes <noralf@tronnes.org>
> > Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Sean Paul <sean@poorly.run>
> > Cc: Simon Ser <contact@emersion.fr>
> > Cc: Ben Skeggs <skeggsb@gmail.com>
> > Cc: Karol Herbst <kherbst@redhat.com>
> >
> > ---
> >
> > This is only about laying out plans for the future, not about what
> > drivers do today. We'd just like to be sure the goals are reasonable and
> > everyone is aware of the idea.
> >
> > Thanks,
> > pq
> >
> > v5:
> > - two grammar fixes (Alex)
> > - added R-b/A-b, dropped extra Cc
> >
> > v4:
> > - two typo fixes (Daniel)
> >
> > v3:
> > - update ENODEV doc (Daniel)
> > - clarify existing vs. new mmaps (Andrey)
> > - split into KMS and render/cross sections (Andrey, Daniel)
> > - open() returns ENXIO (open(2) man page)
> > - ioctls may return ENODEV (Andrey, Daniel)
> > - new wayland-protocols MR
> >
> > v2:
> > - mmap reads/writes undefined (Daniel)
> > - make render ioctl behaviour driver-specific (Daniel)
> > - restructure the mmap paragraphs (Daniel)
> > - chardev minor notes (Simon)
> > - open behaviour (Daniel)
> > - DRM leasing behaviour (Daniel)
> > - added links
> >
> > Disclaimer: I am a userspace developer writing for other userspace developers.
> > I took some liberties in defining what should happen without knowing what is
> > actually possible or what existing drivers already implement.
> > ---
> >  Documentation/gpu/drm-uapi.rst | 114 ++++++++++++++++++++++++++++++++-
> >  1 file changed, 113 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> > index 56fec6ed1ad8..9ce51e4f98f4 100644
> > --- a/Documentation/gpu/drm-uapi.rst
> > +++ b/Documentation/gpu/drm-uapi.rst
> > @@ -1,3 +1,5 @@
> > +.. Copyright 2020 DisplayLink (UK) Ltd.
> > +
> >  ===================
> >  Userland interfaces
> >  ===================
> > @@ -162,6 +164,116 @@ other hand, a driver requires shared state between clients which is
> >  visible to user-space and accessible beyond open-file boundaries, they
> >  cannot support render nodes.
> >
> > +Device Hot-Unplug
> > +=================
> > +
> > +.. note::
> > +   The following is the plan. Implementation is not there yet
> > +   (2020 May).
> > +
> > +Graphics devices (display and/or render) may be connected via USB (e.g.
> > +display adapters or docking stations) or Thunderbolt (e.g. eGPU). An end
> > +user is able to hot-unplug this kind of devices while they are being
> > +used, and expects that the very least the machine does not crash. Any
> > +damage from hot-unplugging a DRM device needs to be limited as much as
> > +possible and userspace must be given the chance to handle it if it wants
> > +to. Ideally, unplugging a DRM device still lets a desktop continue to
> > +run, but that is going to need explicit support throughout the whole
> > +graphics stack: from kernel and userspace drivers, through display
> > +servers, via window system protocols, and in applications and libraries.
> > +
> > +Other scenarios that should lead to the same are: unrecoverable GPU
> > +crash, PCI device disappearing off the bus, or forced unbind of a driver
> > +from the physical device.
> > +
> > +In other words, from userspace perspective everything needs to keep on
> > +working more or less, until userspace stops using the disappeared DRM
> > +device and closes it completely. Userspace will learn of the device
> > +disappearance from the device removed uevent, ioctls returning ENODEV
> > +(or driver-specific ioctls returning driver-specific things), or open()
> > +returning ENXIO.
> > +
> > +Only after userspace has closed all relevant DRM device and dmabuf file
> > +descriptors and removed all mmaps, the DRM driver can tear down its
> > +instance for the device that no longer exists. If the same physical
> > +device somehow comes back in the mean time, it shall be a new DRM
> > +device.
> > +
>
> I don't think we can make a general statement like this. Drivers might
> have kworker polling on the device or other asynchronous or repeating
> jobs it might want to get rid of as soon as possible. I think it
> should be fine for the kernel driver to tear down the instance as long
> as it doesn't conflict with the goal of system stability. And usually
> drivers have some kernel side state for clients anyway, so it could be
> handled in this layer instead.

There's two clear bits:
- userspace stuff needs to stay around until the last userspace is
gone, including indirect references (dma_fence, dma_buf, stuff like
that)
- hw stuff must be released right away at unbind time (mmio maps,
interrupts, that kinds of stuff)

Everything in-between is a bit a grey area. Some workers you might
want to stop at unbind and release, for others it might be easier to
not care. This is kinda all up to drivers and where exactly they put
down the line between the userspace visible sw stuff and the hw
related bits.

Since the above is talking about the uapi (this is an addition to
drm-uapi.rst) I think it's totally fine to make the sweeping general
statement, since the uapi stuff really should all stick around, or
stuff starts blowing up at random.
-Daniel

>
> Or maybe I am overlooking something and we really can't do that :/
>
> > +Similar to PIDs, chardev minor numbers are not recycled immediately. A
> > +new DRM device always picks the next free minor number compared to the
> > +previous one allocated, and wraps around when minor numbers are
> > +exhausted.
> > +
> > +The goal raises at least the following requirements for the kernel and
> > +drivers.
> > +
> > +Requirements for KMS UAPI
> > +-------------------------
> > +
> > +- KMS connectors must change their status to disconnected.
> > +
> > +- Legacy modesets and pageflips, and atomic commits, both real and
> > +  TEST_ONLY, and any other ioctls either fail with ENODEV or fake
> > +  success.
> > +
> > +- Pending non-blocking KMS operations deliver the DRM events userspace
> > +  is expecting. This applies also to ioctls that faked success.
> > +
> > +- open() on a device node whose underlying device has disappeared will
> > +  fail with ENXIO.
> > +
> > +- Attempting to create a DRM lease on a disappeared DRM device will
> > +  fail with ENODEV. Existing DRM leases remain and work as listed
> > +  above.
> > +
> > +Requirements for Render and Cross-Device UAPI
> > +---------------------------------------------
> > +
> > +- All GPU jobs that can no longer run must have their fences
> > +  force-signalled to avoid inflicting hangs on userspace.
> > +  The associated error code is ENODEV.
> > +
> > +- Some userspace APIs already define what should happen when the device
> > +  disappears (OpenGL, GL ES: `GL_KHR_robustness`_; `Vulkan`_:
> > +  VK_ERROR_DEVICE_LOST; etc.). DRM drivers are free to implement this
> > +  behaviour the way they see best, e.g. returning failures in
> > +  driver-specific ioctls and handling those in userspace drivers, or
> > +  rely on uevents, and so on.
> > +
> > +- dmabuf which point to memory that has disappeared will either fail to
> > +  import with ENODEV or continue to be successfully imported if it would
> > +  have succeeded before the disappearance. See also about memory maps
> > +  below for already imported dmabufs.
> > +
> > +- Attempting to import a dmabuf to a disappeared device will either fail
> > +  with ENODEV or succeed if it would have succeeded without the
> > +  disappearance.
> > +
> > +- open() on a device node whose underlying device has disappeared will
> > +  fail with ENXIO.
> > +
> > +.. _GL_KHR_robustness: https://www.khronos.org/registry/OpenGL/extensions/KHR/KHR_robustness.txt
> > +.. _Vulkan: https://www.khronos.org/vulkan/
> > +
> > +Requirements for Memory Maps
> > +----------------------------
> > +
> > +Memory maps have further requirements that apply to both existing maps
> > +and maps created after the device has disappeared. If the underlying
> > +memory disappears, the map is created or modified such that reads and
> > +writes will still complete successfully but the result is undefined.
> > +This applies to both userspace mmap()'d memory and memory pointed to by
> > +dmabuf which might be mapped to other devices (cross-device dmabuf
> > +imports).
> > +
> > +Raising SIGBUS is not an option, because userspace cannot realistically
> > +handle it. Signal handlers are global, which makes them extremely
> > +difficult to use correctly from libraries like those that Mesa produces.
> > +Signal handlers are not composable, you can't have different handlers
> > +for GPU1 and GPU2 from different vendors, and a third handler for
> > +mmapped regular files. Threads cause additional pain with signal
> > +handling as well.
> > +
> >  .. _drm_driver_ioctl:
> >
> >  IOCTL Support on Device Nodes
> > @@ -199,7 +311,7 @@ EPERM/EACCES:
> >          difference between EACCES and EPERM.
> >
> >  ENODEV:
> > -        The device is not (yet) present or fully initialized.
> > +        The device is not present anymore or is not yet fully initialized.
> >
> >  EOPNOTSUPP:
> >          Feature (like PRIME, modesetting, GEM) is not supported by the driver.
> > --
> > 2.20.1
> >
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v5] drm/doc: device hot-unplug for userspace

[Simon Ser]

On Tuesday, July 7, 2020 1:38 PM, Pekka Paalanen <ppaalanen@gmail.com> wrote:

> From: Pekka Paalanen pekka.paalanen@collabora.com
>
> Set up the expectations on how hot-unplugging a DRM device should look like to
> userspace.
>
> Written by Daniel Vetter's request and largely based on his comments in IRC and
> from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html .
>
> A related Wayland protocol change proposal is at
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35
>
> Signed-off-by: Pekka Paalanen pekka.paalanen@collabora.com
> Reviewed-by: Daniel Vetter daniel.vetter@ffwll.ch
> Reviewed-by: Alex Deucher alexander.deucher@amd.com
> Acked-by: Noralf Trønnes noralf@tronnes.org
> Cc: Andrey Grodzovsky andrey.grodzovsky@amd.com
> Cc: Dave Airlie airlied@redhat.com
> Cc: Sean Paul sean@poorly.run
> Cc: Simon Ser contact@emersion.fr
> Cc: Ben Skeggs skeggsb@gmail.com
> Cc: Karol Herbst kherbst@redhat.com

From a user-space point-of-view, this sounds fine.

Acked-by: Simon Ser <contact@emersion.fr>

Thanks!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

drm/doc: missing SPDX license identifier (Was: Re: [PATCH v5] drm/doc: device hot-unplug for userspace)

[Emil Velikov]

Hi Pekka,

Thanks for the patch - merged to drm-misc-next.
While applying the patch the following warning popped-up.

-:37: WARNING:SPDX_LICENSE_TAG: Missing or malformed
SPDX-License-Identifier tag in line 1
#37: FILE: Documentation/gpu/drm-uapi.rst:1:
+.. Copyright 2020 DisplayLink (UK) Ltd.
                                   │--

Upon closer look, it seems that the DRM documentation lacks a license.
An SPDX one at least - I haven't done extensive reading through each
individual file.
I guess we should add one - be that GPL-2.0, MIT and/or otherwise.
Since I haven't contributed such that much on the documentation side,
I'll defer the suggestion to the maintainers.

Daniel, Dave, care to do the honours?

Tl;DR: the DRM documentation is missing SPDX license identifier.

Thanks
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel