| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <alpine.DEB.2.10.1802281708480.4239@sstabellini-ThinkPad-X260>
Date: Wed, 28 Feb 2018 17:14:23 -0800 (PST)
From: Stefano Stabellini <sstabellini@...nel.org>
To: Oleksandr Andrushchenko <andr2000@...il.com>
cc: xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, airlied@...ux.ie,
daniel.vetter@...el.com, seanpaul@...omium.org,
gustavo@...ovan.org, jgross@...e.com, boris.ostrovsky@...cle.com,
konrad.wilk@...cle.com,
Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
Subject: Re: [PATCH 0/9] drm/xen-front: Add support for Xen PV display
frontend
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@...m.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
>
Powered by blists - more mailing lists