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

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

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