RE: [Xen-devel] [PATCH v6 0/1] drm/xen-front: Add support for Xen PV display frontend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx>
> 
> 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@xxxxxxxxxxxxxxxxxxxx
> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux