While it's true that older QEMUs were not able to deal with PCI
domains, we don't support those versions anymore (see
4a42ece1). Therefore it is safe to always format fully
expanded PCI address. Format PCI domain always as it will
simplify next commits.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

A new algorithm for detecting the vcpus and monitor type conflicts
between new monitor an existing allocation and monitor groups.

After refactoring, since we are verifying both @vcpus and monitor
type @tag at the same time, the validating function name has been
renamed from virDomainResctrlMonValidateVcpus to
virDomainResctrlValidateMonitor.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Export virResctrlMonitorGetStats and make
virResctrlMonitorGetCacheOccupancy obsoleted.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Refactor 'virResctrlMonitorStats' to track multiple statistical
records.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Refactor and rename 'virResctrlMonitorFreeStats' to
'virResctrlMonitorStatsFree' to free one
'virResctrlMonitorStatsPtr' object.
Signed-off-by: NWang Huaqiang <huaqiang.wang@intel.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

'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>