In preparation to removing the json field from qemuMonitor,
stop checking for it in QEMU_CHECK_MONITOR.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Always assume JSON monitor was requested, since all the callers
pass true anyway.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Now that we no longer support the HMP monitor, remove some dead code.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
No reason not to be consistent with the user-visible value.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
According to sPAPR, addresses are 32-bit rather than 64-bit.
Update qemuDomainDeviceDefValidateAddress() accordingly.
https://bugzilla.redhat.com/show_bug.cgi?id=1598657
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Introduce a switch() statement and prepare for validating
more address types than just PCI.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Now that the virDomainQemuAttach API returns an error, we can remove the
unused qemuProcessAttach function as well, deleting the only user
that possibly could have requested to open a non-JSON monitor.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The only user is now in qemu_monitor_json.c to re-parse the command line
format into keyvalue pairs for use in QMP command construction.
Move and rename the functions.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
qemu_domain.c is now the only place that uses it, so we can move it from
qemu_parse_command.h
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
It's now unused and utterly obsolete.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This code is really neglected and does not at all work reliably. It
can't even be used for converting our own commandline back.
Since this was mostly useful for aiding migration from manually run qemu
to libvirt and will not work for this puspose in many cases it's not
worth having.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Now that we no longer support attaching to a live QEMU process not
managed by libvirt we can drop the backend functions as well.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Attaching to modern qemu will not work with all this code and attempting
to ressurect it would be mostly pointless.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
If spawning qemu fails then we report an error and proceed to
writing status XML onto the disk. This is unnecessary as we are
sure that the domain is not running.
At the same time, if virPidFileReadPath() fails it returns
-errno. Use it in the error message. It may explain what went
wrong.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Starting from version 4.1 qemu allows reporting 'features' for a given
QAPI type object. This allows reporting support of fixes and additions
which are otherwise invisible in the QAPI schema.
Implement a possibility to query 'features' in the QAPI query strings.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
When updating guest CPU definition according to the vCPU actually
created by QEMU, we want to use the generic qemuMonitorGetGuestCPU to
get both CPUID and MSR features.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unlike the old version (which is now called qemuMonitorGetGuestCPUx86),
this monitor API checks for individual features by their names rather
than processing CPUID bits. Thus we can get the list of enabled and
disabled features for both CPUID and MSR features.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function converts a list of QOM properties into a NULL-terminated
array of property names. The new type parameter may be used to limit the
result to properties of a specific type.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is a generic replacement for the former virCPUx86DataAddFeature,
which worked on the generic virCPUDataPtr anyway.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It was never implemented or used for anything else anyway. Mainly
because it uses CPUID features bits. The function is renamed as
qemuMonitorGetGuestCPUx86 to make this explicit.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Já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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Já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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Já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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Já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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Já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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We will use it to check whether QEMU supports a specific CPU property.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Já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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Normal CPU features use modern -cpu ...,feature=on|off syntax when
available, but kvm features kept using the old +feature or -feature.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Properly filter features which should not be passed to QEMU because they
were never supported by QEMU or they did nothing and QEMU dropped them.
Currently they are just silently ignored by the command line generator.
Let's make this process more visible and clean by dropping the features
from the domain's active definition in qemuProcessUpdateGuestCPU.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Já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: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Unused as of:
commit f136b83139
qemu: Rework setting process affinity
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The current qemu driver code for changing bandwidth on a NIC first asks
the network driver if the change is supported, then changes the
bandwidth on the VIF, and then tells the network driver to update the
bandwidth on the bridge.
This is potentially racing if a parallel API call causes the network
driver to allocate bandwidth on the bridge between the check and the
update phases.
Change the code to just try to apply the network bridge update
immediately and rollback at the end if something failed.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If libvirt receives DISCONNECTED event and prDaemonRunning is set
to false, and qemuDomainRemoveDiskDevice() is performing in the
meantime, then qemuDomainRemoveDiskDevice() will fail to remove
pr-helper object because prDaemonRunning is false. But removing
that check from qemuHotplugRemoveManagedPR() is not enough,
because after removing the object through monitor the
qemuProcessKillManagedPRDaemon() is called which contains the
same check. Thus the pr-helper process might be left behind.
Signed-off-by: Jie Wang <wangjie88@huawei.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Log the flags passed to the function in a exploded state so that it's
easily visible what's happening to the image.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The hash table returned by qemuMonitorGetAllBlockJobInfo is organized by
the frontend name (which skipps the 'drive-' prefix). While our code
properly matches the jobs to the disk, qemu needs the full job name
including the 'drive-' prefix to be able to identify jobs.
Fix this by adding an argument to qemuMonitorGetAllBlockJobInfo which
does not modify the job name before filling the hash.
This fixes a regression where users would not be able to cancel/pivot
block jobs after restarting libvirtd while a blockjob is running.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In commit 76b9aba2ba I refactored how the function treats the readonly
flag which introduced a bug when we'd not allow to force read-write
state for an image.
This created problems with blockjobs where we need to temporarily
force images to have read-write permissions.
Rename QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_READ_ONLY to
QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_ONLY and also introduce
a complement QEMU_DOMAIN_STORAGE_SOURCE_ACCESS_FORCE_READ_WRITE which
will allow to force write access.
https://bugzilla.redhat.com/show_bug.cgi?id=1717768
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In commit 76b9aba2ba I tried to refactor qemuDomainStorageSourceAccessAllow
but used wrong operators for adding bitwise flags.
This way the flags would result in 0 if any of them would be applied.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The upcoming virDomainBackup() API needs to take advantage of the
ability to expose a bitmap as part of nbd-server-add for a pull-mode
backup (this is the recently-added QEMU_CAPS_NBD_BITMAP capability).
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
The upcoming virDomainBackup() API needs to take advantage of various
qcow2 bitmap manipulations as the basis to virDomainCheckpoints and
incremental backups. Add four functions to expose
block-dirty-bitmap-{add,enable,disable,merge} (this is the
recently-added QEMU_CAPS_BITMAP_MERGE capability).
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@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: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Migration always uses a TCP socket for NBD servers, because we don't
support same-host migration. But upcoming pull-mode incremental backup
needs to also support a Unix socket, for retrieving the backup from
the same host. Support this by plumbing virStorageNetHostDef through
the monitor calls, since that is a nice reusable struct that can track
both TCP and Unix sockets.
Update qemumonitorjsontest to verify both forms of the QMP command.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
Now that we never get to the actual snapshot code if there's nothing to
do we can remove the variable and surrounding logic.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Skip actual snapshot creation code if we have 0 disks to snapshot.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All cases taking the 'cleanup' path can take the original 'error' path.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduce 'rc' for collecting state from monitor commands so that we can
initialize 'ret' to -1. This also fixes few cases which could return 0
from the function despite an error condition.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
