Adding build time self tests for basic (deprecated), doorbell and plain mode.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

When starting a domain without a CPU model specified in the domain XML,
QEMU will choose a default one. Which is fine unless the domain gets
migrated to another host because libvirt doesn't perform any CPU ABI
checks and the virtual CPU provided by QEMU on the destination host can
differ from the one on the source host.

With QEMU 4.2.0 we can probe for the default CPU model used by QEMU for
a particular machine type and store it in the domain XML. This way the
chosen CPU model is more visible to users and libvirt will make sure
the guest will see the exact same CPU after migration.

Architecture specific notes
- aarch64: We only set the default CPU for TCG domains as KVM requires
  explicit "-cpu host" to work.

- ppc64: The default CPU for KVM is "host" thanks to some hacks in QEMU,
  we will translate the default model to the model corresponding to the
  host CPU ("POWER8" on a Power8 host, "POWER9" on Power9 host, etc.).
  This is not a problem as the corresponding CPU model is in fact an
  alias for "host". This is probably not ideal, but it's not wrong and
  the default virtual CPU configured by libvirt is the same QEMU would
  use. TCG uses various CPU models depending on machine type and its
  version.

- s390x: The default CPU for KVM is "host" while TCG defaults to "qemu".

- x86_64: The default CPU model (qemu64) is not runnable on any host
  with KVM, but QEMU just disables unavailable features and starts
  happily.

https://bugzilla.redhat.com/show_bug.cgi?id=1598151
https://bugzilla.redhat.com/show_bug.cgi?id=1598162Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

To avoid mismatch between host and QEMU capabilities.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

QEMU 4.2.0 will report default CPU types used by each machine type and
we will want to start using it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Almost all TCG query-machines replies match KVM. The only exceptions are
4.2.0 replies on s390x which differ in the reported default CPU type.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Some specifics of machine types may depend on the accelerator and thus
the data should be moved to virQEMUCapsAccel. The TCG machine types are
just copied from the ones probed for KVM to simplify the changes to
qemucapabilitiestest data files.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

In preparation for making machine types dependent on the accelerator,
the <machine> elements are formatted between <cpu type='kvm'> and
<cpu type='tcg'>.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It is a tiny wrapper around virQEMUCapsProbeQMPCPUDefinitions which will
soon get private parameters and thus it cannot be exposed outside
qemu_capabilities.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The new functions are designed to load and format capabilities which
depend on the accelerator (host CPU expansion and CPU models).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We need to create a mapping between CPU model names and their
corresponding QOM types.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The functions return virDomainCapsCPUModelsPtr and thus they should be
called *CPUModels for consistency. Functions called *CPUDefinitions will
work on qemuMonitorCPUDefsPtr.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

While virDomainCapsCPUModel structure contains 'usable' field with
virDomainCapsCPUUsable type, the lower level structure specific to QEMU
driver used virTriStateBool for the same thing and we had to translate
between them.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Let's store qemuMonitorCPUDefInfo directly in the array of CPUs in
qemuMonitorCPUDefs rather then using an array of pointers.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It is a container for a CPU models list (qemuMonitorCPUDefInfo) and a
number of elements in this list.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Some callers of virQEMUCapsGetCPUDefinitions will need to filter the
returned list of CPU models. Let's add the filtering parameters directly
to virQEMUCapsGetCPUDefinitions to avoid copying the CPU models list
twice.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Rather than returning a direct pointer the list stored in qemuCaps the
function now creates a new copy of the CPU models list.

The main purpose of this seemingly useless change is to update callers
to free the result returned by virQEMUCapsGetCPUDefinitions because the
internals of this function will change significantly in the following
patches.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Generated with "spapr/kvm: Set default cpu model for all machine
classes" fix for QEMU applied.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We replaced them by use of transaction to simplify possible failure
scenarios.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

testSchemaDir is a helper which invokes the schema test using virTestRun
on all schema files. Since the function itself is not called inside
virTestRun any helper function call is not dispatched to the user and
thus it's hard to debug the test. Propagate errors from the directory
traversal.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

In cases when we call a libvirt helper which reports an error the error
would be hidden unless libvirt library debug is on. This produces a lot
of output and is hard to debug.

The helper provides a way to dispatch the libvirt error in specific
cases sice we do already dispatch it in case when virTestRun is used.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Refactor various functions to avoid multiple freeing function calls.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This flag is not implied by g_mkstemp_full, only by g_mkstemp.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reported-by: NBjoern Walk <bwalk@linux.ibm.com>
Fixes: 4ac47730Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Glib implementation follows the ISO C99 standard so it's safe to replace
the gnulib implementation.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

We need to mock virCgroupV2DevicesAvailable() in order to remove any
dependency on kernel as BPF devices might not be available.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Some of our tests try to validate domain XMLs they are working
with (not intentionally, simply because they call top level
domain XML parse function). Anyway, this implies that we build
domain capabilities also - see
virQEMUDriverGetDomainCapabilities(). And since some domain XMLs
are type of 'kvm' the control gets through
virQEMUCapsFillDomainCaps() and virHostCPUGetKVMMaxVCPUs() to
opening /dev/kvm which may be missing on the machine we're
running 'make check'.

Previously, we did not see this issue, because it was masked. If
building domain capabilities failed for whatever reason, we
ignored the failure. Only v5.9.0-207-gc69e6ede uncovered the
problem (it changed reval from 0 to -1 if
virQEMUDriverGetDomainCapabilities() fails). Since the referenced
commit is correct, we need to mock access to /dev/kvm in our
tests.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Some layered products such as oVirt have requested a way to avoid being
blocked by guest agent commands when querying a loaded vm. For example,
many guest agent commands are polled periodically to monitor changes,
and rather than blocking the calling process, they'd prefer to simply
time out when an agent query is taking too long.

This patch adds a way for the user to specify a custom agent timeout
that is applied to all agent commands.

One special case to note here is the 'guest-sync' command. 'guest-sync'
is issued internally prior to calling any other command. (For example,
when libvirt wants to call 'guest-get-fsinfo', we first call
'guest-sync' and then call 'guest-get-fsinfo').

Previously, the 'guest-sync' command used a 5-second timeout
(VIR_DOMAIN_QEMU_AGENT_COMMAND_DEFAULT), whereas the actual command that
followed always blocked indefinitely
(VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK). As part of this patch, if a
custom timeout is specified that is shorter than
5 seconds,  this new timeout is also used for 'guest-sync'. If there is
no custom timeout or if the custom timeout is longer than 5 seconds, we
will continue to use the 5-second timeout.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Prefer the GLib version to the one from gnulib.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

With g_mkstemp_full, there is no need to distinguish between
mkostemp and mkostemps (no suffix vs. a suffix of a fixed length),
because the GLib function looks for the XXXXXX pattern everywhere
in the string.

Use S_IRUSR | S_IWUSR for the permissions and do not pass O_RDWR
in flags since it's implied.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

The code using regexes got moved, but the include stayed.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NPeter Krempa <pkrempa@redhat.com>

The 'ramfb' attribute provides a framebuffer to the guest that can be
used as a boot display for the vgpu

For example, the following configuration can be used to provide a vgpu
with a boot display:

    <hostdev mode='subsystem' type='mdev' model='vfio-pci' display='on' ramfb='on'>
        <source>
            <address uuid='$UUID'/>
        </source>
    </hostdev>
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>

In a follow-up commit, we will use the domain capabilities to validate
video device configurations, which means that we also need to make sure
that the domain capabilities include the "none" video device.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>

commit 9bfcf0f6 added the
QEMU_CAPS_DEVICE_RAMFB capability but did not set the domain capability.
This patch sets the domain capability for the ramfb device and updates
the tests.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>