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>

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

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>

Ensure unexpected values are dealt with correctly, that
is by invoking virReportEnumRangeError() and immediately
returning a negative value to the caller.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

They were introduced by commit 0a97486e when moving functions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Apply renaming of 36603bc5 for the vz driver.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

If the scheduler is set before vCPU0 cannot be moved into its cpu,cpuacct
cgroup.  While it is not yet known whether this is a bug or not, it makes sense
for us to do that later as otherwise the scheduler would be inherited by vCPU
and I/O Threads even when they do not have any such setting specified.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Begins by writing a @start byte in the first position of @buffer and
then for every next byte it stores the value of its previous one
incremented by one.

Behaves the same for both supported flags.
Signed-off-by: NIlias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Fixes: 6864d8f7

Hugepages don't work in session mode but when building memory
part of command line we query for the default size anyway. This
breaks creating domains under session daemon. Query the page size
only if it's clear we need hugepages.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Caused by commit 326c3f54.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Apart from virDomainDefValidate, virDomainDefPostParse is another
place where operating on info-less devices makes sense.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Ignore @source in the case of the test driver and return fixed private
IPv4 addresses for all the interfaces defined in the domain.
Signed-off-by: NIlias Stamatis <stamatis.iliass@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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

Creating firewall rules for the virtual networks causes the kernel to
load the conntrack module. This imposes a significant performance
penalty on Linux network traffic. Thus we want to only take that hit if
we actually have virtual networks running.

We need to create global firewall rules during startup in order to
"upgrade" rules for any running networks created by older libvirt.
If no running networks are present though, we can safely delay setup
until the time we actually start a network.
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Pull the logic for creating global iptables chains into a separate
method and protect its invocation with virOnce, to make it possible
to reuse it in non-startup paths.
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Mostly add comments explaining why there are two capabilites
for the same feature and how they interact.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Device validation should not have to wait until command line
generation time. Moving the code to a separate function also
allows us to avoid some unnecessary repetition.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Rename the DOMAIN_DEVICE_ITERATE_GRAPHICS flag.
It was introduced by commit dd45c271
with the intention to run the Validate callback even on the graphics
device.

However, enumerating every single device in virDomainDeviceIterateFlags
is unsustainable and what really was special about the graphics device
was the lack of DeviceInfo.

Rename the flag and iterate over more info-less devices. (and leases)
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Due to the way that our virObjectUnref() is written it's not
possible that a NULL is passed into *Dispose() function. However,
some functions check for that regardless.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Split out the 'shallow' and 'reuse' flags as booleans rather than passing
in flags and constructing them in irrelevant APIs.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Split out the 'shallow' flag as a boolean argument rather than passing
in flags and constructing them in irrelevant APIs.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>