configure: introduce --enable-xen-fb-backend

From: Oleksandr Andrushchenko <[email protected]>

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 <[email protected]>

---
 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(-)

configure +18 -0

index 476210b1b93f..b805cb908f03 100755
@@ -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

hw/display/Makefile.objs +1 -1

index 063889beaf4a..f5ec97ed4f48 100644
@@ -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

hw/xen/xen_backend.c +2 -0

index d1190041ae12..5146cbba6ca5 100644
@@ -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);

hw/xenpv/xen_machine_pv.c +4 -0

index 79aef4ecc37b..b731344c3f0a 100644
@@ -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)

Signature · 1 line

2.7.4

Quoted 7 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

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".

Quoted 116 lines

Signed-off-by Oleksandr Andrushchenko <[email protected]>

---
  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(-)

configure +18 -0

index 476210b1b93f..b805cb908f03 100755
@@ -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

hw/display/Makefile.objs +1 -1

index 063889beaf4a..f5ec97ed4f48 100644
@@ -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

hw/xen/xen_backend.c +2 -0

index d1190041ae12..5146cbba6ca5 100644
@@ -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);

hw/xenpv/xen_machine_pv.c +4 -0

index 79aef4ecc37b..b731344c3f0a 100644
@@ -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
  }
 

Quoted 4 lines

hw/xenpv/xen_machine_pv.c +0 -0

  static void xenpv_machine_init(MachineClass *mc)

Signature · 1 line

2.7.4

Quoted 8 lines · Stefano Stabellini

Quoted 7 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

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.

Quoted 9 lines

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)

Quoted 18 lines · Oleksandr Andrushchenko

Quoted 8 lines · Stefano Stabellini

Quoted 7 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

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.

Quoted 9 lines

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".

Quoted 7 lines

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"?

Quoted 27 lines · Juergen Gross

Quoted 18 lines · Oleksandr Andrushchenko

Quoted 8 lines · Stefano Stabellini

Quoted 7 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

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.

Quoted 9 lines

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".

Quoted 7 lines

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)

Quoted 2 lines

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?

Quoted 36 lines · Stefano Stabellini

Quoted 27 lines · Juergen Gross

Quoted 18 lines · Oleksandr Andrushchenko

Quoted 8 lines · Stefano Stabellini

Quoted 7 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

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.

Quoted 9 lines

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".

Quoted 7 lines

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)

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 14 lines

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:

Quoted 8 lines

* 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?

Quoted 26 lines · Juergen Gross

Quoted 25 lines · Oleksandr Andrushchenko

Quoted 8 lines · Stefano Stabellini

Quoted 7 lines · Oleksandr Andrushchenko

From: Oleksandr Andrushchenko <[email protected]>

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.

Quoted 9 lines

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)

Quoted 2 lines

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?