QEMU ppce500 board uses the legacy -serial option.

Other PPC boards don't give any way to explicitly wire in a -chardev
except pseries which uses -device spapr-vty with -chardev.

Add test case for -serial option for ppce500
Signed-off-by: NOlivia Yin <Hong-Hua.Yin@freescale.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

QEMU commit 5e2ac51 added a boolean '-msg timestamp=[on|off]'
option, which can enable timestamps on errors:
$ qemu-system-x86_64 -msg timestamp=on zghhdorf
2014-04-09T13:25:46.779484Z qemu-system-x86_64: -msg timestamp=on: could
not open disk image zghhdorf: Could not open 'zghhdorf': No such file or
directory

Enable this timestamp if the QEMU binary supports it.

Add a 'log_timestamp' option to qemu.conf for disabling this behavior.

Quite a long time ago, (apparently between qemu 0.12 and 0.13) qemu
quietly began supporting the optional specification of a domain in the
host-side address of all pci passthrough commands (by simply
prepending it to the bus:slot.function format, as
"dddd:bb:ss.f"). Since machines with multiple PCI domains are very
rare, this never came up in practice, so libvirt was never updated to
support it.

This patch takes the first step to supporting specification of a non-0
domain in the host-side address of PCI devices being assigned to a
domain, by adding a capability bit to indicate support
"QEMU_CAPS_HOST_PCI_MULTIDOMAIN", and detect it. Since this support
was added in a version prior to the minimum version required for
QMP-style capabilities detection, the capability is always enabled for
any qemu that uses QMP for capabilities detection. For older qemus,
the only clue that a domain can be specified in the host pci address
is the presence of the string "[seg:]" in the help string for
-pcidevice. (Ironically, libvirt will not be modified to support
specification of domain for -pcidevice, since any qemu new enough for
us to care about also supports "-device pci-assign" or "-device
vfio-pci", which are greatly preferred).

Recent discussions around naming of 'pci' vs 'pci.0' for PPC
made me go back and look at the PPC emulator in every historical
version of QEMU since 1.0. The results were worse than I imagined.
This patch adds the logic required to make libvirt work with PPC
correctly with naming variations across all versions & machine
types.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Fix minor typos in source comments
Signed-off-by: NEric Blake <eblake@redhat.com>

The version check is for >=1.3.0, but ComputeCmdFlags
is only called for QEMU <1.2.0.

QEMU only supports it on x86, but we've been assuming it for
all QEMUs when doing QMP capability detection.

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

Since it is an abbreviation, PCI should always be fully
capitalized or full lower case, never Pci.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Since it is an abbreviation, USB should always be fully
capitalized or full lower case, never Usb.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Since it is an abbreviation, SCSI should always be fully
capitalized or full lower case, never Scsi.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

I almost wrote a hash value free function that just called
VIR_FREE, then realized I couldn't be the first person to
do that.  Sure enough, it was worth factoring into a common
helper routine.

* src/util/virhash.h (virHashValueFree): New function.
* src/util/virhash.c (virHashValueFree): Implement it.
* src/util/virobject.h (virObjectFreeHashData): New function.
* src/libvirt_private.syms (virhash.h, virobject.h): Export them.
* src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnInit): Use
common function.
* src/qemu/qemu_capabilities.c (virQEMUCapsCacheNew): Likewise.
* src/qemu/qemu_command.c (qemuDomainCCWAddressSetCreate):
Likewise.
* src/qemu/qemu_monitor.c (qemuMonitorGetBlockInfo): Likewise.
* src/qemu/qemu_process.c (qemuProcessWaitForMonitor): Likewise.
* src/util/virclosecallbacks.c (virCloseCallbacksNew): Likewise.
* src/util/virkeyfile.c (virKeyFileParseGroup): Likewise.
* tests/qemumonitorjsontest.c
(testQemuMonitorJSONqemuMonitorJSONGetBlockInfo): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

While running qemucaps2xmltest, it was found that valgrind pointed out
the following memory leaks:

==29896== 0 bytes in 1 blocks are definitely lost in loss record 1 of 65
==29896==    at 0x4A0577B: calloc (vg_replace_malloc.c:593)
==29896==    by 0x4C6B45E: virAllocN (viralloc.c:191)
==29896==    by 0x4232A9: virQEMUCapsGetMachineTypesCaps (qemu_capabilities.c:1999)
==29896==    by 0x4234E7: virQEMUCapsInitGuestFromBinary (qemu_capabilities.c:789)
==29896==    by 0x41F10B: testQemuCapsXML (qemucaps2xmltest.c:118)
==29896==    by 0x41FFD1: virtTestRun (testutils.c:201)
==29896==    by 0x41EE7A: mymain (qemucaps2xmltest.c:203)
==29896==    by 0x42074D: virtTestMain (testutils.c:789)
==29896==    by 0x3E6CE1ED1C: (below main) (libc-start.c:226)
==29896==
==29896== 0 bytes in 1 blocks are definitely lost in loss record 2 of 65
==29896==    at 0x4A0577B: calloc (vg_replace_malloc.c:593)
==29896==    by 0x4C6B45E: virAllocN (viralloc.c:191)
==29896==    by 0x4232A9: virQEMUCapsGetMachineTypesCaps (qemu_capabilities.c:1999)
==29896==    by 0x4234E7: virQEMUCapsInitGuestFromBinary (qemu_capabilities.c:789)
==29896==    by 0x41F10B: testQemuCapsXML (qemucaps2xmltest.c:118)
==29896==    by 0x41FFD1: virtTestRun (testutils.c:201)
==29896==    by 0x41EEA3: mymain (qemucaps2xmltest.c:204)
==29896==    by 0x42074D: virtTestMain (testutils.c:789)
==29896==    by 0x3E6CE1ED1C: (below main) (libc-start.c:226)
Signed-off-by: NEric Blake <eblake@redhat.com>

This patch decouples the binary and the capabilities detection
from the guest initialization.

The purpose is to make testing easier.

This patch adds an element to QEMU's capability XML, to
show if the underlying QEMU binary supports the live disk
snapshotting or not.
This allows any client to know ahead of time if the feature
is available.

Without this information available, the only way to check
for the snapshot support is to request one and check for
errors.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>

Valgrind reported leaking of maxCpus and arch strings from
virXPathString, as well as the leak of the machineMaxCpus array.

Don't use 'str' for the strings we don't want to free, to allow
freeing of 'str' in the cleanup label and free machineMaxCpus
in virCapsReset too.

Any source file which calls the logging APIs now needs
to have a VIR_LOG_INIT("source.name") declaration at
the start of the file. This provides a static variable
of the virLogSource type.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

As part of the goal to get away from doing string matching on
filenames when deciding whether to emit a log message, turn
the virLogSource enum into a struct which contains a log
"name". There will eventually be one virLogSource instance
statically declared per source file. To minimise churn in this
commit though, a single global instance is used.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Extracting capabilities from QEMU takes a notable amount of time
when all QEMU binaries are installed. Each system emulator
needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds.

This change causes the QEMU driver to save an XML file containing
the content of the virQEMUCaps object instance in the cache
dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml
or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml

We attempt to load this and only if it fails, do we fallback to
probing the QEMU binary. The ctime of the QEMU binary and libvirtd
are stored in the cached file and its data discarded if either
of them change.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Debian's package manager will preserve mtime timestamp on binaries
from the time they are built, rather than installed. So if a
user downgrades their QEMU dpkg, the libvirt capabilities
cache will not refresh. The fix is to use ctime instead of mtime
since it cannot be faked.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Auditing all callers of virCommandRun and virCommandWait that
passed a non-NULL pointer for exit status turned up some
interesting observations.  Many callers were merely passing
a pointer to avoid the overall command dying, but without
caring what the exit status was - but these callers would
be better off treating a child death by signal as an abnormal
exit.  Other callers were actually acting on the status, but
not all of them remembered to filter by WIFEXITED and convert
with WEXITSTATUS; depending on the platform, this can result
in a status being reported as 256 times too big.  And among
those that correctly parse the output, it gets rather verbose.
Finally, there were the callers that explicitly checked that
the status was 0, and gave their own message, but with fewer
details than what virCommand gives for free.

So the best idea is to move the complexity out of callers and
into virCommand - by default, we return the actual exit status
already cleaned through WEXITSTATUS and treat signals as a
failed command; but the few callers that care can ask for raw
status and act on it themselves.

* src/util/vircommand.h (virCommandRawStatus): New prototype.
* src/libvirt_private.syms (util/command.h): Export it.
* docs/internals/command.html.in: Document it.
* src/util/vircommand.c (virCommandRawStatus): New function.
(virCommandWait): Adjust semantics.
* tests/commandtest.c (test1): Test it.
* daemon/remote.c (remoteDispatchAuthPolkit): Adjust callers.
* src/access/viraccessdriverpolkit.c (virAccessDriverPolkitCheck):
Likewise.
* src/fdstream.c (virFDStreamCloseInt): Likewise.
* src/lxc/lxc_process.c (virLXCProcessStart): Likewise.
* src/qemu/qemu_command.c (qemuCreateInBridgePortWithHelper):
Likewise.
* src/xen/xen_driver.c (xenUnifiedXendProbe): Simplify.
* tests/reconnect.c (mymain): Likewise.
* tests/statstest.c (mymain): Likewise.
* src/bhyve/bhyve_process.c (virBhyveProcessStart)
(virBhyveProcessStop): Don't overwrite virCommand error.
* src/libvirt.c (virConnectAuthGainPolkit): Likewise.
* src/openvz/openvz_driver.c (openvzDomainGetBarrierLimit)
(openvzDomainSetBarrierLimit): Likewise.
* src/util/virebtables.c (virEbTablesOnceInit): Likewise.
* src/util/viriptables.c (virIpTablesOnceInit): Likewise.
* src/util/virnetdevveth.c (virNetDevVethCreate): Fix debug
message.
* src/qemu/qemu_capabilities.c (virQEMUCapsInitQMP): Add comment.
* src/storage/storage_backend_iscsi.c
(virStorageBackendISCSINodeUpdate): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

When probing QEMU capabilities fails for a binary generate a
log message with MESSAGE_ID==8ae2f3fb-2dbe-498e-8fbd-012d40afa361.

This can be directly queried from journald based on the UUID
instead of needing string grep. This lets tools like libguestfs'
bug reporting tool trivially do automated sanity tests on the
host they're running on.

 $ journalctl MESSAGE_ID=8ae2f3fb-2dbe-498e-8fbd-012d40afa361
 Feb 21 17:11:01 localhost.localdomain lt-libvirtd[9196]:
 Failed to probe capabilities for /bin/qemu-system-alpha:
 internal error: Child process (LC_ALL=C LD_LIBRARY_PATH=
 /home/berrange/src/virt/libvirt/src/.libs PATH=/usr/lib64/
 ccache:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:
 /usr/bin:/root/bin HOME=/root USER=root LOGNAME=root
 /bin/qemu-system-alpha -help) unexpected exit status 127:
 /bin/qemu-system-alpha: error while loading shared libraries:
 libglapi.so.0: cannot open shared object file: No such file
 or directory

 $ journalctl MESSAGE_ID=8ae2f3fb-2dbe-498e-8fbd-012d40afa361 --output=json
 { ...snip...
  "LIBVIRT_SOURCE" : "file",
  "PRIORITY" : "3",
  "CODE_FILE" : "qemu/qemu_capabilities.c",
  "CODE_LINE" : "2770",
  "CODE_FUNC" : "virQEMUCapsLogProbeFailure",
  "MESSAGE_ID" : "8ae2f3fb-2dbe-498e-8fbd-012d40afa361",
  "LIBVIRT_QEMU_BINARY" : "/bin/qemu-system-xtensa",
  "MESSAGE" : "Failed to probe capabilities for /bin/qemu-system-xtensa:
   internal error: Child process (LC_ALL=C LD_LIBRARY_PATH=/home/berrange
   /src/virt/libvirt/src/.libs PATH=/usr/lib64/ccache:/usr/local/sbin:
   /usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin HOME=/root
   USER=root LOGNAME=root /bin/qemu-system-xtensa -help) unexpected
   exit status 127: /bin/qemu-system-xtensa: error while loading shared
   libraries: libglapi.so.0: cannot open shared object file: No such
    file or directory\n" }
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add USB keyboard capability probing and test cases.
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Add a new backend for any character device.  This backend uses channel
in spice connection.  This channel is similar to spicevmc, but
all-purpose in contrast to spicevmc.

Apart from spicevmc, spiceport-backed chardev will not be formatted
into the command-line if there is no spice to use (with test for that
as well).  For this I moved the def->graphics counting to the start
of the function so its results can be used in rest of the code even in
the future.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

spice-server offers an API to disable file transfer messages
on the agent channel between the client and the guest.
This is supported in qemu through the disable-agent-file-xfer option.

This patch detects if QEMU supports this option, and add
a capability if does.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>

This patch fixes a segmentation fault when creating new virtual machines using QEMU.
The segmentation fault is caused by commit f4183068
and commit cbb6ec42.

In virQEMUCapsProbeQMPMachineTypes, when copying machines to qemuCaps, "none" is skipped.
Therefore, the value of i and "qemuCaps->nmachineTypes - 1" do not always match.
However, defIdx value (used to call virQEMUCapsSetDefaultMachine) is set using the value in i
when the array elements are in qemuCaps->nmachineTypes - 1.
So, when libvirt tries to create virtual machines using the default machine type,
qemuCaps->machineTypes[defIdx] is accessed and since the defIdx is NULL, it results in segmentation fault.
Signed-off-by: NYudai Yamagishi <yummy@sfc.wide.ad.jp>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

AArch64 qemu has similar behavior as armv7l, like use of mmio etc.
This patch adds similar bypass checks what we have for armv7l to aarch64.
E.g. we are enabling mmio transport for Nicdev.
Making addDefaultUSB and addDefaultMemballoon to false etc.

V3:
- Adding missing domain rng schema for aarcg64 and test case in
  testutilsqemu.c which was causing test suite failure
  while running make check.

V2:
- Added testcase to qemuxml2argvtest as suggested
  during review comments of V1.

V1:
- Initial patch.
Signed-off-by: NAnup Patel <anup.patel@linaro.org>
Signed-off-by: NPranavkumar Sawargaonkar <pranavkumar@linaro.org>

On a system that is enforcing FIPS, most libraries honor the
current mode by default.  Qemu, on the other hand, refused to
honor FIPS mode unless you add the '-enable-fips' command
line option; worse, this option is not discoverable via QMP,
and is only present on binaries built for Linux.  So, if we
detect FIPS mode, then we unconditionally ask for FIPS; either
qemu is new enough to have the option and then correctly
cripple insecure VNC passwords, or it is so old that we are
correctly avoiding a FIPS violation by preventing qemu from
starting.  Meanwhile, if we don't detect FIPS mode, then
omitting the argument is safe whether the qemu has the option
(but it would do nothing because FIPS is disabled) or whether
qemu lacks the option (including in the case where we are not
running on Linux).

The testsuite was a bit interesting: we don't want our test
to depend on whether it is being run in FIPS mode, so I had
to tweak things to set the capability bit outside of our
normal interaction with capability parsing.

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1035474

* src/qemu/qemu_capabilities.h (QEMU_CAPS_ENABLE_FIPS): New bit.
* src/qemu/qemu_capabilities.c (virQEMUCapsInitQMP): Conditionally
set capability according to detection of FIPS mode.
* src/qemu/qemu_command.c (qemuBuildCommandLine): Use it.
* tests/qemucapabilitiestest.c (testQemuCaps): Conditionally set
capability to test expected output.
* tests/qemucapabilitiesdata/caps_1.2.2-1.caps: Update list.
* tests/qemucapabilitiesdata/caps_1.6.0-1.caps: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

The support for <boot rebootTimeout="12345"/> was added before we were
checking for qemu command line options in QMP, so we haven't properly
adapted virQEMUCaps when using it and thus we report unsupported
option with new enough qemu.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1042690Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Map the new <panic> device in XML to the '-device pvpanic' command
line of qemu.  Clients can then couple the <panic> device and the
<on_crash> directive to control behavior when the guest reports
a panic to qemu.
Signed-off-by: NHu Tao <hutao@cn.fujitsu.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

This resolves:

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

(which was already closed as CANTFIX because the qemu "-boot strict"
commandline option wasn't available at the time).

Problem: you couldn't have a domain that used PXE to boot, but also
had an un-bootable disk device *even if that disk wasn't listed in the
boot order*, because if PXE timed out (e.g. due to the bridge
forwarding delay), the BIOS would move on to the next target, which
would be the unbootable disk device (again - even though it wasn't
given a boot order), and get stuck at a "BOOT DISK FAILURE, PRESS ANY
KEY" message until a user intervened.

The solution available since sometime around QEMU 1.5, is to add
"-boot strict=on" to *every* qemu command. When this is done, if any
devices have a boot order specified, then QEMU will *only* attempt to
boot from those devices that have an explicit boot order, ignoring the
rest.

The 'none' machine type is something only intended for use
by libvirt probing capabilities. It isn't something that
is useful for running real VM instances. As such it should
not be exposed to users in the capabilities.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virQEMUCapsProbeQMPMachineTypes method iterates over machine
types copying them into the qemuCapsPtr object. It only updates
the qemuCaps->nmachinetypes value at the end though. So if OOM
occurs in the middle, the destructor of qemuCapsPtr will not
free the partially initialized machine types.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Since qemu-kvm 1.1 [1] (since 1.3. in upstream QEMU [2])
'-no-kvm-pit-reinjection' has been deprecated.
Use -global kvm-pit.lost_tick_policy=discard instead.

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

[1] http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/commit/?id=4e4fa39
[2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c21fb4f

I've noticed a SIGSEGV-ing libvirtd on the destination when the qemu
died too quickly = in Prepare phase. What is happening here is:

1) [Thread 3493] We are in qemuMigrationPrepareAny() and calling
qemuProcessStart() which subsequently calls qemuProcessWaitForMonitor()
and qemuConnectMonitor(). So far so good. The qemuMonitorOpen()
succeeds, however switching monitor to QMP mode fails as qemu died
meanwhile. That is qemuMonitorSetCapabilities() returns -1.

2013-10-08 15:54:10.629+0000: 3493: debug : qemuMonitorSetCapabilities:1356 : mon=0x14a53da0
2013-10-08 15:54:10.630+0000: 3493: debug : qemuMonitorJSONCommandWithFd:262 : Send command '{"execute":"qmp_capabilities","id":"libvirt-1"}' for write with FD -1
2013-10-08 15:54:10.630+0000: 3493: debug : virEventPollUpdateHandle:147 : EVENT_POLL_UPDATE_HANDLE: watch=17 events=13
...
2013-10-08 15:54:10.631+0000: 3493: debug : qemuMonitorSend:956 : QEMU_MONITOR_SEND_MSG: mon=0x14a53da0 msg={"execute":"qmp_capabilities","id":"libvirt-1"}
 fd=-1
2013-10-08 15:54:10.631+0000: 3262: debug : virEventPollRunOnce:641 : Poll got 1 event(s)

2) [Thread 3262] The event loop is trying to do the talking to monitor.
However, qemu is dead already, remember?

2013-10-08 15:54:13.436+0000: 3262: error : qemuMonitorIORead:551 : Unable to read from monitor: Connection reset by peer
2013-10-08 15:54:13.516+0000: 3262: debug : virFileClose:90 : Closed fd 25
...
2013-10-08 15:54:13.533+0000: 3493: debug : qemuMonitorSend:968 : Send command resulted in error internal error: early end of file from monitor: possible problem:

3) [Thread 3493] qemuProcessStart() failed. No big deal. Go to the
'endjob' label and subsequently to the 'cleanup'. Since the domain is
not persistent and ret is -1, the qemuDomainRemoveInactive() is called.
This has an (unpleasant) effect of virObjectUnref()-in the @vm object.
Unpleasant because the event loop which is about to trigger EOF callback
still holds a pointer to the @vm (not the reference). See the valgrind
output below.

4) [Thread 3262] So the event loop starts triggering EOF:

2013-10-08 15:54:13.542+0000: 3262: debug : qemuMonitorIO:729 : Triggering EOF callback
2013-10-08 15:54:13.543+0000: 3262: debug : qemuProcessHandleMonitorEOF:294 : Received EOF on 0x14549110 'migt10'

And the monitor is cleaned up. This results in calling
qemuProcessHandleMonitorEOF with the @vm pointer passed. The pointer is
kept in qemuMonitor struct.

==3262== Thread 1:
==3262== Invalid read of size 4
==3262==    at 0x77ECCAA: pthread_mutex_lock (in /lib64/libpthread-2.15.so)
==3262==    by 0x52FAA06: virMutexLock (virthreadpthread.c:85)
==3262==    by 0x52E3891: virObjectLock (virobject.c:320)
==3262==    by 0x11626743: qemuProcessHandleMonitorEOF (qemu_process.c:296)
==3262==    by 0x11642593: qemuMonitorIO (qemu_monitor.c:730)
==3262==    by 0x52BD526: virEventPollDispatchHandles (vireventpoll.c:501)
==3262==    by 0x52BDD49: virEventPollRunOnce (vireventpoll.c:648)
==3262==    by 0x52BBC68: virEventRunDefaultImpl (virevent.c:274)
==3262==    by 0x542D3D9: virNetServerRun (virnetserver.c:1112)
==3262==    by 0x11F368: main (libvirtd.c:1513)
==3262==  Address 0x14549128 is 24 bytes inside a block of size 136 free'd
==3262==    at 0x4C2AF5C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3262==    by 0x529B1FF: virFree (viralloc.c:580)
==3262==    by 0x52E3703: virObjectUnref (virobject.c:270)
==3262==    by 0x531557E: virDomainObjListRemove (domain_conf.c:2355)
==3262==    by 0x1160E899: qemuDomainRemoveInactive (qemu_domain.c:2061)
==3262==    by 0x1163A0C6: qemuMigrationPrepareAny (qemu_migration.c:2450)
==3262==    by 0x1163A923: qemuMigrationPrepareDirect (qemu_migration.c:2626)
==3262==    by 0x11682D71: qemuDomainMigratePrepare3Params (qemu_driver.c:10309)
==3262==    by 0x53B0976: virDomainMigratePrepare3Params (libvirt.c:7266)
==3262==    by 0x1502D3: remoteDispatchDomainMigratePrepare3Params (remote.c:4797)
==3262==    by 0x12DECA: remoteDispatchDomainMigratePrepare3ParamsHelper (remote_dispatch.h:5741)
==3262==    by 0x54322EB: virNetServerProgramDispatchCall (virnetserverprogram.c:435)

The mon->vm is set in qemuMonitorOpenInternal() which is the correct
place to increase @vm ref counter. The correct place to decrease the ref
counter is then qemuMonitorDispose().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This basically covers the talking-to-monitor part of
virQEMUCapsInitQMP.  The patch itself has no real value,
but it creates an entity to be tested in the next patches.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This resolves one of the issues in:

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

This device is identical to qemu's "intel-hda" device (known as "ich6"
in libvirt), but has a different PCI device ID (which matches the ID
of the hda audio built into the ich9 chipset, of course). It's not
supported in earlier versions of qemu, so it requires a capability
bit.

Semantics of the libvirt helper are more clear. This change also allows
to clean up some pieces of code.

Starting with qemu 1.6, the qemu-system-arm vexpress-a9 model has a
hardcoded virtio-mmio transport which enables attaching all virtio
devices.

On the command line, we have to use virtio-XXX-device rather than
virtio-XXX-pci, thankfully s390 already set the precedent here so
it's fairly straight forward.

At the XML level, this adds a new device address type virtio-mmio.
The controller and addressing don't have any subelements at the
moment because we they aren't needed for this usecase, but could
be added later if needed.

Add a test case for an ARM guest with one of every virtio device
enabled.