Re: [PATCH 0/9] drm/xen-front: Add support for Xen PV display frontend

From: Stefano Stabellini <sstabellini@kernel.org>
To: Oleksandr Andrushchenko <andr2000@gmail.com>
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 <oleksandr_andrushchenko@epam.com>
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)	[thread overview]
Message-ID: <alpine.DEB.2.10.1802281708480.4239@sstabellini-ThinkPad-X260> (raw)
In-Reply-To: <1519200222-20623-1-git-send-email-andr2000@gmail.com>

[-- Attachment #1: Type: TEXT/PLAIN, Size: 9056 bytes --]

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 <oleksandr_andrushchenko@epam.com>
> 
> 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
> 