Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-20 Thread Daniel Vetter
On Sun, Sep 20, 2020 at 08:23:26AM +0200, Thomas Gleixner wrote: > On Sat, Sep 19 2020 at 12:37, Daniel Vetter wrote: > > On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote: > >> I think it should be the case, but I want to double check: Will > >> copy_*_user be allowed within a kmap_temporary s

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-20 Thread Thomas Gleixner
On Sun, Sep 20 2020 at 08:41, Thomas Gleixner wrote: > On Sat, Sep 19 2020 at 10:18, Linus Torvalds wrote: >> Maybe I've missed something. Is it because the new interface still >> does "pagefault_disable()" perhaps? >> >> But does it even need the pagefault_disable() at all? Yes, the >> *atomic* o

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-20 Thread Linus Torvalds
On Sun, Sep 20, 2020 at 1:49 AM Thomas Gleixner wrote: > > Actually most usage sites of kmap atomic do not need page faults to be > disabled at all. Right. I think the pagefault disabling has (almost) nothing at all to do with the kmap() itself - it comes from the "atomic" part, not the "kmap" pa

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-20 Thread Thomas Gleixner
On Sun, Sep 20 2020 at 10:23, Daniel Vetter wrote: > On Sun, Sep 20, 2020 at 08:23:26AM +0200, Thomas Gleixner wrote: >> On Sat, Sep 19 2020 at 12:37, Daniel Vetter wrote: >> > On Sat, Sep 19, 2020 at 12:35 PM Daniel Vetter wrote: >> >> I think it should be the case, but I want to double check: W

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-20 Thread Thomas Gleixner
On Sun, Sep 20 2020 at 09:57, Linus Torvalds wrote: > On Sun, Sep 20, 2020 at 1:49 AM Thomas Gleixner wrote: > Btw, looking at the stack code, Ithink your new implementation of it > is a bit scary: > >static inline int kmap_atomic_idx_push(void) >{ > - int idx = __this_cpu_inc_retu

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-20 Thread Linus Torvalds
On Sun, Sep 20, 2020 at 10:40 AM Thomas Gleixner wrote: > > I think the more obvious solution is to split the whole exercise: > > schedule() > prepare_switch() > unmap() > > switch_to() > > finish_switch() > map() Yeah, that looks much easier to explain. Ack.

Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends

2020-09-20 Thread Linus Torvalds
On Sun, Sep 20, 2020 at 10:42 AM Linus Torvalds wrote: > > Yeah, that looks much easier to explain. Ack. Btw, one thing that might be a good idea at least initially is to add a check for p->kmap_ctrl.idx being zero at fork, exit and maybe syscall return time (but that last one may be too cumberso

[Intel-gfx] [PATCH] drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler

2020-09-20 Thread Zbigniew Kempczyński
On !llc platforms when buffer is mapped with WB using GEM_MMAP_OFFSET pagefault handler clears its dirty flag. This has consequences buffer is not flushed on exec before moving to render domain. So make sure we keep dirty flag for buffers mapped to write until it leaves cpu domain. Signed-off-by:

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler

2020-09-20 Thread Patchwork
== Series Details == Series: drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler URL : https://patchwork.freedesktop.org/series/81881/ State : warning == Summary == $ dim checkpatch origin/drm-tip bd0e70d971fe drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefaul

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler

2020-09-20 Thread Patchwork
== Series Details == Series: drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler URL : https://patchwork.freedesktop.org/series/81881/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9025 -> Patchwork_18537 ===

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler (rev2)

2020-09-20 Thread Patchwork
== Series Details == Series: drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler (rev2) URL : https://patchwork.freedesktop.org/series/81881/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3d2651f10f09 drm/i915: Ensure bo is dirty when WB-mapped on !llc in

Re: [Intel-gfx] [PATCH v1 01/12] drm/i915: introduced vgpu pv capability

2020-09-20 Thread Zhang, Xiaolin
On Thu, 2020-09-10 at 16:10 +0300, Jani Nikula wrote: > On Sat, 05 Sep 2020, Xiaolin Zhang wrote: > > to enable vgpu pv feature, pv capability is introduced for guest by > > new pv_caps member in struct i915_virtual_gpu and for host GVT by > > new pv_caps register in struct vgt_if. > > > > both o

Re: [Intel-gfx] [PATCH v1 02/12] drm/i915: vgpu shared memory setup for pv support

2020-09-20 Thread Zhang, Xiaolin
On Thu, 2020-09-10 at 16:16 +0300, Jani Nikula wrote: > On Sat, 05 Sep 2020, Xiaolin Zhang wrote: > > To support vgpu pv features, a common shared memory is setup used > > for > > communication and data exchange between guest and host GVTg to > > reduce > > data access overhead and trap cost. > >

Re: [Intel-gfx] [PATCH v1 03/12] drm/i915: vgpu pv command buffer transport protocol

2020-09-20 Thread Zhang, Xiaolin
On Thu, 2020-09-10 at 16:20 +0300, Jani Nikula wrote: > On Sat, 05 Sep 2020, Xiaolin Zhang wrote: > > based on the common shared memory, vgpu pv command transport buffer > > (CTB) > > protocol is implemented which is a simple pv command buffer ring > > with pv > > command descriptor used to perfor

Re: [Intel-gfx] [PATCH v1 01/12] drm/i915: introduced vgpu pv capability

2020-09-20 Thread Zhang, Xiaolin
On Thu, 2020-09-10 at 16:10 +0300, Jani Nikula wrote: > On Sat, 05 Sep 2020, Xiaolin Zhang wrote: > > to enable vgpu pv feature, pv capability is introduced for guest by > > new pv_caps member in struct i915_virtual_gpu and for host GVT by > > new pv_caps register in struct vgt_if. > > > > both o

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler (rev2)

2020-09-20 Thread Patchwork
== Series Details == Series: drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler (rev2) URL : https://patchwork.freedesktop.org/series/81881/ State : success == Summary == CI Bug Log - changes from CI_DRM_9025 -> Patchwork_18538 ===

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler (rev2)

2020-09-20 Thread Patchwork
== Series Details == Series: drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler (rev2) URL : https://patchwork.freedesktop.org/series/81881/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9025_full -> Patchwork_18538_full =