From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965452AbeCABO0 (ORCPT ); Wed, 28 Feb 2018 20:14:26 -0500 Received: from mail.kernel.org ([198.145.29.99]:42626 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965379AbeCABOZ (ORCPT ); Wed, 28 Feb 2018 20:14:25 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7F61421771 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=sstabellini@kernel.org Date: Wed, 28 Feb 2018 17:14:23 -0800 (PST) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-X260 To: Oleksandr Andrushchenko cc: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, airlied@linux.ie, daniel.vetter@intel.com, seanpaul@chromium.org, gustavo@padovan.org, jgross@suse.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, Oleksandr Andrushchenko Subject: Re: [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend In-Reply-To: <1519200222-20623-1-git-send-email-andr2000@gmail.com> Message-ID: References: <1519200222-20623-1-git-send-email-andr2000@gmail.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1461234502-1519866864=:4239" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1461234502-1519866864=:4239 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hi all, just as a clarification, this patch series implements the frontend driver for the "vdispl" protocol, which was reviewed, approved and committed in xen.git back in April: https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/displif.h As Xen maintainer, if a competing PV DRM protocol proposal will come up, I'll try to steer it into evolving the existing vdispl protocol, as we like to have only one protocol per device class. I am really looking forward to having this driver upstream in Linux. Thanks Oleksandr! Cheers, Stefano On Wed, 21 Feb 2018, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Hello! > > This patch series adds support for Xen [1] para-virtualized > frontend display driver. It implements the protocol from > include/xen/interface/io/displif.h [2]. > Accompanying backend [3] is implemented as a user-space application > and its helper library [4], capable of running as a Weston client > or DRM master. > Configuration of both backend and frontend is done via > Xen guest domain configuration options [5]. > > ******************************************************************************* > * Driver limitations > ******************************************************************************* > 1. Configuration options 1.1 (contiguous display buffers) and 2 (backend > allocated buffers) below are not supported at the same time. > > 2. Only primary plane without additional properties is supported. > > 3. Only one video mode supported which resolution is configured via XenStore. > > 4. All CRTCs operate at fixed frequency of 60Hz. > > ******************************************************************************* > * Driver modes of operation in terms of display buffers used > ******************************************************************************* > Depending on the requirements for the para-virtualized environment, namely > requirements dictated by the accompanying DRM/(v)GPU drivers running in both > host and guest environments, number of operating modes of para-virtualized > display driver are supported: > - display buffers can be allocated by either frontend driver or backend > - display buffers can be allocated to be contiguous in memory or not > > Note! Frontend driver itself has no dependency on contiguous memory for > its operation. > > ******************************************************************************* > * 1. Buffers allocated by the frontend driver. > ******************************************************************************* > > The below modes of operation are configured at compile-time via > frontend driver's kernel configuration. > > 1.1. Front driver configured to use GEM CMA helpers > This use-case is useful when used with accompanying DRM/vGPU driver in > guest domain which was designed to only work with contiguous buffers, > e.g. DRM driver based on GEM CMA helpers: such drivers can only import > contiguous PRIME buffers, thus requiring frontend driver to provide > such. In order to implement this mode of operation para-virtualized > frontend driver can be configured to use GEM CMA helpers. > > 1.2. Front driver doesn't use GEM CMA > If accompanying drivers can cope with non-contiguous memory then, to > lower pressure on CMA subsystem of the kernel, driver can allocate > buffers from system memory. > > Note! If used with accompanying DRM/(v)GPU drivers this mode of operation > may require IOMMU support on the platform, so accompanying DRM/vGPU > hardware can still reach display buffer memory while importing PRIME > buffers from the frontend driver. > > ******************************************************************************* > * 2. Buffers allocated by the backend > ******************************************************************************* > > This mode of operation is run-time configured via guest domain configuration > through XenStore entries. > > For systems which do not provide IOMMU support, but having specific > requirements for display buffers it is possible to allocate such buffers > at backend side and share those with the frontend. > For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting > physically contiguous memory, this allows implementing zero-copying > use-cases. > > > I would like to thank at least, but not at last the following > people/communities who helped this driver to happen ;) > > 1. My team at EPAM for continuous support > 2. Xen community for answering tons of questions on different > modes of operation of the driver with respect to virtualized > environment. > 3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6] > 4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7] > 5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8] > > Thank you, > Oleksandr Andrushchenko > > P.S. There are two dependencies for this driver limiting some of the > use-cases which are on review now: > 1. "drm/simple_kms_helper: Add {enable|disable}_vblank callback support" [9] > 2. "drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC" [10] > > [1] https://wiki.xen.org/wiki/Paravirtualization_(PV)#PV_IO_Drivers > [2] https://elixir.bootlin.com/linux/v4.16-rc2/source/include/xen/interface/io/displif.h > [3] https://github.com/xen-troops/displ_be > [4] https://github.com/xen-troops/libxenbe > [5] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.pod.5.in;h=a699367779e2ae1212ff8f638eff0206ec1a1cc9;hb=refs/heads/master#l1257 > [6] https://lists.freedesktop.org/archives/dri-devel/2017-March/136038.html > [7] https://www.spinics.net/lists/dri-devel/msg164102.html > [8] https://www.spinics.net/lists/dri-devel/msg164463.html > [9] https://patchwork.freedesktop.org/series/38073/ > [10] https://patchwork.freedesktop.org/series/38139/ > > Oleksandr Andrushchenko (9): > drm/xen-front: Introduce Xen para-virtualized frontend driver > drm/xen-front: Implement Xen bus state handling > drm/xen-front: Read driver configuration from Xen store > drm/xen-front: Implement Xen event channel handling > drm/xen-front: Implement handling of shared display buffers > drm/xen-front: Introduce DRM/KMS virtual display driver > drm/xen-front: Implement KMS/connector handling > drm/xen-front: Implement GEM operations > drm/xen-front: Implement communication with backend > > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/xen/Kconfig | 30 ++ > drivers/gpu/drm/xen/Makefile | 17 + > drivers/gpu/drm/xen/xen_drm_front.c | 712 ++++++++++++++++++++++++++++ > drivers/gpu/drm/xen/xen_drm_front.h | 154 ++++++ > drivers/gpu/drm/xen/xen_drm_front_cfg.c | 84 ++++ > drivers/gpu/drm/xen/xen_drm_front_cfg.h | 45 ++ > drivers/gpu/drm/xen/xen_drm_front_conn.c | 125 +++++ > drivers/gpu/drm/xen/xen_drm_front_conn.h | 35 ++ > drivers/gpu/drm/xen/xen_drm_front_drv.c | 294 ++++++++++++ > drivers/gpu/drm/xen/xen_drm_front_drv.h | 73 +++ > drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 399 ++++++++++++++++ > drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 89 ++++ > drivers/gpu/drm/xen/xen_drm_front_gem.c | 360 ++++++++++++++ > drivers/gpu/drm/xen/xen_drm_front_gem.h | 46 ++ > drivers/gpu/drm/xen/xen_drm_front_gem_cma.c | 93 ++++ > drivers/gpu/drm/xen/xen_drm_front_kms.c | 299 ++++++++++++ > drivers/gpu/drm/xen/xen_drm_front_kms.h | 30 ++ > drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 430 +++++++++++++++++ > drivers/gpu/drm/xen/xen_drm_front_shbuf.h | 80 ++++ > 21 files changed, 3398 insertions(+) > create mode 100644 drivers/gpu/drm/xen/Kconfig > create mode 100644 drivers/gpu/drm/xen/Makefile > create mode 100644 drivers/gpu/drm/xen/xen_drm_front.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_cfg.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_cfg.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_drv.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_drv.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_evtchnl.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_evtchnl.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_shbuf.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_shbuf.h > > -- > 2.7.4 > --8323329-1461234502-1519866864=:4239-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend Date: Wed, 28 Feb 2018 17:14:23 -0800 (PST) Message-ID: References: <1519200222-20623-1-git-send-email-andr2000@gmail.com> Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1461234502-1519866864=:4239" Return-path: Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by gabe.freedesktop.org (Postfix) with ESMTPS id 20B286EBBE for ; Thu, 1 Mar 2018 01:14:25 +0000 (UTC) In-Reply-To: <1519200222-20623-1-git-send-email-andr2000@gmail.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Oleksandr Andrushchenko Cc: jgross@suse.com, konrad.wilk@oracle.com, airlied@linux.ie, Oleksandr Andrushchenko , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, daniel.vetter@intel.com, xen-devel@lists.xenproject.org, boris.ostrovsky@oracle.com List-Id: dri-devel@lists.freedesktop.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1461234502-1519866864=:4239 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hi all, just as a clarification, this patch series implements the frontend driver for the "vdispl" protocol, which was reviewed, approved and committed in xen.git back in April: https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/displif.h As Xen maintainer, if a competing PV DRM protocol proposal will come up, I'll try to steer it into evolving the existing vdispl protocol, as we like to have only one protocol per device class. I am really looking forward to having this driver upstream in Linux. Thanks Oleksandr! Cheers, Stefano On Wed, 21 Feb 2018, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Hello! > > This patch series adds support for Xen [1] para-virtualized > frontend display driver. It implements the protocol from > include/xen/interface/io/displif.h [2]. > Accompanying backend [3] is implemented as a user-space application > and its helper library [4], capable of running as a Weston client > or DRM master. > Configuration of both backend and frontend is done via > Xen guest domain configuration options [5]. > > ******************************************************************************* > * Driver limitations > ******************************************************************************* > 1. Configuration options 1.1 (contiguous display buffers) and 2 (backend > allocated buffers) below are not supported at the same time. > > 2. Only primary plane without additional properties is supported. > > 3. Only one video mode supported which resolution is configured via XenStore. > > 4. All CRTCs operate at fixed frequency of 60Hz. > > ******************************************************************************* > * Driver modes of operation in terms of display buffers used > ******************************************************************************* > Depending on the requirements for the para-virtualized environment, namely > requirements dictated by the accompanying DRM/(v)GPU drivers running in both > host and guest environments, number of operating modes of para-virtualized > display driver are supported: > - display buffers can be allocated by either frontend driver or backend > - display buffers can be allocated to be contiguous in memory or not > > Note! Frontend driver itself has no dependency on contiguous memory for > its operation. > > ******************************************************************************* > * 1. Buffers allocated by the frontend driver. > ******************************************************************************* > > The below modes of operation are configured at compile-time via > frontend driver's kernel configuration. > > 1.1. Front driver configured to use GEM CMA helpers > This use-case is useful when used with accompanying DRM/vGPU driver in > guest domain which was designed to only work with contiguous buffers, > e.g. DRM driver based on GEM CMA helpers: such drivers can only import > contiguous PRIME buffers, thus requiring frontend driver to provide > such. In order to implement this mode of operation para-virtualized > frontend driver can be configured to use GEM CMA helpers. > > 1.2. Front driver doesn't use GEM CMA > If accompanying drivers can cope with non-contiguous memory then, to > lower pressure on CMA subsystem of the kernel, driver can allocate > buffers from system memory. > > Note! If used with accompanying DRM/(v)GPU drivers this mode of operation > may require IOMMU support on the platform, so accompanying DRM/vGPU > hardware can still reach display buffer memory while importing PRIME > buffers from the frontend driver. > > ******************************************************************************* > * 2. Buffers allocated by the backend > ******************************************************************************* > > This mode of operation is run-time configured via guest domain configuration > through XenStore entries. > > For systems which do not provide IOMMU support, but having specific > requirements for display buffers it is possible to allocate such buffers > at backend side and share those with the frontend. > For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting > physically contiguous memory, this allows implementing zero-copying > use-cases. > > > I would like to thank at least, but not at last the following > people/communities who helped this driver to happen ;) > > 1. My team at EPAM for continuous support > 2. Xen community for answering tons of questions on different > modes of operation of the driver with respect to virtualized > environment. > 3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6] > 4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7] > 5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8] > > Thank you, > Oleksandr Andrushchenko > > P.S. There are two dependencies for this driver limiting some of the > use-cases which are on review now: > 1. "drm/simple_kms_helper: Add {enable|disable}_vblank callback support" [9] > 2. "drm/simple_kms_helper: Fix NULL pointer dereference with no active CRTC" [10] > > [1] https://wiki.xen.org/wiki/Paravirtualization_(PV)#PV_IO_Drivers > [2] https://elixir.bootlin.com/linux/v4.16-rc2/source/include/xen/interface/io/displif.h > [3] https://github.com/xen-troops/displ_be > [4] https://github.com/xen-troops/libxenbe > [5] https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/man/xl.cfg.pod.5.in;h=a699367779e2ae1212ff8f638eff0206ec1a1cc9;hb=refs/heads/master#l1257 > [6] https://lists.freedesktop.org/archives/dri-devel/2017-March/136038.html > [7] https://www.spinics.net/lists/dri-devel/msg164102.html > [8] https://www.spinics.net/lists/dri-devel/msg164463.html > [9] https://patchwork.freedesktop.org/series/38073/ > [10] https://patchwork.freedesktop.org/series/38139/ > > Oleksandr Andrushchenko (9): > drm/xen-front: Introduce Xen para-virtualized frontend driver > drm/xen-front: Implement Xen bus state handling > drm/xen-front: Read driver configuration from Xen store > drm/xen-front: Implement Xen event channel handling > drm/xen-front: Implement handling of shared display buffers > drm/xen-front: Introduce DRM/KMS virtual display driver > drm/xen-front: Implement KMS/connector handling > drm/xen-front: Implement GEM operations > drm/xen-front: Implement communication with backend > > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/xen/Kconfig | 30 ++ > drivers/gpu/drm/xen/Makefile | 17 + > drivers/gpu/drm/xen/xen_drm_front.c | 712 ++++++++++++++++++++++++++++ > drivers/gpu/drm/xen/xen_drm_front.h | 154 ++++++ > drivers/gpu/drm/xen/xen_drm_front_cfg.c | 84 ++++ > drivers/gpu/drm/xen/xen_drm_front_cfg.h | 45 ++ > drivers/gpu/drm/xen/xen_drm_front_conn.c | 125 +++++ > drivers/gpu/drm/xen/xen_drm_front_conn.h | 35 ++ > drivers/gpu/drm/xen/xen_drm_front_drv.c | 294 ++++++++++++ > drivers/gpu/drm/xen/xen_drm_front_drv.h | 73 +++ > drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 399 ++++++++++++++++ > drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 89 ++++ > drivers/gpu/drm/xen/xen_drm_front_gem.c | 360 ++++++++++++++ > drivers/gpu/drm/xen/xen_drm_front_gem.h | 46 ++ > drivers/gpu/drm/xen/xen_drm_front_gem_cma.c | 93 ++++ > drivers/gpu/drm/xen/xen_drm_front_kms.c | 299 ++++++++++++ > drivers/gpu/drm/xen/xen_drm_front_kms.h | 30 ++ > drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 430 +++++++++++++++++ > drivers/gpu/drm/xen/xen_drm_front_shbuf.h | 80 ++++ > 21 files changed, 3398 insertions(+) > create mode 100644 drivers/gpu/drm/xen/Kconfig > create mode 100644 drivers/gpu/drm/xen/Makefile > create mode 100644 drivers/gpu/drm/xen/xen_drm_front.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_cfg.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_cfg.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_conn.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_drv.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_drv.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_evtchnl.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_evtchnl.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_gem_cma.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_kms.h > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_shbuf.c > create mode 100644 drivers/gpu/drm/xen/xen_drm_front_shbuf.h > > -- > 2.7.4 > --8323329-1461234502-1519866864=:4239 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --8323329-1461234502-1519866864=:4239--