[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Qemu-devel][PATCH] configure: introduce --enable-xen-fb-backend



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@xxxxxxxx>
> >>>
> >>> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.