Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts

2020-12-11 Thread Jürgen Groß
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: On 12/10/20 2:26 PM, Thomas Gleixner wrote: All event channel setups bind the interrupt on CPU0 or the target CPU for percpu interrupts and overwrite the affinity mask with the corresponding cpumask. That does not make sense. The XEN impleme

Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts

2020-12-11 Thread Jürgen Groß
On 11.12.20 11:13, Thomas Gleixner wrote: On Fri, Dec 11 2020 at 07:17, Jürgen Groß wrote: On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: On 12/10/20 2:26 PM, Thomas Gleixner wrote: All event channel setups bind the interrupt on CPU0 or the target CPU for percpu interrupts and

Re: [Intel-gfx] [patch 27/30] xen/events: Only force affinity mask for percpu interrupts

2020-12-11 Thread Jürgen Groß
On 11.12.20 00:20, boris.ostrov...@oracle.com wrote: On 12/10/20 2:26 PM, Thomas Gleixner wrote: All event channel setups bind the interrupt on CPU0 or the target CPU for percpu interrupts and overwrite the affinity mask with the corresponding cpumask. That does not make sense. The XEN impleme

Re: [Intel-gfx] [PATCH v2 0/5] Fixes and improvements for Xen pvdrm

2020-08-13 Thread Jürgen Groß
On 13.08.20 17:10, Oleksandr Andrushchenko wrote: On 8/13/20 6:02 PM, Jürgen Groß wrote: On 13.08.20 08:21, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Series pushed to: xen/tip.git for-linus-5.9 The top patch has strange title though: "Subject: [PATCH v2 5/5] dr

Re: [Intel-gfx] [PATCH v2 0/5] Fixes and improvements for Xen pvdrm

2020-08-13 Thread Jürgen Groß
On 13.08.20 08:21, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko Series pushed to: xen/tip.git for-linus-5.9 Juergen ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 0/5] Fixes and improvements for Xen pvdrm

2020-08-13 Thread Jürgen Groß
On 13.08.20 08:32, Oleksandr Andrushchenko wrote: Juergen, Boris, can we please merge these via Xen Linux tree as I have collected enough Ack/R-b? The series has DRM patches, but those anyway are Xen related, so I think this should be fine from DRI point of view. Yes, fine with me. Juergen

Re: [Intel-gfx] [PATCH 2/6] drm/xen-front: Fix misused IS_ERR_OR_NULL checks

2020-08-03 Thread Jürgen Groß
On 04.08.20 08:35, Oleksandr Andrushchenko wrote: On 8/4/20 9:12 AM, Jürgen Groß wrote: On 31.07.20 14:51, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV display frontend" from Apr 3, 2018, leads to the

Re: [Intel-gfx] [PATCH 4/6] xen: Sync up with the canonical protocol definition in Xen

2020-08-03 Thread Jürgen Groß
On 31.07.20 14:51, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko This is the sync up with the canonical definition of the display protocol in Xen. 1. Add protocol version as an integer Version string, which is in fact an integer, is hard to handle in the code that supports diff

Re: [Intel-gfx] [PATCH 2/6] drm/xen-front: Fix misused IS_ERR_OR_NULL checks

2020-08-03 Thread Jürgen Groß
On 31.07.20 14:51, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko The patch c575b7eeb89f: "drm/xen-front: Add support for Xen PV display frontend" from Apr 3, 2018, leads to the following static checker warning: drivers/gpu/drm/xen/xen_drm_front_gem.c:140 xen_drm_front_ge

Re: [Intel-gfx] [PATCH 1/6] xen/gntdev: Fix dmabuf import with non-zero sgt offset

2020-08-03 Thread Jürgen Groß
On 31.07.20 14:51, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko It is possible that the scatter-gather table during dmabuf import has non-zero offset of the data, but user-space doesn't expect that. Fix this by failing the import, so user-space doesn't access wrong data. Fixes:

Re: [Intel-gfx] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions

2019-11-18 Thread Jürgen Groß
On 18.11.19 11:35, Daniel Vetter wrote: There's no in-kernel users for the k(un)map stuff. And the mmap one is actively harmful - return 0 and then _not_ actually mmaping can't end well. Signed-off-by: Daniel Vetter Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: xen-de...@l