'virResctrlAllocIsEmpty' checks if cache allocation or memory
bandwidth allocation settings are specified in configuration
file. It is not proper to be used in checking memory bandwidth
allocation is specified in XML settings because this function
could not distinguish memory bandwidth allocations from cache
allocations.

Here using the local variable @n, which indicates the cache
allocation groups or memory bandwidth groups depending on the
context it is in, to decide if append a new @resctrl object.

If @n is zero and no monitors groups specified in XML, then
we should not append a new @resctrl object to @def->resctrls.

This kind of replacement is also more efficient and avoiding
a long function calling path.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Let 'virDomainResctrlVcpuMatch' to retrieve a pointer of
virDomainResctrlDefPtr in its third parameter instead
of virResctrlAllocPtr, if @vcpus is matched with the vcpus
of some resctrl allocation in list of @def->resctrls.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Creating object and judging if it is successfully created in fewer
lines.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

code cleanup for 'virDomainCachetuneDefParse' and
'virDomainMemorytuneDefParse'.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Remove some redundant space and line.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.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>

Fortunately, the code that handles metadata getting or setting is
driver agnostic, so all that is needed from individual hypervisor
drivers is to call the right functions.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1732306Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

"virsh console" on macOS cannot attach to a domain and it doesn't matter if
it's local or remote domain:
  $ ~ virsh console vm
  Connected to domain vm
  Escape character is ^]
  error: internal error: unable to wait on console condition

The error comes from pthread_cond_wait that fails with EINVAL. The mutex
in the parent is not initialized with pthread_mutex_init and it results
in silent failure of pthead_mutex_lock and the attach failure.

Fixes: 98361cc3 ("tools: console: make console virLockableObject")
Signed-off-by: NRoman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

In v5.6.0-rc1~347 I've mistakenly messed up news.xml as the
change I wanted to promote was added into a comment (I blame git
rebase for that). Anyway, restore the original state of the
comment so it can be copied again.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

* docs/news.xml: updated for release
Signed-off-by: NDaniel Veillard <veillard@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Acked-by: NDaniel Veillard <veillard@redhat.com>

readline-devel is an optional build dependency; when it is not
present, the output of 'virsh <<EOF ... EOF' is different in that the
input provided by the user is not echoed, and prompts become
interleaved on the same line as actual output, which in turn causes
the sed doing prompt filtering to mess up:

| ./virsh-snapshot
| --- exp	2019-07-31 18:42:31.107399428 -0300
| +++ out.cooked	2019-07-31 18:42:31.108399437 -0300
| @@ -1,8 +1,3 @@
| -
| -
| -Domain snapshot s3 created from 's3.xml'
| -Domain snapshot s2 created from 's2.xml'
| -Name:           s2
|  Domain:         test
|  Current:        yes
|  State:          running

Maybe we should fix virsh in interactive mode to echo regardless of
whether readline-devel was used, but the quicker fix is to make the
test use 'virsh "..."' rather than reading its input from stdin.
Reported-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Signed-off-by: NEric Blake <eblake@redhat.com>
Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Checkpoints are definitely a news-worthy addition, even if the
virDomainBackup API is not going to make it until a later release.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Wording improvements in the recent patches.
Signed-off-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NHan Han <hhan@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Signed-off-by: NHan Han <hhan@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Employees from these companies have made contributions to
libvirt over the past few releases.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

I messed up formatting during conflict resolution across rebasing
while preparing my checkpoint patches :)
Signed-off-by: NEric Blake <eblake@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>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Introduced by: commit e9528f41

'msrs' is a feature unrelated to Hyper-V Enlightenments, the commit message
which added it and the test have it right:

    <features>
      ...
      <msrs unknown='ignore'>
      ...
    </features>
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>

SynIC stands for 'Synthetic Interrupt Controller', it is not a NIC. Fix the
spelling in accordance with Hypervisor Top Level Functional Specification.
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>

The example XML we have contains all other Hyper-V Enlightenments but
'stimer' is missing.
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>

CI flagged a failing mingw build, due to:
In file included from ../../src/conf/checkpoint_conf.c:24:
../gnulib/lib/configmake.h:8:17: error: expected identifier or '(' before string constant
    8 | #define DATADIR "/usr/i686-w64-mingw32/sys-root/mingw/share"
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

As previously learned in commits bd205a90 and 976abdf6, gnulib's
configmake.h header does #define DATADIR "string...", while mingw's
<winsock2.h> expects to declare a type named DATADIR. As long as the
mingw system header is included first before configmake.h, the two
uses do not conflict, but until gnulib is patched to make configmake.h
automatically work around the issue, our immediate fix is the
workaround of rearranging our include order to insure no conflict.
Copy the paradigm used in domain_conf.c of using <unistd.h> to trigger
the indirect inclusion of <winsock2.h> on mingw.

Fixes: 1a4df34aSigned-off-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

Turning a NULL URI instead the empty string is very misleading when
reading the debug logs as the distinction between the two is
functionally important.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The recently added test27 spawns commandhelper. This is fine,
except, one of the things that commandhelper does is it records
arguments it was spawn with into commandhelper.log. Other test
cases then use checkoutput() to compare the arguments against the
expected ones and also unlink() the log file. However, test27()
is not doing that and thus it leaves the file behind. This
breaks distcheck.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NIlias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

These test cases will start failing once the test driver provides
implementation for the virDomainGetCPUStats API.
Signed-off-by: NIlias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

The returned array of qemuMonitorJobInfo structs must be freed.

164 (16 direct, 148 indirect) bytes in 1 blocks are definitely lost in loss record 64 of 84
   at 0x4A3568B: realloc (vg_replace_malloc.c:826)
   by 0x4D888BD: virReallocN (viralloc.c:244)
   by 0x4D889B3: virExpandN (viralloc.c:293)
   by 0x4D88C87: virInsertElementsN (viralloc.c:435)
   by 0x214004: qemuMonitorJSONGetJobInfo (qemu_monitor_json.c:9185)
   by 0x148B3F: testQueryJobs (qemumonitorjsontest.c:2979)
   by 0x14C192: virTestRun (testutils.c:174)
   by 0x14BF36: mymain (qemumonitorjsontest.c:3286)
   by 0x14E256: virTestMain (testutils.c:1096)
   by 0x14BFD9: main (qemumonitorjsontest.c:3298)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
ACKed-by: NPeter Krempa <pkrempa@redhat.com>

Originally the names of the KVM CPU features were only used internally
for looking up their CPUID bits. So we used "__kvm_" 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.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Tested-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Most of the internally defined KVM CPUID features are not actually used
by libvirt. The QEMU driver may enable or disable them on the command
line, but we don't check for the associated CPU properties or CPUID
bits. They would be useless with QEMU 4.1 anyway since their names were
only remotely similar to the actual feature names.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Tested-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

All the features are hyperv features even though they are provided by
KVM with QEMU. The "KVM" part in the macro names does not make a lot of
sense.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Tested-by: NVitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Starting with QEMU 4.1, we're using the canonical feature names on the
command line and avoid aliases to prepare for possible deprecation of
all aliases in QEMU. But we do so only for features from our CPU map,
hyperv features defined in the code were unchanged and this patch fixes
it. Some features use "hv-" prefix unconditionally because they were
introduced recently enough to always support spelling with a dash.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Tested-by: NVitaly Kuznetsov <vkuznets@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>

Earlier patches mentioned that the initial implementation will prevent
snapshots and checkpoints from being used on the same domain at once.
However, the actual restriction is done in this separate patch to make
it easier to lift that restriction via a revert, when we are finally
ready to tackle that integration in the future.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Time to actually issue the QMP transactions that create and delete
persistent checkpoints, resolving TODOs intentionally left earlier in
the series.  For create, we only need one transaction: inside, we
visit all disks affected by the checkpoint, and create a new enabled
bitmap, as well as disabling the bitmap of the first ancestor
checkpoint (if any) that also had a bitmap.  For deletion, we need
multiple QMP calls: for each disk, if there is an ancestor checkpoint
with a bitmap, then the bitmap must be merged (including activating
the ancestor bitmap if the leaf node changes), all before deleting the
bitmap from the checkpoint being removed.
Signed-off-by: NEric Blake <eblake@redhat.com>

Qemu bitmap operations require knowing the node name associated with
the format layer (the qcow2 file); as upcoming patches will be
grabbing that information frequently, make a helper function to access
it.

Another potential benefit of this function is that we have a single
place where we could insert a QMP node-name scraping call if we don't
currently know the node name, when -blockdev is not supported;
however, the goal is that we hopefully don't ever have to do that
because we instead scrape node names only at the point where they
change.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>