[PATCH v1 0/2] libxl: add PV display device driver interface

[PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>

These patches add PV display device to libxl and xl.

Changes since initial:
 * re-work libxl displ related functions to use libxl_device_type

Oleksandr Grytsov (2):
  libxl: add PV display device driver interface
  xl: add PV display device commands

 tools/libxl/Makefile                 |   2 +-
 tools/libxl/libxl.h                  |  21 ++++
 tools/libxl/libxl_create.c           |   3 +
 tools/libxl/libxl_device.c           | 206 ++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h         |  24 ++++
 tools/libxl/libxl_types.idl          |  22 +++-
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_usb.c              |   2 +
 tools/libxl/libxl_utils.h            |   4 +
 tools/libxl/libxl_vdispl.c           | 209 +++++++++++++++++++++++++++++++++++
 tools/xl/Makefile                    |   1 +
 tools/xl/xl.h                        |   3 +
 tools/xl/xl_cmdtable.c               |  16 +++
 tools/xl/xl_parse.c                  |  43 ++++++-
 tools/xl/xl_parse.h                  |   2 +-
 tools/xl/xl_vdispl.c                 | 162 +++++++++++++++++++++++++++
 16 files changed, 716 insertions(+), 5 deletions(-)
 create mode 100644 tools/libxl/libxl_vdispl.c
 create mode 100644 tools/xl/xl_vdispl.c

-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v1 1/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>

Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
---
 tools/libxl/Makefile                 |   2 +-
 tools/libxl/libxl.h                  |  21 ++++
 tools/libxl/libxl_create.c           |   3 +
 tools/libxl/libxl_device.c           | 206 ++++++++++++++++++++++++++++++++++
 tools/libxl/libxl_internal.h         |  24 ++++
 tools/libxl/libxl_types.idl          |  22 +++-
 tools/libxl/libxl_types_internal.idl |   1 +
 tools/libxl/libxl_usb.c              |   2 +
 tools/libxl/libxl_utils.h            |   4 +
 tools/libxl/libxl_vdispl.c           | 209 +++++++++++++++++++++++++++++++++++
 10 files changed, 491 insertions(+), 3 deletions(-)
 create mode 100644 tools/libxl/libxl_vdispl.c

diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 566b706..3a932e1 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -138,7 +138,7 @@ LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
 			libxl_dom_suspend.o libxl_dom_save.o libxl_usb.o \
 			libxl_vtpm.o libxl_nic.o libxl_disk.o libxl_console.o \
 			libxl_cpupool.o libxl_mem.o libxl_sched.o libxl_tmem.o \
-			libxl_domain.o \
+			libxl_domain.o libxl_vdispl.o \
                         $(LIBXL_OBJS-y)
 LIBXL_OBJS += libxl_genid.o
 LIBXL_OBJS += _libxl_types.o libxl_flask.o _libxl_types_internal.o
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 72ec39d..4eff121 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -1833,6 +1833,27 @@ libxl_device_vtpm *libxl_device_vtpm_list(libxl_ctx *ctx, uint32_t domid, int *n
 int libxl_device_vtpm_getinfo(libxl_ctx *ctx, uint32_t domid,
                                libxl_device_vtpm *vtpm, libxl_vtpminfo *vtpminfo);
 
+/* Virtual displays */
+int libxl_device_vdispl_add(libxl_ctx *ctx, uint32_t domid,
+                            libxl_device_vdispl *displ,
+                            const libxl_asyncop_how *ao_how)
+                            LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vdispl_remove(libxl_ctx *ctx, uint32_t domid,
+                               libxl_device_vdispl *vdispl,
+                               const libxl_asyncop_how *ao_how)
+                               LIBXL_EXTERNAL_CALLERS_ONLY;
+int libxl_device_vdispl_destroy(libxl_ctx *ctx, uint32_t domid,
+                                libxl_device_vdispl *vdispl,
+                                const libxl_asyncop_how *ao_how)
+                                LIBXL_EXTERNAL_CALLERS_ONLY;
+
+libxl_device_vdispl *libxl_device_vdispl_list(libxl_ctx *ctx, uint32_t domid,
+                                              int *num);
+void libxl_device_vdispl_list_free(libxl_device_vdispl* list, int num);
+int libxl_device_vdispl_getinfo(libxl_ctx *ctx, uint32_t domid,
+                                libxl_device_vdispl *vdispl,
+                                libxl_vdisplinfo *vdisplinfo);
+
 /* Keyboard */
 int libxl_device_vkb_add(libxl_ctx *ctx, uint32_t domid, libxl_device_vkb *vkb,
                          const libxl_asyncop_how *ao_how)
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 25389e1..b36383f 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -1422,6 +1422,8 @@ out:
 
 #define libxl_device_dtdev_list NULL
 #define libxl_device_dtdev_compare NULL
+#define libxl__device_from_dtdev NULL
+#define libxl__device_dtdev_setdefault NULL
 static DEFINE_DEVICE_TYPE_STRUCT(dtdev);
 
 const struct libxl_device_type *device_type_tbl[] = {
@@ -1432,6 +1434,7 @@ const struct libxl_device_type *device_type_tbl[] = {
     &libxl__usbdev_devtype,
     &libxl__pcidev_devtype,
     &libxl__dtdev_devtype,
+    &libxl__vdispl_devtype,
     NULL
 };
 
diff --git a/tools/libxl/libxl_device.c b/tools/libxl/libxl_device.c
index 5e96676..def1859 100644
--- a/tools/libxl/libxl_device.c
+++ b/tools/libxl/libxl_device.c
@@ -1776,6 +1776,212 @@ out:
     return AO_CREATE_FAIL(rc);
 }
 
+static int device_add_domain_config(libxl__gc *gc, uint32_t domid,
+                                    const struct libxl_device_type *dt,
+                                    void *type)
+{
+    int rc;
+    libxl_domain_config d_config;
+    libxl__domain_userdata_lock *lock = NULL;
+    int *num_dev;
+    int i;
+    void *item = NULL;
+
+    libxl_domain_config_init(&d_config);
+
+    lock = libxl__lock_domain_userdata(gc, domid);
+    if (!lock) {
+        rc = ERROR_LOCK_FAIL; goto out;
+    }
+
+    rc = libxl__get_domain_configuration(gc, domid, &d_config);
+    if (rc) goto out;
+
+    num_dev = libxl__device_type_get_num(dt, &d_config);
+
+    /* Check for existing device */
+    for (i = 0; i < *num_dev; i++) {
+        if (dt->compare(libxl__device_type_get_elem(dt, &d_config, i), type)) {
+            item = libxl__device_type_get_elem(dt, &d_config, i);
+        }
+    }
+
+    if (!item) {
+        void **devs= libxl__device_type_get_ptr(dt, &d_config);
+        *devs = libxl__realloc(NOGC, *devs,
+                               dt->dev_elem_size * (*num_dev + 1));
+        item = libxl__device_type_get_elem(dt, &d_config, *num_dev);
+        (*num_dev)++;
+    } else {
+        dt->dispose(item);
+    }
+
+    dt->init(item);
+    dt->copy(CTX, item, type);
+
+    rc = libxl__dm_check_start(gc, &d_config, domid);
+    if (rc) goto out;
+
+    rc = libxl__set_domain_configuration(gc, domid, &d_config);
+    if (rc) goto out;
+
+    rc = 0;
+
+out:
+    if (lock) libxl__unlock_domain_userdata(lock);
+    libxl_domain_config_dispose(&d_config);
+    return rc;
+}
+
+static int device_add_xen_store(libxl__gc *gc, libxl__device *device,
+                                char **bents, char **fents, char **ro_fents)
+{
+    xs_transaction_t t = XBT_NULL;
+    int rc;
+
+    for (;;) {
+        rc = libxl__xs_transaction_start(gc, &t);
+        if (rc) goto out;
+
+        libxl__device_generic_add(gc, t, device, bents, fents, ro_fents);
+
+        rc = libxl__xs_transaction_commit(gc, &t);
+        if (!rc) break;
+        if (rc < 0) goto out;
+    }
+
+    rc = 0;
+
+out:
+    libxl__xs_transaction_abort(gc, &t);
+    return rc;
+}
+
+void libxl__device_add(libxl__egc *egc, uint32_t domid,
+                       const struct libxl_device_type *dt, void *type,
+                       libxl__ao_device *aodev)
+{
+    STATE_AO_GC(aodev->ao);
+    libxl__device *device;
+    int rc;
+    flexarray_t *front = NULL;
+    flexarray_t *back = NULL;
+
+    rc = dt->set_default(gc, domid, type);
+    if (rc) goto out;
+
+    GCNEW(device);
+    rc = dt->to_device(gc, domid, type, device);
+    if ( rc != 0 ) goto out;
+
+    rc = libxl__device_exists(gc, XBT_NULL, device);
+    if (rc < 0) goto out;
+    if (rc == 1) {              /* already exists in xenstore */
+        LOGD(ERROR, domid, "device already exists in xenstore");
+        aodev->action = LIBXL__DEVICE_ACTION_ADD; /* for error message */
+        rc = ERROR_DEVICE_EXISTS;
+        goto out;
+    }
+
+    if (aodev->update_json) {
+        rc = device_add_domain_config(gc, domid, dt, type);
+        if (rc) goto out;
+    }
+
+    if (dt->set_xenstore_config) {
+        dt->set_xenstore_config(gc, domid, type, &front, &back);
+        rc = device_add_xen_store(gc, device,
+                                  libxl__xs_kvs_of_flexarray(gc, back),
+                                  libxl__xs_kvs_of_flexarray(gc, front),
+                                  NULL);
+        if (rc) goto out;
+    }
+
+    aodev->dev = device;
+    aodev->action = LIBXL__DEVICE_ACTION_ADD;
+    libxl__wait_device_connection(egc, aodev);
+
+    rc = 0;
+
+out:
+    aodev->rc = rc;
+    if(rc) aodev->callback(egc, aodev);
+    return;
+}
+
+void* libxl__device_list(const struct libxl_device_type *dt,
+                         libxl_ctx *ctx, uint32_t domid, int *num)
+{
+    GC_INIT(ctx);
+
+    void *r = NULL;
+    void *list = NULL;
+    void *item = NULL;
+    char *libxl_path;
+    char *be_path;
+    char** dir = NULL;
+    unsigned int ndirs = 0;
+    int rc;
+
+    *num = 0;
+
+    libxl_path = GCSPRINTF("%s/device/%s",
+                           libxl__xs_libxl_path(gc, domid), dt->type);
+
+    dir = libxl__xs_directory(gc, XBT_NULL, libxl_path, &ndirs);
+
+    if (dir && ndirs) {
+        list = malloc(dt->dev_elem_size * ndirs);
+        void *end = (uint8_t*)list + ndirs * dt->dev_elem_size;
+        item = list;
+
+        while(item < end) {
+            be_path = libxl__xs_read(gc, XBT_NULL,
+                                     GCSPRINTF("%s/%s/backend",
+                                     libxl_path, *dir));
+
+            dt->init(item);
+
+            rc = dt->from_xenstore(gc, be_path, atoi(*dir), item);
+            if (rc) goto out;
+
+            item = (uint8_t*)item + dt->dev_elem_size;
+            ++dir;
+        }
+    }
+
+    *num = ndirs;
+    r = list;
+    list = NULL;
+
+out:
+
+    if (list) {
+        *num = 0;
+        while(item >= list) {
+            item = (uint8_t*)item - dt->dev_elem_size;
+            dt->dispose(item);
+        }
+        free(list);
+    }
+
+    GC_FREE;
+
+    return r;
+}
+
+void libxl__device_list_free(const struct libxl_device_type *dt,
+                             void *list, int num)
+{
+    int i;
+
+    for (i = 0; i < num; i++) {
+        dt->dispose((uint8_t*)list + i * dt->dev_elem_size);
+    }
+
+    free(list);
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 25cb08a..c07e280 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -3473,11 +3473,18 @@ struct libxl_device_type {
     void (*add)(libxl__egc *, libxl__ao *, uint32_t, libxl_domain_config *,
                 libxl__multidev *);
     void *(*list)(libxl_ctx *, uint32_t, int *);
+    int (*set_default)(libxl__gc *, uint32_t, void *);
+    int (*to_device)(libxl__gc *, uint32_t, void *, libxl__device *);
+    void (*init)(void *);
+    void (*copy)(libxl_ctx *, void *, void *);
     void (*dispose)(void *);
     int (*compare)(void *, void *);
     void (*merge)(libxl_ctx *, void *, void *);
     int (*dm_needed)(void *, unsigned);
     void (*update_config)(libxl__gc *, void *, void *);
+    int (*from_xenstore)(libxl__gc *, const char *, uint32_t, void *);
+    void (*set_xenstore_config)(libxl__gc *, uint32_t, void *,
+                                flexarray_t **, flexarray_t **);
 };
 
 #define DEFINE_DEVICE_TYPE_STRUCT_X(name, sname, ...)                          \
@@ -3489,6 +3496,14 @@ struct libxl_device_type {
         .add           = libxl__add_ ## name ## s,                             \
         .list          = (void *(*)(libxl_ctx *, uint32_t, int *))             \
                          libxl_device_ ## sname ## _list,                      \
+        .set_default   = (int (*)(libxl__gc *, uint32_t, void *))              \
+                         libxl__device_ ## sname ## _setdefault,               \
+        .to_device     = (int (*)(libxl__gc *, uint32_t,                       \
+                                  void *, libxl__device *))                    \
+                         libxl__device_from_ ## name,                          \
+        .init          = (void (*)(void *))libxl_device_ ## sname ## _init,    \
+        .copy          = (void (*)(libxl_ctx *, void *, void *))               \
+                         libxl_device_ ## sname ## _copy,                      \
         .dispose       = (void (*)(void *))libxl_device_ ## sname ## _dispose, \
         .compare       = (int (*)(void *, void *))                             \
                          libxl_device_ ## sname ## _compare,                   \
@@ -3523,6 +3538,7 @@ extern const struct libxl_device_type libxl__vtpm_devtype;
 extern const struct libxl_device_type libxl__usbctrl_devtype;
 extern const struct libxl_device_type libxl__usbdev_devtype;
 extern const struct libxl_device_type libxl__pcidev_devtype;
+extern const struct libxl_device_type libxl__vdispl_devtype;
 
 extern const struct libxl_device_type *device_type_tbl[];
 
@@ -4339,6 +4355,14 @@ static inline bool libxl__acpi_defbool_val(const libxl_domain_build_info *b_info
     return libxl_defbool_val(b_info->acpi) &&
            libxl_defbool_val(b_info->u.hvm.acpi);
 }
+
+void libxl__device_add(libxl__egc *egc, uint32_t domid,
+                       const struct libxl_device_type *dt, void *type,
+                       libxl__ao_device *aodev);
+void* libxl__device_list(const struct libxl_device_type *dt,
+                         libxl_ctx *ctx, uint32_t domid, int *num);
+void libxl__device_list_free(const struct libxl_device_type *dt,
+                             void *list, int num);
 #endif
 
 /*
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 2475a4d..a4ff837 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -738,7 +738,14 @@ libxl_device_vtpm = Struct("device_vtpm", [
     ("backend_domname",  string),
     ("devid",            libxl_devid),
     ("uuid",             libxl_uuid),
-])
+    ])
+
+libxl_device_vdispl = Struct("device_vdispl", [
+    ("backend_domid", libxl_domid),
+    ("backend_domname", string),
+    ("devid", libxl_devid),
+    ("be_alloc", bool),
+    ])
 
 libxl_device_channel = Struct("device_channel", [
     ("backend_domid", libxl_domid),
@@ -750,7 +757,7 @@ libxl_device_channel = Struct("device_channel", [
             ("pty", None),
             ("socket", Struct(None, [("path", string)])),
            ])),
-])
+    ])
 
 libxl_domain_config = Struct("domain_config", [
     ("c_info", libxl_domain_create_info),
@@ -764,6 +771,7 @@ libxl_domain_config = Struct("domain_config", [
     ("vfbs", Array(libxl_device_vfb, "num_vfbs")),
     ("vkbs", Array(libxl_device_vkb, "num_vkbs")),
     ("vtpms", Array(libxl_device_vtpm, "num_vtpms")),
+    ("vdispls", Array(libxl_device_vdispl, "num_vdispls")),
     # a channel manifests as a console with a name,
     # see docs/misc/channels.txt
     ("channels", Array(libxl_device_channel, "num_channels")),
@@ -860,6 +868,16 @@ libxl_physinfo = Struct("physinfo", [
     ("cap_hvm_directio", bool),
     ], dir=DIR_OUT)
 
+libxl_vdisplinfo = Struct("vdisplinfo", [
+    ("backend", string),
+    ("backend_id", uint32),
+    ("frontend", string),
+    ("frontend_id", uint32),
+    ("devid", libxl_devid),
+    ("state", integer),
+    ("be_alloc", bool),
+    ], dir=DIR_OUT)
+
 # NUMA node characteristics: size and free are how much memory it has, and how
 # much of it is free, respectively. dists is an array of distances from this
 # node to each other node.
diff --git a/tools/libxl/libxl_types_internal.idl b/tools/libxl/libxl_types_internal.idl
index 82e5c07..cdef4d3 100644
--- a/tools/libxl/libxl_types_internal.idl
+++ b/tools/libxl/libxl_types_internal.idl
@@ -25,6 +25,7 @@ libxl__device_kind = Enumeration("device_kind", [
     (8, "VTPM"),
     (9, "VUSB"),
     (10, "QUSB"),
+    (11, "VDISPL")
     ])
 
 libxl__console_backend = Enumeration("console_backend", [
diff --git a/tools/libxl/libxl_usb.c b/tools/libxl/libxl_usb.c
index d8948d5..d1ec28f 100644
--- a/tools/libxl/libxl_usb.c
+++ b/tools/libxl/libxl_usb.c
@@ -1968,6 +1968,8 @@ void libxl_device_usbdev_list_free(libxl_device_usbdev *list, int nr)
 DEFINE_DEVICE_TYPE_STRUCT(usbctrl,
     .dm_needed = libxl_device_usbctrl_dm_needed
 );
+
+#define libxl__device_from_usbdev NULL
 DEFINE_DEVICE_TYPE_STRUCT(usbdev);
 
 /*
diff --git a/tools/libxl/libxl_utils.h b/tools/libxl/libxl_utils.h
index 25773d8..9e743dc 100644
--- a/tools/libxl/libxl_utils.h
+++ b/tools/libxl/libxl_utils.h
@@ -78,6 +78,10 @@ int libxl_devid_to_device_vtpm(libxl_ctx *ctx, uint32_t domid,
                                int devid, libxl_device_vtpm *vtpm);
 int libxl_devid_to_device_usbctrl(libxl_ctx *ctx, uint32_t domid,
                                   int devid, libxl_device_usbctrl *usbctrl);
+
+int libxl_devid_to_device_vdispl(libxl_ctx *ctx, uint32_t domid,
+                                 int devid, libxl_device_vdispl *vdispl);
+
 int libxl_ctrlport_to_device_usbdev(libxl_ctx *ctx, uint32_t domid,
                                     int ctrl, int port,
                                     libxl_device_usbdev *usbdev);
diff --git a/tools/libxl/libxl_vdispl.c b/tools/libxl/libxl_vdispl.c
new file mode 100644
index 0000000..85b20db
--- /dev/null
+++ b/tools/libxl/libxl_vdispl.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (C) 2016 EPAM Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include "libxl_osdeps.h"
+
+#include "libxl_internal.h"
+
+static int libxl__device_vdispl_setdefault(libxl__gc *gc, uint32_t domid,
+                                           libxl_device_vdispl *vdispl)
+{
+    int rc;
+
+    rc = libxl__resolve_domid(gc, vdispl->backend_domname,
+                              &vdispl->backend_domid);
+
+    if (vdispl->devid == -1) {
+        vdispl->devid = libxl__device_nextid(gc, domid, "vdispl");
+    }
+
+    return rc;
+}
+
+static int libxl__from_xenstore_vdispl(libxl__gc *gc, const char *be_path,
+                                       uint32_t devid,
+                                       libxl_device_vdispl *vdispl)
+{
+    vdispl->devid = devid;
+
+    return libxl__backendpath_parse_domid(gc, be_path, &vdispl->backend_domid);
+}
+
+static int libxl__device_from_vdispl(libxl__gc *gc, uint32_t domid,
+                                     libxl_device_vdispl *vdispl,
+                                     libxl__device *device)
+{
+   device->backend_devid   = vdispl->devid;
+   device->backend_domid   = vdispl->backend_domid;
+   device->backend_kind    = LIBXL__DEVICE_KIND_VDISPL;
+   device->devid           = vdispl->devid;
+   device->domid           = domid;
+   device->kind            = LIBXL__DEVICE_KIND_VDISPL;
+
+   return 0;
+}
+
+static void libxl__set_xenstore_vdispl(libxl__gc *gc, uint32_t domid,
+                                       libxl_device_vdispl *vdispl,
+                                       flexarray_t **front, flexarray_t **back)
+{
+    *front = flexarray_make(gc, 16, 1);
+    *back = flexarray_make(gc, 16, 1);
+
+    flexarray_append(*back, "frontend-id");
+    flexarray_append(*back, GCSPRINTF("%d", domid));
+    flexarray_append(*back, "online");
+    flexarray_append(*back, "1");
+    flexarray_append(*back, "state");
+    flexarray_append(*back, GCSPRINTF("%d", XenbusStateInitialising));
+    flexarray_append(*back, "handle");
+    flexarray_append(*back, GCSPRINTF("%d", vdispl->devid));
+
+    flexarray_append(*front, "backend-id");
+    flexarray_append(*front, GCSPRINTF("%d", vdispl->backend_domid));
+    flexarray_append(*front, "state");
+    flexarray_append(*front, GCSPRINTF("%d", XenbusStateInitialising));
+    flexarray_append(*front, "handle");
+    flexarray_append(*front, GCSPRINTF("%d", vdispl->devid));
+    flexarray_append(*front, "be_alloc");
+    flexarray_append(*front, GCSPRINTF("%d", vdispl->be_alloc));
+}
+
+static void libxl__update_config_vdispl(libxl__gc *gc,
+                                        libxl_device_vdispl *dst,
+                                        libxl_device_vdispl *src)
+{
+    dst->devid = src->devid;
+    dst->be_alloc = src->be_alloc;
+}
+
+static int libxl_device_vdispl_compare(libxl_device_vdispl *d1,
+                                       libxl_device_vdispl *d2)
+{
+    return COMPARE_DEVID(d1, d2);
+}
+
+static void libxl__device_vdispl_add(libxl__egc *egc, uint32_t domid,
+                                     libxl_device_vdispl *vdispl,
+                                     libxl__ao_device *aodev)
+{
+    libxl__device_add(egc, domid, &libxl__vdispl_devtype, vdispl, aodev);
+}
+
+libxl_device_vdispl *libxl_device_vdispl_list(libxl_ctx *ctx, uint32_t domid,
+                                              int *num)
+{
+    return libxl__device_list(&libxl__vdispl_devtype, ctx, domid, num);
+}
+
+void libxl_device_vdispl_list_free(libxl_device_vdispl* list, int num)
+{
+    libxl__device_list_free(&libxl__vdispl_devtype, list, num);
+}
+
+int libxl_device_vdispl_getinfo(libxl_ctx *ctx, uint32_t domid,
+                                libxl_device_vdispl *vdispl,
+                                libxl_vdisplinfo *info)
+{
+    GC_INIT(ctx);
+    char *libxl_path, *dompath, *devpath;
+    char *val;
+    int rc;
+
+    libxl_vdisplinfo_init(info);
+    dompath = libxl__xs_get_dompath(gc, domid);
+    info->devid = vdispl->devid;
+
+    devpath = GCSPRINTF("%s/device/vdispl/%d", dompath, info->devid);
+    libxl_path = GCSPRINTF("%s/device/vdispl/%d",
+                           libxl__xs_libxl_path(gc, domid),
+                           info->devid);
+    info->backend = xs_read(ctx->xsh, XBT_NULL,
+                            GCSPRINTF("%s/backend", libxl_path),
+                            NULL);
+    if (!info->backend) { rc = ERROR_FAIL; goto out; }
+
+    rc = libxl__backendpath_parse_domid(gc, info->backend, &info->backend_id);
+    if (rc) { goto out; }
+
+    val = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/state", devpath));
+    info->state = val ? strtoul(val, NULL, 10) : -1;
+
+    info->frontend = xs_read(ctx->xsh, XBT_NULL,
+                             GCSPRINTF("%s/frontend", libxl_path),
+                             NULL);
+    info->frontend_id = domid;
+
+    val = libxl__xs_read(gc, XBT_NULL, GCSPRINTF("%s/be_alloc", libxl_path));
+    info->be_alloc = val ? strtoul(val, NULL, 10) : 0;
+
+    rc = 0;
+
+out:
+     GC_FREE;
+     return rc;
+}
+
+int libxl_devid_to_device_vdispl(libxl_ctx *ctx, uint32_t domid,
+                                 int devid, libxl_device_vdispl *vdispl)
+{
+    libxl_device_vdispl *vdispls = NULL;
+    int n, i;
+    int rc;
+
+    libxl_device_vdispl_init(vdispl);
+
+    vdispls = libxl_device_vdispl_list(ctx, domid, &n);
+
+    if (!vdispls) { rc = ERROR_NOTFOUND; goto out; }
+
+    for (i = 0; i < n; ++i) {
+        if (devid == vdispls[i].devid) {
+            libxl_device_vdispl_copy(ctx, vdispl, &vdispls[i]);
+            rc = 0;
+            goto out;
+        }
+    }
+
+    rc = ERROR_NOTFOUND;
+
+out:
+
+    if (vdispls) {
+        libxl_device_vdispl_list_free(vdispls, n);
+    }
+    return rc;
+}
+
+LIBXL_DEFINE_DEVICE_ADD(vdispl)
+static LIBXL_DEFINE_DEVICES_ADD(vdispl)
+LIBXL_DEFINE_DEVICE_REMOVE(vdispl)
+
+DEFINE_DEVICE_TYPE_STRUCT(vdispl,
+    .update_config = (void (*)(libxl__gc *, void *, void *))
+                     libxl__update_config_vdispl,
+    .from_xenstore = (int (*)(libxl__gc *, const char *, uint32_t, void *))
+                     libxl__from_xenstore_vdispl,
+    .set_xenstore_config = (void (*)(libxl__gc *, uint32_t, void *,
+                           flexarray_t **, flexarray_t **))
+                           libxl__set_xenstore_vdispl
+);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

[PATCH v1 2/2] xl: add PV display device commands

[Oleksandr Grytsov]

From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>

Signed-off-by: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
---
 tools/xl/Makefile      |   1 +
 tools/xl/xl.h          |   3 +
 tools/xl/xl_cmdtable.c |  16 +++++
 tools/xl/xl_parse.c    |  43 ++++++++++++-
 tools/xl/xl_parse.h    |   2 +-
 tools/xl/xl_vdispl.c   | 162 +++++++++++++++++++++++++++++++++++++++++++++++++
 6 files changed, 225 insertions(+), 2 deletions(-)
 create mode 100644 tools/xl/xl_vdispl.c

diff --git a/tools/xl/Makefile b/tools/xl/Makefile
index e16f877..5c784b5 100644
--- a/tools/xl/Makefile
+++ b/tools/xl/Makefile
@@ -21,6 +21,7 @@ XL_OBJS += xl_vtpm.o xl_block.o xl_nic.o xl_usb.o
 XL_OBJS += xl_sched.o xl_pci.o xl_vcpu.o xl_cdrom.o xl_mem.o
 XL_OBJS += xl_psr.o xl_info.o xl_console.o xl_misc.o
 XL_OBJS += xl_vmcontrol.o xl_saverestore.o xl_migrate.o
+XL_OBJS += xl_vdispl.o
 
 $(XL_OBJS): CFLAGS += $(CFLAGS_libxentoollog)
 $(XL_OBJS): CFLAGS += $(CFLAGS_XL)
diff --git a/tools/xl/xl.h b/tools/xl/xl.h
index aa95b77..d361241 100644
--- a/tools/xl/xl.h
+++ b/tools/xl/xl.h
@@ -166,6 +166,9 @@ int main_blockdetach(int argc, char **argv);
 int main_vtpmattach(int argc, char **argv);
 int main_vtpmlist(int argc, char **argv);
 int main_vtpmdetach(int argc, char **argv);
+int main_vdisplattach(int argc, char **argv);
+int main_vdispllist(int argc, char **argv);
+int main_vdispldetach(int argc, char **argv);
 int main_usbctrl_attach(int argc, char **argv);
 int main_usbctrl_detach(int argc, char **argv);
 int main_usbdev_attach(int argc, char **argv);
diff --git a/tools/xl/xl_cmdtable.c b/tools/xl/xl_cmdtable.c
index 7d97811..34090e1 100644
--- a/tools/xl/xl_cmdtable.c
+++ b/tools/xl/xl_cmdtable.c
@@ -372,6 +372,22 @@ struct cmd_spec cmd_table[] = {
       "Destroy a domain's virtual TPM device",
       "<Domain> <DevId|uuid>",
     },
+    { "vdispl-attach",
+      &main_vdisplattach, 1, 1,
+      "Create a new virtual display device",
+      "<Domain> [devId=<Device>] [backend=<BackDomain>] [beAlloc=<BackAlloc>]",
+      "    BackAlloc - set to 1 to allow backend allocated display buffers"
+    },
+    { "vdispl-list",
+      &main_vdispllist, 0, 0,
+      "List virtual display devices for a domain",
+      "<Domain(s)>",
+    },
+    { "vdispl-detach",
+      &main_vdispldetach, 0, 1,
+      "Destroy a domain's virtual display device",
+      "<Domain> <DevId>",
+    },
     { "uptime",
       &main_uptime, 0, 0,
       "Print uptime for all/some domains",
diff --git a/tools/xl/xl_parse.c b/tools/xl/xl_parse.c
index b72f990..fd6685a 100644
--- a/tools/xl/xl_parse.c
+++ b/tools/xl/xl_parse.c
@@ -803,6 +803,24 @@ int parse_usbdev_config(libxl_device_usbdev *usbdev, char *token)
     return 0;
 }
 
+int parse_vdispl_config(libxl_device_vdispl *vdispl, char *token)
+{
+    char *oparg;
+
+    if (MATCH_OPTION("backend", token, oparg)) {
+        vdispl->backend_domname = strdup(oparg);
+    } else if (MATCH_OPTION("devId", token, oparg)) {
+        vdispl->devid = atoi(oparg);
+    } else if (MATCH_OPTION("beAlloc", token, oparg)) {
+    	vdispl->be_alloc = strtoul(oparg, NULL, 0);
+    } else {
+        fprintf(stderr, "Unknown string `%s' in vdispl spec\n", token);
+        return 1;
+    }
+
+    return 0;
+}
+
 void parse_config_data(const char *config_source,
                        const char *config_data,
                        int config_len,
@@ -812,7 +830,7 @@ void parse_config_data(const char *config_source,
     long l, vcpus = 0;
     XLU_Config *config;
     XLU_ConfigList *cpus, *vbds, *nics, *pcis, *cvfbs, *cpuids, *vtpms,
-                   *usbctrls, *usbdevs;
+                   *usbctrls, *usbdevs, *vdispls;
     XLU_ConfigList *channels, *ioports, *irqs, *iomem, *viridian, *dtdevs;
     int num_ioports, num_irqs, num_iomem, num_cpus, num_viridian;
     int pci_power_mgmt = 0;
@@ -1390,6 +1408,29 @@ void parse_config_data(const char *config_source,
         }
     }
 
+    if (!xlu_cfg_get_list(config, "vdispl", &vdispls, 0, 0)) {
+        d_config->num_vdispls = 0;
+        d_config->vdispls = NULL;
+        while ((buf = xlu_cfg_get_listitem(vdispls, d_config->num_vdispls)) != NULL) {
+            libxl_device_vdispl *vdispl;
+            char * buf2 = strdup(buf);
+            char *p;
+            vdispl = ARRAY_EXTEND_INIT(d_config->vdispls,
+                                       d_config->num_vdispls,
+                                       libxl_device_vdispl_init);
+            p = strtok (buf2, ",");
+            while (p != NULL)
+            {
+                while (*p == ' ') p++;
+                if (parse_vdispl_config(vdispl, p)) {
+                    exit(1);
+                }
+                p = strtok (NULL, ",");
+            }
+            free(buf2);
+        }
+    }
+
     if (!xlu_cfg_get_list (config, "channel", &channels, 0, 0)) {
         d_config->num_channels = 0;
         d_config->channels = NULL;
diff --git a/tools/xl/xl_parse.h b/tools/xl/xl_parse.h
index db8bc3f..cc459fb 100644
--- a/tools/xl/xl_parse.h
+++ b/tools/xl/xl_parse.h
@@ -33,7 +33,7 @@ int parse_usbctrl_config(libxl_device_usbctrl *usbctrl, char *token);
 int parse_usbdev_config(libxl_device_usbdev *usbdev, char *token);
 int parse_cpurange(const char *cpu, libxl_bitmap *cpumap);
 int parse_nic_config(libxl_device_nic *nic, XLU_Config **config, char *token);
-
+int parse_vdispl_config(libxl_device_vdispl *vdispl, char *token);
 
 int match_option_size(const char *prefix, size_t len,
                       char *arg, char **argopt);
diff --git a/tools/xl/xl_vdispl.c b/tools/xl/xl_vdispl.c
new file mode 100644
index 0000000..4df90c9
--- /dev/null
+++ b/tools/xl/xl_vdispl.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright (C) 2016 EPAM Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License as published
+ * by the Free Software Foundation; version 2.1 only. with the special
+ * exception on linking described in file LICENSE.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ */
+
+#include <stdlib.h>
+
+#include <libxl.h>
+#include <libxl_utils.h>
+#include <libxlutil.h>
+
+#include "xl.h"
+#include "xl_utils.h"
+#include "xl_parse.h"
+
+int main_vdisplattach(int argc, char **argv)
+{
+    int opt;
+    int rc;
+    char *oparg;
+    uint32_t domid;
+    libxl_device_vdispl vdispl;
+
+    SWITCH_FOREACH_OPT(opt, "", NULL, "vdispl-attach", 1) {
+        /* No options */
+    }
+
+    libxl_device_vdispl_init(&vdispl);
+    domid = find_domain(argv[optind++]);
+
+    for (argv += optind, argc -= optind; argc > 0; ++argv, --argc) {
+        if (MATCH_OPTION("devId", *argv, oparg)) {
+            vdispl.devid = atoi(oparg);
+        } else if (MATCH_OPTION("backend", *argv, oparg)) {
+            vdispl.backend_domid = find_domain(oparg);
+            replace_string(&vdispl.backend_domname, oparg);
+        } else if (MATCH_OPTION("beAlloc", *argv, oparg)) {
+            vdispl.be_alloc = strtoul(oparg, NULL, 0);
+        } else {
+            fprintf(stderr, "unrecognized argument `%s'\n", *argv);
+            rc = 1;
+            goto out;
+        }
+    }
+
+    if (dryrun_only) {
+        char *json = libxl_device_vdispl_to_json(ctx, &vdispl);
+        printf("vdispl: %s\n", json);
+        free(json);
+        goto out;
+    }
+
+    if (libxl_device_vdispl_add(ctx, domid, &vdispl, 0)) {
+        fprintf(stderr, "libxl_device_vdispl_add failed.\n");
+        rc = ERROR_FAIL;
+    }
+
+    rc = 0;
+
+out:
+    libxl_device_vdispl_dispose(&vdispl);
+    return rc;
+}
+
+int main_vdispllist(int argc, char **argv)
+{
+   int opt;
+   int i, n;
+   libxl_device_vdispl *vdispls;
+   libxl_vdisplinfo vdisplinfo;
+
+   SWITCH_FOREACH_OPT(opt, "", NULL, "vdispl-list", 1) {
+       /* No options */
+   }
+
+   /* vdisplinfo.uuid should be outputted too */
+   printf("%-5s %-3s %-6s %-5s %-8s %-40s %-40s\n",
+           "Vdev", "BE", "handle", "state", "be-alloc", "BE-path", "FE-path");
+   for (argv += optind, argc -= optind; argc > 0; --argc, ++argv) {
+       uint32_t domid;
+
+       if (libxl_domain_qualifier_to_domid(ctx, *argv, &domid) < 0) {
+           fprintf(stderr, "%s is an invalid domain identifier\n", *argv);
+           continue;
+       }
+
+       vdispls = libxl_device_vdispl_list(ctx, domid, &n);
+
+       if (!vdispls) {
+           continue;
+       }
+
+       for (i = 0; i < n; i++) {
+           libxl_vdisplinfo_init(&vdisplinfo);
+           if (libxl_device_vdispl_getinfo(ctx, domid, &vdispls[i],
+                                           &vdisplinfo) == 0) {
+               /*      Vdev BE   hdl   st  be-alloc BE-path FE-path*/
+               printf("%-5d %-3d %-6d %-5d %-8d %-40s %-40s\n",
+                       vdisplinfo.devid, vdisplinfo.backend_id,
+                       vdisplinfo.frontend_id,
+                       vdisplinfo.state, vdisplinfo.be_alloc,
+                       vdisplinfo.backend, vdisplinfo.frontend);
+           }
+           libxl_vdisplinfo_dispose(&vdisplinfo);
+       }
+
+       libxl_device_vdispl_list_free(vdispls, n);
+   }
+   return 0;
+}
+
+int main_vdispldetach(int argc, char **argv)
+{
+    uint32_t domid, devid;
+    int opt, rc;
+    libxl_device_vdispl vdispl;
+
+    SWITCH_FOREACH_OPT(opt, "", NULL, "vdispl-detach", 2) {
+        /* No options */
+    }
+
+    domid = find_domain(argv[optind++]);
+    devid = atoi(argv[optind++]);
+
+    libxl_device_vdispl_init(&vdispl);
+
+    if (libxl_devid_to_device_vdispl(ctx, domid, devid, &vdispl)) {
+        fprintf(stderr, "Error: Device %d not connected.\n", devid);
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = libxl_device_vdispl_remove(ctx, domid, &vdispl, 0);
+    if (rc) {
+        fprintf(stderr, "libxl_device_vdispl_remove failed.\n");
+        rc = ERROR_FAIL;
+        goto out;
+    }
+
+    rc = 0;
+
+out:
+    libxl_device_vdispl_dispose(&vdispl);
+    return rc;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-basic-offset: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Ian Jackson]

Oleksandr Grytsov writes ("[PATCH v1 0/2] libxl: add PV display device driver interface"):
> From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
> 
> These patches add PV display device to libxl and xl.
> 
> Changes since initial:
>  * re-work libxl displ related functions to use libxl_device_type
> 
> Oleksandr Grytsov (2):
>   libxl: add PV display device driver interface
>   xl: add PV display device commands

Sorry to show my ignorance, but what is a "PV display device" ?
Where is the backend ?  What protocol do the frontend/backend speak ?
What are the parameters ?

Also, there should be some documentation for the new xl options and
config settings.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[al1img .]

On Wed, Apr 5, 2017 at 2:05 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> Oleksandr Grytsov writes ("[PATCH v1 0/2] libxl: add PV display device driver interface"):
>> From: Oleksandr Grytsov <oleksandr_grytsov@epam.com>
>>
>> These patches add PV display device to libxl and xl.
>>
>> Changes since initial:
>>  * re-work libxl displ related functions to use libxl_device_type
>>
>> Oleksandr Grytsov (2):
>>   libxl: add PV display device driver interface
>>   xl: add PV display device commands
>
> Sorry to show my ignorance, but what is a "PV display device" ?
> Where is the backend ?  What protocol do the frontend/backend speak ?

This is PV display device which provides virtual screens for frontends.
We are working on the backend and frontend. They are currently under
development.
The backend uses DRM or Wayland as output. You can check it in my private
github repository [1]. We are also developing libxenbe - generic
library which should
help to implement different kinds of backends [2].

The frontend/backend protocol is under review now [3].

> What are the parameters ?
>

It has two parameters:
    * backend - specifies domain where the backend is running;
    * beAlloc - indicated where display buffers should be allocated
(see Backend buffer allocation in [3]);

> Also, there should be some documentation for the new xl options and
> config settings.

Sure. I will update documentation.

> Thanks,
> Ian.

[1] https://github.com/al1img/displ_be
[2] https://github.com/al1img/libxenbe
[3] http://marc.info/?l=xen-devel&m=149137266022490&w=2

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Ian Jackson]

al1img . writes ("Re: [PATCH v1 0/2] libxl: add PV display device driver interface"):
> On Wed, Apr 5, 2017 at 2:05 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> > Sorry to show my ignorance, but what is a "PV display device" ?
> > Where is the backend ?  What protocol do the frontend/backend speak ?
> 
> This is PV display device which provides virtual screens for frontends.
> We are working on the backend and frontend. They are currently under
> development.

Thanks for the reference to
   http://marc.info/?l=xen-devel&m=149137266022490&w=2
which was very helpful.

I think you should combine this series with that patch.  That patch
will need wider review and ack from Konrad (as our PV interface tsar);
AFAICT you're working on that, but I would like to be CC'd on the
mails too.

> > What are the parameters ?
> 
> It has two parameters:
>     * backend - specifies domain where the backend is running;
>     * beAlloc - indicated where display buffers should be allocated
> (see Backend buffer allocation in [3]);

I don't understand that, I'm afraid.  I guess what I'm missing in this
area is: the guest sees a virtual display device.  But how is this
presented/accessed/named/whatever on the host ?  I would expect to see
some configuraton for this in the libxl idl.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Konrad Rzeszutek Wilk]

On Wed, Apr 05, 2017 at 02:49:26PM +0100, Ian Jackson wrote:
> al1img . writes ("Re: [PATCH v1 0/2] libxl: add PV display device driver interface"):
> > On Wed, Apr 5, 2017 at 2:05 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> > > Sorry to show my ignorance, but what is a "PV display device" ?
> > > Where is the backend ?  What protocol do the frontend/backend speak ?
> > 
> > This is PV display device which provides virtual screens for frontends.
> > We are working on the backend and frontend. They are currently under
> > development.
> 
> Thanks for the reference to
>    http://marc.info/?l=xen-devel&m=149137266022490&w=2
> which was very helpful.
> 
> I think you should combine this series with that patch.  That patch
> will need wider review and ack from Konrad (as our PV interface tsar);

Done, as in Reviewed-by and I am going to check it in once my 'before-staging' tests
finish.

> AFAICT you're working on that, but I would like to be CC'd on the
> mails too.
> 
> > > What are the parameters ?
> > 
> > It has two parameters:
> >     * backend - specifies domain where the backend is running;
> >     * beAlloc - indicated where display buffers should be allocated
> > (see Backend buffer allocation in [3]);
> 
> I don't understand that, I'm afraid.  I guess what I'm missing in this
> area is: the guest sees a virtual display device.  But how is this
> presented/accessed/named/whatever on the host ?  I would expect to see
> some configuraton for this in the libxl idl.
> 
> Thanks,
> Ian.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Wed, Apr 5, 2017 at 5:00 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> On Wed, Apr 05, 2017 at 02:49:26PM +0100, Ian Jackson wrote:
>> al1img . writes ("Re: [PATCH v1 0/2] libxl: add PV display device driver interface"):
>> > On Wed, Apr 5, 2017 at 2:05 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
>> > > Sorry to show my ignorance, but what is a "PV display device" ?
>> > > Where is the backend ?  What protocol do the frontend/backend speak ?
>> >
>> > This is PV display device which provides virtual screens for frontends.
>> > We are working on the backend and frontend. They are currently under
>> > development.
>>
>> Thanks for the reference to
>>    http://marc.info/?l=xen-devel&m=149137266022490&w=2
>> which was very helpful.
>>
>> I think you should combine this series with that patch.  That patch
>> will need wider review and ack from Konrad (as our PV interface tsar);
>
> Done, as in Reviewed-by and I am going to check it in once my 'before-staging' tests
> finish.
>

I guess it is late to combine the patches as the protocol already acked.

>> AFAICT you're working on that, but I would like to be CC'd on the
>> mails too.
>>
>> > > What are the parameters ?
>> >
>> > It has two parameters:
>> >     * backend - specifies domain where the backend is running;
>> >     * beAlloc - indicated where display buffers should be allocated
>> > (see Backend buffer allocation in [3]);
>>
>> I don't understand that, I'm afraid.  I guess what I'm missing in this
>> area is: the guest sees a virtual display device.  But how is this
>> presented/accessed/named/whatever on the host ?  I would expect to see
>> some configuraton for this in the libxl idl.
>>

The display backend is a user-space application which is DRM or Wayland client.
Generally it can be run on any domain.


>> Thanks,
>> Ian.
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org
>> https://lists.xen.org/xen-devel

-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Wed, Apr 5, 2017 at 5:18 PM, Oleksandr Grytsov <al1img@gmail.com> wrote:
> On Wed, Apr 5, 2017 at 5:00 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
>> On Wed, Apr 05, 2017 at 02:49:26PM +0100, Ian Jackson wrote:
>>> al1img . writes ("Re: [PATCH v1 0/2] libxl: add PV display device driver interface"):
>>> > On Wed, Apr 5, 2017 at 2:05 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
>>> > > Sorry to show my ignorance, but what is a "PV display device" ?
>>> > > Where is the backend ?  What protocol do the frontend/backend speak ?
>>> >
>>> > This is PV display device which provides virtual screens for frontends.
>>> > We are working on the backend and frontend. They are currently under
>>> > development.
>>>
>>> Thanks for the reference to
>>>    http://marc.info/?l=xen-devel&m=149137266022490&w=2
>>> which was very helpful.
>>>
>>> I think you should combine this series with that patch.  That patch
>>> will need wider review and ack from Konrad (as our PV interface tsar);
>>
>> Done, as in Reviewed-by and I am going to check it in once my 'before-staging' tests
>> finish.
>>
>
> I guess it is late to combine the patches as the protocol already acked.
>
>>> AFAICT you're working on that, but I would like to be CC'd on the
>>> mails too.
>>>
>>> > > What are the parameters ?
>>> >
>>> > It has two parameters:
>>> >     * backend - specifies domain where the backend is running;
>>> >     * beAlloc - indicated where display buffers should be allocated
>>> > (see Backend buffer allocation in [3]);
>>>
>>> I don't understand that, I'm afraid.  I guess what I'm missing in this
>>> area is: the guest sees a virtual display device.  But how is this
>>> presented/accessed/named/whatever on the host ?  I would expect to see
>>> some configuraton for this in the libxl idl.
>>>
>
> The display backend is a user-space application which is DRM or Wayland client.
> Generally it can be run on any domain.
>

Negotiation between backend and frontend is done by xen store and
described in the protocol:

+ *--------------------------------- Backend -----------------------------------
+ *
+ * /local/domain/0/backend/vdispl/1/0/frontend-id = "1"
+ * /local/domain/0/backend/vdispl/1/0/frontend =
"/local/domain/1/device/vdispl/0"
+ * /local/domain/0/backend/vdispl/1/0/state = "4"
+ * /local/domain/0/backend/vdispl/1/0/versions = "1,2"
+ *
+ *--------------------------------- Frontend ----------------------------------
+ *
+ * /local/domain/1/device/vdispl/0/backend-id = "0"
+ * /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"
+ *

libxl handles Backend/Frontend  configuration above. Which is in lib xl idl.
Description of connectors will be set by the backend to the frontend directly.
Because the backend aware of display(s) configuration(s).

+ *-------------------------- Connector 0 configuration ------------------------
+ *
+ * /local/domain/1/device/vdispl/0/0/resolution = "1920x1080"
+ * /local/domain/1/device/vdispl/0/0/req-ring-ref = "2832"
+ * /local/domain/1/device/vdispl/0/0/req-event-channel = "15"
+ * /local/domain/1/device/vdispl/0/0/evt-ring-ref = "387"
+ * /local/domain/1/device/vdispl/0/0/evt-event-channel = "16"
+ *
+ *-------------------------- Connector 1 configuration ------------------------
+ *
+ * /local/domain/1/device/vdispl/0/1/resolution = "800x600"
+ * /local/domain/1/device/vdispl/0/1/req-ring-ref = "2833"
+ * /local/domain/1/device/vdispl/0/1/req-event-channel = "17"
+ * /local/domain/1/device/vdispl/0/1/evt-ring-ref = "388"
+ * /local/domain/1/device/vdispl/0/1/evt-event-channel = "18"

>
>>> Thanks,
>>> Ian.
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xen.org
>>> https://lists.xen.org/xen-devel
>
> --
> Best Regards,
> Oleksandr Grytsov.



-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Ian Jackson]

Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
> The display backend is a user-space application which is DRM or
> Wayland client.  Generally it can be run on any domain.

Who starts the display backend ?  I'm obviously missing some of the
plumbing.  Sorry again for asking all these daft questions.

> I guess it is late to combine the patches as the protocol already acked.

I didn't find the protocol in tree when I looked.  If you need to
repost the patches, you can combine them into the same series.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Wed, Apr 5, 2017 at 5:28 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
>> The display backend is a user-space application which is DRM or
>> Wayland client.  Generally it can be run on any domain.
>
> Who starts the display backend ?  I'm obviously missing some of the
> plumbing.  Sorry again for asking all these daft questions.
>

Currently it is launched in the host startup script. I guess it will
be normal case.
Your questions are good. Because I'm quite new in Xen and they help to
understand
whether we are on right way or not.

>> I guess it is late to combine the patches as the protocol already acked.
>
> I didn't find the protocol in tree when I looked.  If you need to
> repost the patches, you can combine them into the same series.
>
> Ian.

Actually the protocol patch is submitted by Oleksandr Andrushchenko
(we are working together on protocol/backend/frontend).
And it has passed review process already and about to be committed. I
can add link to the protocol patch in following reposts.

-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Ian Jackson]

Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
> On Wed, Apr 5, 2017 at 5:28 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> > Who starts the display backend ?  I'm obviously missing some of the
> > plumbing.  Sorry again for asking all these daft questions.
> 
> Currently it is launched in the host startup script. I guess it will
> be normal case.

OK.  You said it put the virtual display on the local Wayland or MIR
display.  How does it know which local display to display on, and
how to interact with the windowing system, and so on ?

> > I didn't find the protocol in tree when I looked.  If you need to
> > repost the patches, you can combine them into the same series.
> 
> Actually the protocol patch is submitted by Oleksandr Andrushchenko
> (we are working together on protocol/backend/frontend).

I'm very sorry that I didn't notice the difference in your surnames!
How embarrassing!  My apologies!

> And it has passed review process already and about to be committed. I
> can add link to the protocol patch in following reposts.

Sure.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Wed, Apr 5, 2017 at 6:50 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
>> On Wed, Apr 5, 2017 at 5:28 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
>> > Who starts the display backend ?  I'm obviously missing some of the
>> > plumbing.  Sorry again for asking all these daft questions.
>>
>> Currently it is launched in the host startup script. I guess it will
>> be normal case.
>
> OK.  You said it put the virtual display on the local Wayland or MIR
> display.  How does it know which local display to display on, and
> how to interact with the windowing system, and so on ?

Backend and frontend operate with connectors (virtual displays). They
are identified by connector index.
The virtual display layouts, orders, on which physical display they
are located, resolustions etc. are configured
on backend side through backend configuration file. The matching
between frontend connector index and
backend virtual dispaly is done with the same configuration file.
Configuration example:

    doms = (
        { name = "Dom1"; devId = 0; connectors = ["display0", "display1"]; },
        { name = "Dom1"; devId = 1; connectors = ["display2"]; },
        { name = "Dom2"; devId = 0; connectors = ["display3"]; }
    );
    connectors = (
        { name = "display0"; screen = 0; x = 0; y = 0; w = 320; h =
240; z = 10; },
        { name = "display1"; screen = 1; x = 320; y = 0; w = 320; h =
240; z = 100; },
        { name = "display2"; x = 320; y = 0; w = 320; h = 240; }
        { name = "display3"; x = 320; y = 0; w = 320; h = 240; }
    );

Backend understands that for frontend "Dom1" devId = 0 it should
provide virtual display "display0"
which located on physical screen 0, at coordinates (0,0) and size
320x240 (z - is z-order).
Once frontend from "Dom1" is connected backend sets corresponding
connector resolution in xen store:

/local/domain/1/device/vdispl/0/0/resolution = "320x240"
/local/domain/1/device/vdispl/0/1/resolution = "320x240"

Actually for frontend only resolution matters.

Interacting with windowing system:

There are few different cases:

1. DRM mode:

In this mode the backend exclusively opens DRM device. It can be done
only without any windowing system.
We can't do match in this mode. We can't share the screen between
different domains. The backend can only
map virtual connector to physical one and provide it for frontend. For
example on the host we have a video adapter
with HDMI0, HDM1, VGA output. In this case the backend can provide
HDMI0 to "Dom1", HDMI1 to "Dom2" etc.

2. Wayland with Weston compositor:

Weston can be launched with X11 or without. With X11 it is not so
usable case because Weston looks like a X11 application:
windowing system inside windowing system but it works.

So we use Weston without X11. Unfortunately Weston itself doesn't
allow us to configure
windows position layouts etc. For this purpose we use
wayland-ivi-extension and its layer management [1].
It allows to put windows at any position, order, screen etc.

[1] https://github.com/GENIVI/wayland-ivi-extension

>> > I didn't find the protocol in tree when I looked.  If you need to
>> > repost the patches, you can combine them into the same series.
>>
>> Actually the protocol patch is submitted by Oleksandr Andrushchenko
>> (we are working together on protocol/backend/frontend).
>
> I'm very sorry that I didn't notice the difference in your surnames!
> How embarrassing!  My apologies!
>
>> And it has passed review process already and about to be committed. I
>> can add link to the protocol patch in following reposts.
>
> Sure.
>
> Ian.



-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Ian Jackson]

Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
> Backend and frontend operate with connectors (virtual displays). They
> are identified by connector index.
> The virtual display layouts, orders, on which physical display they
> are located, resolustions etc. are configured
> on backend side through backend configuration file. The matching
> between frontend connector index and
> backend virtual dispaly is done with the same configuration file.
> Configuration example:

Oh!

>     doms = (
>         { name = "Dom1"; devId = 0; connectors = ["display0", "display1"]; },
>         { name = "Dom1"; devId = 1; connectors = ["display2"]; },
>         { name = "Dom2"; devId = 0; connectors = ["display3"]; }
>     );
>     connectors = (
>         { name = "display0"; screen = 0; x = 0; y = 0; w = 320; h =
> 240; z = 10; },
>         { name = "display1"; screen = 1; x = 320; y = 0; w = 320; h =
> 240; z = 100; },
>         { name = "display2"; x = 320; y = 0; w = 320; h = 240; }
>         { name = "display3"; x = 320; y = 0; w = 320; h = 240; }
>     );
> 
> Backend understands that for frontend "Dom1" devId = 0 it should
> provide virtual display "display0"
> which located on physical screen 0, at coordinates (0,0) and size
> 320x240 (z - is z-order).
> Once frontend from "Dom1" is connected backend sets corresponding
> connector resolution in xen store:

Right.  I understand.  Thanks for the explanation.

The normal approach, for any kind of backend, with xl/libxl would be
that the xl domain configuration file (and the libxl domain
configuration struct) would specify the backend configuration
information.

I think at the very least the section "doms" there ought to be defined
in the libxl configuration file.

Is there any way (in the backend) of updating this backend
configuration dynamically ?  If so then your libxl patch could take
the per-domain configuration and update the backend config
appropriately.

I guess the z order is useful because either (i) the vdisplay protocol
supports transparency, so a "front" vdisplay can decide which bits of
a "rear" vdisplay show through or (ii) "front" vdisplays occlude
"rear" vdisplays when the appropriate connection (backend/frontend) is
in use, but the "rear" one shows through the rest of the time ?

Am I right ?  If so, is it (i) or (ii) ?

> 1. DRM mode:
> 
> In this mode the backend exclusively opens DRM device. It can be done
> only without any windowing system.
> We can't do match in this mode. We can't share the screen between
> different domains. The backend can only
> map virtual connector to physical one and provide it for frontend. For
> example on the host we have a video adapter
> with HDMI0, HDM1, VGA output. In this case the backend can provide
> HDMI0 to "Dom1", HDMI1 to "Dom2" etc.

That makes sense.  But your example configuration above doesn't seem
to specify HDMI ports, just locations on the screen.  How is this
configured, then ?

Ideally, in this use case, one would write in the xl domain config
file something like this:
  vdisplays = ["output=HDMI1"]

> 2. Wayland with Weston compositor:
> 
> Weston can be launched with X11 or without. With X11 it is not so
> usable case because Weston looks like a X11 application:
> windowing system inside windowing system but it works.

Right.  So in that case what is the function of the x/y locations
specified in the backend configuration ?  If you have windowing-system
within windowing-system then the location on the real screen is
determined by the outer (host) windowing system, surely.

> So we use Weston without X11. Unfortunately Weston itself doesn't
> allow us to configure
> windows position layouts etc. For this purpose we use
> wayland-ivi-extension and its layer management [1].
> It allows to put windows at any position, order, screen etc.

So this is for what is sometimes called "seamless" integration, where
the individual guest applications each have their own window on the
host display ?  Again, I don't see how this relates to the example
backend configuration file you showed above.

I would expect that in this configuration one would write in the xl
domain config file something like
  vdisplays=["output=wayland0,seamless"]

Please forgive me if none of this seems to make sense...

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Thu, Apr 6, 2017 at 2:17 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
>> Backend and frontend operate with connectors (virtual displays). They
>> are identified by connector index.
>> The virtual display layouts, orders, on which physical display they
>> are located, resolustions etc. are configured
>> on backend side through backend configuration file. The matching
>> between frontend connector index and
>> backend virtual dispaly is done with the same configuration file.
>> Configuration example:
>
> Oh!
>
>>     doms = (
>>         { name = "Dom1"; devId = 0; connectors = ["display0", "display1"]; },
>>         { name = "Dom1"; devId = 1; connectors = ["display2"]; },
>>         { name = "Dom2"; devId = 0; connectors = ["display3"]; }
>>     );
>>     connectors = (
>>         { name = "display0"; screen = 0; x = 0; y = 0; w = 320; h =
>> 240; z = 10; },
>>         { name = "display1"; screen = 1; x = 320; y = 0; w = 320; h =
>> 240; z = 100; },
>>         { name = "display2"; x = 320; y = 0; w = 320; h = 240; }
>>         { name = "display3"; x = 320; y = 0; w = 320; h = 240; }
>>     );
>>
>> Backend understands that for frontend "Dom1" devId = 0 it should
>> provide virtual display "display0"
>> which located on physical screen 0, at coordinates (0,0) and size
>> 320x240 (z - is z-order).
>> Once frontend from "Dom1" is connected backend sets corresponding
>> connector resolution in xen store:
>
> Right.  I understand.  Thanks for the explanation.
>
> The normal approach, for any kind of backend, with xl/libxl would be
> that the xl domain configuration file (and the libxl domain
> configuration struct) would specify the backend configuration
> information.
>
> I think at the very least the section "doms" there ought to be defined
> in the libxl configuration file.
>
> Is there any way (in the backend) of updating this backend
> configuration dynamically ?  If so then your libxl patch could take
> the per-domain configuration and update the backend config
> appropriately.

I see your point. We can keep configuration either in local for
backend config file or
in Xen store (by libxl/xl) which is more common way. In case Xen store
it is more
convenient to keep it in per-domain basis. Actually no need to update the config
dynamically, the backend can read Xen store configuration as well.

We have to think about this approach.

>
> I guess the z order is useful because either (i) the vdisplay protocol
> supports transparency, so a "front" vdisplay can decide which bits of
> a "rear" vdisplay show through or (ii) "front" vdisplays occlude
> "rear" vdisplays when the appropriate connection (backend/frontend) is
> in use, but the "rear" one shows through the rest of the time ?
>
> Am I right ?  If so, is it (i) or (ii) ?
>

I guess it is to (ii). The protocol doesn't support transparency. In
case of vdisplays
overlapping, z-order indicates which vdisplay should be on top.

>> 1. DRM mode:
>>
>> In this mode the backend exclusively opens DRM device. It can be done
>> only without any windowing system.
>> We can't do match in this mode. We can't share the screen between
>> different domains. The backend can only
>> map virtual connector to physical one and provide it for frontend. For
>> example on the host we have a video adapter
>> with HDMI0, HDM1, VGA output. In this case the backend can provide
>> HDMI0 to "Dom1", HDMI1 to "Dom2" etc.
>
> That makes sense.  But your example configuration above doesn't seem
> to specify HDMI ports, just locations on the screen.  How is this
> configured, then ?
>
> Ideally, in this use case, one would write in the xl domain config
> file something like this:
>   vdisplays = ["output=HDMI1"]

In DRM case connectors section from example is not relevant. And doms
section looks like:
    doms = (
        { name = "Dom1"; devId = 0; connectors = ["HDMI-A-0", "HDMI-B-0"]; },

Where HDMI-A-0, HDMI-B-0 names of physical DRM connectors.

>
>> 2. Wayland with Weston compositor:
>>
>> Weston can be launched with X11 or without. With X11 it is not so
>> usable case because Weston looks like a X11 application:
>> windowing system inside windowing system but it works.
>
> Right.  So in that case what is the function of the x/y locations
> specified in the backend configuration ?  If you have windowing-system
> within windowing-system then the location on the real screen is
> determined by the outer (host) windowing system, surely.
>

In this case x/y locations just ignored. Window manager (Weston) decides how
to tile the vdisplays.

>> So we use Weston without X11. Unfortunately Weston itself doesn't
>> allow us to configure
>> windows position layouts etc. For this purpose we use
>> wayland-ivi-extension and its layer management [1].
>> It allows to put windows at any position, order, screen etc.
>
> So this is for what is sometimes called "seamless" integration, where
> the individual guest applications each have their own window on the
> host display ?  Again, I don't see how this relates to the example
> backend configuration file you showed above.
>
> I would expect that in this configuration one would write in the xl
> domain config file something like
>   vdisplays=["output=wayland0,seamless"]
>

Example:

- host with backend has one display with 1024х768 resolution;
- there two domains (with name "Dom1", "Dom2") with frontends
  and they would like to share the screen like this: [][]
- in this case the example configuration will look like:

doms = (
    { name = "Dom1"; devId = 0; connectors = ["display0"]; },
    { name = "Dom2"; devId = 0; connectors = ["display1"]; },
);
connectors = (
    { name = "display0"; screen = 0; x = 0; y = 0; w = 512; h = 768; z = 0; },
    { name = "display1"; screen = 0; x = 512; y = 0; w = 512 h = 768; z = 0; },
);

> Please forgive me if none of this seems to make sense...

Your comments are valuable. I really appreciate it.

>
> Thanks,
> Ian.

-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Ian Jackson]

Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
> On Thu, Apr 6, 2017 at 2:17 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> > Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
> > I think at the very least the section "doms" there ought to be defined
> > in the libxl configuration file.
> >
> > Is there any way (in the backend) of updating this backend
> > configuration dynamically ?  If so then your libxl patch could take
> > the per-domain configuration and update the backend config
> > appropriately.
> 
> I see your point. We can keep configuration either in local for
> backend config file or in Xen store (by libxl/xl) which is more
> common way. In case Xen store it is more convenient to keep it in
> per-domain basis. Actually no need to update the config dynamically,
> the backend can read Xen store configuration as well.
> 
> We have to think about this approach.

Right.  If this can be done, I think it would be much better.  Having
the backend read xenstore would remove a layer of configuration
management and simplify the design.

> > I guess the z order is useful because either (i) the vdisplay protocol
> > supports transparency, so a "front" vdisplay can decide which bits of
> > a "rear" vdisplay show through or (ii) "front" vdisplays occlude
> > "rear" vdisplays when the appropriate connection (backend/frontend) is
> > in use, but the "rear" one shows through the rest of the time ?
> >
> > Am I right ?  If so, is it (i) or (ii) ?
> 
> I guess it is to (ii). The protocol doesn't support transparency. In
> case of vdisplays overlapping, z-order indicates which vdisplay
> should be on top.

Right.

So that would be useful for a static configuration.

> > Ideally, in this use case, one would write in the xl domain config
> > file something like this:
> >   vdisplays = ["output=HDMI1"]
> 
> In DRM case connectors section from example is not relevant. And doms
> section looks like:
>     doms = (
>         { name = "Dom1"; devId = 0; connectors = ["HDMI-A-0", "HDMI-B-0"]; },
> Where HDMI-A-0, HDMI-B-0 names of physical DRM connectors.

Right.  Sending this information to the backend via xenstore would a
best I think.

> >> 2. Wayland with Weston compositor:
> >>
> >> Weston can be launched with X11 or without. With X11 it is not so
> >> usable case because Weston looks like a X11 application:
> >> windowing system inside windowing system but it works.
> >
> > Right.  So in that case what is the function of the x/y locations
> > specified in the backend configuration ?  If you have windowing-system
> > within windowing-system then the location on the real screen is
> > determined by the outer (host) windowing system, surely.
> 
> In this case x/y locations just ignored. Window manager (Weston) decides how
> to tile the vdisplays.

Right.

> >> So we use Weston without X11. Unfortunately Weston itself doesn't
> >> allow us to configure
> >> windows position layouts etc. For this purpose we use
> >> wayland-ivi-extension and its layer management [1].
> >> It allows to put windows at any position, order, screen etc.
> >
> > So this is for what is sometimes called "seamless" integration, where
> > the individual guest applications each have their own window on the
> > host display ?  Again, I don't see how this relates to the example
> > backend configuration file you showed above.
> >
> > I would expect that in this configuration one would write in the xl
> > domain config file something like
> >   vdisplays=["output=wayland0,seamless"]
> 
> Example:
> 
> - host with backend has one display with 1024х768 resolution;
> - there two domains (with name "Dom1", "Dom2") with frontends
>   and they would like to share the screen like this: [][]
> - in this case the example configuration will look like:
> 
> doms = (
>     { name = "Dom1"; devId = 0; connectors = ["display0"]; },
>     { name = "Dom2"; devId = 0; connectors = ["display1"]; },
> );
> connectors = (
>     { name = "display0"; screen = 0; x = 0; y = 0; w = 512; h = 768; z = 0; },
>     { name = "display1"; screen = 0; x = 512; y = 0; w = 512 h = 768; z = 0; },
> );

But surely the outer window manager would want to move the individual
guest windows about ?  How is that done ?  Again, the x/y coordinates
in the backend configuration seem unhelpful.

> > Please forgive me if none of this seems to make sense...
> 
> Your comments are valuable. I really appreciate it.

You're welcome.  I hope that you don't mind me making all these rather
design-level comments at this stage.

I would suggest that before you go away and rework the code, it would
be a good idea to come up with a sketch of the configuration flows,
xenstore layouts, xl config file fragments, etc.

Then we can discuss the best way to configure things, without having
to iterate on a lot of code.

Regards,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Thu, Apr 6, 2017 at 4:03 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
>> On Thu, Apr 6, 2017 at 2:17 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
>> > Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
>> > I think at the very least the section "doms" there ought to be defined
>> > in the libxl configuration file.
>> >
>> > Is there any way (in the backend) of updating this backend
>> > configuration dynamically ?  If so then your libxl patch could take
>> > the per-domain configuration and update the backend config
>> > appropriately.
>>
>> I see your point. We can keep configuration either in local for
>> backend config file or in Xen store (by libxl/xl) which is more
>> common way. In case Xen store it is more convenient to keep it in
>> per-domain basis. Actually no need to update the config dynamically,
>> the backend can read Xen store configuration as well.
>>
>> We have to think about this approach.
>
> Right.  If this can be done, I think it would be much better.  Having
> the backend read xenstore would remove a layer of configuration
> management and simplify the design.
>
>> > I guess the z order is useful because either (i) the vdisplay protocol
>> > supports transparency, so a "front" vdisplay can decide which bits of
>> > a "rear" vdisplay show through or (ii) "front" vdisplays occlude
>> > "rear" vdisplays when the appropriate connection (backend/frontend) is
>> > in use, but the "rear" one shows through the rest of the time ?
>> >
>> > Am I right ?  If so, is it (i) or (ii) ?
>>
>> I guess it is to (ii). The protocol doesn't support transparency. In
>> case of vdisplays overlapping, z-order indicates which vdisplay
>> should be on top.
>
> Right.
>
> So that would be useful for a static configuration.
>
>> > Ideally, in this use case, one would write in the xl domain config
>> > file something like this:
>> >   vdisplays = ["output=HDMI1"]
>>
>> In DRM case connectors section from example is not relevant. And doms
>> section looks like:
>>     doms = (
>>         { name = "Dom1"; devId = 0; connectors = ["HDMI-A-0", "HDMI-B-0"]; },
>> Where HDMI-A-0, HDMI-B-0 names of physical DRM connectors.
>
> Right.  Sending this information to the backend via xenstore would a
> best I think.
>
>> >> 2. Wayland with Weston compositor:
>> >>
>> >> Weston can be launched with X11 or without. With X11 it is not so
>> >> usable case because Weston looks like a X11 application:
>> >> windowing system inside windowing system but it works.
>> >
>> > Right.  So in that case what is the function of the x/y locations
>> > specified in the backend configuration ?  If you have windowing-system
>> > within windowing-system then the location on the real screen is
>> > determined by the outer (host) windowing system, surely.
>>
>> In this case x/y locations just ignored. Window manager (Weston) decides how
>> to tile the vdisplays.
>
> Right.
>
>> >> So we use Weston without X11. Unfortunately Weston itself doesn't
>> >> allow us to configure
>> >> windows position layouts etc. For this purpose we use
>> >> wayland-ivi-extension and its layer management [1].
>> >> It allows to put windows at any position, order, screen etc.
>> >
>> > So this is for what is sometimes called "seamless" integration, where
>> > the individual guest applications each have their own window on the
>> > host display ?  Again, I don't see how this relates to the example
>> > backend configuration file you showed above.
>> >
>> > I would expect that in this configuration one would write in the xl
>> > domain config file something like
>> >   vdisplays=["output=wayland0,seamless"]
>>
>> Example:
>>
>> - host with backend has one display with 1024х768 resolution;
>> - there two domains (with name "Dom1", "Dom2") with frontends
>>   and they would like to share the screen like this: [][]
>> - in this case the example configuration will look like:
>>
>> doms = (
>>     { name = "Dom1"; devId = 0; connectors = ["display0"]; },
>>     { name = "Dom2"; devId = 0; connectors = ["display1"]; },
>> );
>> connectors = (
>>     { name = "display0"; screen = 0; x = 0; y = 0; w = 512; h = 768; z = 0; },
>>     { name = "display1"; screen = 0; x = 512; y = 0; w = 512 h = 768; z = 0; },
>> );
>
> But surely the outer window manager would want to move the individual
> guest windows about ?  How is that done ?  Again, the x/y coordinates
> in the backend configuration seem unhelpful.

We use wayland-ivi-extension in this case.  This is special Weston shell
and surfaces which can move, scale surfaces by ivi layer management.

https://github.com/GENIVI/wayland-ivi-extension
https://at.projects.genivi.org/wiki/display/WIE/01.+Quick+start

>> > Please forgive me if none of this seems to make sense...
>>
>> Your comments are valuable. I really appreciate it.
>
> You're welcome.  I hope that you don't mind me making all these rather
> design-level comments at this stage.
>
> I would suggest that before you go away and rework the code, it would
> be a good idea to come up with a sketch of the configuration flows,
> xenstore layouts, xl config file fragments, etc.
>
> Then we can discuss the best way to configure things, without having
> to iterate on a lot of code.

Great. I will do it in this way.

Thank you.

> Regards,
> Ian.



-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

Hi Ian,

After internal discussion we think that putting positions and z-orders
of virtual connectors
to the Xen store and libxl configuration is not so good idea. Because
their composition
depends on an application and usage. We consider automotive usage.
For example one of domain drives navigation system and depends on scenario
the navigation window position and size can be changed. In that case on the host
should be an instance of window manager or something like that.
The window manager will decide where to put the virtual displays.

What is important for frontend and backend are number of virtual
connectors and their
resolutions.

If it is ok, following is libxl/xl configuration proposal:

1. Configuration file:
vdispl = [ 'backend=0, devId=0, beAlloc=1, connectors=800x600,1024x768' ]

    * backend - backend domain id or name (if different from dom 0);
    * devId - device id (if different from 0);
    * beAlloc - indicated where to allocate buffers (according to protocol [1]);
    * connectors - resolutions for connectors list: 800x600 for
connector 0, 1024x768 for connector 1, etc.

2. libxl_types.idl:

libxl_connector_param = Struct("connector_param", [
    ("width", uint32),
    ("height", uint32)
    ])

libxl_device_vdispl = Struct("device_vdispl", [
    ("backend_domid", libxl_domid),
    ("backend_domname", string),
    ("devid", libxl_devid),
    ("be_alloc", bool),
    ("connectors", Array(libxl_connector_param, "num_connectors"))
    ])

libxl_connectorinfo = Struct("connectorinfo", [
    ("width", uint32),
    ("height", uint32),
    ("evtch", integer),
    ("rref", integer),
    ], dir=DIR_OUT)

libxl_vdisplinfo = Struct("vdisplinfo", [
    ("backend", string),
    ("backend_id", uint32),
    ("frontend", string),
    ("frontend_id", uint32),
    ("devid", libxl_devid),
    ("state", integer),
    ("be_alloc", bool),
    ("connectors", Array(libxl_connectorinfo, "num_connectors"))
    ], dir=DIR_OUT)

3. xl command line:

    { "vdispl-attach",
      &main_vdisplattach, 1, 1,
      "Create a new virtual display device",
      "<Domain> [devId=<Device>] [backend=<BackDomain>] [beAlloc=<BackAlloc>]"\
      " [connectors=<Resolutions>",
      "    BackAlloc - set to 1 to allow backend allocated display buffers\n"
      "    Resolutions - list of connector's resolutions in WxH format:\n"
      "800x600,1024x768"
    },
    { "vdispl-list",
      &main_vdispllist, 0, 0,
      "List virtual display devices for a domain",
      "<Domain(s)>",
    },
    { "vdispl-detach",
      &main_vdispldetach, 0, 1,
      "Destroy a domain's virtual display device",
      "<Domain> <DevId>",
    },


[1] http://marc.info/?l=xen-devel&m=149137266022490&w=2

Thanks.

-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Wei Liu]

On Mon, Apr 10, 2017 at 01:58:47PM +0300, Oleksandr Grytsov wrote:
> Hi Ian,
> 
> After internal discussion we think that putting positions and z-orders
> of virtual connectors
> to the Xen store and libxl configuration is not so good idea. Because
> their composition
> depends on an application and usage. We consider automotive usage.
> For example one of domain drives navigation system and depends on scenario
> the navigation window position and size can be changed. In that case on the host
> should be an instance of window manager or something like that.
> The window manager will decide where to put the virtual displays.
> 
> What is important for frontend and backend are number of virtual
> connectors and their
> resolutions.
> 
> If it is ok, following is libxl/xl configuration proposal:
> 
> 1. Configuration file:
> vdispl = [ 'backend=0, devId=0, beAlloc=1, connectors=800x600,1024x768' ]
> 

The connectors= syntax is ambiguous, note the comma.

(I haven't read the rest of this thread, sorry)

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Wed, Apr 12, 2017 at 7:48 PM, Wei Liu <wei.liu2@citrix.com> wrote:
> On Mon, Apr 10, 2017 at 01:58:47PM +0300, Oleksandr Grytsov wrote:
>> Hi Ian,
>>
>> After internal discussion we think that putting positions and z-orders
>> of virtual connectors
>> to the Xen store and libxl configuration is not so good idea. Because
>> their composition
>> depends on an application and usage. We consider automotive usage.
>> For example one of domain drives navigation system and depends on scenario
>> the navigation window position and size can be changed. In that case on the host
>> should be an instance of window manager or something like that.
>> The window manager will decide where to put the virtual displays.
>>
>> What is important for frontend and backend are number of virtual
>> connectors and their
>> resolutions.
>>
>> If it is ok, following is libxl/xl configuration proposal:
>>
>> 1. Configuration file:
>> vdispl = [ 'backend=0, devId=0, beAlloc=1, connectors=800x600,1024x768' ]
>>
>
> The connectors= syntax is ambiguous, note the comma.
>
> (I haven't read the rest of this thread, sorry)

Hi Wei,

You are right, Thank you for pointing it out.
I will change comma to semicolon:

vdispl = [ 'backend=0, devId=0, beAlloc=1, connectors=800x600;1024x768' ]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Ian Jackson]

Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
> After internal discussion we think that putting positions and
> z-orders of virtual connectors to the Xen store and libxl
> configuration is not so good idea. Because their composition depends
> on an application and usage. We consider automotive usage.  For
> example one of domain drives navigation system and depends on
> scenario the navigation window position and size can be changed. In
> that case on the host should be an instance of window manager or
> something like that.  The window manager will decide where to put
> the virtual displays.

Right.

> If it is ok, following is libxl/xl configuration proposal:

This looks much better to me.  (See of course Wei's point about the
connector list ambiguity.)

Can you sketch out what the rest of the system does, then ?
Presumably there has to be a different control protocol to your
backend, to tell it where to put the actual displays.  I think it
would be good if that protocol were the same for different use cases,
and documented somewhere.

So for example, when a window manager moves a window, how is the
backend told where to display the guest output ?

Your final patches should come with changese to the xl.cfg
documentation, but I think we can still discuss this in generalities
for now and then the text you write in your emails or example comments
will make a good starting point for the xl.cfg documentation.

Thanks,
Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
>> After internal discussion we think that putting positions and
>> z-orders of virtual connectors to the Xen store and libxl
>> configuration is not so good idea. Because their composition depends
>> on an application and usage. We consider automotive usage.  For
>> example one of domain drives navigation system and depends on
>> scenario the navigation window position and size can be changed. In
>> that case on the host should be an instance of window manager or
>> something like that.  The window manager will decide where to put
>> the virtual displays.
>
> Right.
>
>> If it is ok, following is libxl/xl configuration proposal:
>
> This looks much better to me.  (See of course Wei's point about the
> connector list ambiguity.)
>
> Can you sketch out what the rest of the system does, then ?
> Presumably there has to be a different control protocol to your
> backend, to tell it where to put the actual displays.  I think it
> would be good if that protocol were the same for different use cases,
> and documented somewhere.

Well, yes there will be some protocol to communicate with the window manager.
We consider to use wayland and weston as display system.
The idea is the backend and other applications on the host render content onto
wayland surfaces. Each surface will have  a unique identifier or attribute
(like multimedia, navigation etc.). The window manager based on these
attributes, configured policies and scenarios will set positions and geometries
for the surfaces.

> So for example, when a window manager moves a window, how is the
> backend told where to display the guest output ?

The backend will create the wayland surface and tell the window manager
the attribute it has. All rest will be done by the window manager.

> Your final patches should come with changese to the xl.cfg
> documentation, but I think we can still discuss this in generalities
> for now and then the text you write in your emails or example comments
> will make a good starting point for the xl.cfg documentation.

In my opinion the details how the virtual displays are placed on the host
should be separated from xl configuration. Because it really depends on
backend implementation. We have generalized display protocol (displif.h).
There could be different frontend/backend implementations and each
implementation will require its own configuration.
That's why in xl.cfg should be only parameters related to display protocol
namely resolutions of virtual connectors.


> Thanks,
> Ian.

-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Fri, Apr 14, 2017 at 1:12 PM, Oleksandr Grytsov <al1img@gmail.com> wrote:
> On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
>> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
>>> After internal discussion we think that putting positions and
>>> z-orders of virtual connectors to the Xen store and libxl
>>> configuration is not so good idea. Because their composition depends
>>> on an application and usage. We consider automotive usage.  For
>>> example one of domain drives navigation system and depends on
>>> scenario the navigation window position and size can be changed. In
>>> that case on the host should be an instance of window manager or
>>> something like that.  The window manager will decide where to put
>>> the virtual displays.
>>
>> Right.
>>
>>> If it is ok, following is libxl/xl configuration proposal:
>>
>> This looks much better to me.  (See of course Wei's point about the
>> connector list ambiguity.)
>>
>> Can you sketch out what the rest of the system does, then ?
>> Presumably there has to be a different control protocol to your
>> backend, to tell it where to put the actual displays.  I think it
>> would be good if that protocol were the same for different use cases,
>> and documented somewhere.
>
> Well, yes there will be some protocol to communicate with the window manager.
> We consider to use wayland and weston as display system.
> The idea is the backend and other applications on the host render content onto
> wayland surfaces. Each surface will have  a unique identifier or attribute
> (like multimedia, navigation etc.). The window manager based on these
> attributes, configured policies and scenarios will set positions and geometries
> for the surfaces.
>
>> So for example, when a window manager moves a window, how is the
>> backend told where to display the guest output ?
>
> The backend will create the wayland surface and tell the window manager
> the attribute it has. All rest will be done by the window manager.
>
>> Your final patches should come with changese to the xl.cfg
>> documentation, but I think we can still discuss this in generalities
>> for now and then the text you write in your emails or example comments
>> will make a good starting point for the xl.cfg documentation.
>
> In my opinion the details how the virtual displays are placed on the host
> should be separated from xl configuration. Because it really depends on
> backend implementation. We have generalized display protocol (displif.h).
> There could be different frontend/backend implementations and each
> implementation will require its own configuration.
> That's why in xl.cfg should be only parameters related to display protocol
> namely resolutions of virtual connectors.
>
>
>> Thanks,
>> Ian.
>
> --
> Best Regards,
> Oleksandr Grytsov.

ping

Any objection about to have only connector's resolutions in xl.cfg?

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Ian Jackson]

Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
> On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> > Can you sketch out what the rest of the system does, then ?
> > Presumably there has to be a different control protocol to your
> > backend, to tell it where to put the actual displays.  I think it
> > would be good if that protocol were the same for different use cases,
> > and documented somewhere.
> 
> Well, yes there will be some protocol to communicate with the window
> manager.  We consider to use wayland and weston as display system.
> The idea is the backend and other applications on the host render
> content onto wayland surfaces. Each surface will have a unique
> identifier or attribute (like multimedia, navigation etc.). The
> window manager based on these attributes, configured policies and
> scenarios will set positions and geometries for the surfaces.

That seems to make some kind of sense.  However, surely that means
that the backend needs to be told the "identifier or attribute" to
assign to the surfaces it is creating ?

Ie that would have to be in here somewhere
 vdispl = [ 'backend=0, devId=0, beAlloc=1, connectors=800x600,1024x768' ]

> > So for example, when a window manager moves a window, how is the
> > backend told where to display the guest output ?
> 
> The backend will create the wayland surface and tell the window manager
> the attribute it has. All rest will be done by the window manager.

Or to put my comment above another way: if there are several such
surfaces, how does the window manager tell which is intended for
what ?

> In my opinion the details how the virtual displays are placed on the host
> should be separated from xl configuration. Because it really depends on
> backend implementation. We have generalized display protocol (displif.h).
> There could be different frontend/backend implementations and each
> implementation will require its own configuration.
> That's why in xl.cfg should be only parameters related to display protocol
> namely resolutions of virtual connectors.

xl.cfg normally also contains information necessary for plumbing the
virtual device back to some physical hardware.

So for example, the disk specification specifies not only the names of
the virtual devices, but also the corresponding host physical devices
(or files), host data storage format, etc.

As I say I think in this case we probably want the configuration file
to assign names or ids to the backend surfaces.

Ian.

PS: Sorry for the slow reply.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Tue, May 2, 2017 at 5:28 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
> Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
>> On Thu, Apr 13, 2017 at 3:54 PM, Ian Jackson <ian.jackson@eu.citrix.com> wrote:
>> > Can you sketch out what the rest of the system does, then ?
>> > Presumably there has to be a different control protocol to your
>> > backend, to tell it where to put the actual displays.  I think it
>> > would be good if that protocol were the same for different use cases,
>> > and documented somewhere.
>>
>> Well, yes there will be some protocol to communicate with the window
>> manager.  We consider to use wayland and weston as display system.
>> The idea is the backend and other applications on the host render
>> content onto wayland surfaces. Each surface will have a unique
>> identifier or attribute (like multimedia, navigation etc.). The
>> window manager based on these attributes, configured policies and
>> scenarios will set positions and geometries for the surfaces.
>
> That seems to make some kind of sense.  However, surely that means
> that the backend needs to be told the "identifier or attribute" to
> assign to the surfaces it is creating ?
>
> Ie that would have to be in here somewhere
>  vdispl = [ 'backend=0, devId=0, beAlloc=1, connectors=800x600,1024x768' ]
>
>> > So for example, when a window manager moves a window, how is the
>> > backend told where to display the guest output ?
>>
>> The backend will create the wayland surface and tell the window manager
>> the attribute it has. All rest will be done by the window manager.
>
> Or to put my comment above another way: if there are several such
> surfaces, how does the window manager tell which is intended for
> what ?
>
>> In my opinion the details how the virtual displays are placed on the host
>> should be separated from xl configuration. Because it really depends on
>> backend implementation. We have generalized display protocol (displif.h).
>> There could be different frontend/backend implementations and each
>> implementation will require its own configuration.
>> That's why in xl.cfg should be only parameters related to display protocol
>> namely resolutions of virtual connectors.
>
> xl.cfg normally also contains information necessary for plumbing the
> virtual device back to some physical hardware.
>
> So for example, the disk specification specifies not only the names of
> the virtual devices, but also the corresponding host physical devices
> (or files), host data storage format, etc.
>
> As I say I think in this case we probably want the configuration file
> to assign names or ids to the backend surfaces.
>
> Ian.
>
> PS: Sorry for the slow reply.

I considered that frontend domain name and surface index is a unique surface
identifier. Like following:

Surface with index 0 from DomU should be placed at x, y, display 0  etc.

Surely, we can add identifier into xl.cfg to make it more generic or more
readable from user point of view. In this case the config line could look like:

vdispl = [ 'backend=0, devId=0, beAlloc=1,
connectors=id0:800x600,id1:1024x768' ]

id0, id1 could be either integer id or string name. For example in our case it
could be wayland surface id.



-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Ian Jackson]

Oleksandr Grytsov writes ("Re: [Xen-devel] [PATCH v1 0/2] libxl: add PV display device driver interface"):
> I considered that frontend domain name and surface index is a unique surface
> identifier. Like following:
> 
> Surface with index 0 from DomU should be placed at x, y, display 0  etc.

Right, I see.

The difficulty with that is that as vdisplays might be added and
removed, there is not really a stable well-defined index.  At least,
if there is, then it would have to be specifiable in the config.

Eg, what if you decide to get rid of surface index 0 ?  Then there
would have to still be surface index 1.  So the indices have to be
settable.

> Surely, we can add identifier into xl.cfg to make it more generic or more
> readable from user point of view. In this case the config line could look like:
> 
> vdispl = [ 'backend=0, devId=0, beAlloc=1,
> connectors=id0:800x600,id1:1024x768' ]
> 
> id0, id1 could be either integer id or string name. For example in our case it
> could be wayland surface id.

Right.  I think that would solve this problem.  I don't have an
opinion about whether these things should be integers or strings, but
you should pick one in your design.  If they are to be strings you
should specify a (fairly restrictive) character set.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

Hi All,

Here is configuration proposal with connector (surface) id:

1. Configuration file:
vdispl = [ 'backend=0, devId=0, beAlloc=1,
connectors=id0:800x600;id1:1024x768' ]

    * backend - backend domain id or name (if different from dom 0);
    * devId - device id (if different from 0);
    * beAlloc - indicated where to allocate buffers (according to protocol [1]);
    * connectors - list of available connectors: each connector
description consists of
      string id and resolution separated by colon:
        * id0, id1 - unique connector id. It is string which may contain:
            - uppercase [A-Z] and lowercase [a-z] English alphabet characters;
            - digits 0-9;
            - special symbols except: space : ; , ' "
        * 800x600, 1024x768 - connectors resolutions.

2. libxl_types.idl:

libxl_connector_param = Struct("connector_param", [
    ("id", string),
    ("width", uint32),
    ("height", uint32)
    ])

libxl_device_vdispl = Struct("device_vdispl", [
    ("backend_domid", libxl_domid),
    ("backend_domname", string),
    ("devid", libxl_devid),
    ("be_alloc", bool),
    ("connectors", Array(libxl_connector_param, "num_connectors"))
    ])

libxl_connectorinfo = Struct("connectorinfo", [
    ("id", string),
    ("width", uint32),
    ("height", uint32),
    ("evtch", integer),
    ("rref", integer),
    ], dir=DIR_OUT)

libxl_vdisplinfo = Struct("vdisplinfo", [
    ("backend", string),
    ("backend_id", uint32),
    ("frontend", string),
    ("frontend_id", uint32),
    ("devid", libxl_devid),
    ("state", integer),
    ("be_alloc", bool),
    ("connectors", Array(libxl_connectorinfo, "num_connectors"))
    ], dir=DIR_OUT)

3. xl command line:

    { "vdispl-attach",
      &main_vdisplattach, 1, 1,
      "Create a new virtual display device",
      "<Domain> [devId=<Device>] [backend=<BackDomain>] [beAlloc=<BackAlloc>]"\
      " [connectors=<Connectors>]",
      "    BackAlloc - set to 1 to allow backend allocated display buffers\n"
      "    Connectors - list of connector's description in ID:WxH format,\n"
      "    Where: ID - unique connector ID, W - connector width, H -
connector height:\n"
      "         id0:800x600;id1:1024x768"
    },
    { "vdispl-list",
      &main_vdispllist, 0, 0,
      "List virtual display devices for a domain",
      "<Domain(s)>",
    },
    { "vdispl-detach",
      &main_vdispldetach, 0, 1,
      "Destroy a domain's virtual display device",
      "<Domain> <DevId>",
    },

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Thu, May 4, 2017 at 11:49 AM, Oleksandr Grytsov <al1img@gmail.com> wrote:
> Hi All,
>
> Here is configuration proposal with connector (surface) id:
>
> 1. Configuration file:
> vdispl = [ 'backend=0, devId=0, beAlloc=1,
> connectors=id0:800x600;id1:1024x768' ]
>
>     * backend - backend domain id or name (if different from dom 0);
>     * devId - device id (if different from 0);
>     * beAlloc - indicated where to allocate buffers (according to protocol [1]);
>     * connectors - list of available connectors: each connector
> description consists of
>       string id and resolution separated by colon:
>         * id0, id1 - unique connector id. It is string which may contain:
>             - uppercase [A-Z] and lowercase [a-z] English alphabet characters;
>             - digits 0-9;
>             - special symbols except: space : ; , ' "
>         * 800x600, 1024x768 - connectors resolutions.
>
> 2. libxl_types.idl:
>
> libxl_connector_param = Struct("connector_param", [
>     ("id", string),
>     ("width", uint32),
>     ("height", uint32)
>     ])
>
> libxl_device_vdispl = Struct("device_vdispl", [
>     ("backend_domid", libxl_domid),
>     ("backend_domname", string),
>     ("devid", libxl_devid),
>     ("be_alloc", bool),
>     ("connectors", Array(libxl_connector_param, "num_connectors"))
>     ])
>
> libxl_connectorinfo = Struct("connectorinfo", [
>     ("id", string),
>     ("width", uint32),
>     ("height", uint32),
>     ("evtch", integer),
>     ("rref", integer),
>     ], dir=DIR_OUT)
>
> libxl_vdisplinfo = Struct("vdisplinfo", [
>     ("backend", string),
>     ("backend_id", uint32),
>     ("frontend", string),
>     ("frontend_id", uint32),
>     ("devid", libxl_devid),
>     ("state", integer),
>     ("be_alloc", bool),
>     ("connectors", Array(libxl_connectorinfo, "num_connectors"))
>     ], dir=DIR_OUT)
>
> 3. xl command line:
>
>     { "vdispl-attach",
>       &main_vdisplattach, 1, 1,
>       "Create a new virtual display device",
>       "<Domain> [devId=<Device>] [backend=<BackDomain>] [beAlloc=<BackAlloc>]"\
>       " [connectors=<Connectors>]",
>       "    BackAlloc - set to 1 to allow backend allocated display buffers\n"
>       "    Connectors - list of connector's description in ID:WxH format,\n"
>       "    Where: ID - unique connector ID, W - connector width, H -
> connector height:\n"
>       "         id0:800x600;id1:1024x768"
>     },
>     { "vdispl-list",
>       &main_vdispllist, 0, 0,
>       "List virtual display devices for a domain",
>       "<Domain(s)>",
>     },
>     { "vdispl-detach",
>       &main_vdispldetach, 0, 1,
>       "Destroy a domain's virtual display device",
>       "<Domain> <DevId>",
>     },

Ping

-- 
Best Regards,
Oleksandr Grytsov.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [PATCH v1 0/2] libxl: add PV display device driver interface

[Oleksandr Grytsov]

On Fri, May 12, 2017 at 3:12 PM, Oleksandr Grytsov <al1img@gmail.com> wrote:
> On Thu, May 4, 2017 at 11:49 AM, Oleksandr Grytsov <al1img@gmail.com> wrote:
>> Hi All,
>>
>> Here is configuration proposal with connector (surface) id:
>>
>> 1. Configuration file:
>> vdispl = [ 'backend=0, devId=0, beAlloc=1,
>> connectors=id0:800x600;id1:1024x768' ]
>>
>>     * backend - backend domain id or name (if different from dom 0);
>>     * devId - device id (if different from 0);
>>     * beAlloc - indicated where to allocate buffers (according to protocol [1]);
>>     * connectors - list of available connectors: each connector
>> description consists of
>>       string id and resolution separated by colon:
>>         * id0, id1 - unique connector id. It is string which may contain:
>>             - uppercase [A-Z] and lowercase [a-z] English alphabet characters;
>>             - digits 0-9;
>>             - special symbols except: space : ; , ' "
>>         * 800x600, 1024x768 - connectors resolutions.
>>
>> 2. libxl_types.idl:
>>
>> libxl_connector_param = Struct("connector_param", [
>>     ("id", string),
>>     ("width", uint32),
>>     ("height", uint32)
>>     ])
>>
>> libxl_device_vdispl = Struct("device_vdispl", [
>>     ("backend_domid", libxl_domid),
>>     ("backend_domname", string),
>>     ("devid", libxl_devid),
>>     ("be_alloc", bool),
>>     ("connectors", Array(libxl_connector_param, "num_connectors"))
>>     ])
>>
>> libxl_connectorinfo = Struct("connectorinfo", [
>>     ("id", string),
>>     ("width", uint32),
>>     ("height", uint32),
>>     ("evtch", integer),
>>     ("rref", integer),
>>     ], dir=DIR_OUT)
>>
>> libxl_vdisplinfo = Struct("vdisplinfo", [
>>     ("backend", string),
>>     ("backend_id", uint32),
>>     ("frontend", string),
>>     ("frontend_id", uint32),
>>     ("devid", libxl_devid),
>>     ("state", integer),
>>     ("be_alloc", bool),
>>     ("connectors", Array(libxl_connectorinfo, "num_connectors"))
>>     ], dir=DIR_OUT)
>>
>> 3. xl command line:
>>
>>     { "vdispl-attach",
>>       &main_vdisplattach, 1, 1,
>>       "Create a new virtual display device",
>>       "<Domain> [devId=<Device>] [backend=<BackDomain>] [beAlloc=<BackAlloc>]"\
>>       " [connectors=<Connectors>]",
>>       "    BackAlloc - set to 1 to allow backend allocated display buffers\n"
>>       "    Connectors - list of connector's description in ID:WxH format,\n"
>>       "    Where: ID - unique connector ID, W - connector width, H -
>> connector height:\n"
>>       "         id0:800x600;id1:1024x768"
>>     },
>>     { "vdispl-list",
>>       &main_vdispllist, 0, 0,
>>       "List virtual display devices for a domain",
>>       "<Domain(s)>",
>>     },
>>     { "vdispl-detach",
>>       &main_vdispldetach, 0, 1,
>>       "Destroy a domain's virtual display device",
>>       "<Domain> <DevId>",
>>     },
>
> Ping
>
> --
> Best Regards,
> Oleksandr Grytsov.

Hi All,

Any objections about the configuration?

If not I will start working on implementation.

Thanks.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel