Re: [RESUBMIT][PATCH] x86/mm: Fix PAT bit missing from page protection modify mask

On 02.06.23 16:48, Juergen Gross wrote: On 02.06.23 16:43, Borislav Petkov wrote: On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote: As described in the commit message, this only works on bare metal due to the PAT bit not being needed for WC mappings. Making this patch Xen

Re: [RESUBMIT][PATCH] x86/mm: Fix PAT bit missing from page protection modify mask

On 02.06.23 16:43, Borislav Petkov wrote: On Thu, Jun 01, 2023 at 10:47:39AM +0200, Juergen Gross wrote: As described in the commit message, this only works on bare metal due to the PAT bit not being needed for WC mappings. Making this patch Xen specific would try to cure the symptoms without

Re: [RESUBMIT][PATCH] x86/mm: Fix PAT bit missing from page protection modify mask

the result would be a WC or UC mapped memory area in userland. This isn't as problematic as the case under Xen, but it still results in worse performance than necessary. IOW: Acked-by: Juergen Gross Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: OpenPGP public key OpenPGP_signature Desc

Re: [RFC PATCH] x86/mm: Fix PAT bit missing from page protection modify mask

On 24.04.23 14:35, Janusz Krzysztofik wrote: Visible glitches have been observed when running graphics applications on Linux under Xen hypervisor. Those observations have been confirmed with failures from kms_pwrite_crc Intel GPU test that verifies data coherency of DRM frame buffer objects

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

On 16.03.23 14:53, Alex Deucher wrote: On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross wrote: On 16.03.23 14:45, Alex Deucher wrote: On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich wrote: On 16.03.2023 00:25, Stefano Stabellini wrote: On Wed, 15 Mar 2023, Jan Beulich wrote: On 15.03.2023 01

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

On 16.03.23 14:45, Alex Deucher wrote: On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich wrote: On 16.03.2023 00:25, Stefano Stabellini wrote: On Wed, 15 Mar 2023, Jan Beulich wrote: On 15.03.2023 01:52, Stefano Stabellini wrote: On Mon, 13 Mar 2023, Jan Beulich wrote: On 12.03.2023 13:01,

Re: Issue on unmap_grant_pages before releasing dmabuf

On 19.10.22 12:43, Oleksii Moisieiev wrote: Greetings. I need your advise about the problem I'm facing right now: I'm working on the new type of dmabuf export implementation. This is going to be new ioctl to the gntdev and it's purpose is to use external buffer, provided by file descriptor as

Re: i915 "GPU HANG", bisected to a2daa27c0c61 "swiotlb: simplify swiotlb_max_segment"

On 18.10.22 16:33, Christoph Hellwig wrote: On Tue, Oct 18, 2022 at 04:21:43PM +0200, Jan Beulich wrote: Leaving the "i915 abuses" part aside (because I can't tell what exactly the abuse is), but assuming that "can't cope with bounce buffering" means they don't actually use the allocated

Re: [PATCH 1/5] xen: add "not_essential" flag to struct xenbus_driver

On 22.10.21 11:28, Andrew Cooper wrote: On 22/10/2021 07:47, Juergen Gross wrote: When booting the xenbus driver will wait for PV devices to have connected to their backends before continuing. The timeout is different between essential and non-essential devices. Non-essential devices

Re: [PATCH 0/5] xen: cleanup detection of non-essential pv devices

On 22.10.21 09:24, Jan Beulich wrote: On 22.10.2021 08:47, Juergen Gross wrote: Today the non-essential pv devices are hard coded in the xenbus driver and this list is lacking multiple entries. This series reworks the detection logic of non-essential devices by adding a flag for that purpose

[PATCH 2/5] xen: flag xen_drm_front to be not essential for system boot

Similar to the virtual frame buffer (vfb) the pv display driver is not essential for booting the system. Set the respective flag. Signed-off-by: Juergen Gross --- drivers/gpu/drm/xen/xen_drm_front.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/xen/xen_drm_front.c b

[PATCH 1/5] xen: add "not_essential" flag to struct xenbus_driver

s currently regarded to be not essential (vkbs and vfb) and use it for testing in the xenbus driver. Signed-off-by: Juergen Gross --- drivers/input/misc/xen-kbdfront.c | 1 + drivers/video/fbdev/xen-fbfront.c | 1 + drivers/xen/xenbus/xenbus_probe_frontend.c | 14 +++

[PATCH 0/5] xen: cleanup detection of non-essential pv devices

Today the non-essential pv devices are hard coded in the xenbus driver and this list is lacking multiple entries. This series reworks the detection logic of non-essential devices by adding a flag for that purpose to struct xenbus_driver. Juergen Gross (5): xen: add "not_essential&

[PATCH v2] efi: avoid error message when booting under Xen

pping the FB") Signed-off-by: Juergen Gross --- drivers/video/fbdev/efifb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index 65491ae74808..e57c00824965 100644 --- a/drivers/video/fbdev/efifb.c +++ b/drivers/v

[PATCH] efi: avoid error message when booting under Xen

when mapping the FB") Signed-off-by: Juergen Gross --- drivers/video/fbdev/efifb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c index 65491ae74808..f5eccd1373e9 100644 --- a/drivers/video/fbdev/efifb.c +++ b/dri

Re: [PATCH v2 20/34] xen: convert put_page() to put_user_page*()

fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder versions"). This also handles pages[i] == NULL cases, thanks to an approach that is actually written by Juergen Gross. Signed-off-by: Juergen Gross Signed-off-by: John Hubbard Cc: Boris Ostrovsky Cc: xen-de...@lists.xenproject.o

Re: [PATCH 20/34] xen: convert put_page() to put_user_page*()

On 02.08.19 07:48, John Hubbard wrote: On 8/1/19 9:36 PM, Juergen Gross wrote: On 02.08.19 04:19, john.hubb...@gmail.com wrote: From: John Hubbard ... diff --git a/drivers/xen/privcmd.c b/drivers/xen/privcmd.c index 2f5ce7230a43..29e461dbee2d 100644 --- a/drivers/xen/privcmd.c +++ b/drivers

Re: [PATCH 20/34] xen: convert put_page() to put_user_page*()

fc1d8e7cca2d ("mm: introduce put_user_page*(), placeholder versions"). Cc: Boris Ostrovsky Cc: Juergen Gross Cc: xen-de...@lists.xenproject.org Signed-off-by: John Hubbard --- drivers/xen/gntdev.c | 5 + drivers/xen/privcmd.c | 7 +-- 2 files changed, 2 insertions(+), 10 deletion

Re: [PATCH] MAINTAINERS: unify reference to xen-devel list

-de...@lists.xen.org instead, but that is just the same > mailing list as the mailing list above. > > Signed-off-by: Lukas Bulwahn Reviewed-by: Juergen Gross Juergen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Xen-devel][PATCH 1/3] xen: Introduce shared buffer helpers for page directory...

On 29/11/2018 12:22, Oleksandr Andrushchenko wrote: > ping > > On 11/22/18 12:02 PM, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> based frontends. Currently the frontends which implement >> similar code for sharing big buffers between frontend and >> backend are

Re: [Xen-devel][PATCH 2/3] drm/xen-front: Use Xen common shared buffer implementation

On 22/11/2018 15:33, Daniel Vetter wrote: > On Thu, Nov 22, 2018 at 12:02:29PM +0200, Oleksandr Andrushchenko wrote: >> From: Oleksandr Andrushchenko >> >> Use page directory based shared buffer implementation >> now available as common code for Xen frontend drivers. >> >> Signed-off-by:

Re: [PATCH v4 0/9] xen: dma-buf support for grant device

On 02/07/18 09:10, Oleksandr Andrushchenko wrote: > Hello, Boris, Juergen! > > Do you think I can re-base the series (which already has > all required R-b's from Xen community) onto the latest kernel > with API changes to patches 5 (of_dma_configure) and 8 > (dma-buf atomic ops) and we can merge

Re: [PATCH v4 5/9] xen/gntdev: Allow mappings for DMA buffers

On 15/06/18 08:32, Oleksandr Andrushchenko wrote: > Please note, that this will need a change (attached) while > applying to the mainline kernel because of API changes [1]. > > Unfortunately, current Xen tip kernel tree is v4.17-rc5 based, > so I cannot make the change in this patch now. I don't

Re: [PATCH 2/8] xen/balloon: Move common memory reservation routines to a module

On 25/05/18 17:33, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Memory {increase|decrease}_reservation and VA mappings update/reset > code used in balloon driver can be made common, so other drivers can > also re-use the same functionality without open-coding. > Create a

Re: [PATCH 1/8] xen/grant-table: Make set/clear page private code shared

On 25/05/18 17:33, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Make set/clear page private code shared and accessible to > other kernel modules which can re-use these instead of open-coding. > > Signed-off-by: Oleksandr Andrushchenko > --- > drivers/xen/grant-table.c |

Re: [PATCH v2] drm/xen-front: fix pointer casts

rs to uintptr_t first. > > Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> Reviewed-by: Juergen Gross <jgr...@suse.com> Juergen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/xen-front: fix pointer casts

On 21/05/18 09:39, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Building for a 32-bit target results in warnings from casting > between a 32-bit pointer and a 64-bit integer. Fix the warnings > by casting those pointers to uintptr_t first.

Re: [PATCH] drm/xen-front: fix pointer casts

On 23/05/18 12:00, Oleksandr Andrushchenko wrote: > On 05/23/2018 12:19 PM, Juergen Gross wrote: >> On 21/05/18 09:39, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> >>> >>> Building for a 32-b

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 24/04/18 12:14, Oleksandr Andrushchenko wrote: > On 04/24/2018 01:01 PM, Wei Liu wrote: >> On Tue, Apr 24, 2018 at 11:08:41AM +0200, Juergen Gross wrote: >>> On 24/04/18 11:03, Oleksandr Andrushchenko wrote: >>>> On 04/24/2018 11:40 AM, Juergen Gross wrote: >

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 24/04/18 07:43, Oleksandr Andrushchenko wrote: > On 04/24/2018 01:41 AM, Boris Ostrovsky wrote: >> On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote: >>> On 04/23/2018 02:52 PM, Wei Liu wrote: On Fri, Apr 20, 2018 at 02:25:20PM +0300, Oleksandr Andrushchenko wrote: >>>  

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 24/04/18 10:07, Oleksandr Andrushchenko wrote: > On 04/24/2018 10:51 AM, Juergen Gross wrote: >> On 24/04/18 07:43, Oleksandr Andrushchenko wrote: >>> On 04/24/2018 01:41 AM, Boris Ostrovsky wrote: >>>> On 04/23/2018 08:10 AM, Oleksandr Andrushchenko wrote: >>

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 24/04/18 11:03, Oleksandr Andrushchenko wrote: > On 04/24/2018 11:40 AM, Juergen Gross wrote: >> On 24/04/18 10:07, Oleksandr Andrushchenko wrote: >>> On 04/24/2018 10:51 AM, Juergen Gross wrote: >>>> On 24/04/18 07:43, Oleksandr Andrushchenko wrote: >&

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On 24/04/18 22:35, Dongwon Kim wrote: > Had a meeting with Daniel and talked about bringing out generic > part of hyper-dmabuf to the userspace, which means we most likely > reuse IOCTLs defined in xen-zcopy for our use-case if we follow > his suggestion. > > So assuming we use these IOCTLs as

Re: [PATCH 2/9] drm/xen-front: Implement Xen bus state handling

On 21/02/18 09:03, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Initial handling for Xen bus states: implement > Xen bus state machine for the frontend driver according to > the state diagram and recovery flow from display para-virtualized

Re: [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On 21/02/18 09:03, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Introduce skeleton of the para-virtualized Xen display > frontend driver. This patch only adds required > essential stubs. > > Signed-off-by: Oleksandr Andrushchenko

Re: [PATCH 1/9] drm/xen-front: Introduce Xen para-virtualized frontend driver

On 21/02/18 09:47, Oleksandr Andrushchenko wrote: > On 02/21/2018 10:19 AM, Juergen Gross wrote: >> On 21/02/18 09:03, Oleksandr Andrushchenko wrote: >>> From: Oleksandr Andrushchenko <oleksandr_andrushche...@epam.com> >>> >>> Introduce skeleton of the

Re: [Xen-devel] [RFC PATCH 01/60] hyper_dmabuf: initial working version of hyper_dmabuf drv

On 20/12/17 00:27, Dongwon Kim wrote: > I forgot to include this brief information about this patch series. > > This patch series contains the implementation of a new device driver, > hyper_dmabuf, which provides a method for DMA-BUF sharing across > different OSes running on the same virtual OS

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On 11/05/17 23:08, Pavel Machek wrote: > On Mon 2017-01-23 10:39:27, Juergen Gross wrote: >> On 13/01/17 15:41, Juergen Gross wrote: >>> On 12/01/17 10:21, Chris Wilson wrote: >>>> On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote: >>>&

[PATCH] drm/i915: fix i915 running as dom0 under Xen

c549f5f648 ("swiotlb: Export swiotlb_max_segment to users") to i915_gem_object_get_pages_internal(). So limit the maximum page order to be used according to the maximum swiotlb segment size instead to the complete swiotlb size. Signed-off-by: Juergen Gross <jgr...@suse.com> --

Re: Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On 13/01/17 15:41, Juergen Gross wrote: > On 12/01/17 10:21, Chris Wilson wrote: >> On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote: >>> On 11/01/17 18:08, Chris Wilson wrote: >>>> On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote: >>&g

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On 12/01/17 10:21, Chris Wilson wrote: > On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote: >> On 11/01/17 18:08, Chris Wilson wrote: >>> On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote: >>>> With kernel 4.10rc3 running

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

On 11/01/17 18:08, Chris Wilson wrote: > On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote: >> With kernel 4.10rc3 running as Xen dm0 I get at each boot: >> >> [ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell >> [1431], reason: Hang on

GPU hang with kernel 4.10rc3

With kernel 4.10rc3 running as Xen dm0 I get at each boot: [ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell [1431], reason: Hang on render ring, action: reset [ 49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 49.213700]

i915 regression in kernel 4.10

On 19/12/16 13:29, Chris Wilson wrote: > On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote: >> With recent 4.10 kernel the graphics isn't coming up under Xen. First >> failure message is: >> >> [ 46.656649] i915 :00:02.0: swiotlb buffer is full (sz: 16

i915 regression in kernel 4.10

With recent 4.10 kernel the graphics isn't coming up under Xen. First failure message is: [ 46.656649] i915 :00:02.0: swiotlb buffer is full (sz: 1630208 bytes) Later I see splats like: [ 49.393583] general protection fault: [#1] SMP [ 49.403800] Modules linked in: bridge stp llc