Re: [Xen-devel] [For Linux 4/4] xen/displif: add ABI for para-virtual display

[Juergen Gross <jgross@suse.com>]

On 07/04/17 10:30, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> 
> This is the ABI for the two halves of a para-virtualized
> display driver.
> 
> This protocol aims to provide a unified protocol which fits more
> sophisticated use-cases than a framebuffer device can handle. At the
> moment basic functionality is supported with the intention to extend:
>   o multiple dynamically allocated/destroyed framebuffers
>   o buffers of arbitrary sizes
>   o better configuration options including multiple display support
> 
> Note: existing fbif can be used together with displif running at the
> same time, e.g. on Linux one provides framebuffer and another DRM/KMS
> 
> Future extensions to the existing protocol may include:
>   o allow display/connector cloning
>   o allow allocating objects other than display buffers
>   o add planes/overlays support
>   o support scaling
>   o support rotation
> 
> Note, that this protocol doesn't use ring macros for
> bi-directional exchange (PV calls/9pfs) bacause:
>   o it statically defines the use of a single page
>     for the ring buffer
>   o it uses direct memory access to ring's contents
>     w/o memory copying
>   o re-uses the same idea that kbdif/fbif use
>     which for this use-case seems to be appropriate
> 
> ==================================================
> Rationale for introducing this protocol instead of
> using the existing fbif:
> ==================================================
> 
> 1. In/out event sizes
>   o fbif - 40 octets
>   o displif - 40 octets
> This is only the initial version of the displif protocol
> which means that there could be requests which will not fit
> (WRT introducing some GPU related functionality
> later on). In that case we cannot alter fbif sizes as we need to
> be backward compatible an will be forced to handle those
> apart of fbif.
> 
> 2. Shared page
> Displif doesn't use anything like struct xenfb_page, but
> DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct
> xendispl_resp) which is a better and more common way.
> Output events use a shared page which only has in_cons and in_prod
> and all the rest is used for incoming events. Here struct xenfb_page
> could probably be used as is despite the fact that it only has a half
> of a page for incoming events which is only 50 events. (consider
> something like 60Hz display)
> 
> 3. Amount of changes.
> fbif only provides XENFB_TYPE_UPDATE and XENFB_TYPE_RESIZE
> events, so it looks like it is easier to get fb support into displif
> than vice versa. displif at the moment has 6 requests and 1 event,
> multiple connector support, etc.
> 
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

Acked-by: Juergen Gross <jgross@suse.com>


Juergen