The model logic is taken from qemuDomainRNGDefValidate
Reviewed-by: NReviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Starting with QEMU 4.1 qemuMonitorCPUModelInfo structure in virQEMUCaps
stores only canonical feature names which may differ from the name used
by libvirt. We need translate these canonical names into libvirt names
for further consumption.

This fixes a bug in qemuConnectBaselineHypervisorCPU which would remove
all features for which libvirt's spelling differs from the QEMU's
preferred name. For example, the following result of
qemuConnectBaselineHypervisorCPU on my host with QEMU 4.1 is wrong:

    <cpu mode='custom' match='exact'>
      <model fallback='forbid'>Skylake-Client</model>
      <vendor>Intel</vendor>
      <feature policy='require' name='ss'/>
      <feature policy='require' name='vmx'/>
      <feature policy='require' name='hypervisor'/>
      <feature policy='require' name='clflushopt'/>
      <feature policy='require' name='umip'/>
      <feature policy='require' name='arch-capabilities'/>
      <feature policy='require' name='xsaves'/>
      <feature policy='require' name='pdpe1gb'/>
      <feature policy='require' name='invtsc'/>
      <feature policy='disable' name='pclmuldq'/>
      <feature policy='disable' name='lahf_lm'/>
    </cpu>

The 'pclmuldq' and 'lahf_lm' should not be disabled in the baseline CPU
as they are supported by QEMU on this host.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Check whether qemu supports the bochs-display device and set a
capability. Update tests.
Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

With QEMU versions which lack "unavailable-features" we use CPUID based
detection of features which were enabled or disabled once QEMU starts.
Thus using MSR features with host-model would result in all of them
being marked as disabled in the active domain definition even though
QEMU did not actually disable them.

Let's make sure we add MSR features to host-model only when
"unavailable-features" property is supported by QEMU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This is a generic replacement for the former virCPUx86DataAddFeature,
which worked on the generic virCPUDataPtr anyway.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We used type=full expansion on the result of previous type=static
expansion to get all possible spellings of CPU features. Since we can
now translate the QEMU's canonical names to our names, we can drop this
magic and do only type=static CPU model expansion.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

By default query-cpu-model-expansion only reports canonical names of all
CPU features. We do some magic and call the command twice to get all
possible spellings of the features, but being able to consume canonical
names will allow us to drop this magic.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When building QEMU command line, we should use the preferred spelling of
each CPU feature without relying on compatibility aliases (which may be
removed at some point).

The "unavailable-features" CPU property is used as a witness for the
correct names of the features in our translation table.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The way we call query-cpu-model-expansion will rely on some capabilities
bits. Let's make sure all capabilities are set before probing host CPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It is similar to "filtered-features" property, which reports CPUID bits
corresponding to disabled features, but more general. The
"unavailable-features" property supports both CPUID and MSR features by
listing their names.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We will use it to check whether QEMU supports a specific CPU property.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

So far we always used libvirt's name of each CPU feature relying on
backward compatible aliases in QEMU. The new translation table can be
used whenever QEMU mandates or prefers canonical feature names.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We already have virQEMUCapsCPUFilterFeatures for filtering features
which QEMU does not know about. Let's move osxsave and ospke from
qemuFeatureNoEffect there.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Add two capabilities for testing features required for the upcoming
virDomainBackupBegin: use block-dirty-bitmap-merge as the generic
witness of bitmap support needed for checkpoints (since all of the
bitmap management functionalities were finalized in the same qemu 4.0
release), and the bitmap parameter to nbd-server-add for pull-mode
backup support.  Even though both capabilities are likely to be
present or absent together (that is, it is unlikely to encounter a
qemu that backports only one of the two), it still makes sense to keep
two capabilities as the two uses are orthogonal (full backups don't
require checkpoints, push mode backups don't require NBD bitmap
support, and checkpoints can be used for more than just incremental
backups).

Existing code is not affected by the new capabilities.
Signed-off-by: NEric Blake <eblake@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

The function is renamed as virQEMUCapsProbeHostCPU and it does not get
the list of allowed CPU models from qemuCaps anymore. This is
responsibility is moved to the caller. The result is just a very thin
wrapper around virCPUGetHost mostly required mocking in tests.

The generic function is used in place of a direct call to virCPUGetHost
in virQEMUCapsInitHostCPUModel to make sure tests don't accidentally
probe host CPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This capability can be used to figure out whether the
QEMU binary at hand supports the machine type property
we need in order to enable SMMUv3 IOMMU support.

Unfortunately we can't avoid probing the RISC-V binaries
along with the ARM ones, since both architectures have
their own 'virt' machine type.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Since we know the full list of machine types supported
by the QEMU binary when probing machine type properties,
we can save some work (and eventually test suite churn,
as more architecture-specific machine types need to be
probed) by only probing machines that we know exist.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Now that we have the list of machine types available when
probing machine type properties, we can list properties for
the canonicalized version of the "pseries" machine type
instead of having to go through "spapr-machine", which we
know to be the parent type for all "pseries-*-machine"
types. By doing this, we'll be able to find even properties
that are only available from a certain versioned machine
type forward, and can't thus be obtained when looking at
the parent type only.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

The QOM type for machine types is the machine type name
followed by the -machine suffix. Since this is always the
case, we can make virQEMUCapsMachineProps more readable
and avoid repetition by not including the suffix there and
adding it automatically while processing the data; moreover,
when later on we will start figuring out which specific
versioned machine type to probe at runtime instead of doing
so statically, adding the suffix dynamically will become
necessary.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

We're going to need information about available machine types
when probing machine type properties soon, and that means we
have to change the order we call QMP commands.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Up until now we've probed machine type properties, along with
properties for other types, in virQEMUCapsProbeQMPDevices(), but
soon we're going to need some logic that is specific to machine
types and as such wouldn't quite fit into that function.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

QEMU commit 46ea94ca9cf ("qmp: query-current-machine with
wakeup-suspend-support") added a new QMP command called
'query-current-machine' that retrieves guest parameters that
can vary in the same machine model (e.g. ACPI support for x86 VMs
depends on the '--no-acpi' option). Currently, this API has a single
flag, 'wakeup-suspend-support', that indicates whether the guest has
the capability of waking up from suspended state.

Introduce a libvirt capability that reflects whether qemu has the
monitor command.
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

My earlier commit be46f613 was incomplete. It removed caching of
microcode version in the CPU driver, which means the capabilities XML
will see the correct microcode version. But it is also cached in the
QEMU capabilities cache where it is used to detect whether we need to
reprobe QEMU. By missing the second place, the original commit
be46f613 made the situation even worse since libvirt would report
correct microcode version while still using the old host CPU model
(visible in domain capabilities XML).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Support for kqemu was dropped in libvirt by commit 8e91a400 and even
back then we never set these capabilities when doing QMP probing.

Since no QEMU we aim to support has these, drop them completely.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Added in QEMU commit of v3.0.0-rc0~48^2~9 (then fixed by
v3.1.0-rc0~119^2~37) QEMU is replacing '-realtime mlock' with
'-overcommit mem-lock'. Add a capability to tell if we're dealing
new new enough qemu to use the replacement.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The '-realtime mlock' cmd line argument was introduced in QEMU
commit v1.5.0-rc0~190 which matches minimal QEMU version we
require. Therefore, the capability will always be present.

Apparently, nearly none of our xml2argv test cases had the
capability hence slightly bigger change under qemuxml2argvdata/.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Standardize on putting the _LAST enum value on the second line
of VIR_ENUM_IMPL invocations. Later patches that add string labels
to VIR_ENUM_IMPL will push most of these to the second line anyways,
so this saves some noise.
Signed-off-by: NCole Robinson <crobinso@redhat.com>

If a management application wants to use firmware auto selection
feature it can't currently know if the libvirtd it's talking to
support is or not. Moreover, it doesn't know which values that
are accepted for the @firmware attribute of <os/> when parsing
will allow successful start of the domain later, i.e. if the mgmt
application wants to use 'bios' whether there exists a FW
descriptor in the system that describes bios.

This commit then adds 'firmware' enum to <os/> element in
<domainCapabilities/> XML like this:

  <enum name='firmware'>
    <value>bios</value>
    <value>efi</value>
  </enum>

We can see both 'bios' and 'efi' listed which means that there
are descriptors for both found in the system (matched with the
machine type and architecture reported in the domain capabilities
earlier and not shown here).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>

'blockdev-snapshot-sync' is present in QEMU since v0.14.0-rc0 and
'transaction' since v1.1.0 (52e7c241ac766406f05fa)
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

qemu added the 'drive-mirror' command in v1.3.0 (d9b902db3fb71fdc)
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

qemu added the 'block-commit' command in v1.3.0 (ed61fc10e8c8d2)
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This was detected by the presence of 'block-stream' which is present in
qemu since v1.1 (db58f9c0605fa151b8c4)
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

There's nothing to clean up.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

It's actually used.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Failure of qemuMonitorGetVersion is fatal now that we only support QMP
based qemus. Remove the debug message since we report an error already.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

If the detected qemu version is below our required version 'package'
would be leaked.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Move the check out of virQEMUCapsInitQMPMonitor similarly to other
functions.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Move the code out of virQEMUCapsInitQMPMonitor similarly to other
functions.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Move the check out of virQEMUCapsInitQMPMonitor similarly to other
functions.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>