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=1641702
Signed-off-by: Jiri 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: Jiri Denemark <jdenemar@redhat.com>
Commit 0a97486e09 moved them outside #ifdef, but after virCPUx86GetHost,
which will start calling them in the following patch.
Signed-off-by: Jiri 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: Jiri 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: Jiri 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: Jiri 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: Jiri 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: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea 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: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This test case uses (anonimized) data pulled from a
GIGABYTE R120-T34 server.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal 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: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
SMMUv3 is an IOMMU implementation for ARM virt guests.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Já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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Já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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Já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: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Ensure unexpected values are dealt with correctly, that
is by invoking virReportEnumRangeError() and immediately
returning a negative value to the caller.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All other examples are organized using the either the format/
or the format/category/ hierarchy already, and grouping all
C programs together removes the last remaining outliers.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Now that all C examples are neatly sorted into only three
categories, getting rid of our custom installation machinery
and replacing it with the standard autotools mechanism
finally becomes feasible.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Most C examples live in their own directory, which seems a
bit unnecessary especially considering that all virt-admin
related examples share a single admin/ directory. Reorganize
non-admin C examples in two categories: domain/ for those
that act on a domain, and misc/ for everything else.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
The virt-lxc-convert shell script is at this point the
only example we don't install on the target system.
Create a sh/ subdirectory, following the example set by
the existing polkit/, systemtap/ and xml/, and move the
script there; then add rules that will install all example
shell scripts as documentation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Right now we install the files in RPMs only, and we include
them in the -daemon package which is probably not the best
option either. Start installing them via autotools; the RPMs
will get them automatically in the -docs package.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
We're doing nothing more than copying files to a target
directory, so we don't need any custom shell commands and
can just use the standard autotools data installation
support instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
$(mkinstalldirs) works like 'mkdir -p' in that it will
create all the necessary parts of the path leading up to
the actual directory, which means creating $(examplesdir)
beforehand is not necessary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
$(AM_CPPFLAGS) is for passing options to the C preprocessor,
not the C compiler, and the stuff in $(WARN_CFLAGS) belongs
to the latter category.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
$(LDADD) is for object files that should be added during
linking, not for options that should be passed to the
linker: that's what $(AM_LDFLAGS) is for.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
The C programs in this directory are supposed to be only
using public functions, so having $(top_srcdir) in the
header search path is unnecessary at best and actively
harmful at worst.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
$(WARN_CFLAGS) contains options intended for the compiler,
whereas $(LDADD) is supposed to list additional objects
required during linking, so the former clearly doesn't
belong in the latter.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
This will make further changes easier to review.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
$(AM_CPPFLAGS) already includes $(WARN_CFLAGS), so this is
not doing anything useful.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
We already install the file, along with its driver-specific
counterparts, into ${datadir}/libvirt/api/ where language
bindings will actually look for them.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
They were introduced by commit 0a97486e09 when moving functions.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Depending on the way ctags was compiled, it may look for
.ctags.d/*.ctags files rather than .ctags for reading configuration.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
One of the current SEV document links went dead as AMD moved the
resource to another place (document store), so there's probably very
little point in maintaining 3rd party links if the resources are being
moved.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
