Re: [PATCH 09/10] device: cleanup input device code

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

 



On Thu, Jan 07, 2016 at 12:32:41 +0100, Pavel Hrdina wrote:
> The current code was a little bit odd.  At first we've removed all
> possible implicit input devices from domain definition to add them later
> back if there was any graphics device defined while parsing XML
> description.  That's not all, while formating domain definition to XML
> description we at first ignore any input devices with bus different to
> USB and VIRTIO and few lines later we add implicit input devices to XML.
> 
> This seems to me as a lot of code for nothing.  This patch may look
> to be more complicated than original approach, but this is a preferred
> way to modify/add driver specific staff only in those drivers and not

s/staff/stuff/

> deal with them in common parsing/formating functions.
> 
> The update is to add those implicit input devices into config XML to
> follow the real HW configuration visible by guest OS.
> 
> There was also inconsistence between our behavior and QEMU's in the way,
> that in QEMU there is no way how to disable those implicit input devices
> for x86 architecture and they are available always, even without graphics
> device.  This applies also to XEN hypervisor.  VZ driver already does its
> part by putting correct implicit devices into live XML.

It would be also worth mentioning that qemu always adds PS2 devices even
if graphics are disabled.

> 
> Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx>
> ---
>  src/Makefile.am            |  4 +--
>  src/conf/domain_conf.c     | 77 ++--------------------------------------------
>  src/libxl/libxl_domain.c   |  5 +++
>  src/qemu/qemu_domain.c     | 22 +++++++++++++
>  src/xen/xen_driver.c       |  5 +++
>  src/xenapi/xenapi_driver.c |  5 +++
>  src/xenconfig/xen_common.c | 22 +++++++++++++
>  src/xenconfig/xen_common.h |  2 ++
>  8 files changed, 66 insertions(+), 76 deletions(-)

> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 9d47846..d4ceb32 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -15930,27 +15930,6 @@ virDomainDefParseXML(xmlDocPtr xml,
>              goto error;
>          }
>  
> -        /* With QEMU / KVM / Xen graphics, mouse + PS/2 is implicit
> -         * with graphics, so don't store it.
> -         * XXX will this be true for other virt types ? */
> -        if ((def->os.type == VIR_DOMAIN_OSTYPE_HVM &&
> -             input->bus == VIR_DOMAIN_INPUT_BUS_PS2 &&
> -             (input->type == VIR_DOMAIN_INPUT_TYPE_MOUSE ||
> -              input->type == VIR_DOMAIN_INPUT_TYPE_KBD)) ||
> -            (def->os.type == VIR_DOMAIN_OSTYPE_XEN &&
> -             input->bus == VIR_DOMAIN_INPUT_BUS_XEN &&
> -             (input->type == VIR_DOMAIN_INPUT_TYPE_MOUSE ||
> -              input->type == VIR_DOMAIN_INPUT_TYPE_KBD)) ||
> -            (def->os.type == VIR_DOMAIN_OSTYPE_EXE &&
> -             (def->virtType == VIR_DOMAIN_VIRT_VZ ||
> -              def->virtType == VIR_DOMAIN_VIRT_PARALLELS)  &&
> -             input->bus == VIR_DOMAIN_INPUT_BUS_PARALLELS &&

One small nit is that parallels adds the device only when it loads the
internal config, but not when it would create a new one from user-passed
XML. The code seems just to validate that a expected config is peresent
(where 0 devices are actually a expected option) and ignores any further
config.

It might be worth checking with parallels guys that this is ok, but I
don't see a problem with it right now.

Also note that the VZ driver enforces a rigorous ordering, where the
mouse has be at index 0 and keyboard at index 1. Not that this patch
would break that, I just noticed it.

> -             (input->type == VIR_DOMAIN_INPUT_TYPE_MOUSE ||
> -              input->type == VIR_DOMAIN_INPUT_TYPE_KBD))) {
> -            virDomainInputDefFree(input);
> -            continue;
> -        }
> -
>          def->inputs[def->ninputs++] = input;
>      }
>      VIR_FREE(nodes);

...

> @@ -22247,32 +22202,6 @@ virDomainDefFormatInternal(virDomainDefPtr def,
>      }
>  
>      if (def->ngraphics > 0) {
> -        /* If graphics is enabled, add the implicit mouse/keyboard */
> -        if ((ARCH_IS_X86(def->os.arch)) || def->os.arch == VIR_ARCH_NONE) {
> -            virDomainInputDef autoInput = {
> -                .type = VIR_DOMAIN_INPUT_TYPE_MOUSE,
> -                .info = { .alias = NULL },
> -            };
> -
> -            if (def->os.type == VIR_DOMAIN_OSTYPE_HVM)
> -                autoInput.bus = VIR_DOMAIN_INPUT_BUS_PS2;
> -            else if (def->os.type == VIR_DOMAIN_OSTYPE_EXE &&
> -                     (def->virtType == VIR_DOMAIN_VIRT_VZ ||
> -                      def->virtType == VIR_DOMAIN_VIRT_PARALLELS))
> -                autoInput.bus = VIR_DOMAIN_INPUT_BUS_PARALLELS;
> -            else
> -               autoInput.bus = VIR_DOMAIN_INPUT_BUS_XEN;
> -
> -            if (virDomainInputDefFormat(buf, &autoInput, flags) < 0)
> -                goto error;
> -
> -            if (!(flags & VIR_DOMAIN_DEF_FORMAT_MIGRATABLE)) {
> -                autoInput.type = VIR_DOMAIN_INPUT_TYPE_KBD;
> -                if (virDomainInputDefFormat(buf, &autoInput, flags) < 0)
> -                    goto error;

Hmm, this looks problematic though. In case when the XML will be used
for migration after this patch the XML will start to contain the
keyboard input definition. Jiri might be able to chime in to quantify
the extent of things this might break.

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]