[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qemu-devel
Subject:    Re: [Qemu-devel] [Xen-devel] [PATCH] configure: introduce --enable-xen-fb-backend
From:       Oleksandr Andrushchenko <andr2000 () gmail ! com>
Date:       2017-04-20 6:14:09
Message-ID: 2da8fea2-6293-c1b5-c671-ae16b8445de4 () gmail ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]