When the network interface is of "user" type, and QEMU has the "-net
socket,fd=" datagram support, call qemuInterfacePrepareSlirp() to
probe and associate a slirp-helper with the interface.

The usage of automated slirp-helper can be prevented with
disableSlirp (in particular when resuming a
VM that didn't start with slirp-helper before).
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

If a slirp-helper is associated with a network interface,
prepare/start/stop the process via qemu-extdevice.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

pid filenames (from swtpm and other helpers from this series) are
based on VM shortname, which is derived from VM id. If the id is reset
to early, the state filenames will not be found.
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Once QEMU is started, the qemuDomainLogContext is owned by it, and can
no longer be used from libvirt. Instead, use
qemuDomainLogAppendMessage() which will redirect the log.

This is not strictly necessary for swtpm, but the following patches
are going to reuse qemuExtDeviceLogCommand().
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

With blockdev we must issue the block_set_io_throttle QMP command to
setup disk throttling as we currently can't do it with the 'throttle'
layer.

Unfortunately there's nothing we can do if it fails.

https://bugzilla.redhat.com/show_bug.cgi?id=1733163Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

QEMU-4.1 supports 'Direct Mode' for Hyper-V synthetic timers
(hv-stimer-direct CPU flag): Windows guests can request that timer
expiration notifications are delivered as normal interrupts (and not
VMBus messages). This is used by Hyper-V on KVM.
Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.

This patch fixes all paths leading to virDomainDefPostParse.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.

Several general functions from domain_conf.c were lazily passing NULL as
the parseOpaque pointer instead of letting their callers pass the right
data. This patch fixes all paths leading to virDomainDefCopy to do the
right thing.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Since qemuDomainDefPostParse callback requires qemuCaps, we need to make
sure it gets the capabilities stored in the domain's private data if the
domain is running. Passing NULL may cause QEMU capabilities probing to
be triggered in case QEMU binary changed in the meantime. When this
happens while a running domain object is locked, QMP event delivered to
the domain before QEMU capabilities probing finishes will deadlock the
event loop.

This patch fixes all paths leading to qemuDomainDefFormatBufInternal.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

'default monitor of an allocation' is defined as the resctrl
monitor group that created along with an resctrl allocation,
which is created by resctrl file system. If the monitor group
specified in domain configuration file is happened to be a
default monitor group of an allocation, then it is not necessary
to create monitor group since it is already created. But if
an monitor group is not an allocation default group, you
should create the group under folder
'/sys/fs/resctrl/mon_groups' and fill the vcpu PIDs to 'tasks'
file.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

hv-spinlocks is not a CPUID feature and should not be checked as such.
While starting a domain with hv-spinlocks enabled, we would report a
warning about unsupported hyperv spinlocks feature even though it was
set properly.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Originally the names of the hyperv CPU features were only used
internally for looking up their CPUID bits. So we used "__kvm_hv_"
prefix for them to make sure the names do not collide with normal CPU
features stored in our CPU map.

But with QEMU 4.1 we check which features were enabled or disabled by a
freshly started QEMU process using their names rather than their CPUID
bits (mostly because of MSR features). Thus we need to change our made
up internal names into the actual names used by QEMU. Most of the names
are only used with QEMU 4.1 and newer and the reset was introduced with
QEMU recently enough to already support spelling with "-". Thus we don't
need to define them as "hv_*" with a translation to "hv-*" for new QEMU.

Without this patch libvirt would mistakenly report all hyperv features
as unavailable and refuse to start any domain using them with QEMU 4.1.
Reported-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Tested-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

In case of an incoming migration we do not need to run swtpm_setup
with all the parameters but only want to get the benefit of it
creating a TPM state file for us that we can then label with an
SELinux label. The actual state will be overwritten by the in-
coming state. So we have to pass an indicator for incomingMigration
all the way to the command line parameter generation for swtpm_setup.
Signed-off-by: NStefan Berger <stefanb@linux.ibm.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

If we are using -blockdev, then node names are always available
(because we set them).  But when not using it, we have to scrape node
names from QMP, and want to do so as infrequently as possible.  We
were scraping node names after reconnecting a new libvirtd to an
existing guest (see qemuProcessReconnect), and after any block job
that may have changed the set of node names we care about (legacy
block jobs), but forgot to scrape the names when first starting a
guest.  Do so now in order to allow the checkpoint code to always have
access to a node name without having to repeat a node name scrape
itself.

Future patches may need to clean up qemuDomainSetBlockThreshold (if
node names are always available, then it doesn't need to repeat a
scrape) and/or hotplug and media changes (if the addition of new nodes
can result in a null node name, then scraping at that point in time
would be appropriate).  But for now, this patch addresses only the
most common instance of a missing node name.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

The block job event handler qemuProcessHandleBlockJob looks at the block
job data to see whether the job requires synchronous handling. Since the
block job event may arrive before we continue the job handling (if the
job has no data to copy) we could hit the state when the job is still
set as QEMU_BLOCKJOB_STATE_NEW (as we move it to the
QEMU_BLOCKJOB_STATE_RUNNING state only after returning from monitor).

If the event handler uses qemuBlockJobStartupFinalize it would
unregister and free the job. Thankfully this is not a big problem for
legacy blockjobs as we don't need much data for them but since we'd
re-instantiate the job data structure we'd report wrong job type for
active commit as qemu reports it as a regular commit job.

Fix it by not using qemuBlockJobStartupFinalize function in
qemuProcessHandleBlockJob as it is not starting the job anyways.

https://bugzilla.redhat.com/show_bug.cgi?id=1721375Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The PR manager is a property of the format layer in qemu so we need to
be able to track it also in the chains of orphaned block jobs.

Add a helper for qemu to look also into the blockjob state.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Refresh the state of the jobs and process any events that might have
happened while libvirt was not running.

The job state processing requires some care to figure out if a job
needs to be bumped.

For any invalid job try doing our best to cancel it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Add support for handling the event either synchronously or
asynchronously using the event thread.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

With blockdev we'll need to use the JOB_STATUS_CHANGE so gate the old
events by the blockdev capability.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Now that block job data is stored in the status XML portion we need to
make sure that everything which changes the state also saves the status
XML. The job registering function is used while parsing the status XML
so in that case we need to skip the XML saving.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Add the job structure to the table when instantiating a new job and
remove it when it terminates/fails.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Pass an xmlopt argument through all the needed network conf
functions, like is done for domain XML handling. No functional
change for now
Reviewed-by: NLaine Stump <laine@laine.org>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Filter out the given capabilities and set domain taint if we've done so.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

For testing purposes it's sometimes desired to be able to control the
presence of capabilities of qemu. This adds the possibility to do this
via the qemu namespace.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When connecting to virtlogd fails e.g. due to wrong libvirtd selinux
process label we'd report an utterly useless error message:

$ virsh start upstream
error: Failed to start domain upstream
error: Cannot recv data: Connection reset by peer

Use virLastErrorPrefixMessage in the correct place to give a better
sense of what's going on:

$ virsh start upstream
error: Failed to start domain upstream
error: can't connect to virtlogd: Cannot recv data: Connection reset by peer
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
ACKed-by: NMichal Privoznik <mprivozn@redhat.com>

Without "unavailable-features" CPU property we cannot properly detect
whether a specific MSR feature we asked for (either explicitly or
implicitly via a CPU model) was disabled by QEMU for some reason.
Because this could break migration, snapshots, and save/restore
operaions, it's better to just forbid any use of MSR features with QEMU
which lacks "unavailable-features" CPU property.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Always assume JSON monitor was requested, since all the callers
pass true anyway.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

If we have a monitor, it is a JSON monitor.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Acked-by: NPeter Krempa <pkrempa@redhat.com>

Now that we no longer support the HMP monitor, remove some dead code.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Acked-by: NPeter Krempa <pkrempa@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: NJán Tomko <jtomko@redhat.com>
Acked-by: NPeter Krempa <pkrempa@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: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@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: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJá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: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJá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: 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>

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: NJie Wang <wangjie88@huawei.com>
Reviewed-by: NMichal Privoznik <mprivozn@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: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Commit 2f2254c7 attempted to fix a memory leak by ensuring
cpumapToSet is always a freshly allocated bitmap, but regrettably
introduced a NULL pointer access while doing so, because it called
virBitmapCopy() without allocating the destination bitmap first.

Solve the issue by using virBitmapNewCopy() instead.
Reported-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

We're using VIR_AUTOPTR() for everything now, plus the
cleanup section was not doing anything useful anyway.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

In two out of three scenarios we are cleaning up properly after
ourselves, but commit 5f2212c0 has changed the remaining one
in a way that caused it to start leaking cpumapToSet.

Refactor the logic so that cpumapToSet is always a freshly
allocated bitmap that gets cleaned up automatically thanks to
VIR_AUTOPTR(); this also allows us to remove the hostcpumap
variable.
Reported-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>