From patchwork Wed Apr 5 06:11:43 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Oleksandr Andrushchenko X-Patchwork-Id: 9663001 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id A30A960352 for ; Wed, 5 Apr 2017 06:14:04 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 913962843F for ; Wed, 5 Apr 2017 06:14:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 83F50284D5; Wed, 5 Apr 2017 06:14:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 9E0F12843F for ; Wed, 5 Apr 2017 06:14:03 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cveAW-0000RJ-4H; Wed, 05 Apr 2017 06:11:48 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cveAV-0000R8-8h for xen-devel@lists.xenproject.org; Wed, 05 Apr 2017 06:11:47 +0000 Received: from [85.158.143.35] by server-11.bemta-6.messagelabs.com id FB/C1-03642-2AA84E85; Wed, 05 Apr 2017 06:11:46 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFKsWRWlGSWpSXmKPExsVyMfS6i+7Cric RBgs3yVp83zKZyYHR4/CHKywBjFGsmXlJ+RUJrBkPN2xhLnjkW3Gg7z1rA2OHXRcjF4eQwFRG iennmplBHBaBblaJB3/eMoE4EgLLWSX+nVjO2MXICeTESCyY3McKYZdKTHvexQRiCwkoSnx9N p0JYtQ0JomGo8fZQRLCAq4Siye/YAaxRQSUJO6tmgzV4CRxa2kvO0gDs8BnRon3Dx6DFbEJGE ksv/GDBcTmFbCRmHV+F5jNIqAisfjhe7DNogLhEm8bj0DVCEqcnPkEzOYUcJY42HYDbAGzgL/ E2cPPWSYwCs1CUjYLSQrCtpW4M3c3M4QtL7H97Rwo21ji89wVTJjiNhJHprYyLWBkX8WoUZxa VJZapGtorpdUlJmeUZKbmJmja2hgppebWlycmJ6ak5hUrJecn7uJERg3DECwg/H2xoBDjJIcT EqivAo+TyKE+JLyUyozEosz4otKc1KLDzHKcHAoSfDWdQLlBItS01Mr0jJzgBEMk5bg4FES4T UHSfMWFyTmFmemQ6ROMVpyPDi16w0Tx5zZu4Hkp/7Db5iEWPLy81KlxHlXgTQIgDRklObBjYM lmUuMslLCvIxABwrxFKQW5WaWoMq/YhTnYFQS5t0AMoUnM68EbusroIOYgA56cuchyEEliQgp qQZG5p3hUaVn9J4feJZ2qe+NnpLHH0t16yc7y5e1i9tNVdyqq3XZauPWvtWM+06yty3Smf/0g 7DhyuppJXcOnGSJ1riXdifpxPkNqZZfFtvlPn7W5cM1R0L7psvtlfVKGes/rLRV/DD//55816 9x/AvEa2bOiThSsv98q2Sgo0D8/YVa9pZH+sp4lFiKMxINtZiLihMB7HoAJC0DAAA= X-Env-Sender: andr2000@gmail.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1491372705!58717166!1 X-Originating-IP: [209.85.215.68] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16896 invoked from network); 5 Apr 2017 06:11:45 -0000 Received: from mail-lf0-f68.google.com (HELO mail-lf0-f68.google.com) (209.85.215.68) by server-3.tower-21.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 5 Apr 2017 06:11:45 -0000 Received: by mail-lf0-f68.google.com with SMTP id v2so292595lfi.2 for ; Tue, 04 Apr 2017 23:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=i9nq+LAFF9DH92hG8V6Mhp6WQ0zHUa584AsyPnYS3Bs=; b=IvD+luAasLKEOgLslovOKOaAzBn+rvRTHgAK+8sgBCmRhXaZ9ZuXBXEQgJpa6l1Eif v79NVlQUH43XsCdIArP8OtON5OiwN653QLyJQQM5ZcmOd2Pw3IqKXZ2thJPl4XzxAMGX PSDZkfqdnqDUaNIXcIJrC9xcFELfPa1Qr+3IOaZl7/5GnbRP6GYnxi/7pvZZnvg9n+b/ 10noBe0C9OhMMFMZkCZl9G+djeQdDoxRRgNxxjI72uey6JXG8GXgZhdSmz1IoBcMIg5w vgMiz5KFNES6gLvYS8wifoZCvgvNFBi1uA5rrUaStP5s3mywjBlN0UERS4AjgZKgiySn QEdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=i9nq+LAFF9DH92hG8V6Mhp6WQ0zHUa584AsyPnYS3Bs=; b=jgO0p71rzfZWwZdR/yOkzJAtQWmmnZT/5K6fIuggtZxZ5sa9rPksYQi2YoAZRUPhNM hZyFbq1+qwBH7csc0O7yJFpD4c3IHPjuY+kqc29Kn9D3aKQi6CCHMOABga5jD7Xhm9AH 7nOO2U0hPMBkjeoUnQ+cbuZ+oXZpC1JhlHuSIn9Kwb8ybi6tOi21d/uix0p79+JRB/ZE +0uzyk7DYUyzFBO7N25xGBhWtpB+0miHsDSM8yBgKwx0jVYbuq7U4rNjf1qd9ATupJzd SKGKt5JRrLa98EW5OWvuKmbGQ6r0j1uQeZLPlDQlXDHsQrwpQo8ICOHOumIkf4pULv8M HXbQ== X-Gm-Message-State: AFeK/H11uXk/IG6S4kYHv4jhaqu3y4+8z7znhU2KroSEh3xprXDtD88R01qRz4dzpKWawg== X-Received: by 10.46.32.4 with SMTP id g4mr8169779ljg.18.1491372704770; Tue, 04 Apr 2017 23:11:44 -0700 (PDT) Received: from [10.17.182.9] (ll-74.141.223.85.sovam.net.ua. [85.223.141.74]) by smtp.gmail.com with ESMTPSA id v30sm3506066ljd.65.2017.04.04.23.11.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 23:11:44 -0700 (PDT) To: xen-devel@lists.xenproject.org References: <1491372547-10236-1-git-send-email-andr2000@gmail.com> From: Oleksandr Andrushchenko Message-ID: <5d9fcc61-c7f6-1f06-f69c-3bdaa14d6881@gmail.com> Date: Wed, 5 Apr 2017 09:11:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1491372547-10236-1-git-send-email-andr2000@gmail.com> Cc: lars.kurth@citrix.com, vlad.babchuk@gmail.com, Oleksandr Andrushchenko , julien.grall@arm.com, andrii.anisov@gmail.com, olekstysh@gmail.com, al1img@gmail.com, joculator@gmail.com Subject: Re: [Xen-devel] [PATCH v5] xen/displif: add ABI for para-virtual display X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP For your convenience, PFA diff between v4..v5 Thank you, Oleksandr On 04/05/2017 09:09 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > 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 > > Thank you, > Oleksandr Andrushchenko > Oleksandr Grytsov > > Oleksandr Andrushchenko (1): > displif: add ABI for para-virtual display > > xen/include/public/io/displif.h | 864 ++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 864 insertions(+) > create mode 100644 xen/include/public/io/displif.h > diff --git a/xen/include/public/io/displif.h b/xen/include/public/io/displif.h index ac55c4fe8bbe..8a94f1f9b9d0 100644 --- a/xen/include/public/io/displif.h +++ b/xen/include/public/io/displif.h @@ -35,6 +35,13 @@ /* ****************************************************************************** + * Protocol version + ****************************************************************************** + */ +#define XENDISPL_PROTOCOL_VERSION "1" + +/* + ****************************************************************************** * Main features provided by the protocol ****************************************************************************** * This protocol aims to provide a unified protocol which fits more @@ -111,7 +118,7 @@ * /local/domain/1/device/vdispl/0/backend = "/local/domain/0/backend/vdispl/1/0" * /local/domain/1/device/vdispl/0/state = "4" * /local/domain/1/device/vdispl/0/version = "1" - * /local/domain/1/device/vdispl/0/be_alloc = "1" + * /local/domain/1/device/vdispl/0/be-alloc = "1" * *-------------------------- Connector 0 configuration ------------------------ * @@ -172,7 +179,7 @@ * *------------------------- Backend buffer allocation ------------------------- * - * be_alloc + * be-alloc * Values: "0", "1" * * If value is set to "1", then backend can be a buffer provider/allocator @@ -205,7 +212,7 @@ * Values: * * The Xen grant reference granting permission for the backend to map - * a sole page in a single page sized connector's control ring buffer. + * a sole page of connector's control ring buffer. * *------------------- Connector Event Transport Parameters -------------------- * @@ -222,7 +229,7 @@ * Values: * * The Xen grant reference granting permission for the backend to map - * a sole page in a single page sized connector's event ring buffer. + * a sole page of connector's event ring buffer. */ /* @@ -295,7 +302,7 @@ * then frontend goes into the XenbusStateInitialising state and is ready for * new connection with backend. If the virtualized device is still in use and * cannot be removed, then frontend goes into the XenbusStateReconfiguring state - * until either the virtualized device removed or backend initiates a new + * until either the virtualized device is removed or backend initiates a new * connection. On the virtualized device removal frontend goes into the * XenbusStateInitialising state. * @@ -304,7 +311,7 @@ * and thus cannot provide functionality of the virtualized device anymore. * After backend is back to normal the virtualized device may still hold some * state: configuration in use, allocated buffers, client application state etc. - * So, in most cases, this will require frontend to implement complex recovery + * In most cases, this will require frontend to implement complex recovery * reconnect logic. Instead, by going into XenbusStateReconfiguring state, * frontend will make sure no new clients of the virtualized device are * accepted, allow existing client(s) to exit gracefully by signaling error @@ -360,7 +367,7 @@ #define XENDISPL_FIELD_EVT_RING_REF "evt-ring-ref" #define XENDISPL_FIELD_EVT_CHANNEL "evt-event-channel" #define XENDISPL_FIELD_RESOLUTION "resolution" -#define XENDISPL_FIELD_BE_ALLOC "be_alloc" +#define XENDISPL_FIELD_BE_ALLOC "be-alloc" /* ****************************************************************************** @@ -387,8 +394,8 @@ * Shared page contains a ring with request/response packets. * * All reserved fields in the structures below must be 0. - * Display buffers's cookie of value 0 treated as invalid. - * Framebuffer's cookie of value 0 treated as invalid. + * Display buffers's cookie of value 0 is treated as invalid. + * Framebuffer's cookie of value 0 is treated as invalid. * * For all request/response/event packets that use cookies: * dbuf_cookie - uint64_t, unique to guest domain value used by the backend @@ -399,7 +406,8 @@ *---------------------------------- Requests --------------------------------- * * All requests/responses, which are not connector specific, must be sent over - * control ring of the connector with index 0. + * control ring of the connector which has the index value of 0: + * /local/domain//device/vdispl//0/req-ring-ref * * All request packets have the same length (64 octets) * All request packets have common header: @@ -442,7 +450,9 @@ * | reserved | 64 * +----------------+----------------+----------------+----------------+ * - * Must be sent over control ring of the connector with index 0. + * Must be sent over control ring of the connector which has the index + * value of 0: + * /local/domain//device/vdispl//0/req-ring-ref * All unused bits in flags field must be set to 0. * * An attempt to create multiple display buffers with the same dbuf_cookie is @@ -464,12 +474,13 @@ * Frontend on request: * o allocates pages for the directory (gref_directory, * gref_dir_next_page(s) - * o grants permissions for the pages of the directory + * o grants permissions for the pages of the directory to the backend * o sets gref_dir_next_page fields * Backend on response: - * o grants permissions for the pages of the buffer allocated + * o grants permissions for the pages of the buffer allocated to + * the frontend * o fills in page directory with grant references - * (gref[] in struct xendispl_page_directorygref) + * (gref[] in struct xendispl_page_directory) * gref_directory - grant_ref_t, a reference to the first shared page * describing shared buffer references. At least one page exists. If shared * buffer size (buffer_sz) exceeds what can be addressed by this single page, @@ -543,7 +554,9 @@ struct xendispl_page_directory { * | reserved | 64 * +----------------+----------------+----------------+----------------+ * - * Must be sent over control ring of the connector with index 0. + * Must be sent over control ring of the connector which has the index + * value of 0: + * /local/domain//device/vdispl//0/req-ring-ref */ struct xendispl_dbuf_destroy_req { @@ -580,7 +593,9 @@ struct xendispl_dbuf_destroy_req { * | reserved | 64 * +----------------+----------------+----------------+----------------+ * - * Must be sent over control ring of the connector with index 0. + * Must be sent over control ring of the connector which has the index + * value of 0: + * /local/domain//device/vdispl//0/req-ring-ref * Width and height can be smaller, equal or bigger than the connector's * resolution. * @@ -621,7 +636,9 @@ struct xendispl_fb_attach_req { * | reserved | 64 * +----------------+----------------+----------------+----------------+ * - * Must be sent over control ring of the connector with index 0. + * Must be sent over control ring of the connector which has the index + * value of 0: + * /local/domain//device/vdispl//0/req-ring-ref */ struct xendispl_fb_detach_req { @@ -809,7 +826,7 @@ DEFINE_RING_TYPES(xen_displif, struct xendispl_req, struct xendispl_resp); ****************************************************************************** * In order to deliver asynchronous events from back to front a shared page is * allocated by front and its granted reference propagated to back via - * XenStore entries (event-XXX). + * XenStore entries (evt-ring-ref/evt-event-channel). * This page has a common header used by both front and back to synchronize * access and control event's ring buffer, while back being a producer of the * events and front being a consumer. The rest of the page after the header