QEMU added support for ivshmem-plain and ivshmem-doorbell.  Those are
reworked varians of legacy ivshmem that are compatible from the guest
POV, but not from host's POV and have sane specification and handling.

Details about the newer device type can be found in qemu's commit
5400c02b90bb:

  http://git.qemu.org/?p=qemu.git;a=commit;h=5400c02b90bbSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

The old ivshmem is deprecated in QEMU, so let's use the better
ivshmem-{plain,doorbell} variants instead.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Just the default one now, new ones will be added in following commits.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Add the secret object so the 'passwordid=' can be added if the command line
if there's a secret defined in/on the host for TCP chardev TLS objects.

Preparation for the secret involves adding the secinfo to the char source
device prior to command line processing. There are multiple possibilities
for TCP chardev source backend usage.

Add test for at least a serial chardev as an example.

Add in the block I/O throttling length/duration parameter to the command
line if supported. If not supported, fail command creation.

Add the xml2argvtest for testing.

Add an optional "tls='yes|no'" attribute for a TCP chardev.

For QEMU, this will allow for disabling the host config setting of the
'chardev_tls' for a domain chardev channel by setting the value to "no" or
to attempt to use a host TLS environment when setting the value to "yes"
when the host config 'chardev_tls' setting is disabled, but a TLS environment
is configured via either the host config 'chardev_tls_x509_cert_dir' or
'default_tls_x509_cert_dir'
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Currently the union has only one member so remove that union.  If there
is a need to add a new type of source for new bus in the future this
will force the author to add a union and properly check bus type before
any access to union member.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Use a pointer and the virDomainChrSourceDefNew() function in order to
allocate the structure for _virDomainRedirdevDef.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Use a pointer and the virDomainChrSourceDefNew() function in order to
allocate the structure for _virDomainSmartcardDef.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Change the virDomainChrDef to use a pointer to 'source' and allocate
that pointer during virDomainChrDefNew.

This has tremendous "fallout" in the rest of the code which mainly
has to change source.$field to source->$field.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

This function is never called for VIR_DOMAIN_NET_TYPE_HOSTDEV,
and the dead code comment agrees.

Introduced by commit 1dcbef8a.

Put the comma at the end and trim it later for consistency.

When hotplugging networks with ancient QEMUs not supporting
QEMU_CAPS_NETDEV, we use space instead of a comma as the separator
between the network type and other options.

Except for "user", all the network types pass other options
and use up the first separator by the time we get to the section
that adds the alias (or vlan for QEMUs without CAPS_NETDEV).

Since the alias/vlan is mandatory, convert all preceding code to add
the separator at the end, removing the need to rewrite type_sep for
all types but NET_TYPE_USER.

There was inconsistency between alias used to create tls-creds-x509
object and alias used to link that object to chardev while hotpluging.
Hotplug ends with this error:

  error: Failed to detach device from channel-tcp.xml
  error: internal error: unable to execute QEMU command 'chardev-add':
  No TLS credentials with id 'objcharchannel3_tls0'

In XML we have for example alias "serial0", but on qemu command line we
generate "charserial0".

The issue was that code, that creates QMP command to hotplug chardev
devices uses only the second alias "charserial0" and that alias is also
used to link the tls-creds-x509 object.

This patch unifies the aliases for tls-creds-x509 to be always generated
from "charserial0".
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Instead of typing the prefix every time we want to append parameters
to qemu command line use a variable that contains prefixed alias.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1366505

So far, this function lacked support for
VIR_DOMAIN_NET_TYPE_VHOSTUSER leaving callers to hack around the
problem by constructing the command line on their own. This is
not ideal as it blocks hot plug support.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Currently, what we do for vhost-user network is generate the
following part of command line:

-netdev type=vhost-user,id=hostnet0,chardev=charnet0

There's no need for 'type=' it is the default. Drop it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There's no need to reinvent the wheel here. We already have a
function to format virDomainChrSourceDefPtr. It's called
qemuBuildChrChardevStr(). Use that instead of some dummy
virBufferAsprintf().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This alone makes not much sense. But the aim is to reuse this
function in qemuBuildVhostuserCommandLine() where 'nowait' is not
supported for vhost-user devices.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We tend to prevent using 'default' in switches. And it is for a
good reason - control may end up in paths we wouldn't want for
new values. In this specific case, if qemuBuildHostNetStr is
called over VIR_DOMAIN_NET_TYPE_VHOSTUSER it would produce
meaningless output. Fortunately, there no such call yet.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The idea is to have function that does some checking of the
arguments at its beginning and then have one big switch for all
the interface types it supports. Each one of them generating the
corresponding part of the command line.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The idea is to have function that does some checking of the
arguments at its beginning and then have one big switch for all
the interface types it supports. Each one of them generating the
corresponding part of the command line.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This function for some weird reason returns integer instead of
virDomainNetType type. It is important to return the correct type
so that we know what values we can expect.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We pass free-form strings from the users to qemu, thus we need escape
commas since they are passed to qemu monitor.

Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1373535

qemuBuildSmbiosBiosStr and qemuBuildSmbiosSystemStr return NULL if
there's nothing to format on the commandline. Reporting errors from
buffer creation doesn't make sense since it would be ignored.

There are two video devices with models without VGA compatibility mode.
They are primary used as secondary video devices, but in some cases it
is required to use them also as primary video devices.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This improves commit 706b5b62 in a way that we check qemu capabilities
instead of what architecture we are running on to detect whether we can
use *virtio-vga* model or not.  This is not a case only for arm/aarch64.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Runtime validation that depend on qemu capabilities should be moved
into qemuProcessStartValidateXML.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

All definition validation that doesn't depend on qemu capabilities
and was allowed previously as valid definition should be placed into
qemuDomainDefValidate.

The check whether video type is supported or not was based on an enum
that translates type into model.  Use switch to ensure that if new
video type is added, it will be properly handled.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We generally uses QEMU_CAPS_DEVICE_$NAME to probe for existence of some
device and QEMU_CAPS_$NAME_$PROP to probe for existence of some property
of that device.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

If QEMU in question supports QMP, this capability is set if
QEMU_CAPS_DEVICE_QXL was set based on existence of "-device qxl". If
libvirt needs to parse *help*, because there is no QMP support, it
checks for existence of "-vga qxl", but it also parses output of
"-device ?" and sets QEMU_CAPS_DEVICE_QXL too.

Now that libvirt supports only QEMU that has "-device" implemented it's
safe to drop this capability and stop using it.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

This patch simplifies QEMU capabilities for QXL video device.  QEMU
exposes this device as *qxl-vga* and *qxl* and they are both the same
device with the same set of parameters, the only difference is that
*qxl-vga* includes VGA compatibility.

Based on QEMU code they are tied together so it's safe to check only for
presence of only one of them.

This patch also removes an invalid test case "video-qxl-sec-nodevice"
where there is only *qxl-vga* device and *qxl* device is not present.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Qemu supports *xen* video device only with XEN and this code was part
of xenner code.  We dropped support for xenner in commit de9be0ab.

Before this patch if you used 'xen' video type you ended up with
domain without any video device at all.  Now we don't allow to start
such domain.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The intel-iommu device has existed since QEMU 2.2.0, but
it was only possible to create it with -device since
QEMU 2.7.0, thanks to:

  commit 621d983a1f9051f4cfc3f402569b46b77d8449fc
  Author: Marcel Apfelbaum <marcel@redhat.com>
  Date:   Mon Jun 27 18:38:34 2016 +0300

    hw/iommu: enable iommu with -device

    Use the standard '-device intel-iommu' to create the IOMMU device.
    The legacy '-machine,iommu=on' can still be used.

The libvirt capability check & command line formatting code
is thus broken for all QEMU versions 2.2.0 -> 2.6.0 inclusive.

This fixes it to use iommu=on instead.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>