* [PATCH v1 0/2] libxl: add PV display device driver interface @ 2017-04-05 10:03 Oleksandr Grytsov 2017-04-05 10:03 ` [PATCH v1 1/2] " Oleksandr Grytsov ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-05 10:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, ian.jackson, wei.liu2, Oleksandr Grytsov, andr2000 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH v1 1/2] libxl: add PV display device driver interface 2017-04-05 10:03 [PATCH v1 0/2] libxl: add PV display device driver interface Oleksandr Grytsov @ 2017-04-05 10:03 ` Oleksandr Grytsov 2017-04-05 10:03 ` [PATCH v1 2/2] xl: add PV display device commands Oleksandr Grytsov 2017-04-05 11:05 ` [PATCH v1 0/2] libxl: add PV display device driver interface Ian Jackson 2 siblings, 0 replies; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-05 10:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, ian.jackson, wei.liu2, Oleksandr Grytsov, andr2000 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 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [PATCH v1 2/2] xl: add PV display device commands 2017-04-05 10:03 [PATCH v1 0/2] libxl: add PV display device driver interface Oleksandr Grytsov 2017-04-05 10:03 ` [PATCH v1 1/2] " Oleksandr Grytsov @ 2017-04-05 10:03 ` Oleksandr Grytsov 2017-04-05 11:05 ` [PATCH v1 0/2] libxl: add PV display device driver interface Ian Jackson 2 siblings, 0 replies; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-05 10:03 UTC (permalink / raw) To: xen-devel; +Cc: jgross, ian.jackson, wei.liu2, Oleksandr Grytsov, andr2000 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 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-05 10:03 [PATCH v1 0/2] libxl: add PV display device driver interface Oleksandr Grytsov 2017-04-05 10:03 ` [PATCH v1 1/2] " Oleksandr Grytsov 2017-04-05 10:03 ` [PATCH v1 2/2] xl: add PV display device commands Oleksandr Grytsov @ 2017-04-05 11:05 ` Ian Jackson 2017-04-05 12:25 ` al1img . 2 siblings, 1 reply; 29+ messages in thread From: Ian Jackson @ 2017-04-05 11:05 UTC (permalink / raw) To: Oleksandr Grytsov Cc: jgross, xen-devel, wei.liu2, Oleksandr Grytsov, andr2000 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-05 11:05 ` [PATCH v1 0/2] libxl: add PV display device driver interface Ian Jackson @ 2017-04-05 12:25 ` al1img . 2017-04-05 13:49 ` Ian Jackson 0 siblings, 1 reply; 29+ messages in thread From: al1img . @ 2017-04-05 12:25 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, xen-devel, Wei Liu, Oleksandr Grytsov, Oleksandr Andrushchenko 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-05 12:25 ` al1img . @ 2017-04-05 13:49 ` Ian Jackson 2017-04-05 14:00 ` Konrad Rzeszutek Wilk 0 siblings, 1 reply; 29+ messages in thread From: Ian Jackson @ 2017-04-05 13:49 UTC (permalink / raw) To: al1img . Cc: Juergen Gross, xen-devel, Wei Liu, Oleksandr Grytsov, Oleksandr Andrushchenko 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-05 13:49 ` Ian Jackson @ 2017-04-05 14:00 ` Konrad Rzeszutek Wilk 2017-04-05 14:18 ` Oleksandr Grytsov 0 siblings, 1 reply; 29+ messages in thread From: Konrad Rzeszutek Wilk @ 2017-04-05 14:00 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, al1img ., Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-05 14:00 ` Konrad Rzeszutek Wilk @ 2017-04-05 14:18 ` Oleksandr Grytsov 2017-04-05 14:28 ` Oleksandr Grytsov 2017-04-05 14:28 ` Ian Jackson 0 siblings, 2 replies; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-05 14:18 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Ian Jackson, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-05 14:18 ` Oleksandr Grytsov @ 2017-04-05 14:28 ` Oleksandr Grytsov 2017-04-05 14:28 ` Ian Jackson 1 sibling, 0 replies; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-05 14:28 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Ian Jackson, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-05 14:18 ` Oleksandr Grytsov 2017-04-05 14:28 ` Oleksandr Grytsov @ 2017-04-05 14:28 ` Ian Jackson 2017-04-05 14:53 ` Oleksandr Grytsov 1 sibling, 1 reply; 29+ messages in thread From: Ian Jackson @ 2017-04-05 14:28 UTC (permalink / raw) To: Oleksandr Grytsov Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-05 14:28 ` Ian Jackson @ 2017-04-05 14:53 ` Oleksandr Grytsov 2017-04-05 15:50 ` Ian Jackson 0 siblings, 1 reply; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-05 14:53 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-05 14:53 ` Oleksandr Grytsov @ 2017-04-05 15:50 ` Ian Jackson 2017-04-06 9:22 ` Oleksandr Grytsov 0 siblings, 1 reply; 29+ messages in thread From: Ian Jackson @ 2017-04-05 15:50 UTC (permalink / raw) To: Oleksandr Grytsov Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-05 15:50 ` Ian Jackson @ 2017-04-06 9:22 ` Oleksandr Grytsov 2017-04-06 11:17 ` Ian Jackson 0 siblings, 1 reply; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-06 9:22 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-06 9:22 ` Oleksandr Grytsov @ 2017-04-06 11:17 ` Ian Jackson 2017-04-06 12:42 ` Oleksandr Grytsov 0 siblings, 1 reply; 29+ messages in thread From: Ian Jackson @ 2017-04-06 11:17 UTC (permalink / raw) To: Oleksandr Grytsov Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-06 11:17 ` Ian Jackson @ 2017-04-06 12:42 ` Oleksandr Grytsov 2017-04-06 13:03 ` Ian Jackson 0 siblings, 1 reply; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-06 12:42 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-06 12:42 ` Oleksandr Grytsov @ 2017-04-06 13:03 ` Ian Jackson 2017-04-06 13:27 ` Oleksandr Grytsov 0 siblings, 1 reply; 29+ messages in thread From: Ian Jackson @ 2017-04-06 13:03 UTC (permalink / raw) To: Oleksandr Grytsov Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-06 13:03 ` Ian Jackson @ 2017-04-06 13:27 ` Oleksandr Grytsov 2017-04-10 10:58 ` Oleksandr Grytsov 0 siblings, 1 reply; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-06 13:27 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-06 13:27 ` Oleksandr Grytsov @ 2017-04-10 10:58 ` Oleksandr Grytsov 2017-04-12 16:48 ` Wei Liu 2017-04-13 12:54 ` Ian Jackson 0 siblings, 2 replies; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-10 10:58 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-10 10:58 ` Oleksandr Grytsov @ 2017-04-12 16:48 ` Wei Liu 2017-04-13 8:41 ` Oleksandr Grytsov 2017-04-13 12:54 ` Ian Jackson 1 sibling, 1 reply; 29+ messages in thread From: Wei Liu @ 2017-04-12 16:48 UTC (permalink / raw) To: Oleksandr Grytsov Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Ian Jackson, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-12 16:48 ` Wei Liu @ 2017-04-13 8:41 ` Oleksandr Grytsov 0 siblings, 0 replies; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-13 8:41 UTC (permalink / raw) To: Wei Liu Cc: Juergen Gross, Oleksandr Andrushchenko, Ian Jackson, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-10 10:58 ` Oleksandr Grytsov 2017-04-12 16:48 ` Wei Liu @ 2017-04-13 12:54 ` Ian Jackson 2017-04-14 10:12 ` Oleksandr Grytsov 1 sibling, 1 reply; 29+ messages in thread From: Ian Jackson @ 2017-04-13 12:54 UTC (permalink / raw) To: Oleksandr Grytsov Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-13 12:54 ` Ian Jackson @ 2017-04-14 10:12 ` Oleksandr Grytsov 2017-04-26 10:15 ` Oleksandr Grytsov 2017-05-02 14:28 ` Ian Jackson 0 siblings, 2 replies; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-14 10:12 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-14 10:12 ` Oleksandr Grytsov @ 2017-04-26 10:15 ` Oleksandr Grytsov 2017-05-02 14:28 ` Ian Jackson 1 sibling, 0 replies; 29+ messages in thread From: Oleksandr Grytsov @ 2017-04-26 10:15 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-04-14 10:12 ` Oleksandr Grytsov 2017-04-26 10:15 ` Oleksandr Grytsov @ 2017-05-02 14:28 ` Ian Jackson 2017-05-03 15:08 ` Oleksandr Grytsov 1 sibling, 1 reply; 29+ messages in thread From: Ian Jackson @ 2017-05-02 14:28 UTC (permalink / raw) To: Oleksandr Grytsov Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-05-02 14:28 ` Ian Jackson @ 2017-05-03 15:08 ` Oleksandr Grytsov 2017-05-03 15:13 ` Ian Jackson 0 siblings, 1 reply; 29+ messages in thread From: Oleksandr Grytsov @ 2017-05-03 15:08 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-05-03 15:08 ` Oleksandr Grytsov @ 2017-05-03 15:13 ` Ian Jackson 2017-05-04 8:49 ` Oleksandr Grytsov 0 siblings, 1 reply; 29+ messages in thread From: Ian Jackson @ 2017-05-03 15:13 UTC (permalink / raw) To: Oleksandr Grytsov Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-05-03 15:13 ` Ian Jackson @ 2017-05-04 8:49 ` Oleksandr Grytsov 2017-05-12 12:12 ` Oleksandr Grytsov 0 siblings, 1 reply; 29+ messages in thread From: Oleksandr Grytsov @ 2017-05-04 8:49 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-05-04 8:49 ` Oleksandr Grytsov @ 2017-05-12 12:12 ` Oleksandr Grytsov 2017-05-18 11:42 ` Oleksandr Grytsov 0 siblings, 1 reply; 29+ messages in thread From: Oleksandr Grytsov @ 2017-05-12 12:12 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v1 0/2] libxl: add PV display device driver interface 2017-05-12 12:12 ` Oleksandr Grytsov @ 2017-05-18 11:42 ` Oleksandr Grytsov 0 siblings, 0 replies; 29+ messages in thread From: Oleksandr Grytsov @ 2017-05-18 11:42 UTC (permalink / raw) To: Ian Jackson Cc: Juergen Gross, Wei Liu, Oleksandr Andrushchenko, Oleksandr Grytsov, xen-devel 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2017-05-18 11:42 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-04-05 10:03 [PATCH v1 0/2] libxl: add PV display device driver interface Oleksandr Grytsov 2017-04-05 10:03 ` [PATCH v1 1/2] " Oleksandr Grytsov 2017-04-05 10:03 ` [PATCH v1 2/2] xl: add PV display device commands Oleksandr Grytsov 2017-04-05 11:05 ` [PATCH v1 0/2] libxl: add PV display device driver interface Ian Jackson 2017-04-05 12:25 ` al1img . 2017-04-05 13:49 ` Ian Jackson 2017-04-05 14:00 ` Konrad Rzeszutek Wilk 2017-04-05 14:18 ` Oleksandr Grytsov 2017-04-05 14:28 ` Oleksandr Grytsov 2017-04-05 14:28 ` Ian Jackson 2017-04-05 14:53 ` Oleksandr Grytsov 2017-04-05 15:50 ` Ian Jackson 2017-04-06 9:22 ` Oleksandr Grytsov 2017-04-06 11:17 ` Ian Jackson 2017-04-06 12:42 ` Oleksandr Grytsov 2017-04-06 13:03 ` Ian Jackson 2017-04-06 13:27 ` Oleksandr Grytsov 2017-04-10 10:58 ` Oleksandr Grytsov 2017-04-12 16:48 ` Wei Liu 2017-04-13 8:41 ` Oleksandr Grytsov 2017-04-13 12:54 ` Ian Jackson 2017-04-14 10:12 ` Oleksandr Grytsov 2017-04-26 10:15 ` Oleksandr Grytsov 2017-05-02 14:28 ` Ian Jackson 2017-05-03 15:08 ` Oleksandr Grytsov 2017-05-03 15:13 ` Ian Jackson 2017-05-04 8:49 ` Oleksandr Grytsov 2017-05-12 12:12 ` Oleksandr Grytsov 2017-05-18 11:42 ` Oleksandr Grytsov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.