The qemuMonitorOpen method only needs a virDomainObjPtr in order
to access the QEMU pid. This is not critical when detecting the
QEMU capabilties, so can easily be skipped
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The help output for QEMU 1.2.0 changed 'pci-assign' to 'kvm-pci-assign'.
Since the new capabilities code does exact device name matching
instead of substring matching, this caused the capabilities to go
missing.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the qemuCapsParseDeviceStr method has a bunch of open
coded string searches/comparisons to detect devices and their
properties. Soon this data will be obtained from QMP queries
instead of -device help output. Maintaining the list of device
and properties in two places is undesirable. Thus the existing
qemuCapsParseDeviceStr() method needs to be refactored to
separate the device types and properties from the actual
search code.

Thus the -device help output is now parsed to construct a
list of device names, and device properties. These are then
checked against a set of datatables to set the capability
flags
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If QEMU reports CommandNotFound for the 'query-events' command,
we must treat that as success, returning a zero-length array
of events
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The qemuMonitorSetCapabilities() API is used to initialize the QMP
protocol capabilities. It has since been abused to initialize some
libvirt internal capabilities based on command/event existance too.
Move the latter code out into qemuCapsProbeQMP() in the QEMU
capabilities source file instead
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The qemu monitor does not require qemu_conf.h, and the
qemu capabilities code actually wants bitmap.h
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add a new qemuMonitorGetTargetArch() method to support invocation
of the 'query-target' JSON monitor command. No HMP equivalent
is required, since this will only be present for QEMU >= 1.2
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add a new qemuMonitorGetObjectProps() method to support invocation
of the 'device-list-properties' JSON monitor command. No HMP equivalent
is required, since this will only be present for QEMU >= 1.2
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add a new qemuMonitorGetObjectTypes() method to support invocation
of the 'qom-list-types' JSON monitor command. No HMP equivalent
is required, since this will only be present for QEMU >= 1.2
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add a new qemuMonitorGetEvents() method to support invocation
of the 'query-events' JSON monitor command. No HMP equivalent
is required, since this will only be used when JSON is available

The existing qemuMonitorJSONCheckEvents() method is refactored
to use this new method
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add a new qemuMonitorGetCPUCommands() method to support invocation
of the 'query-commands' JSON monitor command. No HMP equivalent
is required, since this will only be used when JSON is available

The existing qemuMonitorJSONCheckCommands() method is refactored
to use this new method
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add a new qemuMonitorGetCPUDefinitions() method to support invocation
of the 'query-cpu-definitions' JSON monitor command. No HMP equivalent
is required, since this will only be present for QEMU >= 1.2
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add a new qemuMonitorGetMachines() method to support invocation
of the 'query-machines' JSON monitor command. No HMP equivalent
is required, since this will only be present for QEMU >= 1.2
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add a new qemuMonitorGetVersion() method to support invocation
of the 'query-version' JSON monitor command. No HMP equivalent
is provided, since this will only be used for QEMU >= 1.2
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

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

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

The qemuCapsProbeMachineTypes & qemuCapsProbeCPUModels methods
do not need to be invoked directly anymore. Make them static
and refactor them to directly populate the qemuCapsPtr object
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When launching a QEMU guest the binary is probed to discover
the list of supported CPU names. Remove this probing with a
simple lookup of CPU models in the qemuCapsPtr object. This
avoids another invocation of the QEMU binary during the
startup path.

As a nice benefit we can now remove all the nasty hacks from
the test suite which were done to avoid having to exec QEMU
on the test system. The building of the -cpu command line
can just rely on data we pre-populate in qemuCapsPtr.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When XML for a new guest is received, the machine type is
immediately canonicalized into the version specific name.
This involves probing QEMU for supported machine types.
Replace this probing with a lookup of the machine types
in the (hopefully cached) qemuCapsPtr object
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Remove all use of the existing APIs for querying QEMU
capability flags. Instead obtain a qemuCapsPtr object
from the global cache. This avoids the execution of
'qemu -help' (and related commands) when launching new
guests.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When building up a virCapsPtr instance, the QEMU driver
was copying the list of machine types across from the
previous virCapsPtr instance, if the QEMU binary had not
changed. Replace this ad-hoc caching of data with use
of the new qemuCapsCache global cache.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Introduce a qemuCapsCachePtr object to provide a global cache
of capabilities for QEMU binaries. The cache auto-populates
on first request for capabilities about a binary, and will
auto-refresh if the binary has changed since a previous cache
was populated
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

For historical compat we use 'itanium' as the arch name, so
if the QEMU binary suffix is 'ia64' we need to translate it
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If the qemuAgentClose method is called from a place which holds
the domain lock, it is theoretically possible to get a deadlock
in the agent destroy callback. This has not been observed, but
the equivalent code in the QEMU monitor destroy callback has seen
a deadlock.

Remove the redundant locking while unrefing the object and the
bogus assignment
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Many parts of virDomainDefPtr were using 'int' variables as
array length counts. Replace all these with size_t and update
various format strings & API signatures to adapt
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Some users report (very rarely) seeing a deadlock in the QEMU
monitor callbacks

 Thread 10 (Thread 0x7fcd11e20700 (LWP 26753)):
 #0  0x00000030d0e0de4d in __lll_lock_wait () from /lib64/libpthread.so.0
 #1  0x00000030d0e09ca6 in _L_lock_840 () from /lib64/libpthread.so.0
 #2  0x00000030d0e09ba8 in pthread_mutex_lock () from /lib64/libpthread.so.0
 #3  0x00007fcd162f416d in virMutexLock (m=<optimized out>)
     at util/threads-pthread.c:85
 #4  0x00007fcd1632c651 in virDomainObjLock (obj=<optimized out>)
     at conf/domain_conf.c:14256
 #5  0x00007fcd0daf05cc in qemuProcessHandleMonitorDestroy (mon=0x7fcccc0029e0,
     vm=0x7fcccc00a850) at qemu/qemu_process.c:1026
 #6  0x00007fcd0db01710 in qemuMonitorDispose (obj=0x7fcccc0029e0)
     at qemu/qemu_monitor.c:249
 #7  0x00007fcd162fd4e3 in virObjectUnref (anyobj=<optimized out>)
     at util/virobject.c:139
 #8  0x00007fcd0db027a9 in qemuMonitorClose (mon=<optimized out>)
     at qemu/qemu_monitor.c:860
 #9  0x00007fcd0daf61ad in qemuProcessStop (driver=driver@entry=0x7fcd04079d50,
     vm=vm@entry=0x7fcccc00a850,
     reason=reason@entry=VIR_DOMAIN_SHUTOFF_DESTROYED, flags=flags@entry=0)
     at qemu/qemu_process.c:4057
 #10 0x00007fcd0db323cf in qemuDomainDestroyFlags (dom=<optimized out>,
     flags=<optimized out>) at qemu/qemu_driver.c:1977
 #11 0x00007fcd1637ff51 in virDomainDestroyFlags (
     domain=domain@entry=0x7fccf00c1830, flags=1) at libvirt.c:2256

At frame #10 we are holding the domain lock, we call into
qemuProcessStop() to cleanup QEMU, which triggers the monitor
to close, which invokes qemuProcessHandleMonitorDestroy() which
tries to obtain the domain lock again. This is a non-recursive
lock, hence hang.

Since qemuMonitorPtr is a virObject, the unref call in
qemuProcessHandleMonitorDestroy no longer needs mutex
protection. The assignment of priv->mon = NULL, can be
instead done by the caller of qemuMonitorClose(), thus
removing all need for locking.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

If QEMU quits immediately after we opened the monitor it was
possible we would skip the clearing of the SELinux process
socket context
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In the cgroups APIs we have a virCgroupKillPainfully function
which does the loop sending SIGTERM, then SIGKILL and waiting
for the process to exit. There is similar functionality for
simple processes in qemuProcessKill, but it is tangled with
the QEMU code. Untangle it to provide a virProcessKillPainfuly
function
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When calling qemuProcessKill from the virDomainDestroy impl
in QEMU, do not ignore the return value. This ensures that
if QEMU fails to respond to SIGKILL, the caller will know
about the failure.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Recently, there have been some improvements made to qemu so it
supports seamless migration or something very close to it.
However, it requires libvirt interaction. Once qemu is migrated,
the SPICE server needs to send its internal state to the destination.
Once it's done, it fires SPICE_MIGRATE_COMPLETED event and this
fact is advertised in 'query-spice' output as well.
We must not kill qemu until SPICE server finishes the transfer.

SELinux wants all log files opened with O_APPEND. When
running non-root though, libvirtd likes to use O_TRUNC
to avoid log files growing in size indefinitely. Instead
of using O_TRUNC though, we can use O_APPEND and then
call ftruncate() which keeps SELinux happier.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There is no need to hold the mutex when unref'ing
virObject instances
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There are a number of process related functions spread
across multiple files. Start to consolidate them by
creating a virprocess.{c,h} file
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Changing naming to follow the convention of "object" followed
by "action"
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In most of the snapshot API's there's no need to hold the driver lock
the whole time.

This patch adds helper functions that get the domain object in functions
that don't require the driver lock and simplifies call paths from
snapshot-related API's.

maxcpu and hostcpus are defined and calculated in qemudDomainPinVcpuFlags()
and qemudDomainPinEmulator(), but never used. So remove them including nodeinfo.
Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>

Disk hotplug is a two phase action: qemuMonitorAddDrive followed by
qemuMonitorAddDevice. When the first part succeeds but the second one
fails, we need to rollback the drive addition.

Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>

https://www.gnu.org/licenses/gpl-howto.html recommends that
the 'If not, see <url>.' phrase be a separate sentence.

* tests/securityselinuxhelper.c: Remove doubled line.
* tests/securityselinuxtest.c: Likewise.
* globally: s/;  If/.  If/

The "dump-guest-core' option is new option for the machine type
(-machine pc,dump-guest-core) that controls whether the guest memory
will be marked as dumpable.

While testing this, I've found out that the value for the '-M' options
is not parsed correctly when additional parameters are used. However,
when '-machine' is used for the same options, it gets parsed as
expected. That's why this patch also modifies the parsing and creating
of the command line, so both '-M' and '-machine' are recognized. In
QEMU's help there is only mention of the 'machine parameter now with
no sign of the older '-M'.