Minimal CPU "parser" for armhf to avoid compile time warning.
Signed-off-by: NChuck Short <chuck.short@canonical.com>

Probe to see if the systemd journal is accessible, and if
so enable logging to the journal by default, rather than
stderr (current default under systemd).
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Add support for logging to the systemd journal, using its
simple client library. The benefit over syslog is that it
accepts structured log data, so the journald can store
individual items like code file/line/func separately from
the string message. Tools which require structured log
data can then query the journal to extract exactly what
they desire without resorting to string parsing

While systemd provides a simple client library for logging,
it is more convenient for libvirt to directly write its
own client code. This lets us build up the iovec's on
the stack, avoiding the need to alloc memory when writing
log messages.
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>

The virInitialize function initializes logging from the env,
so there is no need for another call to virLogSetFromEnv
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The 'const char *category' parameter only has a few possible
values now that the filename has been separated. Turn this
parameter into an enum instead.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the logging APIs have a 'const char *category' parameter
which indicates where the log message comes from. This is typically
a combination of the __FILE__ string and other prefix. Split the
__FILE__ off into a dedicated parameter so it can passed to the
log outputs
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

General whitespace cleanup in the logging files

 - Move '{' to a new line after funtion declaration
 - Put each parameter on a new line to avoid long lines
 - Put return type on new line
 - Leave 2 blank lines between functions
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The log destinations are an enum, but most of the code was
just using a plain 'int' for function params / variables.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The __LINE__ macro value is specified to fit in the size_t
type, so use that instead of 'long long' in the logging code
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The log priority levels are an enum, but most of the code was
just using a plain 'int' for function params / variables.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The result is indeterminate for NULL argument to python
functions as follows. It's better to return negative value in
these situations.

PyObject_IsTrue will segfault if the argument is NULL
PyFloat_AsDouble(NULL) is -1.000000
PyLong_AsUnsignedLongLong(NULL) is 0.000000

I hit this problem recently when trying to create a bridge with an IPv6
address on a 3.2 kernel: dnsmasq (and, further, radvd) would not bind to
the given address, waiting 20s and then giving up with -EADDRNOTAVAIL
(resp. exiting immediately with "error parsing or activating the config
file", without libvirt noticing it, BTW). This can be reproduced with (I
think) any kernel >= 2.6.39 and the following XML (to be used with
"virsh net-create"):

        <network>
          <name>test-bridge</name>
          <bridge name='testbr0' />
          <ip family='ipv6' address='fd00::1' prefix='64'>
          </ip>
        </network>

(it happens even when you have an IPv4, too)

The problem is that since commit [1] (which, ironically, was made to
“help IPv6 autoconfiguration”) the linux bridge code makes bridges
behave like “real” devices regarding carrier detection. This makes the
bridges created by libvirt, which are started without any up devices,
stay with the NO-CARRIER flag set, and thus prevents DAD (Duplicate
address detection) from happening, thus letting the IPv6 address flagged
as “tentative”. Such addresses cannot be bound to (see RFC 2462), so
dnsmasq fails binding to it (for radvd, it detects that "interface XXX
is not RUNNING", thus that "interface XXX does not exist, ignoring the
interface" (sic)). It seems that this behavior was enhanced somehow with
commit [2] by avoiding setting NO-CARRIER on empty bridges, but I
couldn't reproduce this behavior on my kernel. Anyway, with the “dummy
tap to set MAC address” trick, this wouldn't work.

To fix this, the idea is to get the bridge's attached device to be up so
that DAD can happen (deactivating DAD altogether is not a good idea, I
think). Currently, libvirt creates a dummy TAP device to set the MAC
address of the bridge, keeping it down. But even if we set this device
up, it is not RUNNING as soon as the tap file descriptor attached to it
is closed, thus still preventing DAD. So, we must modify the API a bit,
so that we can get the fd, keep the tap device persistent, run the
daemons, and close it after DAD has taken place. After that, the bridge
will be flagged NO-CARRIER again, but the daemons will be running, even
if not happy about the device's state (but we don't really care about
the bridge's daemons doing anything when no up interface is connected to
it).

Other solutions that I envisioned were:
      * Keeping the *-nic interface up: this would waste an fd for each
        bridge during all its life. May be acceptable, I don't really
        know.
      * Stop using the dummy tap trick, and set the MAC address directly
        on the bridge: it is possible since quite some time it seems,
        even if then there is the problem of the bridge not being
        RUNNING when empty, contrary to what [2] says, so this will need
        fixing (and this fix only happened in 3.1, so it wouldn't work
        for 2.6.39)
      * Using the --interface option of dnsmasq, but I saw somewhere
        that it's not used by libvirt for backward compatibility. I am
        not sure this would solve this problem, though, as I don't know
        how dnsmasq binds itself to it with this option.

This is why this patch does what's described earlier.

This patch also makes radvd start even if the interface is
“missing” (i.e. it is not RUNNING), as it daemonizes before binding to
it, and thus sometimes does it after the interface has been brought down
by us (by closing the tap fd), and then originally stops. This also
makes it stop yelling about it in the logs when the interface is down at
a later time.

[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=1faa4356a3bd89ea11fb92752d897cff3a20ec0e
[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=b64b73d7d0c480f75684519c6134e79d50c1b341

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>

In Xen 4.2, xs.h is deprecated in favor of xenstore.h.  xs.h now
contains

#warning xs.h is deprecated use xenstore.h instead
#include <xenstore.h>

which fails compilation when warnings are treated as errors.

Introduce a configure-time check for xenstore.h and if found,
use it instead of xs.h.

In addition to the preformatted text line, pass the raw message as well,
to allow the output functions to use a different output format.
Signed-off-by: NMiloslav Trmač <mitr@redhat.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Allow for the code converting from libvirt log levels to syslog
log levels to be reused.
Signed-off-by: NMiloslav Trmač <mitr@redhat.com>
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>