== 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
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
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
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.
> >
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
== 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
== 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
== 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
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:
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
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.
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 =
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:
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"
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*
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
On Sat, Sep 19 2020 at 10:18, Linus Torvalds wrote:
> On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
>>
>> this provides a preemptible variant of kmap_atomic & related
>> interfaces. This is achieved by:
>
> Ack. This looks really nice, even apart from the new capability.
>
> The only
Hi Logan,
On 2020/9/19 4:47, Logan Gunthorpe wrote:
Hi Lu,
On 2020-09-11 9:21 p.m., Lu Baolu wrote:
Tom Murphy has almost done all the work. His latest patch series was
posted here.
https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/
Thanks a lot!
This series is a
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 section? This would
>> allow us to ditch an absolute pile of slowpaths.
>
19 matches
Mail list logo
