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

[Pekka Paalanen <ppaalanen@gmail.com>]

[-- 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