* [Qemu-devel] [Xen-devel][PATCH] configure: introduce --enable-xen-fb-backend
@ 2017-04-11 9:35 ` Oleksandr Andrushchenko
0 siblings, 0 replies; 16+ messages in thread
From: Oleksandr Andrushchenko @ 2017-04-11 9:35 UTC (permalink / raw)
To: qemu-devel, xen-devel
Cc: joculator, al1img, vlad.babchuk, andrii.anisov, olekstysh,
andr2000, sstabellini, anthony.perard, Oleksandr Andrushchenko
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
For some use cases when Xen framebuffer/input backend
is not a part of Qemu it is required to disable it,
because of conflicting access to input/display devices.
Introduce additional configuration option for explicit
input/display control.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
configure | 18 ++++++++++++++++++
hw/display/Makefile.objs | 2 +-
hw/xen/xen_backend.c | 2 ++
hw/xenpv/xen_machine_pv.c | 4 ++++
4 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 476210b1b93f..b805cb908f03 100755
--- a/configure
+++ b/configure
@@ -220,6 +220,7 @@ xen=""
xen_ctrl_version=""
xen_pv_domain_build="no"
xen_pci_passthrough=""
+xen_fb_backend=""
linux_aio=""
cap_ng=""
attr=""
@@ -909,6 +910,10 @@ for opt do
;;
--enable-xen-pv-domain-build) xen_pv_domain_build="yes"
;;
+ --disable-xen-fb-backend) xen_fb_backend="no"
+ ;;
+ --enable-xen-fb-backend) xen_fb_backend="yes"
+ ;;
--disable-brlapi) brlapi="no"
;;
--enable-brlapi) brlapi="yes"
@@ -1368,6 +1373,7 @@ disabled with --disable-FEATURE, default is enabled if available:
virtfs VirtFS
xen xen backend driver support
xen-pci-passthrough
+ xen-fb-backend framebuffer/input backend support
brlapi BrlAPI (Braile)
curl curl connectivity
fdt fdt device tree
@@ -2213,6 +2219,15 @@ if test "$xen_pv_domain_build" = "yes" &&
"which requires Xen support."
fi
+if test "$xen_fb_backend" != "no"; then
+ if test "$xen" = "yes"; then
+ xen_fb_backend=yes
+ else
+ error_exit "User requested feature Xen framebufer backend support" \
+ " but this feature requires Xen support."
+ fi
+fi
+
##########################################
# Sparse probe
if test "$sparse" != "no" ; then
@@ -5444,6 +5459,9 @@ if test "$xen" = "yes" ; then
if test "$xen_pv_domain_build" = "yes" ; then
echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
fi
+ if test "$xen_fb_backend" = "yes" ; then
+ echo "CONFIG_XEN_FB_BACKEND=y" >> $config_host_mak
+ fi
fi
if test "$linux_aio" = "yes" ; then
echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 063889beaf4a..f5ec97ed4f48 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -5,7 +5,7 @@ common-obj-$(CONFIG_JAZZ_LED) += jazz_led.o
common-obj-$(CONFIG_PL110) += pl110.o
common-obj-$(CONFIG_SSD0303) += ssd0303.o
common-obj-$(CONFIG_SSD0323) += ssd0323.o
-common-obj-$(CONFIG_XEN_BACKEND) += xenfb.o
+common-obj-$(CONFIG_XEN_FB_BACKEND) += xenfb.o
common-obj-$(CONFIG_VGA_PCI) += vga-pci.o
common-obj-$(CONFIG_VGA_ISA) += vga-isa.o
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index d1190041ae12..5146cbba6ca5 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -582,7 +582,9 @@ void xen_be_register_common(void)
xen_set_dynamic_sysbus();
xen_be_register("console", &xen_console_ops);
+#ifdef CONFIG_XEN_FB_BACKEND
xen_be_register("vkbd", &xen_kbdmouse_ops);
+#endif
xen_be_register("qdisk", &xen_blkdev_ops);
#ifdef CONFIG_USB_LIBUSB
xen_be_register("qusb", &xen_usb_ops);
diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index 79aef4ecc37b..b731344c3f0a 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -68,7 +68,9 @@ static void xen_init_pv(MachineState *machine)
}
xen_be_register_common();
+#ifdef CONFIG_XEN_FB_BACKEND
xen_be_register("vfb", &xen_framebuffer_ops);
+#endif
xen_be_register("qnic", &xen_netdev_ops);
/* configure framebuffer */
@@ -95,8 +97,10 @@ static void xen_init_pv(MachineState *machine)
/* config cleanup hook */
atexit(xen_config_cleanup);
+#ifdef CONFIG_XEN_FB_BACKEND
/* setup framebuffer */
xen_init_display(xen_domid);
+#endif
}
static void xenpv_machine_init(MachineClass *mc)
--
2.7.4
^ permalink raw reply related [flat|nested] 16+ messages in thread
* [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend
@ 2017-04-11 9:35 ` Oleksandr Andrushchenko
0 siblings, 0 replies; 16+ messages in thread
From: Oleksandr Andrushchenko @ 2017-04-11 9:35 UTC (permalink / raw)
To: qemu-devel, xen-devel
Cc: sstabellini, Oleksandr Andrushchenko, vlad.babchuk,
andrii.anisov, olekstysh, andr2000, al1img, anthony.perard,
joculator
From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
For some use cases when Xen framebuffer/input backend
is not a part of Qemu it is required to disable it,
because of conflicting access to input/display devices.
Introduce additional configuration option for explicit
input/display control.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
configure | 18 ++++++++++++++++++
hw/display/Makefile.objs | 2 +-
hw/xen/xen_backend.c | 2 ++
hw/xenpv/xen_machine_pv.c | 4 ++++
4 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 476210b1b93f..b805cb908f03 100755
--- a/configure
+++ b/configure
@@ -220,6 +220,7 @@ xen=""
xen_ctrl_version=""
xen_pv_domain_build="no"
xen_pci_passthrough=""
+xen_fb_backend=""
linux_aio=""
cap_ng=""
attr=""
@@ -909,6 +910,10 @@ for opt do
;;
--enable-xen-pv-domain-build) xen_pv_domain_build="yes"
;;
+ --disable-xen-fb-backend) xen_fb_backend="no"
+ ;;
+ --enable-xen-fb-backend) xen_fb_backend="yes"
+ ;;
--disable-brlapi) brlapi="no"
;;
--enable-brlapi) brlapi="yes"
@@ -1368,6 +1373,7 @@ disabled with --disable-FEATURE, default is enabled if available:
virtfs VirtFS
xen xen backend driver support
xen-pci-passthrough
+ xen-fb-backend framebuffer/input backend support
brlapi BrlAPI (Braile)
curl curl connectivity
fdt fdt device tree
@@ -2213,6 +2219,15 @@ if test "$xen_pv_domain_build" = "yes" &&
"which requires Xen support."
fi
+if test "$xen_fb_backend" != "no"; then
+ if test "$xen" = "yes"; then
+ xen_fb_backend=yes
+ else
+ error_exit "User requested feature Xen framebufer backend support" \
+ " but this feature requires Xen support."
+ fi
+fi
+
##########################################
# Sparse probe
if test "$sparse" != "no" ; then
@@ -5444,6 +5459,9 @@ if test "$xen" = "yes" ; then
if test "$xen_pv_domain_build" = "yes" ; then
echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
fi
+ if test "$xen_fb_backend" = "yes" ; then
+ echo "CONFIG_XEN_FB_BACKEND=y" >> $config_host_mak
+ fi
fi
if test "$linux_aio" = "yes" ; then
echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 063889beaf4a..f5ec97ed4f48 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -5,7 +5,7 @@ common-obj-$(CONFIG_JAZZ_LED) += jazz_led.o
common-obj-$(CONFIG_PL110) += pl110.o
common-obj-$(CONFIG_SSD0303) += ssd0303.o
common-obj-$(CONFIG_SSD0323) += ssd0323.o
-common-obj-$(CONFIG_XEN_BACKEND) += xenfb.o
+common-obj-$(CONFIG_XEN_FB_BACKEND) += xenfb.o
common-obj-$(CONFIG_VGA_PCI) += vga-pci.o
common-obj-$(CONFIG_VGA_ISA) += vga-isa.o
diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index d1190041ae12..5146cbba6ca5 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -582,7 +582,9 @@ void xen_be_register_common(void)
xen_set_dynamic_sysbus();
xen_be_register("console", &xen_console_ops);
+#ifdef CONFIG_XEN_FB_BACKEND
xen_be_register("vkbd", &xen_kbdmouse_ops);
+#endif
xen_be_register("qdisk", &xen_blkdev_ops);
#ifdef CONFIG_USB_LIBUSB
xen_be_register("qusb", &xen_usb_ops);
diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index 79aef4ecc37b..b731344c3f0a 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -68,7 +68,9 @@ static void xen_init_pv(MachineState *machine)
}
xen_be_register_common();
+#ifdef CONFIG_XEN_FB_BACKEND
xen_be_register("vfb", &xen_framebuffer_ops);
+#endif
xen_be_register("qnic", &xen_netdev_ops);
/* configure framebuffer */
@@ -95,8 +97,10 @@ static void xen_init_pv(MachineState *machine)
/* config cleanup hook */
atexit(xen_config_cleanup);
+#ifdef CONFIG_XEN_FB_BACKEND
/* setup framebuffer */
xen_init_display(xen_domid);
+#endif
}
static void xenpv_machine_init(MachineClass *mc)
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [Xen-devel][PATCH] configure: introduce --enable-xen-fb-backend
2017-04-11 9:35 ` [Qemu-devel][PATCH] " Oleksandr Andrushchenko
@ 2017-04-14 0:12 ` Stefano Stabellini
-1 siblings, 0 replies; 16+ messages in thread
From: Stefano Stabellini @ 2017-04-14 0:12 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: qemu-devel, xen-devel, joculator, al1img, vlad.babchuk,
andrii.anisov, olekstysh, sstabellini, anthony.perard,
Oleksandr Andrushchenko
On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>
> For some use cases when Xen framebuffer/input backend
> is not a part of Qemu it is required to disable it,
> because of conflicting access to input/display devices.
> Introduce additional configuration option for explicit
> input/display control.
In these cases when you don't want xenfb, why don't you just remove
"vfb" from the xl config file? QEMU only starts the xenfb backend when
requested by the toolstack.
Is it because you have an alternative xenfb backend? If so, is it really
fully xenfb compatible, or is it a different protocol? If it is a
different protocol, I suggest you rename your frontend/backend PV device
name to something different from "vfb".
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> ---
> configure | 18 ++++++++++++++++++
> hw/display/Makefile.objs | 2 +-
> hw/xen/xen_backend.c | 2 ++
> hw/xenpv/xen_machine_pv.c | 4 ++++
> 4 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 476210b1b93f..b805cb908f03 100755
> --- a/configure
> +++ b/configure
> @@ -220,6 +220,7 @@ xen=""
> xen_ctrl_version=""
> xen_pv_domain_build="no"
> xen_pci_passthrough=""
> +xen_fb_backend=""
> linux_aio=""
> cap_ng=""
> attr=""
> @@ -909,6 +910,10 @@ for opt do
> ;;
> --enable-xen-pv-domain-build) xen_pv_domain_build="yes"
> ;;
> + --disable-xen-fb-backend) xen_fb_backend="no"
> + ;;
> + --enable-xen-fb-backend) xen_fb_backend="yes"
> + ;;
> --disable-brlapi) brlapi="no"
> ;;
> --enable-brlapi) brlapi="yes"
> @@ -1368,6 +1373,7 @@ disabled with --disable-FEATURE, default is enabled if available:
> virtfs VirtFS
> xen xen backend driver support
> xen-pci-passthrough
> + xen-fb-backend framebuffer/input backend support
> brlapi BrlAPI (Braile)
> curl curl connectivity
> fdt fdt device tree
> @@ -2213,6 +2219,15 @@ if test "$xen_pv_domain_build" = "yes" &&
> "which requires Xen support."
> fi
>
> +if test "$xen_fb_backend" != "no"; then
> + if test "$xen" = "yes"; then
> + xen_fb_backend=yes
> + else
> + error_exit "User requested feature Xen framebufer backend support" \
> + " but this feature requires Xen support."
> + fi
> +fi
> +
> ##########################################
> # Sparse probe
> if test "$sparse" != "no" ; then
> @@ -5444,6 +5459,9 @@ if test "$xen" = "yes" ; then
> if test "$xen_pv_domain_build" = "yes" ; then
> echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
> fi
> + if test "$xen_fb_backend" = "yes" ; then
> + echo "CONFIG_XEN_FB_BACKEND=y" >> $config_host_mak
> + fi
> fi
> if test "$linux_aio" = "yes" ; then
> echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
> diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
> index 063889beaf4a..f5ec97ed4f48 100644
> --- a/hw/display/Makefile.objs
> +++ b/hw/display/Makefile.objs
> @@ -5,7 +5,7 @@ common-obj-$(CONFIG_JAZZ_LED) += jazz_led.o
> common-obj-$(CONFIG_PL110) += pl110.o
> common-obj-$(CONFIG_SSD0303) += ssd0303.o
> common-obj-$(CONFIG_SSD0323) += ssd0323.o
> -common-obj-$(CONFIG_XEN_BACKEND) += xenfb.o
> +common-obj-$(CONFIG_XEN_FB_BACKEND) += xenfb.o
>
> common-obj-$(CONFIG_VGA_PCI) += vga-pci.o
> common-obj-$(CONFIG_VGA_ISA) += vga-isa.o
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index d1190041ae12..5146cbba6ca5 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -582,7 +582,9 @@ void xen_be_register_common(void)
> xen_set_dynamic_sysbus();
>
> xen_be_register("console", &xen_console_ops);
> +#ifdef CONFIG_XEN_FB_BACKEND
> xen_be_register("vkbd", &xen_kbdmouse_ops);
> +#endif
> xen_be_register("qdisk", &xen_blkdev_ops);
> #ifdef CONFIG_USB_LIBUSB
> xen_be_register("qusb", &xen_usb_ops);
> diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
> index 79aef4ecc37b..b731344c3f0a 100644
> --- a/hw/xenpv/xen_machine_pv.c
> +++ b/hw/xenpv/xen_machine_pv.c
> @@ -68,7 +68,9 @@ static void xen_init_pv(MachineState *machine)
> }
>
> xen_be_register_common();
> +#ifdef CONFIG_XEN_FB_BACKEND
> xen_be_register("vfb", &xen_framebuffer_ops);
> +#endif
> xen_be_register("qnic", &xen_netdev_ops);
>
> /* configure framebuffer */
> @@ -95,8 +97,10 @@ static void xen_init_pv(MachineState *machine)
> /* config cleanup hook */
> atexit(xen_config_cleanup);
>
> +#ifdef CONFIG_XEN_FB_BACKEND
> /* setup framebuffer */
> xen_init_display(xen_domid);
> +#endif
> }
>
> static void xenpv_machine_init(MachineClass *mc)
> --
> 2.7.4
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend
@ 2017-04-14 0:12 ` Stefano Stabellini
0 siblings, 0 replies; 16+ messages in thread
From: Stefano Stabellini @ 2017-04-14 0:12 UTC (permalink / raw)
To: Oleksandr Andrushchenko
Cc: sstabellini, Oleksandr Andrushchenko, vlad.babchuk, qemu-devel,
andrii.anisov, olekstysh, al1img, anthony.perard, xen-devel,
joculator
On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>
> For some use cases when Xen framebuffer/input backend
> is not a part of Qemu it is required to disable it,
> because of conflicting access to input/display devices.
> Introduce additional configuration option for explicit
> input/display control.
In these cases when you don't want xenfb, why don't you just remove
"vfb" from the xl config file? QEMU only starts the xenfb backend when
requested by the toolstack.
Is it because you have an alternative xenfb backend? If so, is it really
fully xenfb compatible, or is it a different protocol? If it is a
different protocol, I suggest you rename your frontend/backend PV device
name to something different from "vfb".
> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> ---
> configure | 18 ++++++++++++++++++
> hw/display/Makefile.objs | 2 +-
> hw/xen/xen_backend.c | 2 ++
> hw/xenpv/xen_machine_pv.c | 4 ++++
> 4 files changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 476210b1b93f..b805cb908f03 100755
> --- a/configure
> +++ b/configure
> @@ -220,6 +220,7 @@ xen=""
> xen_ctrl_version=""
> xen_pv_domain_build="no"
> xen_pci_passthrough=""
> +xen_fb_backend=""
> linux_aio=""
> cap_ng=""
> attr=""
> @@ -909,6 +910,10 @@ for opt do
> ;;
> --enable-xen-pv-domain-build) xen_pv_domain_build="yes"
> ;;
> + --disable-xen-fb-backend) xen_fb_backend="no"
> + ;;
> + --enable-xen-fb-backend) xen_fb_backend="yes"
> + ;;
> --disable-brlapi) brlapi="no"
> ;;
> --enable-brlapi) brlapi="yes"
> @@ -1368,6 +1373,7 @@ disabled with --disable-FEATURE, default is enabled if available:
> virtfs VirtFS
> xen xen backend driver support
> xen-pci-passthrough
> + xen-fb-backend framebuffer/input backend support
> brlapi BrlAPI (Braile)
> curl curl connectivity
> fdt fdt device tree
> @@ -2213,6 +2219,15 @@ if test "$xen_pv_domain_build" = "yes" &&
> "which requires Xen support."
> fi
>
> +if test "$xen_fb_backend" != "no"; then
> + if test "$xen" = "yes"; then
> + xen_fb_backend=yes
> + else
> + error_exit "User requested feature Xen framebufer backend support" \
> + " but this feature requires Xen support."
> + fi
> +fi
> +
> ##########################################
> # Sparse probe
> if test "$sparse" != "no" ; then
> @@ -5444,6 +5459,9 @@ if test "$xen" = "yes" ; then
> if test "$xen_pv_domain_build" = "yes" ; then
> echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
> fi
> + if test "$xen_fb_backend" = "yes" ; then
> + echo "CONFIG_XEN_FB_BACKEND=y" >> $config_host_mak
> + fi
> fi
> if test "$linux_aio" = "yes" ; then
> echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
> diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
> index 063889beaf4a..f5ec97ed4f48 100644
> --- a/hw/display/Makefile.objs
> +++ b/hw/display/Makefile.objs
> @@ -5,7 +5,7 @@ common-obj-$(CONFIG_JAZZ_LED) += jazz_led.o
> common-obj-$(CONFIG_PL110) += pl110.o
> common-obj-$(CONFIG_SSD0303) += ssd0303.o
> common-obj-$(CONFIG_SSD0323) += ssd0323.o
> -common-obj-$(CONFIG_XEN_BACKEND) += xenfb.o
> +common-obj-$(CONFIG_XEN_FB_BACKEND) += xenfb.o
>
> common-obj-$(CONFIG_VGA_PCI) += vga-pci.o
> common-obj-$(CONFIG_VGA_ISA) += vga-isa.o
> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
> index d1190041ae12..5146cbba6ca5 100644
> --- a/hw/xen/xen_backend.c
> +++ b/hw/xen/xen_backend.c
> @@ -582,7 +582,9 @@ void xen_be_register_common(void)
> xen_set_dynamic_sysbus();
>
> xen_be_register("console", &xen_console_ops);
> +#ifdef CONFIG_XEN_FB_BACKEND
> xen_be_register("vkbd", &xen_kbdmouse_ops);
> +#endif
> xen_be_register("qdisk", &xen_blkdev_ops);
> #ifdef CONFIG_USB_LIBUSB
> xen_be_register("qusb", &xen_usb_ops);
> diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
> index 79aef4ecc37b..b731344c3f0a 100644
> --- a/hw/xenpv/xen_machine_pv.c
> +++ b/hw/xenpv/xen_machine_pv.c
> @@ -68,7 +68,9 @@ static void xen_init_pv(MachineState *machine)
> }
>
> xen_be_register_common();
> +#ifdef CONFIG_XEN_FB_BACKEND
> xen_be_register("vfb", &xen_framebuffer_ops);
> +#endif
> xen_be_register("qnic", &xen_netdev_ops);
>
> /* configure framebuffer */
> @@ -95,8 +97,10 @@ static void xen_init_pv(MachineState *machine)
> /* config cleanup hook */
> atexit(xen_config_cleanup);
>
> +#ifdef CONFIG_XEN_FB_BACKEND
> /* setup framebuffer */
> xen_init_display(xen_domid);
> +#endif
> }
>
> static void xenpv_machine_init(MachineClass *mc)
> --
> 2.7.4
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [Xen-devel][PATCH] configure: introduce --enable-xen-fb-backend
2017-04-14 0:12 ` [Qemu-devel][PATCH] " Stefano Stabellini
@ 2017-04-14 6:06 ` Oleksandr Andrushchenko
-1 siblings, 0 replies; 16+ messages in thread
From: Oleksandr Andrushchenko @ 2017-04-14 6:06 UTC (permalink / raw)
To: Stefano Stabellini, Oleksandr Andrushchenko
Cc: qemu-devel, xen-devel, joculator, al1img, vlad.babchuk,
andrii.anisov, olekstysh, anthony.perard
On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> For some use cases when Xen framebuffer/input backend
>> is not a part of Qemu it is required to disable it,
>> because of conflicting access to input/display devices.
>> Introduce additional configuration option for explicit
>> input/display control.
> In these cases when you don't want xenfb, why don't you just remove
> "vfb" from the xl config file? QEMU only starts the xenfb backend when
> requested by the toolstack.
>
> Is it because you have an alternative xenfb backend? If so, is it really
> fully xenfb compatible, or is it a different protocol? If it is a
> different protocol, I suggest you rename your frontend/backend PV device
> name to something different from "vfb".
>
Well, offending part is vkbd actually (for multi-touch
we run our own user-space backend which supports
kbd/ptr/mtouch), but vfb and vkbd is the same backend
in QEMU. So, I am ok for vfb, but just want vkbd off
So, there are 2 options:
1. At compile time remove vkbd and still allow vfb
2. Remove xenfb completely, if acceptable (this is my case)
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> ---
>> configure | 18 ++++++++++++++++++
>> hw/display/Makefile.objs | 2 +-
>> hw/xen/xen_backend.c | 2 ++
>> hw/xenpv/xen_machine_pv.c | 4 ++++
>> 4 files changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 476210b1b93f..b805cb908f03 100755
>> --- a/configure
>> +++ b/configure
>> @@ -220,6 +220,7 @@ xen=""
>> xen_ctrl_version=""
>> xen_pv_domain_build="no"
>> xen_pci_passthrough=""
>> +xen_fb_backend=""
>> linux_aio=""
>> cap_ng=""
>> attr=""
>> @@ -909,6 +910,10 @@ for opt do
>> ;;
>> --enable-xen-pv-domain-build) xen_pv_domain_build="yes"
>> ;;
>> + --disable-xen-fb-backend) xen_fb_backend="no"
>> + ;;
>> + --enable-xen-fb-backend) xen_fb_backend="yes"
>> + ;;
>> --disable-brlapi) brlapi="no"
>> ;;
>> --enable-brlapi) brlapi="yes"
>> @@ -1368,6 +1373,7 @@ disabled with --disable-FEATURE, default is enabled if available:
>> virtfs VirtFS
>> xen xen backend driver support
>> xen-pci-passthrough
>> + xen-fb-backend framebuffer/input backend support
>> brlapi BrlAPI (Braile)
>> curl curl connectivity
>> fdt fdt device tree
>> @@ -2213,6 +2219,15 @@ if test "$xen_pv_domain_build" = "yes" &&
>> "which requires Xen support."
>> fi
>>
>> +if test "$xen_fb_backend" != "no"; then
>> + if test "$xen" = "yes"; then
>> + xen_fb_backend=yes
>> + else
>> + error_exit "User requested feature Xen framebufer backend support" \
>> + " but this feature requires Xen support."
>> + fi
>> +fi
>> +
>> ##########################################
>> # Sparse probe
>> if test "$sparse" != "no" ; then
>> @@ -5444,6 +5459,9 @@ if test "$xen" = "yes" ; then
>> if test "$xen_pv_domain_build" = "yes" ; then
>> echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
>> fi
>> + if test "$xen_fb_backend" = "yes" ; then
>> + echo "CONFIG_XEN_FB_BACKEND=y" >> $config_host_mak
>> + fi
>> fi
>> if test "$linux_aio" = "yes" ; then
>> echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
>> diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
>> index 063889beaf4a..f5ec97ed4f48 100644
>> --- a/hw/display/Makefile.objs
>> +++ b/hw/display/Makefile.objs
>> @@ -5,7 +5,7 @@ common-obj-$(CONFIG_JAZZ_LED) += jazz_led.o
>> common-obj-$(CONFIG_PL110) += pl110.o
>> common-obj-$(CONFIG_SSD0303) += ssd0303.o
>> common-obj-$(CONFIG_SSD0323) += ssd0323.o
>> -common-obj-$(CONFIG_XEN_BACKEND) += xenfb.o
>> +common-obj-$(CONFIG_XEN_FB_BACKEND) += xenfb.o
>>
>> common-obj-$(CONFIG_VGA_PCI) += vga-pci.o
>> common-obj-$(CONFIG_VGA_ISA) += vga-isa.o
>> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
>> index d1190041ae12..5146cbba6ca5 100644
>> --- a/hw/xen/xen_backend.c
>> +++ b/hw/xen/xen_backend.c
>> @@ -582,7 +582,9 @@ void xen_be_register_common(void)
>> xen_set_dynamic_sysbus();
>>
>> xen_be_register("console", &xen_console_ops);
>> +#ifdef CONFIG_XEN_FB_BACKEND
>> xen_be_register("vkbd", &xen_kbdmouse_ops);
>> +#endif
>> xen_be_register("qdisk", &xen_blkdev_ops);
>> #ifdef CONFIG_USB_LIBUSB
>> xen_be_register("qusb", &xen_usb_ops);
>> diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
>> index 79aef4ecc37b..b731344c3f0a 100644
>> --- a/hw/xenpv/xen_machine_pv.c
>> +++ b/hw/xenpv/xen_machine_pv.c
>> @@ -68,7 +68,9 @@ static void xen_init_pv(MachineState *machine)
>> }
>>
>> xen_be_register_common();
>> +#ifdef CONFIG_XEN_FB_BACKEND
>> xen_be_register("vfb", &xen_framebuffer_ops);
>> +#endif
>> xen_be_register("qnic", &xen_netdev_ops);
>>
>> /* configure framebuffer */
>> @@ -95,8 +97,10 @@ static void xen_init_pv(MachineState *machine)
>> /* config cleanup hook */
>> atexit(xen_config_cleanup);
>>
>> +#ifdef CONFIG_XEN_FB_BACKEND
>> /* setup framebuffer */
>> xen_init_display(xen_domid);
>> +#endif
>> }
>>
>> static void xenpv_machine_init(MachineClass *mc)
>> --
>> 2.7.4
>>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend
@ 2017-04-14 6:06 ` Oleksandr Andrushchenko
0 siblings, 0 replies; 16+ messages in thread
From: Oleksandr Andrushchenko @ 2017-04-14 6:06 UTC (permalink / raw)
To: Stefano Stabellini, Oleksandr Andrushchenko
Cc: vlad.babchuk, qemu-devel, andrii.anisov, olekstysh, al1img,
anthony.perard, xen-devel, joculator
On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>
>> For some use cases when Xen framebuffer/input backend
>> is not a part of Qemu it is required to disable it,
>> because of conflicting access to input/display devices.
>> Introduce additional configuration option for explicit
>> input/display control.
> In these cases when you don't want xenfb, why don't you just remove
> "vfb" from the xl config file? QEMU only starts the xenfb backend when
> requested by the toolstack.
>
> Is it because you have an alternative xenfb backend? If so, is it really
> fully xenfb compatible, or is it a different protocol? If it is a
> different protocol, I suggest you rename your frontend/backend PV device
> name to something different from "vfb".
>
Well, offending part is vkbd actually (for multi-touch
we run our own user-space backend which supports
kbd/ptr/mtouch), but vfb and vkbd is the same backend
in QEMU. So, I am ok for vfb, but just want vkbd off
So, there are 2 options:
1. At compile time remove vkbd and still allow vfb
2. Remove xenfb completely, if acceptable (this is my case)
>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>> ---
>> configure | 18 ++++++++++++++++++
>> hw/display/Makefile.objs | 2 +-
>> hw/xen/xen_backend.c | 2 ++
>> hw/xenpv/xen_machine_pv.c | 4 ++++
>> 4 files changed, 25 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 476210b1b93f..b805cb908f03 100755
>> --- a/configure
>> +++ b/configure
>> @@ -220,6 +220,7 @@ xen=""
>> xen_ctrl_version=""
>> xen_pv_domain_build="no"
>> xen_pci_passthrough=""
>> +xen_fb_backend=""
>> linux_aio=""
>> cap_ng=""
>> attr=""
>> @@ -909,6 +910,10 @@ for opt do
>> ;;
>> --enable-xen-pv-domain-build) xen_pv_domain_build="yes"
>> ;;
>> + --disable-xen-fb-backend) xen_fb_backend="no"
>> + ;;
>> + --enable-xen-fb-backend) xen_fb_backend="yes"
>> + ;;
>> --disable-brlapi) brlapi="no"
>> ;;
>> --enable-brlapi) brlapi="yes"
>> @@ -1368,6 +1373,7 @@ disabled with --disable-FEATURE, default is enabled if available:
>> virtfs VirtFS
>> xen xen backend driver support
>> xen-pci-passthrough
>> + xen-fb-backend framebuffer/input backend support
>> brlapi BrlAPI (Braile)
>> curl curl connectivity
>> fdt fdt device tree
>> @@ -2213,6 +2219,15 @@ if test "$xen_pv_domain_build" = "yes" &&
>> "which requires Xen support."
>> fi
>>
>> +if test "$xen_fb_backend" != "no"; then
>> + if test "$xen" = "yes"; then
>> + xen_fb_backend=yes
>> + else
>> + error_exit "User requested feature Xen framebufer backend support" \
>> + " but this feature requires Xen support."
>> + fi
>> +fi
>> +
>> ##########################################
>> # Sparse probe
>> if test "$sparse" != "no" ; then
>> @@ -5444,6 +5459,9 @@ if test "$xen" = "yes" ; then
>> if test "$xen_pv_domain_build" = "yes" ; then
>> echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
>> fi
>> + if test "$xen_fb_backend" = "yes" ; then
>> + echo "CONFIG_XEN_FB_BACKEND=y" >> $config_host_mak
>> + fi
>> fi
>> if test "$linux_aio" = "yes" ; then
>> echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
>> diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
>> index 063889beaf4a..f5ec97ed4f48 100644
>> --- a/hw/display/Makefile.objs
>> +++ b/hw/display/Makefile.objs
>> @@ -5,7 +5,7 @@ common-obj-$(CONFIG_JAZZ_LED) += jazz_led.o
>> common-obj-$(CONFIG_PL110) += pl110.o
>> common-obj-$(CONFIG_SSD0303) += ssd0303.o
>> common-obj-$(CONFIG_SSD0323) += ssd0323.o
>> -common-obj-$(CONFIG_XEN_BACKEND) += xenfb.o
>> +common-obj-$(CONFIG_XEN_FB_BACKEND) += xenfb.o
>>
>> common-obj-$(CONFIG_VGA_PCI) += vga-pci.o
>> common-obj-$(CONFIG_VGA_ISA) += vga-isa.o
>> diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
>> index d1190041ae12..5146cbba6ca5 100644
>> --- a/hw/xen/xen_backend.c
>> +++ b/hw/xen/xen_backend.c
>> @@ -582,7 +582,9 @@ void xen_be_register_common(void)
>> xen_set_dynamic_sysbus();
>>
>> xen_be_register("console", &xen_console_ops);
>> +#ifdef CONFIG_XEN_FB_BACKEND
>> xen_be_register("vkbd", &xen_kbdmouse_ops);
>> +#endif
>> xen_be_register("qdisk", &xen_blkdev_ops);
>> #ifdef CONFIG_USB_LIBUSB
>> xen_be_register("qusb", &xen_usb_ops);
>> diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
>> index 79aef4ecc37b..b731344c3f0a 100644
>> --- a/hw/xenpv/xen_machine_pv.c
>> +++ b/hw/xenpv/xen_machine_pv.c
>> @@ -68,7 +68,9 @@ static void xen_init_pv(MachineState *machine)
>> }
>>
>> xen_be_register_common();
>> +#ifdef CONFIG_XEN_FB_BACKEND
>> xen_be_register("vfb", &xen_framebuffer_ops);
>> +#endif
>> xen_be_register("qnic", &xen_netdev_ops);
>>
>> /* configure framebuffer */
>> @@ -95,8 +97,10 @@ static void xen_init_pv(MachineState *machine)
>> /* config cleanup hook */
>> atexit(xen_config_cleanup);
>>
>> +#ifdef CONFIG_XEN_FB_BACKEND
>> /* setup framebuffer */
>> xen_init_display(xen_domid);
>> +#endif
>> }
>>
>> static void xenpv_machine_init(MachineClass *mc)
>> --
>> 2.7.4
>>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [Xen-devel] [PATCH] configure: introduce --enable-xen-fb-backend
2017-04-14 6:06 ` [Qemu-devel][PATCH] " Oleksandr Andrushchenko
@ 2017-04-14 8:50 ` Juergen Gross
-1 siblings, 0 replies; 16+ messages in thread
From: Juergen Gross @ 2017-04-14 8:50 UTC (permalink / raw)
To: Oleksandr Andrushchenko, Stefano Stabellini
Cc: vlad.babchuk, qemu-devel, andrii.anisov, olekstysh, al1img,
anthony.perard, xen-devel, joculator
On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
>> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>
>>> For some use cases when Xen framebuffer/input backend
>>> is not a part of Qemu it is required to disable it,
>>> because of conflicting access to input/display devices.
>>> Introduce additional configuration option for explicit
>>> input/display control.
>> In these cases when you don't want xenfb, why don't you just remove
>> "vfb" from the xl config file? QEMU only starts the xenfb backend when
>> requested by the toolstack.
>>
>> Is it because you have an alternative xenfb backend? If so, is it really
>> fully xenfb compatible, or is it a different protocol? If it is a
>> different protocol, I suggest you rename your frontend/backend PV device
>> name to something different from "vfb".
>>
> Well, offending part is vkbd actually (for multi-touch
> we run our own user-space backend which supports
> kbd/ptr/mtouch), but vfb and vkbd is the same backend
> in QEMU. So, I am ok for vfb, but just want vkbd off
> So, there are 2 options:
> 1. At compile time remove vkbd and still allow vfb
> 2. Remove xenfb completely, if acceptable (this is my case)
What about adding a Xenstore entry for backend type and let qemu test
for it being not present or containing "qemu"?
Juergen
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend
@ 2017-04-14 8:50 ` Juergen Gross
0 siblings, 0 replies; 16+ messages in thread
From: Juergen Gross @ 2017-04-14 8:50 UTC (permalink / raw)
To: Oleksandr Andrushchenko, Stefano Stabellini
Cc: vlad.babchuk, qemu-devel, andrii.anisov, olekstysh, al1img,
anthony.perard, xen-devel, joculator
On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
>> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>
>>> For some use cases when Xen framebuffer/input backend
>>> is not a part of Qemu it is required to disable it,
>>> because of conflicting access to input/display devices.
>>> Introduce additional configuration option for explicit
>>> input/display control.
>> In these cases when you don't want xenfb, why don't you just remove
>> "vfb" from the xl config file? QEMU only starts the xenfb backend when
>> requested by the toolstack.
>>
>> Is it because you have an alternative xenfb backend? If so, is it really
>> fully xenfb compatible, or is it a different protocol? If it is a
>> different protocol, I suggest you rename your frontend/backend PV device
>> name to something different from "vfb".
>>
> Well, offending part is vkbd actually (for multi-touch
> we run our own user-space backend which supports
> kbd/ptr/mtouch), but vfb and vkbd is the same backend
> in QEMU. So, I am ok for vfb, but just want vkbd off
> So, there are 2 options:
> 1. At compile time remove vkbd and still allow vfb
> 2. Remove xenfb completely, if acceptable (this is my case)
What about adding a Xenstore entry for backend type and let qemu test
for it being not present or containing "qemu"?
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [Xen-devel] [PATCH] configure: introduce --enable-xen-fb-backend
2017-04-14 8:50 ` [Qemu-devel][PATCH] " Juergen Gross
@ 2017-04-14 17:52 ` Stefano Stabellini
-1 siblings, 0 replies; 16+ messages in thread
From: Stefano Stabellini @ 2017-04-14 17:52 UTC (permalink / raw)
To: Juergen Gross
Cc: Oleksandr Andrushchenko, Stefano Stabellini, vlad.babchuk,
qemu-devel, andrii.anisov, olekstysh, al1img, anthony.perard,
xen-devel, joculator
On Fri, 14 Apr 2017, Juergen Gross wrote:
> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
> > On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
> >> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
> >>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>
> >>> For some use cases when Xen framebuffer/input backend
> >>> is not a part of Qemu it is required to disable it,
> >>> because of conflicting access to input/display devices.
> >>> Introduce additional configuration option for explicit
> >>> input/display control.
> >> In these cases when you don't want xenfb, why don't you just remove
> >> "vfb" from the xl config file? QEMU only starts the xenfb backend when
> >> requested by the toolstack.
> >>
> >> Is it because you have an alternative xenfb backend? If so, is it really
> >> fully xenfb compatible, or is it a different protocol? If it is a
> >> different protocol, I suggest you rename your frontend/backend PV device
> >> name to something different from "vfb".
> >>
> > Well, offending part is vkbd actually (for multi-touch
> > we run our own user-space backend which supports
> > kbd/ptr/mtouch), but vfb and vkbd is the same backend
> > in QEMU. So, I am ok for vfb, but just want vkbd off
> > So, there are 2 options:
> > 1. At compile time remove vkbd and still allow vfb
> > 2. Remove xenfb completely, if acceptable (this is my case)
>
> What about adding a Xenstore entry for backend type and let qemu test
> for it being not present or containing "qemu"?
That is what we do for the console, using the xenstore node "type". QEMU
is "ioemu" while xenconsoled is "xenconsoled". Weirdly, instead of a
backend node, it is a read-only frontend node, see
tools/libxl/libxl_console.c:libxl__device_console_add.
Oleksandr, I am sorry to feature-creep this simple patch, but I think
Juergen is right. But we cannot do it just for one protocol. We need to
introduce a generic way to enable/disable backends in QEMU. Using a
xenstore node is OK.
We could do exactly the same as the PV console, thus "type" = "ioemu",
read-only, under the frontend xenstore directory. Or we could introduce
new nodes. I would probably go for "backend-type" = "qemu" under the
backend xenstore directory. I don't have a strong opinion about this. In
the example below I'll use the PV console convention.
For starters:
* libxl needs to write the "type" node to xenstore for *all* protocols.
The "type" is not yet configurable.
* qemu reads them for all backends, proceeds if "type" = "ioemu"
These should be two simple patches. Stage 2:
* we add options in the xl config file to configure any backend, libxl
set "type" accordingly (Maybe not *any*, but vif, vkbd, vfb could all
have a "type". It is OK if you only add an option for vkbd.)
* non-QEMU backends, in particular Linux backends, also read the "type"
node and proceed if it's "linux"
Does this sound OK to you?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend
@ 2017-04-14 17:52 ` Stefano Stabellini
0 siblings, 0 replies; 16+ messages in thread
From: Stefano Stabellini @ 2017-04-14 17:52 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Oleksandr Andrushchenko, qemu-devel,
andrii.anisov, olekstysh, vlad.babchuk, al1img, anthony.perard,
xen-devel, joculator
On Fri, 14 Apr 2017, Juergen Gross wrote:
> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
> > On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
> >> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
> >>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>
> >>> For some use cases when Xen framebuffer/input backend
> >>> is not a part of Qemu it is required to disable it,
> >>> because of conflicting access to input/display devices.
> >>> Introduce additional configuration option for explicit
> >>> input/display control.
> >> In these cases when you don't want xenfb, why don't you just remove
> >> "vfb" from the xl config file? QEMU only starts the xenfb backend when
> >> requested by the toolstack.
> >>
> >> Is it because you have an alternative xenfb backend? If so, is it really
> >> fully xenfb compatible, or is it a different protocol? If it is a
> >> different protocol, I suggest you rename your frontend/backend PV device
> >> name to something different from "vfb".
> >>
> > Well, offending part is vkbd actually (for multi-touch
> > we run our own user-space backend which supports
> > kbd/ptr/mtouch), but vfb and vkbd is the same backend
> > in QEMU. So, I am ok for vfb, but just want vkbd off
> > So, there are 2 options:
> > 1. At compile time remove vkbd and still allow vfb
> > 2. Remove xenfb completely, if acceptable (this is my case)
>
> What about adding a Xenstore entry for backend type and let qemu test
> for it being not present or containing "qemu"?
That is what we do for the console, using the xenstore node "type". QEMU
is "ioemu" while xenconsoled is "xenconsoled". Weirdly, instead of a
backend node, it is a read-only frontend node, see
tools/libxl/libxl_console.c:libxl__device_console_add.
Oleksandr, I am sorry to feature-creep this simple patch, but I think
Juergen is right. But we cannot do it just for one protocol. We need to
introduce a generic way to enable/disable backends in QEMU. Using a
xenstore node is OK.
We could do exactly the same as the PV console, thus "type" = "ioemu",
read-only, under the frontend xenstore directory. Or we could introduce
new nodes. I would probably go for "backend-type" = "qemu" under the
backend xenstore directory. I don't have a strong opinion about this. In
the example below I'll use the PV console convention.
For starters:
* libxl needs to write the "type" node to xenstore for *all* protocols.
The "type" is not yet configurable.
* qemu reads them for all backends, proceeds if "type" = "ioemu"
These should be two simple patches. Stage 2:
* we add options in the xl config file to configure any backend, libxl
set "type" accordingly (Maybe not *any*, but vif, vkbd, vfb could all
have a "type". It is OK if you only add an option for vkbd.)
* non-QEMU backends, in particular Linux backends, also read the "type"
node and proceed if it's "linux"
Does this sound OK to you?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [Xen-devel] [PATCH] configure: introduce --enable-xen-fb-backend
2017-04-14 17:52 ` [Qemu-devel][PATCH] " Stefano Stabellini
@ 2017-04-18 5:26 ` Juergen Gross
-1 siblings, 0 replies; 16+ messages in thread
From: Juergen Gross @ 2017-04-18 5:26 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Oleksandr Andrushchenko, vlad.babchuk, qemu-devel, andrii.anisov,
olekstysh, al1img, anthony.perard, xen-devel, joculator
On 14/04/17 19:52, Stefano Stabellini wrote:
> On Fri, 14 Apr 2017, Juergen Gross wrote:
>> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
>>> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
>>>> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>
>>>>> For some use cases when Xen framebuffer/input backend
>>>>> is not a part of Qemu it is required to disable it,
>>>>> because of conflicting access to input/display devices.
>>>>> Introduce additional configuration option for explicit
>>>>> input/display control.
>>>> In these cases when you don't want xenfb, why don't you just remove
>>>> "vfb" from the xl config file? QEMU only starts the xenfb backend when
>>>> requested by the toolstack.
>>>>
>>>> Is it because you have an alternative xenfb backend? If so, is it really
>>>> fully xenfb compatible, or is it a different protocol? If it is a
>>>> different protocol, I suggest you rename your frontend/backend PV device
>>>> name to something different from "vfb".
>>>>
>>> Well, offending part is vkbd actually (for multi-touch
>>> we run our own user-space backend which supports
>>> kbd/ptr/mtouch), but vfb and vkbd is the same backend
>>> in QEMU. So, I am ok for vfb, but just want vkbd off
>>> So, there are 2 options:
>>> 1. At compile time remove vkbd and still allow vfb
>>> 2. Remove xenfb completely, if acceptable (this is my case)
>>
>> What about adding a Xenstore entry for backend type and let qemu test
>> for it being not present or containing "qemu"?
>
> That is what we do for the console, using the xenstore node "type". QEMU
> is "ioemu" while xenconsoled is "xenconsoled". Weirdly, instead of a
> backend node, it is a read-only frontend node, see
> tools/libxl/libxl_console.c:libxl__device_console_add.
>
> Oleksandr, I am sorry to feature-creep this simple patch, but I think
> Juergen is right. But we cannot do it just for one protocol. We need to
> introduce a generic way to enable/disable backends in QEMU. Using a
> xenstore node is OK.
An alternative solution would be similar to qdisk/tap or qusb/vusb
backends: Use different device types on backend side while keeping
frontend side of Xenstore the same as today.
So today the vkbd backend nodes are:
/local/domain/0/backend/vkbd/
You could use:
/local/domain/0/backend/mtouch
and keep the frontend nodes (/local/domain/<n>/device/vkbd/), possibly
with additional feature node(s).
The qemu backend would have to check for the vkbd backend nodes to be
present before enabling the related backend.
Juergen
>
> We could do exactly the same as the PV console, thus "type" = "ioemu",
> read-only, under the frontend xenstore directory. Or we could introduce
> new nodes. I would probably go for "backend-type" = "qemu" under the
> backend xenstore directory. I don't have a strong opinion about this. In
> the example below I'll use the PV console convention.
>
> For starters:
>
> * libxl needs to write the "type" node to xenstore for *all* protocols.
> The "type" is not yet configurable.
> * qemu reads them for all backends, proceeds if "type" = "ioemu"
>
> These should be two simple patches. Stage 2:
>
> * we add options in the xl config file to configure any backend, libxl
> set "type" accordingly (Maybe not *any*, but vif, vkbd, vfb could all
> have a "type". It is OK if you only add an option for vkbd.)
> * non-QEMU backends, in particular Linux backends, also read the "type"
> node and proceed if it's "linux"
>
> Does this sound OK to you?
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend
@ 2017-04-18 5:26 ` Juergen Gross
0 siblings, 0 replies; 16+ messages in thread
From: Juergen Gross @ 2017-04-18 5:26 UTC (permalink / raw)
To: Stefano Stabellini
Cc: Oleksandr Andrushchenko, qemu-devel, andrii.anisov, olekstysh,
vlad.babchuk, al1img, anthony.perard, xen-devel, joculator
On 14/04/17 19:52, Stefano Stabellini wrote:
> On Fri, 14 Apr 2017, Juergen Gross wrote:
>> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
>>> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
>>>> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>
>>>>> For some use cases when Xen framebuffer/input backend
>>>>> is not a part of Qemu it is required to disable it,
>>>>> because of conflicting access to input/display devices.
>>>>> Introduce additional configuration option for explicit
>>>>> input/display control.
>>>> In these cases when you don't want xenfb, why don't you just remove
>>>> "vfb" from the xl config file? QEMU only starts the xenfb backend when
>>>> requested by the toolstack.
>>>>
>>>> Is it because you have an alternative xenfb backend? If so, is it really
>>>> fully xenfb compatible, or is it a different protocol? If it is a
>>>> different protocol, I suggest you rename your frontend/backend PV device
>>>> name to something different from "vfb".
>>>>
>>> Well, offending part is vkbd actually (for multi-touch
>>> we run our own user-space backend which supports
>>> kbd/ptr/mtouch), but vfb and vkbd is the same backend
>>> in QEMU. So, I am ok for vfb, but just want vkbd off
>>> So, there are 2 options:
>>> 1. At compile time remove vkbd and still allow vfb
>>> 2. Remove xenfb completely, if acceptable (this is my case)
>>
>> What about adding a Xenstore entry for backend type and let qemu test
>> for it being not present or containing "qemu"?
>
> That is what we do for the console, using the xenstore node "type". QEMU
> is "ioemu" while xenconsoled is "xenconsoled". Weirdly, instead of a
> backend node, it is a read-only frontend node, see
> tools/libxl/libxl_console.c:libxl__device_console_add.
>
> Oleksandr, I am sorry to feature-creep this simple patch, but I think
> Juergen is right. But we cannot do it just for one protocol. We need to
> introduce a generic way to enable/disable backends in QEMU. Using a
> xenstore node is OK.
An alternative solution would be similar to qdisk/tap or qusb/vusb
backends: Use different device types on backend side while keeping
frontend side of Xenstore the same as today.
So today the vkbd backend nodes are:
/local/domain/0/backend/vkbd/
You could use:
/local/domain/0/backend/mtouch
and keep the frontend nodes (/local/domain/<n>/device/vkbd/), possibly
with additional feature node(s).
The qemu backend would have to check for the vkbd backend nodes to be
present before enabling the related backend.
Juergen
>
> We could do exactly the same as the PV console, thus "type" = "ioemu",
> read-only, under the frontend xenstore directory. Or we could introduce
> new nodes. I would probably go for "backend-type" = "qemu" under the
> backend xenstore directory. I don't have a strong opinion about this. In
> the example below I'll use the PV console convention.
>
> For starters:
>
> * libxl needs to write the "type" node to xenstore for *all* protocols.
> The "type" is not yet configurable.
> * qemu reads them for all backends, proceeds if "type" = "ioemu"
>
> These should be two simple patches. Stage 2:
>
> * we add options in the xl config file to configure any backend, libxl
> set "type" accordingly (Maybe not *any*, but vif, vkbd, vfb could all
> have a "type". It is OK if you only add an option for vkbd.)
> * non-QEMU backends, in particular Linux backends, also read the "type"
> node and proceed if it's "linux"
>
> Does this sound OK to you?
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [Xen-devel] [PATCH] configure: introduce --enable-xen-fb-backend
2017-04-18 5:26 ` [Qemu-devel][PATCH] " Juergen Gross
@ 2017-04-18 17:25 ` Stefano Stabellini
-1 siblings, 0 replies; 16+ messages in thread
From: Stefano Stabellini @ 2017-04-18 17:25 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Oleksandr Andrushchenko, vlad.babchuk,
qemu-devel, andrii.anisov, olekstysh, al1img, anthony.perard,
xen-devel, joculator
On Tue, 18 Apr 2017, Juergen Gross wrote:
> On 14/04/17 19:52, Stefano Stabellini wrote:
> > On Fri, 14 Apr 2017, Juergen Gross wrote:
> >> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
> >>> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
> >>>> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
> >>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>>>
> >>>>> For some use cases when Xen framebuffer/input backend
> >>>>> is not a part of Qemu it is required to disable it,
> >>>>> because of conflicting access to input/display devices.
> >>>>> Introduce additional configuration option for explicit
> >>>>> input/display control.
> >>>> In these cases when you don't want xenfb, why don't you just remove
> >>>> "vfb" from the xl config file? QEMU only starts the xenfb backend when
> >>>> requested by the toolstack.
> >>>>
> >>>> Is it because you have an alternative xenfb backend? If so, is it really
> >>>> fully xenfb compatible, or is it a different protocol? If it is a
> >>>> different protocol, I suggest you rename your frontend/backend PV device
> >>>> name to something different from "vfb".
> >>>>
> >>> Well, offending part is vkbd actually (for multi-touch
> >>> we run our own user-space backend which supports
> >>> kbd/ptr/mtouch), but vfb and vkbd is the same backend
> >>> in QEMU. So, I am ok for vfb, but just want vkbd off
> >>> So, there are 2 options:
> >>> 1. At compile time remove vkbd and still allow vfb
> >>> 2. Remove xenfb completely, if acceptable (this is my case)
> >>
> >> What about adding a Xenstore entry for backend type and let qemu test
> >> for it being not present or containing "qemu"?
> >
> > That is what we do for the console, using the xenstore node "type". QEMU
> > is "ioemu" while xenconsoled is "xenconsoled". Weirdly, instead of a
> > backend node, it is a read-only frontend node, see
> > tools/libxl/libxl_console.c:libxl__device_console_add.
> >
> > Oleksandr, I am sorry to feature-creep this simple patch, but I think
> > Juergen is right. But we cannot do it just for one protocol. We need to
> > introduce a generic way to enable/disable backends in QEMU. Using a
> > xenstore node is OK.
>
> An alternative solution would be similar to qdisk/tap or qusb/vusb
> backends: Use different device types on backend side while keeping
> frontend side of Xenstore the same as today.
>
> So today the vkbd backend nodes are:
>
> /local/domain/0/backend/vkbd/
>
> You could use:
>
> /local/domain/0/backend/mtouch
>
> and keep the frontend nodes (/local/domain/<n>/device/vkbd/), possibly
> with additional feature node(s).
>
> The qemu backend would have to check for the vkbd backend nodes to be
> present before enabling the related backend.
Yes, that also works. Either way, we don't have a "registry" of backend
protocol nodes; we don't have a doc that ties qdisk with QEMU and
the block protocol. We should introduce one before adding any more.
> > We could do exactly the same as the PV console, thus "type" = "ioemu",
> > read-only, under the frontend xenstore directory. Or we could introduce
> > new nodes. I would probably go for "backend-type" = "qemu" under the
> > backend xenstore directory. I don't have a strong opinion about this. In
> > the example below I'll use the PV console convention.
> >
> > For starters:
> >
> > * libxl needs to write the "type" node to xenstore for *all* protocols.
> > The "type" is not yet configurable.
> > * qemu reads them for all backends, proceeds if "type" = "ioemu"
> >
> > These should be two simple patches. Stage 2:
> >
> > * we add options in the xl config file to configure any backend, libxl
> > set "type" accordingly (Maybe not *any*, but vif, vkbd, vfb could all
> > have a "type". It is OK if you only add an option for vkbd.)
> > * non-QEMU backends, in particular Linux backends, also read the "type"
> > node and proceed if it's "linux"
> >
> > Does this sound OK to you?
> >
>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend
@ 2017-04-18 17:25 ` Stefano Stabellini
0 siblings, 0 replies; 16+ messages in thread
From: Stefano Stabellini @ 2017-04-18 17:25 UTC (permalink / raw)
To: Juergen Gross
Cc: Stefano Stabellini, Oleksandr Andrushchenko, qemu-devel,
andrii.anisov, olekstysh, vlad.babchuk, al1img, anthony.perard,
xen-devel, joculator
On Tue, 18 Apr 2017, Juergen Gross wrote:
> On 14/04/17 19:52, Stefano Stabellini wrote:
> > On Fri, 14 Apr 2017, Juergen Gross wrote:
> >> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
> >>> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
> >>>> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
> >>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> >>>>>
> >>>>> For some use cases when Xen framebuffer/input backend
> >>>>> is not a part of Qemu it is required to disable it,
> >>>>> because of conflicting access to input/display devices.
> >>>>> Introduce additional configuration option for explicit
> >>>>> input/display control.
> >>>> In these cases when you don't want xenfb, why don't you just remove
> >>>> "vfb" from the xl config file? QEMU only starts the xenfb backend when
> >>>> requested by the toolstack.
> >>>>
> >>>> Is it because you have an alternative xenfb backend? If so, is it really
> >>>> fully xenfb compatible, or is it a different protocol? If it is a
> >>>> different protocol, I suggest you rename your frontend/backend PV device
> >>>> name to something different from "vfb".
> >>>>
> >>> Well, offending part is vkbd actually (for multi-touch
> >>> we run our own user-space backend which supports
> >>> kbd/ptr/mtouch), but vfb and vkbd is the same backend
> >>> in QEMU. So, I am ok for vfb, but just want vkbd off
> >>> So, there are 2 options:
> >>> 1. At compile time remove vkbd and still allow vfb
> >>> 2. Remove xenfb completely, if acceptable (this is my case)
> >>
> >> What about adding a Xenstore entry for backend type and let qemu test
> >> for it being not present or containing "qemu"?
> >
> > That is what we do for the console, using the xenstore node "type". QEMU
> > is "ioemu" while xenconsoled is "xenconsoled". Weirdly, instead of a
> > backend node, it is a read-only frontend node, see
> > tools/libxl/libxl_console.c:libxl__device_console_add.
> >
> > Oleksandr, I am sorry to feature-creep this simple patch, but I think
> > Juergen is right. But we cannot do it just for one protocol. We need to
> > introduce a generic way to enable/disable backends in QEMU. Using a
> > xenstore node is OK.
>
> An alternative solution would be similar to qdisk/tap or qusb/vusb
> backends: Use different device types on backend side while keeping
> frontend side of Xenstore the same as today.
>
> So today the vkbd backend nodes are:
>
> /local/domain/0/backend/vkbd/
>
> You could use:
>
> /local/domain/0/backend/mtouch
>
> and keep the frontend nodes (/local/domain/<n>/device/vkbd/), possibly
> with additional feature node(s).
>
> The qemu backend would have to check for the vkbd backend nodes to be
> present before enabling the related backend.
Yes, that also works. Either way, we don't have a "registry" of backend
protocol nodes; we don't have a doc that ties qdisk with QEMU and
the block protocol. We should introduce one before adding any more.
> > We could do exactly the same as the PV console, thus "type" = "ioemu",
> > read-only, under the frontend xenstore directory. Or we could introduce
> > new nodes. I would probably go for "backend-type" = "qemu" under the
> > backend xenstore directory. I don't have a strong opinion about this. In
> > the example below I'll use the PV console convention.
> >
> > For starters:
> >
> > * libxl needs to write the "type" node to xenstore for *all* protocols.
> > The "type" is not yet configurable.
> > * qemu reads them for all backends, proceeds if "type" = "ioemu"
> >
> > These should be two simple patches. Stage 2:
> >
> > * we add options in the xl config file to configure any backend, libxl
> > set "type" accordingly (Maybe not *any*, but vif, vkbd, vfb could all
> > have a "type". It is OK if you only add an option for vkbd.)
> > * non-QEMU backends, in particular Linux backends, also read the "type"
> > node and proceed if it's "linux"
> >
> > Does this sound OK to you?
> >
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel] [Xen-devel] [PATCH] configure: introduce --enable-xen-fb-backend
2017-04-14 17:52 ` [Qemu-devel][PATCH] " Stefano Stabellini
@ 2017-04-20 6:14 ` Oleksandr Andrushchenko
-1 siblings, 0 replies; 16+ messages in thread
From: Oleksandr Andrushchenko @ 2017-04-20 6:14 UTC (permalink / raw)
To: Stefano Stabellini, Juergen Gross
Cc: vlad.babchuk, qemu-devel, andrii.anisov, olekstysh, al1img,
anthony.perard, xen-devel, joculator
On 04/14/2017 08:52 PM, Stefano Stabellini wrote:
> On Fri, 14 Apr 2017, Juergen Gross wrote:
>> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
>>> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
>>>> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>
>>>>> For some use cases when Xen framebuffer/input backend
>>>>> is not a part of Qemu it is required to disable it,
>>>>> because of conflicting access to input/display devices.
>>>>> Introduce additional configuration option for explicit
>>>>> input/display control.
>>>> In these cases when you don't want xenfb, why don't you just remove
>>>> "vfb" from the xl config file? QEMU only starts the xenfb backend when
>>>> requested by the toolstack.
>>>>
>>>> Is it because you have an alternative xenfb backend? If so, is it really
>>>> fully xenfb compatible, or is it a different protocol? If it is a
>>>> different protocol, I suggest you rename your frontend/backend PV device
>>>> name to something different from "vfb".
>>>>
>>> Well, offending part is vkbd actually (for multi-touch
>>> we run our own user-space backend which supports
>>> kbd/ptr/mtouch), but vfb and vkbd is the same backend
>>> in QEMU. So, I am ok for vfb, but just want vkbd off
>>> So, there are 2 options:
>>> 1. At compile time remove vkbd and still allow vfb
>>> 2. Remove xenfb completely, if acceptable (this is my case)
>> What about adding a Xenstore entry for backend type and let qemu test
>> for it being not present or containing "qemu"?
sounds reasonable
> That is what we do for the console, using the xenstore node "type". QEMU
> is "ioemu" while xenconsoled is "xenconsoled". Weirdly, instead of a
> backend node, it is a read-only frontend node, see
> tools/libxl/libxl_console.c:libxl__device_console_add.
>
> Oleksandr, I am sorry to feature-creep this simple patch, but I think
> Juergen is right. But we cannot do it just for one protocol. We need to
> introduce a generic way to enable/disable backends in QEMU. Using a
> xenstore node is OK.
agree
>
> We could do exactly the same as the PV console, thus "type" = "ioemu",
> read-only, under the frontend xenstore directory. Or we could introduce
> new nodes. I would probably go for "backend-type" = "qemu" under the
> backend xenstore directory. I don't have a strong opinion about this. In
> the example below I'll use the PV console convention.
>
> For starters:
>
> * libxl needs to write the "type" node to xenstore for *all* protocols.
> The "type" is not yet configurable.
> * qemu reads them for all backends, proceeds if "type" = "ioemu"
>
> These should be two simple patches. Stage 2:
>
> * we add options in the xl config file to configure any backend, libxl
> set "type" accordingly (Maybe not *any*, but vif, vkbd, vfb could all
> have a "type". It is OK if you only add an option for vkbd.)
> * non-QEMU backends, in particular Linux backends, also read the "type"
> node and proceed if it's "linux"
>
> Does this sound OK to you?
For the first take it does, but I'll get back to it a bit later
Actually the purpose of the change was to find a way
we can live with backends implemented in QEMU and user-space
and how they can co-exist
Thank you,
Oleksandr
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend
@ 2017-04-20 6:14 ` Oleksandr Andrushchenko
0 siblings, 0 replies; 16+ messages in thread
From: Oleksandr Andrushchenko @ 2017-04-20 6:14 UTC (permalink / raw)
To: Stefano Stabellini, Juergen Gross
Cc: vlad.babchuk, qemu-devel, andrii.anisov, olekstysh, al1img,
anthony.perard, xen-devel, joculator
On 04/14/2017 08:52 PM, Stefano Stabellini wrote:
> On Fri, 14 Apr 2017, Juergen Gross wrote:
>> On 14/04/17 08:06, Oleksandr Andrushchenko wrote:
>>> On 04/14/2017 03:12 AM, Stefano Stabellini wrote:
>>>> On Tue, 11 Apr 2017, Oleksandr Andrushchenko wrote:
>>>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
>>>>>
>>>>> For some use cases when Xen framebuffer/input backend
>>>>> is not a part of Qemu it is required to disable it,
>>>>> because of conflicting access to input/display devices.
>>>>> Introduce additional configuration option for explicit
>>>>> input/display control.
>>>> In these cases when you don't want xenfb, why don't you just remove
>>>> "vfb" from the xl config file? QEMU only starts the xenfb backend when
>>>> requested by the toolstack.
>>>>
>>>> Is it because you have an alternative xenfb backend? If so, is it really
>>>> fully xenfb compatible, or is it a different protocol? If it is a
>>>> different protocol, I suggest you rename your frontend/backend PV device
>>>> name to something different from "vfb".
>>>>
>>> Well, offending part is vkbd actually (for multi-touch
>>> we run our own user-space backend which supports
>>> kbd/ptr/mtouch), but vfb and vkbd is the same backend
>>> in QEMU. So, I am ok for vfb, but just want vkbd off
>>> So, there are 2 options:
>>> 1. At compile time remove vkbd and still allow vfb
>>> 2. Remove xenfb completely, if acceptable (this is my case)
>> What about adding a Xenstore entry for backend type and let qemu test
>> for it being not present or containing "qemu"?
sounds reasonable
> That is what we do for the console, using the xenstore node "type". QEMU
> is "ioemu" while xenconsoled is "xenconsoled". Weirdly, instead of a
> backend node, it is a read-only frontend node, see
> tools/libxl/libxl_console.c:libxl__device_console_add.
>
> Oleksandr, I am sorry to feature-creep this simple patch, but I think
> Juergen is right. But we cannot do it just for one protocol. We need to
> introduce a generic way to enable/disable backends in QEMU. Using a
> xenstore node is OK.
agree
>
> We could do exactly the same as the PV console, thus "type" = "ioemu",
> read-only, under the frontend xenstore directory. Or we could introduce
> new nodes. I would probably go for "backend-type" = "qemu" under the
> backend xenstore directory. I don't have a strong opinion about this. In
> the example below I'll use the PV console convention.
>
> For starters:
>
> * libxl needs to write the "type" node to xenstore for *all* protocols.
> The "type" is not yet configurable.
> * qemu reads them for all backends, proceeds if "type" = "ioemu"
>
> These should be two simple patches. Stage 2:
>
> * we add options in the xl config file to configure any backend, libxl
> set "type" accordingly (Maybe not *any*, but vif, vkbd, vfb could all
> have a "type". It is OK if you only add an option for vkbd.)
> * non-QEMU backends, in particular Linux backends, also read the "type"
> node and proceed if it's "linux"
>
> Does this sound OK to you?
For the first take it does, but I'll get back to it a bit later
Actually the purpose of the change was to find a way
we can live with backends implemented in QEMU and user-space
and how they can co-exist
Thank you,
Oleksandr
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-04-20 6:14 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-11 9:35 [Qemu-devel] [Xen-devel][PATCH] configure: introduce --enable-xen-fb-backend Oleksandr Andrushchenko
2017-04-11 9:35 ` [Qemu-devel][PATCH] " Oleksandr Andrushchenko
2017-04-14 0:12 ` [Qemu-devel] [Xen-devel][PATCH] " Stefano Stabellini
2017-04-14 0:12 ` [Qemu-devel][PATCH] " Stefano Stabellini
2017-04-14 6:06 ` [Qemu-devel] [Xen-devel][PATCH] " Oleksandr Andrushchenko
2017-04-14 6:06 ` [Qemu-devel][PATCH] " Oleksandr Andrushchenko
2017-04-14 8:50 ` [Qemu-devel] [Xen-devel] [PATCH] " Juergen Gross
2017-04-14 8:50 ` [Qemu-devel][PATCH] " Juergen Gross
2017-04-14 17:52 ` [Qemu-devel] [Xen-devel] [PATCH] " Stefano Stabellini
2017-04-14 17:52 ` [Qemu-devel][PATCH] " Stefano Stabellini
2017-04-18 5:26 ` [Qemu-devel] [Xen-devel] [PATCH] " Juergen Gross
2017-04-18 5:26 ` [Qemu-devel][PATCH] " Juergen Gross
2017-04-18 17:25 ` [Qemu-devel] [Xen-devel] [PATCH] " Stefano Stabellini
2017-04-18 17:25 ` [Qemu-devel][PATCH] " Stefano Stabellini
2017-04-20 6:14 ` [Qemu-devel] [Xen-devel] [PATCH] " Oleksandr Andrushchenko
2017-04-20 6:14 ` [Qemu-devel][PATCH] " Oleksandr Andrushchenko
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.