Commit dc567cc2 introduced qemuDomainObjPrivateXMLParseJob, but forgot
to move "./job[1]/@type" parsing into it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We read from the agent until seeing a \r\n pair to indicate a completed
reply or event. To avoid memory denial-of-service though, we must have a
size limit on amount of data we buffer. 10 MB is large enough that it
ought to cope with normal agent replies, and small enough that we're not
consuming unreasonable mem.

This is identical to the flaw we had reading from the QEMU monitor
as CVE-2018-5748, so rather embarrassing that we forgot to fix
the agent code at the same time.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

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

This is missing in 6bc4a371 and therefore we are effectively
overwriting user provided aliases for <input/> devices.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Similarly to the formatter extract the parser code.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Modernize the code by using the clever formatter rather than checking
manually when to format the end of the element.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Remove one level of nesting by returing early.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

The code overwrote the internal job type and then fixed it back. Since
the job type is not accessed in the code this does not make much sense.
Use the temporary value instead.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Separate the code for later refactoring
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Since data.count is not a pointer, but an integer,
compare it against an integer value instead of using
the implicit "boolean" conversion that is customarily
used for pointers.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

This time around it's not enough to just pick the latest commit,
because with aed87bb2aa6ed83b49574eb982e3bdd4c36acf17 keycodemapdb
renamed the 'rfb' keycode to 'qnum' and we need to accept the new
name while maintaining backwards compatibility.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Recently, this warning is appearing while libvirt is being compiled:
Function 'qemuAssignDeviceDiskAlias' argument order different:
declaration 'vmdef, def' definition 'def, disk'

This commit change the default declaration for qemuAssignDeviceDiskAlias
specified at src/qemu/qemu_alias.c.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The qemu driver registered the helpers from util code, but it will be
necessary to format also some qemu-specific data.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

We've implemented all existing checks, and more, in the new
function, so we can finally drop the old one.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

This change catches an invalid use of the option in our
test suite.

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

This change catches an invalid use of the option in our
test suite.

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

https://bugzilla.redhat.com/show_bug.cgi?id=1483816Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

The existing function is renamed and called from the new one, so
that even while we're in the process of implementing new checks
all the existing ones will be performed.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

In qemuMigrationSrcRun, we already checked for non-NULL mig
and then dereferenced it. It's only possible for mig to be
NULL in the error section.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Some instances of ARCH_IS_PPC64 did not use them.

Introduced by commits da636d83 and ef08a545Signed-off-by: NJán Tomko <jtomko@redhat.com>

This function was introduced in commit 41f5c2ca as a way
to probe the same property for multiple devices at once.

Although the resulting representation is very compact, it
doesn't provide any extra features compared to the existing
virQEMUCapsProcessStringFlags() mechanism, which is already
used for pretty much all device properties.

Drop the custom function and datatypes and start using the
standard ones instead.

Note that, in theory, the end result is not identical
because we're no longer probing properties for

  virtio-serial-pci
  virtio-9p-pci
  virtio-rng-pci
  virtio-input-host-pci
  virtio-keyboard-pci
  virtio-mouse-pci
  virtio-tablet-pci

However, chances of any of those devices being compiled
into a QEMU binary where

  virtio-balloon-pci
  virtio-blk-pci
  virtio-scsi-pci
  virtio-net-pci
  virtio-gpu-pci

are compiled out are slim enough that it doesn't make any
difference in practice, as the lack of test suite churn
shows.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

In some cases, we are probing multiple devices for the same
property and setting the corresponding capability if it's
found on any of the devices: when that happens, we can quit
early after finding the first property and avoiding a bunch
of string comparisons.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Commit 4ae59411 introduced the ability to make probing for
device properties conditional on a capability being set, but
didn't extend the use of this feature to existing devices.

This commit does the last bit of work, which results in a lot
of pointless QMP chatter no longer happening and our test suite
shrinking a fair bit.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

If we return -1 on VIR_ALLOC_N failure, we leaked @vms, so
goto cleanup instead.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If the user tries to define a domain that has

  <controller type='usb' model='none'/>

and also some USB devices, we report an error:
  error: internal error: No free USB ports

Which is technically still correct for a domain with no USB ports.

Change it to:

USB is disabled for this domain, but USB devices are present in the domain XML

https://bugzilla.redhat.com/show_bug.cgi?id=1347550Signed-off-by: NJán Tomko <jtomko@redhat.com>

When trying to destroy a domain (e.g. because we've seen EOF on
the monitor) we try to acquire QEMU_JOB_DESTROY. However, if
max_queued is set in qemu.conf this may fail and since our code
doesn't count on that we will still report domain as active even
though the qemu process is long gone. More specifically, if we've
seen EOF on the monitor, qemuProcessHandleMonitorEOF() is called
which sends MONITOR_EOF job to the event worker pool and
unregisters monitor from the event loop. The worker pool calls
processMonitorEOFEvent() which tries to set job which may fail
due to the limit as described above.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since QEMU 2.12 commit id '4ada99ade' guest crash information for
S390 is available in the QEMU monitor, e.g.:

  {
    "timestamp": {
        "seconds": 1518004739,
        "microseconds": 552563
    },
    "event": "GUEST_PANICKED",
    "data": {
        "action": "pause",
        "info": {
            "core": 0,
            "psw-addr": 1102832,
            "reason": "disabled-wait",
            "psw-mask": 562956395872256,
            "type": "s390"
        }
    }
  }

Let's log this information into the domain log file, e.g.:

    2018-02-08 13:11:26.075+0000: panic s390: core='0' psw-mask='0x0002000180000000' psw-addr='0x000000000010f146' reason='disabled-wait'
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Fix this common typo and assign a value rather than implicitly
type-casted comparison result. Introduced by commit b6a264e8.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

12 bytes in 1 blocks are definitely lost in loss record 188 of 1,145
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D2CD77: xmlStrndup (in /lib/x86_64-linux-gnu/libxml2.so.2.7.8)
by 0x514E137: virXMLPropString (virxml.c:506)
by 0x234F51: qemuMigrationCookieNetworkXMLParse qemu_migration.c:1001)
by 0x235FF8: qemuMigrationCookieXMLParse (qemu_migration.c:1333)
by 0x236214: qemuMigrationCookieXMLParseStr (qemu_migration.c:1372)
by 0x2365D2: qemuMigrationEatCookie (qemu_migration.c:1456)
by 0x243DBA: qemuMigrationFinish (qemu_migration.c:6381)
by 0x204032: qemuDomainMigrateFinish3 (qemu_driver.c:13228)
by 0x521CCBB: virDomainMigrateFinish3 (libvirt-domain.c:4788)
by 0x1936DE: remoteDispatchDomainMigrateFinish3 (remote.c:4580)
by 0x16DBB1: remoteDispatchDomainMigrateFinish3Helper(remote_dispatch.h:7582)
Signed-off-by: NZhangZijian <zhang.zijian@h3c.com>

This partially reverts 82592551.

When migrating a domain, qemuMigrationDstPrepareAny() is called
which eventually calls qemuProcessLaunch(conn = NULL, flags =
VIR_QEMU_PROCESS_START_AUTODESTROY); But the very first thing
that qemuProcessLaunch does is check if AUTODESTROY flag is set
and @conn is not NULL. Well, it is.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

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

If a domain disk is stored on local filesystem (e.g. ext4) but is
not being migrated it is very likely that domain is not able to
run on destination. Regardless of share/cache mode.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

When calling virDomainDefCompatibleDevice to check a new device during
device update, we need to pass the original device which is going to be
updated in addition to the new device. Otherwise, the function can
report false conflicts.

The new argument is currently ignored by virDomainDefCompatibleDevice,
but this will change in the following patch.

https://bugzilla.redhat.com/show_bug.cgi?id=1546971Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

vm->def->nets[changeidx] can never be NULL for changeidx returned by
virDomainNetFindIdx.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>