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

An advice appeared there on the qemu-devel list [1]. When a domain is
suspended and then resumed guest kernel is not aware of this. So we've
introduced virDomainSetTime API that resets the time within guest
using qemu-ga. On the other hand, qemu itself is trying to make RTC
beat faster to catch the difference. But if we don't tell qemu that
guest's time was reset via the other method, both mechanisms are
applied resulting in again wrong guest time. In order to avoid summing
both corrections we need to tell qemu that it should not use the RTC
injection if the guest time is set via guest agent.

1: http://www.mail-archive.com/qemu-devel@nongnu.org/msg236435.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

When qemu switched to using OptsVisitor for -numa parameter, it did
two things in the same patch.  One of them is that the numa parameter
is now visible in "query-command-line-options", the second one is that
it enabled using disjoint cpu ranges for -numa specification.  This
will be used in later patch.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

The numa patch series in qemu adds "memory-backend-ram" object type by
which we can tell whether we can use such objects.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

That can be lately achieved with by having .param == NULL in the
virQEMUCapsCommandLineProps struct.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

There are many places with numatune-related code that should be put
into special numatune_conf and this patch creates a basis for that.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

In many places we define a variable as a 'const char *' when in fact
we modify it just a few lines below. Or even free it. We should not do
that.

There's one exception though, in xenSessionFree() xenapi_utils.c. We
are freeing the xen_session structure which is defined in
xen/api/xen_common.h public header. The structure contains session_id
which is type of 'const char *' when in fact it should have been just
'char *'. So I'm leaving this unmodified, just noticing the fact in
comment.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

While preparing to add a capability for active commit, I noticed
that the existing code was abusing int for boolean values.

* src/conf/capabilities.h (_virCapsGuestFeature, _virCapsHost)
(virCapabilitiesNew, virCapabilitiesAddGuestFeature): Improve
types.
* src/conf/capabilities.c (virCapabilitiesNew)
(virCapabilitiesAddGuestFeature): Adjust signature.
* src/bhyve/bhyve_capabilities.c (virBhyveCapsBuild): Update
clients.
* src/esx/esx_driver.c (esxCapsInit): Likewise.
* src/libxl/libxl_conf.c (libxlMakeCapabilities): Likewise.
* src/lxc/lxc_conf.c (virLXCDriverCapsInit): Likewise.
* src/openvz/openvz_conf.c (openvzCapsInit): Likewise.
* src/parallels/parallels_driver.c (parallelsBuildCapabilities):
Likewise.
* src/phyp/phyp_driver.c (phypCapsInit): Likewise.
* src/qemu/qemu_capabilities.c (virQEMUCapsInit)
(virQEMUCapsInitGuestFromBinary): Likewise.
* src/security/virt-aa-helper.c (get_definition): Likewise.
* src/test/test_driver.c (testBuildCapabilities): Likewise.
* src/uml/uml_conf.c (umlCapsInit): Likewise.
* src/vbox/vbox_tmpl.c (vboxCapsInit): Likewise.
* src/vmware/vmware_conf.c (vmwareCapsInit): Likewise.
* src/xen/xen_hypervisor.c (xenHypervisorBuildCapabilities):
Likewise.
* src/xenapi/xenapi_driver.c (getCapsObject): Likewise.
* tests/qemucaps2xmltest.c (testGetCaps): Likewise.
* tests/testutils.c (virTestGenericCapsInit): Likewise.
* tests/testutilslxc.c (testLXCCapsInit): Likewise.
* tests/testutilsqemu.c (testQemuCapsInit): Likewise.
* tests/testutilsxen.c (testXenCapsInit): Likewise.
* tests/vircaps2xmltest.c (buildVirCapabilities): Likewise.
* tests/vircapstest.c (buildNUMATopology): Likewise.
* tests/vmx2xmltest.c (testCapsInit): Likewise.
* tests/xml2vmxtest.c (testCapsInit): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

This command allows to change the backing file name recorded in the
metadata of a qcow (or other) image. The capability also notifies that
the "block-stream" and "block-commit" commands understand the
"backing-file" attribute.

Use the probing functionality added in the last patch to turn on
a capability bit when active commit is present, and gate active
commit on that capability.

For my own reference: the difference between BLOCKJOB_SYNC and
BLOCKJOB_ASYNC is whether qemu generated an event at the
conclusion of blockpull; basically, RHEL 6.2 was the only release
of qemu that has the sync semantics and lacks the event.  RHEL
6.3 added blockcopy, but also picked up on the upstream style
of qemu generating events.  As no one is likely to backport
active commit to RHEL 6.2, it's safe for blockcommit to always
require async blockjob support.

Modifying qemucapabilitiestest is painful; the .replies files would
be so much easier if they had comments correlating which command
generated the given reply.  Maybe I'll fix that up later...

* src/qemu/qemu_capabilities.h (QEMU_CAPS_ACTIVE_COMMIT): New
capability.
* src/qemu/qemu_driver.c (qemuDomainBlockCommit): Use the new bit
* src/qemu/qemu_capabilities.c (virQEMUCaps): Name the new bit.
(virQEMUCapsProbeQMPCommands): Set it.
* tests/qemucapabilitiesdata/caps_1.3.1-1.replies: Update.
* tests/qemucapabilitiesdata/caps_1.4.2-1.replies: Likewise.
* tests/qemucapabilitiesdata/caps_1.5.3-1.replies: Likewise.
* tests/qemucapabilitiesdata/caps_1.6.0-1.replies: Likewise.
* tests/qemucapabilitiesdata/caps_1.6.50-1.replies: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

So far only information on disks and host devices are exposed in the
capabilities XML. Well, at least something. Even a new test is
introduced. The qemu capabilities are stolen from already existing
qemucapabilities test. There's one tricky point though. Functions that
checks host's KVM and VFIO capabilities, are impossible to mock
currently. So in the test, we are setting the capabilities by hand.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Sometimes it may be useful to get a default machine for given qemu
binary. Fortunately, the default machine is stored always on the first
position in the supported machines array.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This internal API is meant to answer the question 'Is this machine
type supported by given qemu?'.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The API may come handy if somebody has an architecture and wants to
look through available qemus if the architecture is supported or not.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

They report errors in all other cases.

As we are doing with the enum structures, a cleanup in "src/qemu/"
directory was done now. All the enums that were defined in the
header files were converted to typedefs in this directory. This
patch includes all the adjustments to remove conflicts when you do
this kind of change. "Enum-to-typedef"'s conversions were made in
"src/qemu/qemu_{capabilities, domain, migration, hotplug}.h".
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

There are two places where you'll find info on page sizes. The first
one is under <cpu/> element, where all supported pages sizes are
listed. Then the second one is under each <cell/> element which refers
to concrete NUMA node. At this place, the size of page's pool is
reported. So the capabilities XML looks something like this:

<capabilities>

  <host>
    <uuid>01281cda-f352-cb11-a9db-e905fe22010c</uuid>
    <cpu>
      <arch>x86_64</arch>
      <model>Westmere</model>
      <vendor>Intel</vendor>
      <topology sockets='1' cores='1' threads='1'/>
      ...
      <pages unit='KiB' size='4'/>
      <pages unit='KiB' size='2048'/>
      <pages unit='KiB' size='1048576'/>
    </cpu>
    ...
    <topology>
      <cells num='4'>
        <cell id='0'>
          <memory unit='KiB'>4054408</memory>
          <pages unit='KiB' size='4'>1013602</pages>
          <pages unit='KiB' size='2048'>3</pages>
          <pages unit='KiB' size='1048576'>1</pages>
          <distances/>
          <cpus num='1'>
            <cpu id='0' socket_id='0' core_id='0' siblings='0'/>
          </cpus>
        </cell>
        <cell id='1'>
          <memory unit='KiB'>4071072</memory>
          <pages unit='KiB' size='4'>1017768</pages>
          <pages unit='KiB' size='2048'>3</pages>
          <pages unit='KiB' size='1048576'>1</pages>
          <distances/>
          <cpus num='1'>
            <cpu id='1' socket_id='0' core_id='0' siblings='1'/>
          </cpus>
        </cell>
        ...
      </cells>
    </topology>
    ...
  </host>

  <guest/>

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

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>