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

[Oleksandr Andrushchenko]

Hi, Peng!

On 04/12/2018 05:21 AM, Peng Fan wrote:

Hi Oleksandr,

Just have a question, is this drm/xen-front stuff orthogonal to xen shared
coprocessor framework for gpu, or are they exclusive?

They are orthogonal

Thanks,
Peng.

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

[Oleksandr Andrushchenko]

Hi, Peng!

On 04/12/2018 05:21 AM, Peng Fan wrote:

Hi Oleksandr,

Just have a question, is this drm/xen-front stuff orthogonal to xen shared
coprocessor framework for gpu, or are they exclusive?

They are orthogonal

Thanks,
Peng.

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

[Peng Fan]

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_andrushche...@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. 
>

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

[Peng Fan]

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 
> 
> 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. 
> Maart

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

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

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 

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

[Oleksandr Andrushchenko]

From: Oleksandr Andrushchenko 

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