Truncate the output so that it is only as big as is needed to fit all
the bits, not all the units from the map.  This will be needed in the
future in order to properly format bitmaps for kernel's sysfs files.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This follows the virBitmapToData() function and, similarly to
virBitmapNewData(), we'll be able to have virBitmapNewString() later
on without name confusion.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Most of the time it's okay to leave this up to negotiation between
the guest and the host, but in some situations it can be useful to
manually decide the behavior, especially to enforce its availability.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1308743Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Don't leak @blockNodes in the loop.

==226576== 7,120 bytes in 60 blocks are definitely lost in loss record 122 of 125
==226576==    at 0x4835214: calloc (vg_replace_malloc.c:711)
==226576==    by 0x4950D7B: virAllocN (viralloc.c:191)
==226576==    by 0x49EB5BB: virXPathNodeSet (virxml.c:676)
==226576==    by 0x104DB67: virQEMUCapsLoadCPUModels (qemu_capabilities.c:3738)
==226576==    by 0x105510D: virQEMUCapsLoadCache (qemu_capabilities.c:3929)
==226576==    by 0x104459F: qemuTestParseCapabilities (testutilsqemu.c:498)
==226576==    by 0x1040DC9: testQemuCapsCopy (qemucapabilitiestest.c:105)
==226576==    by 0x1041F07: virTestRun (testutils.c:180)
==226576==    by 0x1040B45: mymain (qemucapabilitiestest.c:181)
==226576==    by 0x104320F: virTestMain (testutils.c:1119)
==226576==    by 0x1041149: main (qemucapabilitiestest.c:193)
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Even though only family and model are used for matching CPUID data with
CPU models from cpu_map.xml, stepping is used by x86DataFilterTSX which
is supposed to disable TSX on CPU models with broken TSX support. Thus
we need to start parsing stepping from QEMU to make sure we don't
disable TSX on CPUs which provide working TSX implementation. See the
following patch for a real world example of such CPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Gather query-cpu-definitions results and use them for testing CPU model
usability blockers in CPUID to virCPUDef translation.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The "preferred" parameter is not used by any caller of cpuDecode
anymore. It's only used internally in cpu_x86 to implement cpuBaseline.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

All APIs which expect a list of CPU models supported by hypervisors were
switched from char **models and int models to just accept a pointer to
virDomainCapsCPUModels object stored in domain capabilities. This avoids
the need to transform virDomainCapsCPUModelsPtr into a NULL-terminated
list of model names and also allows the various cpu driver APIs to
access additional details (such as its usability) about each CPU model.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

query-cpu-definitions QMP command returns a list of unavailable features
which prevent CPU models from being usable on the current host. So far
we only checked whether the list was empty to mark CPU models as
(un)usable. This patch parses all unavailable features for each CPU
model and stores them in virDomainCapsCPUModel as a list of usability
blockers.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

When a hypervisor marks a CPU model as unusable on the current host, it
may also give us a list of features which prevent the model from being
usable. Storing this list in virDomainCapsCPUModel will help the CPU
driver with creating a host-model CPU configuration.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NLin Ma <lma@suse.com>

Some distros (see diff) chose to backport QMP support rather than rebase
to newer version of qemu. As a hack they added the string 'libvirt' to
the qemu -help output. Remove this as downstream-only hacks should be
carried by downstream and not litter upstream.

This effectively reverts commit ff88cd59

Using the query-qmp-schema introspection - look for the 'vxhs'
blockdevOptions type.

NB: This is a "best effort" type situation as there is not a
    mechanism to determine whether the running QEMU has been
    built with '--enable-vxhs'. All we can do is check if the
    option to use vxhs for a blockdev-add exists in the command
    infrastructure which does not take that into account when
    building its table of commands and options.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The filter only needs to know the CPU architecture. Passing
virQEMUCapsPtr as opaque is a bit overkill.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Interestingly, none of the qemus we have caps for supported it ...
Reviewed-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Report the given GIC version as unsupported if @qemuCapsi is NULL. This
will be helpful to run post parse callbacks even if qemu is not
currently installed.

If qemuCaps are not present, just return the original machine type name.

This will help in situations when qemuCaps is not available in the post
parse callback.

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

Just like I've added support for setting rx_queue_size (in
c56cdf25 and friends), qemu just gained support for setting tx
ring size.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The switch contains considerable amount of changes:

  virQEMUCapsRememberCached() is removed because this is now handled
  by virFileCacheSave().

  virQEMUCapsInitCached() is removed because this is now handled by
  virFileCacheLoad().

  virQEMUCapsNewForBinary() is split into two functions,
  virQEMUCapsNewData() which creates new data if there is nothing
  cached and virQEMUCapsLoadFile() which loads the cached data.
  This is now handled by virFileCacheNewData().

  virQEMUCapsCacheValidate() is removed because this is now handled by
  virFileCacheValidate().

  virQEMUCapsCacheFree() is removed because it's no longer required.

  Add virCapsPtr into virQEMUCapsCachePriv because for each call of
  virFileCacheLookup*() we need to use current virCapsPtr.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

This is a preparation for following patches where we switch to
virFileCache for QEMU capabilities cache

The host arch will always remain the same but virCaps may change.  Now
the host arch is stored while creating new qemu capabilities cache.
It removes the need to pass virCaps into virQEMUCapsCache*() functions.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

This will store private data that will be used by following patches
when switching to virFileCache.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

It was observed while adding new property that there should be a space
before closing a curly brace in intel-iommu object property definition.
Fixing it as a separate patch.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>

So the way we format this huge virQEMUCaps enum is we group the
values in groups of five. And then at the beginning of each group
we have a small comment that says what's the number of the first
item in the group. Well, the last commit of 11b2ebf3 does not
follow this formatting.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The patch adds a capability for spapr-pci-host-bridge.numa_node.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Preparation for switching to virFileCache where there are two callbacks,
one to get a new data and second one to load a cached data.

This also removes virQEMUCapsReset which is no longer required.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

It's not required and following patches will change the code.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Cleanups the code a little bit and reduces amount of arguments passed
throughout the functions.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

While searching for an element using a function it may be
desirable to know the element key for future operation.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

This new capability can be used to detect whether a QEMU
binary supports the spapr-pci-host-bridge controller.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

This is only used in qemu_command.c, so move it, and clarify that
it's really about identifying if the serial config is a platform
device or not.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>