This configuration can be used by gitdm to generate reports about
libvirt development.

The goal I was working with was being able to generate a report
for every single libvirt release and having zero "email address
as company" entries; picking different commit ranges might result
in some contributions not being accounted for.

I had to make some judgement calls when the situation was not
entirely clear-cut: when in doubt, and not finding any obvious
signs of the opposite being true, I mostly ended up dumping
people in the "unaffiliated contributions" bin. If I got it
wrong, and companies want to get recognition for their sponsored
contributions to libvirt, they can send patches.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Fabiano Fidencio was working for Red Hat when he contributed to
libvirt, Shi Lei's non-company email address contains the company
name so it's fair to assume contributions using it were made on
company time, and Adrian Brzezinski's personal email was used
for the S-o-b while the git authorship information clearly pointed
at the company being involved.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Validate @keycodes before successfully returning. Since this is test
driver, @holdtime is being unused here.
Signed-off-by: NIlias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: NErik Skultety <eskultet@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>

The flag causes undefine to fail if trying to remove a non-RBD disk. Add
a warning about that.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
ACKed-by: NEric Blake <eblake@redhat.com>

The old flag name confused some users into thinking it's the correct way
to undefine a VM with libvirt (not storage volume) snapshots.

The correct flag in that case is way less obvious: --snapshots-metadata.

Rename the flag (by adding an alias) to something which will promote
looking up the actual purpose of the flag.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
ACKed-by: NEric Blake <eblake@redhat.com>

Reword the end of the help string to make it more obvious that the VM
must be inactive.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NFabiano Fidêncio <fidencio@redhat.com>
ACKed-by: NEric Blake <eblake@redhat.com>

Due to this bug the following command would fail on any host where TSC
frequency can be probed:

    $ virsh capabilities | virsh cpu-baseline /dev/stdin
    error: unsupported configuration: Invalid TSC frequency

https://bugzilla.redhat.com/show_bug.cgi?id=1641702Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It's a premature optimization. It's perfectly acceptable for
'error' label to deal with @vm == NULL case.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1717090Signed-off-by: NErik Skultety <eskultet@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>

Right now, if numad fails, we raise an error but return an
empty string to the caller instead of a NULL pointer, which
means processing will continue and the user will see

  # virsh start guest
  error: Failed to start domain guest
  error: invalid argument: Failed to parse bitmap ''

instead of a more reasonable

  # virsh start guest
  error: Failed to start domain guest
  error: operation failed: Failed to query numad for the advisory nodeset

Make sure the user gets a better error message.

https://bugzilla.redhat.com/show_bug.cgi?id=1716387Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Ever since the feature was introduced with commit 0f8e7ae3,
it has contained a logic error in that it attempted to use a NUMA
node map where a CPU map was expected.

Because of that, guests using <numatune> might fail to start:

  # virsh start guest
  error: Failed to start domain guest
  error: cannot set CPU affinity on process 40055: Invalid argument

This was particularly easy to trigger on POWER 8 machines, where
secondary threads always show up as offline in the host: having

  <numatune>
    <memory mode='strict' placement='static' nodeset='1'/>
  </numatune>

in the guest configuration, for example, would result in libvirt
trying to set the process affinity so that it would prefer
running on CPU 1, but since that's a secondary thread and thus
shows up as offline, the operation would fail, and so would
starting the guest.

Use the newly introduced virNumaNodesetToCPUset() to convert the
NUMA node map to a CPU map, which in the example above would be
48,56,64,72,80,88 - a valid input for virProcessSetAffinity().

https://bugzilla.redhat.com/show_bug.cgi?id=1703661Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This helper converts a set of NUMA node to the set of CPUs
they contain.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This argument wasn't validated anywhere, neither in the generic
implementation nor in the individual drivers. As a result a call to this
function with a large enough codeset value prior to this change causes
libvirtd to crash.

This happens because all drivers call virKeycodeValueTranslate which
uses codeset as an index to the virKeymapValues array, causing an
out-of-bounds error.
Signed-off-by: NIlias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Always return "domain_name" + "host".
Signed-off-by: NIlias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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

When migrating a domain with invtsc CPU feature enabled, the TSC
frequency of the destination host must match the frequency used when the
domain was started on the source host or the destination host has to
support TSC scaling.

If the frequencies do not match and the destination host does not
support TSC scaling, QEMU will fail to set the right TSC frequency when
starting vCPUs on the destination and thus migration will fail. However,
this is quite late since both host might have spent significant time
transferring memory and perhaps even storage data.

By adding the check to libvirt we can let migration fail before any data
starts to be sent over. If for some reason libvirt is unable to detect
the host's TSC frequency or scaling support, we'll just let QEMU try and
the migration will either succeed or fail later.

Luckily, we mandate TSC frequency to be explicitly set in the domain XML
to even allow migration of domains with invtsc. We can just check
whether the requested frequency is compatible with the current host
before starting QEMU.

https://bugzilla.redhat.com/show_bug.cgi?id=1641702Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

When the host CPU supports invariant TSC the host CPU definition created
by virCPUx86GetHost will contain (unless probing fails for some reason)
addition TSC related data.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Commit 0a97486e moved them outside #ifdef, but after virCPUx86GetHost,
which will start calling them in the following patch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

This patch adds a new

    <counter name='tsc' frequency='N' scaling='on|off'/>

element into the host CPU capabilities XML.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

On a KVM x86_64 host which supports invariant TSC this function can be
used to detect the TSC frequency and the availability of TSC scaling.

The magic MSR numbers required to check if VMX scaling is supported on
the host are documented in Volume 3 of the Intel® 64 and IA-32
Architectures Software Developer’s Manual.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The qemuTestParseCapabilitiesArch call would eventually lead to the host
CPU being probed via virCPUGetHost. Let's divert this to a mocked
version already used by the qemuxml2argvtest.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The function is renamed as virQEMUCapsProbeHostCPU and it does not get
the list of allowed CPU models from qemuCaps anymore. This is
responsibility is moved to the caller. The result is just a very thin
wrapper around virCPUGetHost mostly required mocking in tests.

The generic function is used in place of a direct call to virCPUGetHost
in virQEMUCapsInitHostCPUModel to make sure tests don't accidentally
probe host CPU.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

Turns out, some aarch64 systems have SMBIOS info. That means we
can use dmidecode to fetch some information. If that fails, fall
back to the old behaviour.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

There's nothing x86 specific about this function. Rename the
function so that it has DMI suffix which enables it to be reused
on different arches (as using X86 from say ARM would look
suspicious).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This test case uses (anonimized) data pulled from a
GIGABYTE R120-T34 server.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

We have a single mock dmidecode script right now, but we're
going to add another one soon, so we need to make sure its
name contains the test case name as a prefix, just like we
already do with all data files.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1575526Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

All current IOMMU features are specific to Intel IOMMU, so
understandably we check for the corresponding capabilities
inside the Intel-specific switch() branch; however, we want
to make sure SMMUv3 IOMMU users get an error if they try to
enable any of those features in their guest, and performing
the capability checks unconditionally is both the easiest
way to achieve that, as well as the one least likely to
result in us inadvertently letting users enable some new
Intel-specific IOMMU feature for ARM guests later on.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

SMMUv3 is an IOMMU implementation for ARM virt guests.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This capability can be used to figure out whether the
QEMU binary at hand supports the machine type property
we need in order to enable SMMUv3 IOMMU support.

Unfortunately we can't avoid probing the RISC-V binaries
along with the ARM ones, since both architectures have
their own 'virt' machine type.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Current capability checks are specific to Intel IOMMU, so
we need to move them inside the switch() statement before
we can introduce more virDomainIOMMUModel values.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This doesn't make a whole lot of difference now, but once
we introduce more virDomainIOMMUModel values the current
structure will no longer work.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>