[Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend
Peng Fan
peng.fan at nxp.com
Thu Apr 12 02:21:55 UTC 2018
Hi Oleksandr,
Just have a question, is this drm/xen-front stuff orthogonal to xen shared
coprocessor framework for gpu, or are they exclusive?
Thanks,
Peng.
> Subject: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV
> display frontend
>
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko at epam.com>
>
> Hello!
>
> Boris/Daniel, I put your R-b tags, so please do let me know if this is not
> acceptable, so I remove the tags.
>
> 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]
>
> Changes since v5:
> ****************************************************************
> ***************
> - fixed most of scripts/checkpatch.pl warnings
>
> Changes since v4:
> ****************************************************************
> ***************
> - updated the driver after "drm/simple-kms-helper: Plumb plane state
> to the enable hook" [14]
> - made display_mode_valid static
> - fixed page leak on event channel error path
> - changed title of the documentation to match the rest of the drivers
> - removed from the series the patch from Noralf Trønnes [12] as it was sent out
> as a standalone one
>
> Changes since v3:
> ****************************************************************
> ***************
> - no changes to Xen related code (shared buffer handling, event channels etc.),
> but minor changes to xenbus_driver state machine due to re-worked unplug
> implementation: additional state checks added
> - re-worked dumb creation code to fix race condition (drm_gem_handle_create)
> - use drm_dev_{enter|exit} to protect code which must not run when unplugged
> - re-work unplug code to fully support "zombie" DRM devices on backend
> disconnect
> - implement a dedicated page flip time-out worker, remove logic from connector
> detect callback
> - move mode_valid from drm_connector_helper_funcs to
> drm_simple_display_pipe_funcs
> - use drm_gem_object_put_unlocked instead of obsolete
> drm_gem_object_unreference_unlocked
> - minor cleanups
>
> Changes since v2:
> ****************************************************************
> ***************
> - no changes to Xen related code (shared buffer handling, event channels etc.)
> - rework DRM driver release with hotplug (Daniel)
> - squash xen_drm_front and xen_drm_front_drv as they depend on each
> other too heavily now
> - remove platform driver and instantiate DRM device
> from xenbus driver directly
> - have serializing mutex per connector, not a single one,
> so we don't introduce a bottle neck for multiple connectors
> - minor comments addressed (Daniel)
>
> Changes since v1:
> ****************************************************************
> ***************
> - use SPDX license identifier, set license to GPLv2 OR MIT
> - changed midlayers to direct function calls, removed:
> - front_ops
> - gem_ops
> - renamed xenbus_driver callbacks to align with exisitng PV drivers
> - re-worked backend error handling with connector hotplug uevents
> - removed vblank handling so user-space doesn't have an impression
> we really support that
> - directly use front's mode_set in display enable/disable
> - removed BUG_ON, error handling implemented
> - moved driver documentation into Documentation/gpu
> - other comments from Xen community addressed (Boris and Juergen)
> - squashed Xen and DRM patches for better interrconnection visibility
> - for your convenience driver is available at [11]
>
> Thank you,
> Oleksandr Andrushchenko
>
> [1]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.xe
> n.org%2Fwiki%2FParavirtualization_(PV)%23PV_IO_Drivers&data=02%7C01%7
> Cpeng.fan%40nxp.com%7C491c555fd11142b0b81d08d5993d07bd%7C686ea1d
> 3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C636583409853555702&sdata=kYlS
> H60OQxnE0JVYYfMLSDswZ48%2FsJCTCJTeIshsa%2Bo%3D&reserved=0
> [2]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felixir.b
> ootlin.com%2Flinux%2Fv4.16-rc2%2Fsource%2Finclude%2Fxen%2Finterface%2F
> io%2Fdisplif.h&data=02%7C01%7Cpeng.fan%40nxp.com%7C491c555fd11142b0
> b81d08d5993d07bd%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C6
> 36583409853555702&sdata=UPRuN9ZLYaB6cWx%2B485viTv1KetOu5mr6VsAa
> nhB7ww%3D&reserved=0
> [3]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fxen-troops%2Fdispl_be&data=02%7C01%7Cpeng.fan%40nxp.com%7C4
> 91c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C1%7C636583409853555702&sdata=TuxkfTq5mJMD394E0dV78sUBrf
> NxUaFNCpyIB26zC0c%3D&reserved=0
> [4]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fxen-troops%2Flibxenbe&data=02%7C01%7Cpeng.fan%40nxp.com%7C4
> 91c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C1%7C636583409853555702&sdata=2jiqzZwcT7CXOW07YTGPZ9DDlL
> sarOKeCneUeeZ3npw%3D&reserved=0
> [5]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fxenbits
> .xen.org%2Fgitweb%2F%3Fp%3Dxen.git%3Ba%3Dblob%3Bf%3Ddocs%2Fman%
> 2Fxl.cfg.pod.5.in%3Bh%3Da699367779e2ae1212ff8f638eff0206ec1a1cc9%3Bh
> b%3Drefs%2Fheads%2Fmaster%23l1257&data=02%7C01%7Cpeng.fan%40nxp.
> com%7C491c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c6fa92cd99
> c5c301635%7C0%7C1%7C636583409853555702&sdata=wL00UQDV89%2B5rrV
> 8yQZ8rskE8wy37rymIaWbfjdIMIQ%3D&reserved=0
> [6]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fre
> edesktop.org%2Farchives%2Fdri-devel%2F2017-March%2F136038.html&data=
> 02%7C01%7Cpeng.fan%40nxp.com%7C491c555fd11142b0b81d08d5993d07bd
> %7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63658340985355570
> 2&sdata=%2BgTfS2Zo4nwBIv590wyoxBOyQ%2F3rc9DOsYsEP7MSquU%3D&res
> erved=0
> [7]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.s
> pinics.net%2Flists%2Fdri-devel%2Fmsg164102.html&data=02%7C01%7Cpeng.fa
> n%40nxp.com%7C491c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c
> 6fa92cd99c5c301635%7C0%7C1%7C636583409853555702&sdata=qDRZz7S6D
> zV0XxWtI57Hv9X08%2FTEc6XB7z82bdnkkaE%3D&reserved=0
> [8]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.s
> pinics.net%2Flists%2Fdri-devel%2Fmsg164463.html&data=02%7C01%7Cpeng.fa
> n%40nxp.com%7C491c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c
> 6fa92cd99c5c301635%7C0%7C1%7C636583409853555702&sdata=tyIcJNSgrJF0
> Wx%2B0OES3qUIxJIxmkkqRzMQLwCARGao%3D&reserved=0
> [9]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.freedesktop.org%2Fseries%2F38073%2F&data=02%7C01%7Cpeng.fan%40
> nxp.com%7C491c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c6fa92
> cd99c5c301635%7C0%7C1%7C636583409853555702&sdata=M%2BbMg%2BM
> RimzNrhsjkTjt%2B2qv9WyGGbOkA7rFv7fsDuU%3D&reserved=0
> [10]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.freedesktop.org%2Fseries%2F38139%2F&data=02%7C01%7Cpeng.fan%40
> nxp.com%7C491c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c6fa92
> cd99c5c301635%7C0%7C1%7C636583409853555702&sdata=MzVUZgSRFDksI5
> gol9txf%2FkKy3SRgtQDR6oppPg%2BHDA%3D&reserved=0
> [11]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.
> com%2Fandr2000%2Flinux%2Fcommits%2Fdrm_tip_pv_drm_v2&data=02%7C0
> 1%7Cpeng.fan%40nxp.com%7C491c555fd11142b0b81d08d5993d07bd%7C686e
> a1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636583409853555702&sdata=
> IfUfMOcEoRJuW7YrzzgMcCp34jIwwxEVxndfVM8ALBU%3D&reserved=0
> [12]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.freedesktop.org%2Fpatch%2F175779%2F&data=02%7C01%7Cpeng.fan%4
> 0nxp.com%7C491c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c6fa9
> 2cd99c5c301635%7C0%7C0%7C636583409853555702&sdata=9ketFmRDsilVTQ
> CeRwCMXJABL9l6aaIQF8tY9dFFhI0%3D&reserved=0
> [13]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.s
> pinics.net%2Flists%2Fdri-devel%2Fmsg170453.html&data=02%7C01%7Cpeng.fa
> n%40nxp.com%7C491c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c
> 6fa92cd99c5c301635%7C0%7C0%7C636583409853555702&sdata=FCcWcL20k
> 4gn5hRMjpy6hjYs%2B%2FeKDNTKhcMq2N%2FBHOk%3D&reserved=0
> [14]
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatch
> work.freedesktop.org%2Fpatch%2F212321%2F&data=02%7C01%7Cpeng.fan%4
> 0nxp.com%7C491c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c6fa9
> 2cd99c5c301635%7C0%7C0%7C636583409853555702&sdata=WVa04Dos0bRI
> Q%2BdpDsngeXeH4tGfKozvSbyWhiCa2R4%3D&reserved=0
>
> Oleksandr Andrushchenko (1):
> drm/xen-front: Add support for Xen PV display frontend
>
> Documentation/gpu/drivers.rst | 1 +
> Documentation/gpu/xen-front.rst | 43 ++
> drivers/gpu/drm/Kconfig | 2 +
> drivers/gpu/drm/Makefile | 1 +
> drivers/gpu/drm/xen/Kconfig | 30 +
> drivers/gpu/drm/xen/Makefile | 16 +
> drivers/gpu/drm/xen/xen_drm_front.c | 882
> ++++++++++++++++++++++++++++
> drivers/gpu/drm/xen/xen_drm_front.h | 188 ++++++
> drivers/gpu/drm/xen/xen_drm_front_cfg.c | 77 +++
> drivers/gpu/drm/xen/xen_drm_front_cfg.h | 37 ++
> drivers/gpu/drm/xen/xen_drm_front_conn.c | 115 ++++
> drivers/gpu/drm/xen/xen_drm_front_conn.h | 27 +
> drivers/gpu/drm/xen/xen_drm_front_evtchnl.c | 386 ++++++++++++
> drivers/gpu/drm/xen/xen_drm_front_evtchnl.h | 81 +++
> drivers/gpu/drm/xen/xen_drm_front_gem.c | 311 ++++++++++
> drivers/gpu/drm/xen/xen_drm_front_gem.h | 41 ++
> drivers/gpu/drm/xen/xen_drm_front_gem_cma.c | 77 +++
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 370 ++++++++++++
> drivers/gpu/drm/xen/xen_drm_front_kms.h | 26 +
> drivers/gpu/drm/xen/xen_drm_front_shbuf.c | 432 ++++++++++++++
> drivers/gpu/drm/xen/xen_drm_front_shbuf.h | 72 +++
> 21 files changed, 3215 insertions(+)
> create mode 100644 Documentation/gpu/xen-front.rst 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_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.16.2
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xenproject.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.xe
> nproject.org%2Fmailman%2Flistinfo%2Fxen-devel&data=02%7C01%7Cpeng.fan
> %40nxp.com%7C491c555fd11142b0b81d08d5993d07bd%7C686ea1d3bc2b4c6f
> a92cd99c5c301635%7C0%7C0%7C636583409853555702&sdata=EhVL5bx3fsV9
> D2n6Rix%2Bcckcwp0atrgoHc%2B1heQ5HKc%3D&reserved=0
More information about the dri-devel
mailing list