Commit Graph

5833 Commits

Author SHA1 Message Date
Nikolay Shirokovskiy
c9a191fc48 qemu: don't use vm when lock is dropped in qemuDomainGetFSInfo
Current call to qemuAgentGetFSInfo in qemuDomainGetFSInfo is
unsafe. Domain lock is dropped and we use vm->def. Let's make
def copy to fix that.
2016-12-12 17:14:11 -05:00
Nikolay Shirokovskiy
3ab9652a86 qemu: agent: fix uninitialized var case in qemuAgentGetFSInfo
In case of 0 filesystems *info is not set while according
to virDomainGetFSInfo contract user should call free on it even
in case of 0 filesystems. Thus we need to properly set
it. NULL will be enough as free eats NULLs ok.
2016-12-12 17:14:11 -05:00
John Ferlan
cf436a560d qemu: Fix GetBlockInfo setting allocation from wr_highest_offset
The libvirt-domain.h documentation indicates that for a qcow2 file
in a filesystem being used for a backing store should report the disk
space occupied by a file; however, commit id '15fa84ac' altered the
code to trust that the wr_highest_offset should be used whenever
wr_highest_offset_valid was set.

As it turns out this will lead to indeterminite results. For an active
domain when qemu hasn't yet had the need to find the wr_highest_offset
value, qemu will report 0 even though qemu-img will report the proper
disk size. This causes reporting of the following XML:

  <disk type='file' device='disk'>
    <driver name='qemu' type='qcow2'/>
    <source file='/path/to/test-1g.qcow2'/>

to be as follows:

Capacity:       1073741824
Allocation:     0
Physical:       1074139136

with qemu-img indicating:

image: /path/to/test-1g.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 1.0G

Once the backing source file is opened on the guest, then wr_highest_offset
is updated, but only to the high water mark and not the size of the file.

This patch will adjust the logic to check for the file backed qcow2 image
and enforce setting the allocation to the returned 'physical' value, which
is the 'actual-size' value from a 'query-block' operation.

NB: The other consumer of the wr_highest_offset output (GetAllDomainStats)
has a contract that indicates 'allocation' is the offset of the highest
written sector, so it doesn't need adjustment.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-12 16:04:17 -05:00
John Ferlan
9d734b60a7 util: Introduce virStorageSourceUpdateCapacity
Instead of having duplicated code in qemuStorageLimitsRefresh and
virStorageBackendUpdateVolTargetInfo to get capacity specific data
about the storage backing source or volume -- create a common API
to handle the details for both.

As a side effect, virStorageFileProbeFormatFromBuf returns to being
a local/static helper to virstoragefile.c

For the QEMU code - if the probe is done, then the format is saved so
as to avoid future such probes.

For the storage backend code, there is no need to deal with the probe
since we cannot call the new API if target->format == NONE.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-12 16:04:17 -05:00
John Ferlan
3039ec962e util: Introduce virStorageSourceUpdateBackingSizes
Instead of having duplicated code in qemuStorageLimitsRefresh and
virStorageBackendUpdateVolTargetInfoFD to fill in the storage backing
source or volume allocation, capacity, and physical values - create a
common API that will handle the details for both.

The common API will fill in "default" capacity values as well - although
those more than likely will be overridden by subsequent code. Having just
one place to make the determination of what the values should be will
make things be more consistent.

For the QEMU code - the data filled in will be for inactive domains
for the GetBlockInfo and DomainGetStatsOneBlock API's. For the storage
backend code - the data will be filled in during the volume updates.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-12 16:04:17 -05:00
John Ferlan
c5f6151390 util: Introduce virStorageSourceUpdatePhysicalSize
Commit id '8dc27259' introduced virStorageSourceUpdateBlockPhysicalSize
in order to retrieve the physical size for a block backed source device
for an active domain since commit id '15fa84ac' changed to use the
qemuMonitorGetAllBlockStatsInfo and qemuMonitorBlockStatsUpdateCapacity
API's to (essentially) retrieve the "actual-size" from a 'query-block'
operation for the source device.

However, the code only was made functional for a BLOCK backing type
and it neglected to use qemuOpenFile, instead using just open. After
the open the block lseek would find the end of the block and set the
physical value, close the fd and return.

Since the code would return 0 immediately if the source device wasn't
a BLOCK backed device, the physical would be displayed incorrectly,
such as follows in domblkinfo for a file backed source device:

Capacity:       1073741824
Allocation:     0
Physical:       0

This patch will modify the algorithm to get the physical size for other
backing types and it will make use of the qemuDomainStorageOpenStat
helper in order to open/stat the source file depending on its type.
The qemuDomainGetStatsOneBlock will no longer inhibit printing errors,
but it will still ignore them leaving the physical value set to 0.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-12 16:04:17 -05:00
John Ferlan
a7fea19fcd qemu: Introduce helper qemuDomainStorageUpdatePhysical
Currently just a shim to call virStorageSourceUpdateBlockPhysicalSize

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-12 16:04:17 -05:00
John Ferlan
732af77cce qemu: Add helpers to handle stat data for qemuStorageLimitsRefresh
Split out the opening of the file and fetch of the stat buffer into a
helper qemuDomainStorageOpenStat. This will handle either opening the
local or remote storage.

Additionally split out the cleanup of that into a separate helper
qemuDomainStorageCloseStat which will either close the file or
call the virStorageFileDeinit function.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-12 16:04:17 -05:00
John Ferlan
7149d1693d qemu: Clean up description for qemuStorageLimitsRefresh
Originally added by commit id '89646e69' prior to commit id '15fa84ac'
and '71d2c172' which ensured that qemuStorageLimitsRefresh was only called
for inactive domains.

Adjust the comment describing the need for FIXME and move all the text
to the function description.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-12 16:04:17 -05:00
Nikolay Shirokovskiy
1215965a4c qemu: mark user defined websocket as used
We need extra state variable to distinguish between autogenerated
and user defined cases after auto generation is done.
2016-12-09 07:54:34 -05:00
Nikolay Shirokovskiy
b07cfd724f qemu: Refactor qemuProcessGraphicsReservePorts
Use switch for enums rather than if/else conditions.
2016-12-09 07:40:46 -05:00
Michal Privoznik
b492f7ef0f qemuGetDomainHugepagePath: Initialize @ret
The variable may be used uninitialized in this function.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-12-09 10:51:37 +01:00
Mehdi Abaakouk
e0d893e86d Move virstat.c code to virnetdevtap.c
This is just a code move of virstat.c to virnetdevtap.c
2016-12-09 10:28:07 +01:00
Mehdi Abaakouk
9b6de7c506 virstat: fix signature of virstat helper
In preparation to the code move to virnetdevtap.c, this change:

* renames virNetInterfaceStats to virNetDevTapInterfaceStats
* changes 'path' to 'ifname', to use the same vocable as other
  method in virnetdevtap.c.
* Add the attributes checker
2016-12-09 10:27:56 +01:00
Mehdi Abaakouk
013df874db Gathering vhostuser interface stats with ovs
When vhostuser interfaces are used, the interface statistics
are not available in /proc/net/dev.

This change looks at the openvswitch interfaces statistics
tables to provide this information for vhostuser interface.

Note that in openvswitch world drop/error doesn't always make sense
for some interface type. When these informations are not available we
set them to 0 on the virDomainInterfaceStats.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-12-09 10:23:09 +01:00
Peter Krempa
a4ed5b4212 qemu: Don't try to find compression program for "raw" memory images
There's nothing to compress if the requested snapshot memory format is
set to 'raw' explicitly. After commit 9e14689ea libvirt would try to
run /sbin/raw to process the memory stream if the qemu.conf option
snapshot_image_format is set.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1402726
2016-12-08 17:12:54 +01:00
Michal Privoznik
ce937d3710 security: Drop virSecurityManagerSetHugepages
Since its introduction in 2012 this internal API did nothing.
Moreover we have the same API that does exactly the same:
virSecurityManagerDomainSetPathLabel.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-12-08 15:45:52 +01:00
Michal Privoznik
f55afd83b1 qemu: Create hugepage path on per domain basis
If you've ever tried running a huge page backed guest under
different user than in qemu.conf, you probably failed. Problem is
even though we have corresponding APIs in the security drivers,
there's no implementation and thus we don't relabel the huge page
path. But even if we did, so far all of the domains share the
same path:

   /hugepageMount/libvirt/qemu

Our only option there would be to set 0777 mode on the qemu dir
which is totally unsafe. Therefore, we can create dir on
per-domain basis, i.e.:

   /hugepageMount/libvirt/qemu/domainName

and chown domainName dir to the user that domain is configured to
run under.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-12-08 15:45:52 +01:00
Michal Privoznik
7ed6934f3b virDomainObjGetShortName: take virDomainDef
So far this function takes virDomainObjPtr which:
1) is an overkill,
2) might be not available in all the places we will use it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-12-08 15:45:52 +01:00
Peter Krempa
cf44dc072a qemu: capabilities: Add gluster.debug_level detection for 2.8.0+
Qemu 2.8.0+ changes arguments structure for blockdev-add in the effort
to make it finally stable. Since libvirt recently added the detection of
gluster debug support relying on the old syntax we need to add the new
as well.
2016-12-07 13:34:22 +01:00
Nitesh Konkar
8546adf80b perf: add one more perf event support
With current perf framework, this patch adds support and documentation
for the branch_instructions perf event.

Signed-off-by: Nitesh Konkar <nitkon12@linux.vnet.ibm.com>
2016-12-07 07:03:57 -05:00
John Ferlan
1ff38366b8 qemu: Add the group name option to the iotune command line
Add in the block I/O throttling group parameter to the command line
if supported. If not supported, fail command creation.

Add the xml2argvtest for testing.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-05 18:30:38 -05:00
John Ferlan
c53bd25b13 qemu: Add support for parsing iotune group setting
Add support to read/parse the iotune group setting for qemu.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-12-05 18:12:08 -05:00
John Ferlan
d0f82df205 qemu: Adjust various bool BlockIoTune set_ values into a single mask
Rather than have multiple bool values, create a single enum with bits
representing what fields are set. Fields are generally set in groups
of 3 (read, write, total).
2016-12-05 18:12:08 -05:00
John Ferlan
ad9f127302 qemu: Alter qemuMonitorJSONSetBlockIoThrottle command logic
Currently we build the JSON object for the "block_set_io_throttle"
command using the knowledge that a NULL for a support*Options boolean
would essentially ignore the rest of the arguments.

This may not work properly if some capability was backported, plus it just
looks rather ugly. So instead, build the "base" arguments and then if
the support*Option bool capability is set, add in the arguments on the fly.

Then append those arguments to the basic command and send to qemu.
2016-12-05 18:12:08 -05:00
John Ferlan
c84ad82a2d qemu: Adjust maxparams logic for qemuDomainGetBlockIoTune
Rather than using negative logic and setting the maxparams to a lesser
value based on which capabilities exist, alter the logic to modify the
maxparams based on a base value plus the found capabilities. Reduces the
chance that some backported feature produces an incorrect value.
2016-12-05 18:12:08 -05:00
John Ferlan
d3364dfdc8 caps: Add new capability for the iotune group name
Add the capability to detect if the qemu binary can support the feature
to use throttling.group.
2016-12-05 18:12:08 -05:00
Yuri Chornoivan
ff8e021225 Fix minor typos 2016-12-02 09:25:13 +01:00
gaohaifeng
f81b33b50c qemuDomainAttachNetDevice: pass mq and vectors for vhost-user with multiqueue
Two reasons:
1.in none hotplug, we will pass it. We can see from libvirt function
qemuBuildVhostuserCommandLine
2.qemu will use this vetcor num to init msix table. If we don't pass, qemu
will use default value, this will cause VM can only use default value
interrupts at most.

Signed-off-by: gaohaifeng <gaohaifeng.gao@huawei.com>
2016-12-01 15:02:35 +01:00
Eric Farman
655429a0d4 qemu: Prevent detaching SCSI controller used by hostdev
Consider the following XML snippets:

  $ cat scsicontroller.xml
      <controller type='scsi' model='virtio-scsi' index='0'/>
  $ cat scsihostdev.xml
      <hostdev mode='subsystem' type='scsi'>
        <source>
          <adapter name='scsi_host0'/>
          <address bus='0' target='8' unit='1074151456'/>
        </source>
      </hostdev>

If we create a guest that includes the contents of scsihostdev.xml,
but forget the virtio-scsi controller described in scsicontroller.xml,
one is silently created for us.  The same holds true when attaching
a hostdev before the matching virtio-scsi controller.
(See qemuDomainFindOrCreateSCSIDiskController for context.)

Detaching the hostdev, followed by the controller, works well and the
guest behaves appropriately.

If we detach the virtio-scsi controller device first, any associated
hostdevs are detached for us by the underlying virtio-scsi code (this
is fine, since the connection is broken).  But all is not well, as the
guest is unable to receive new virtio-scsi devices (the attach commands
succeed, but devices never appear within the guest), nor even be
shutdown, after this point.

While this is not libvirt's problem, we can prevent falling into this
scenario by checking if a controller is being used by any hostdev
devices.  The same is already done for disk elements today.

Applying this patch and then using the XML snippets from earlier:

  $ virsh detach-device guest_01 scsicontroller.xml
  error: Failed to detach device from scsicontroller.xml
  error: operation failed: device cannot be detached: device is busy

  $ virsh detach-device guest_01 scsihostdev.xml
  Device detached successfully

  $ virsh detach-device guest_01 scsicontroller.xml
  Device detached successfully

Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2016-11-30 17:16:47 -05:00
Laine Stump
70249927b7 qemu: assign VFIO devices to PCIe addresses when appropriate
Although nearly all host devices that are assigned to guests using
VFIO ("<hostdev>" devices in libvirt) are physically PCI Express
devices, until now libvirt's PCI address assignment has always
assigned them addresses on legacy PCI controllers in the guest, even
if the guest's machinetype has a PCIe root bus (e.g. q35 and
aarch64/virt).

This patch tries to assign them to an address on a PCIe controller
instead, when appropriate. First we do some preliminary checks that
might allow setting the flags without doing any extra work, and if
those conditions aren't met (and if libvirt is running privileged so
that it has proper permissions), we perform the (relatively) time
consuming task of reading the device's PCI config to see if it is an
Express device. If this is successful, the connect flags are set based
on the result, but if we aren't able to read the PCI config (most
likely due to the device not being present on the system at the time
of the check) we assume it is (or will be) an Express device, since
that is almost always the case anyway.
2016-11-30 15:41:57 -05:00
Laine Stump
9b0848d523 qemu: propagate virQEMUDriver object to qemuDomainDeviceCalculatePCIConnectFlags
If libvirtd is running unprivileged, it can open a device's PCI config
data in sysfs, but can only read the first 64 bytes. But as part of
determining whether a device is Express or legacy PCI,
qemuDomainDeviceCalculatePCIConnectFlags() will be updated in a future
patch to call virPCIDeviceIsPCIExpress(), which tries to read beyond
the first 64 bytes of the PCI config data and fails with an error log
if the read is unsuccessful.

In order to avoid creating a parallel "quiet" version of
virPCIDeviceIsPCIExpress(), this patch passes a virQEMUDriverPtr down
through all the call chains that initialize the
qemuDomainFillDevicePCIConnectFlagsIterData, and saves the driver
pointer with the rest of the iterdata so that it can be used by
qemuDomainDeviceCalculatePCIConnectFlags(). This pointer isn't used
yet, but will be used in an upcoming patch (that detects Express vs
legacy PCI for VFIO assigned devices) to examine driver->privileged.
2016-11-30 15:28:07 -05:00
Jiri Denemark
0355de2e77 qemuProcessReconnect: Avoid relabeling images after migration
Restarting libvirtd on the source host at the end of migration when a
domain is already running on the destination would cause image labels to
be reset effectively killing the domain. Commit e8d0166e1d fixed similar
issue on the destination host, but kept the source always resetting the
labels, which was mostly correct except for the specific case handled by
this patch.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-29 12:37:04 +01:00
Jiri Denemark
ee3ea86b37 qemu: Report tunnelled post-copy migration as unsupported
Post-copy migration needs bi-directional communication between the
source and the destination QEMU processes, which is not supported by
tunnelled migration.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-29 12:31:25 +01:00
Peter Krempa
b87a11340f qemu: capabilities: Don't partially reprope caps on process reconnect
Thanks to the complex capability caching code virQEMUCapsProbeQMP was
never called when we were starting a new qemu VM. On the other hand,
when we are reconnecting to the qemu process we reload the capability
list from the status XML file. This means that the flag preventing the
function being called was not set and thus we partially reprobed some of
the capabilities.

The recent addition of CPU hotplug clears the
QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine does not support it.
The partial re-probe on reconnect results into attempting to call the
unsupported command and then killing the VM.

Remove the partial reprobe and depend on the stored capabilities. If it
will be necessary to reprobe the capabilities in the future, we should
do a full reprobe rather than this partial one.
2016-11-28 10:02:36 +01:00
Jiri Denemark
a1adfb0f06 qemu: Add support for unavailable-features
QEMU 2.8.0 adds support for unavailable-features in
query-cpu-definitions reply. The unavailable-features array lists CPU
features which prevent a corresponding CPU model from being usable on
current host. It can only be used when all the unavailable features are
disabled. Empty array means the CPU model can be used without
modifications.

We can use unavailable-features for providing CPU model usability info
in domain capabilities XML:

    <domainCapabilities>
      ...
      <cpu>
        <mode name='host-passthrough' supported='yes'/>
        <mode name='host-model' supported='yes'>
          <model fallback='allow'>Skylake-Client</model>
          ...
        </mode>
        <mode name='custom' supported='yes'>
          <model usable='yes'>qemu64</model>
          <model usable='yes'>qemu32</model>
          <model usable='no'>phenom</model>
          <model usable='yes'>pentium3</model>
          <model usable='yes'>pentium2</model>
          <model usable='yes'>pentium</model>
          <model usable='yes'>n270</model>
          <model usable='yes'>kvm64</model>
          <model usable='yes'>kvm32</model>
          <model usable='yes'>coreduo</model>
          <model usable='yes'>core2duo</model>
          <model usable='no'>athlon</model>
          <model usable='yes'>Westmere</model>
          <model usable='yes'>Skylake-Client</model>
          ...
        </mode>
      </cpu>
      ...
    </domainCapabilities>

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-28 09:11:22 +01:00
Jiri Denemark
73411a7ff1 qemu: Avoid reporting "host" as a supported CPU model
"host" CPU model is supported by a special host-passthrough CPU mode and
users is not allowed to specify this model directly with custom mode.
Thus we should not advertise "host" CPU model in domain capabilities.
This worked well on architectures for which libvirt provides a list of
supported CPU models in cpu_map.xml (since "host" is not in the list).
But we need to explicitly filter "host" model out for all other
architectures.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:59:19 +01:00
Jiri Denemark
7bf6f345e0 qemu: Probe CPU models for KVM and TCG
CPU models (and especially some additional details which we will start
probing for later) differ depending on the accelerator. Thus we need to
call query-cpu-definitions in both KVM and TCG mode to get all data we
want.

Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid
having to squash even more stuff into this single patch. They will all
be switched back later in separate commits.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
7c95619cb1 qemu: Introduce virQEMUCapsFormatCPUModels
This patch moves the CPU models formatting code from
virQEMUCapsFormatCache into a separate function.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
1bdcd7a4ee qemu: Introduce virQEMUCapsLoadCPUModels
This patch moves the CPU models parsing code from virQEMUCapsLoadCache
into a separate function.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
f9d57f2b57 qemu: Refresh caps in virQEMUCapsCacheLookupByArch
The function just returned cached capabilities without checking whether
they are still valid. We should check that and refresh the capabilities
to make sure we don't return stale data. In other words, we should do
what all other lookup functions do.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
72e5aa4e1e qemu: Refactor virQEMUCapsCacheLookup
The function is made a little bit more readable and the code which
refreshes cached capabilities if they are not valid any more was moved
into a separate function (virQEMUCapsCacheValidate) so that it can be
reused in other places.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
cd51b90fbf qemu: Don't return unusable virttype in domain capabilities
If a user asked for a KVM domain capabilities when KVM is not available,
we would happily return data we got when probing through TCG and
pretended they were relevant for KVM. Let's just report KVM is not
supported to avoid confusion.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
8f55eef246 qemu: Use saner defaults for domain capabilities
When domain capabilities were introduced we did not have enough data to
decide whether KVM works on the host or not and thus working legacy/VFIO
device assignment was used as a witness. Now that we know whether KVM
was enabled when probing QEMU capabilities (and thus we know it's
working), we can use this knowledge to provide better default value for
virttype.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
d87df9bd39 qemu: Discard caps cache when KVM availability changes
Since some may depend on the accelerator used when probing QEMU the
cache becomes invalid when KVM becomes available or if it is not
available anymore.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
25ba9c31f5 qemu: Enable KVM when probing capabilities
CPU related capabilities may differ depending on accelerator used when
probing. Let's use KVM if available when probing QEMU and fall back to
TCG. The created capabilities already contain all we need to distinguish
whether KVM or TCG was used:

    - KVM was used when probing capabilities:
        QEMU_CAPS_KVM is set
        QEMU_CAPS_ENABLE_KVM is not set

    - TCG was used and QEMU supports KVM, but it failed (e.g., missing
      kernel module or wrong /dev/kvm permissions)
        QEMU_CAPS_KVM is not set
        QEMU_CAPS_ENABLE_KVM is set

    - KVM was not used and QEMU does not support it
        QEMU_CAPS_KVM is not set
        QEMU_CAPS_ENABLE_KVM is not set

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
429a7b231c qemu: Probe KVM state earlier
Let's set QEMU_CAPS_KVM and QEMU_CAPS_ENABLE_KVM early so that the rest
of the probing code can use these capabilities to handle KVM/TCG replies
differently.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
e73447f693 qemu: Use -machine when probing capabilities via QMP
Using -machine instead of -M for QMP probing is safe because any QEMU
binary which is capable of QMP probing supports -machine.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
4c5d05ea8a qemu: Make QMP probing process reusable
The code that runs a new QEMU process to be used for probing
capabilities is separated into four reusable functions so that any code
that wants to probe a QEMU process may just follow a few simple steps:

    cmd = virQEMUCapsInitQMPCommandNew(...);
    virQEMUCapsInitQMPCommandRun(cmd);

    /* talk to the running QEMU process using its QMP monitor */

    if (reprobeIsRequired) {
        virQEMUCapsInitQMPCommandAbort(cmd, ...);
        virQEMUCapsInitQMPCommandRun(cmd);

        /* talk to the running QEMU process again */
    }

    virQEMUCapsInitQMPCommandFree(cmd);

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Michal Privoznik
c2a5a4e7ea virstring: Unify string list function names
We have couple of functions that operate over NULL terminated
lits of strings. However, our naming sucks:

virStringJoin
virStringFreeList
virStringFreeListCount
virStringArrayHasString
virStringGetFirstWithPrefix

We can do better:

virStringListJoin
virStringListFree
virStringListFreeCount
virStringListHasString
virStringListGetFirstWithPrefix

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-11-25 13:54:05 +01:00