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

2018-04-12 Thread 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. 
> 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:
>

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

2018-04-12 Thread 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.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel