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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 7 Apr 2017 13:31:57 +0200
From:   Juergen Gross <jgross@...e.com>
To:     Oleksandr Andrushchenko <andr2000@...il.com>,
        xen-devel@...ts.xenproject.org
Cc:     lars.kurth@...rix.com, sstabellini@...nel.org,
        vlad.babchuk@...il.com, linux-kernel@...r.kernel.org,
        Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>,
        julien.grall@....com, andrii.anisov@...il.com, olekstysh@...il.com,
        al1img@...il.com, Oleksandr Grytsov <oleksandr_grytsov@...m.com>,
        joculator@...il.com, Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] [For Linux 4/4] xen/displif: add ABI for para-virtual
 display

On 07/04/17 10:30, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.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@...cle.com>
> Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@...m.com>
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>

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


Juergen