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.free... >> . >> >> 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