The documentation could confuse people to expect that CPU models with
usable='no' attribute are not usable at all on the current host. But
they cannot be only used without explicitly disabling some features.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The daemons are not supported on Win32 and therefore were not compiled
in that platform. However, with the daemon code sharing, all the code in
utils *is* compiled and it failed because `waitpid`, `fork`, and
`setsid` are not available. So, as before, let's not build them on
Win32 and make the code more portable by using existing vir* wrappers.
Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This new template provides a standardized place where environment
variables which are not static, but rather depend on the output of
some shell command, can be defined for later use. This pattern is
already used in libosinfo's GitLab CI integration.

Defining $MAKEFLAGS there means we don't need to call getconf over
and over, and the actual build steps don't end up drowned in the
noise.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NChristian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The aim was to break a long line, but it is not long anymore.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The last usage of plain fork() was removed in v0.9.7-rc1~50, but
we forgot to update the syntax-check exemption list accordingly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Several daemons have similar code around general daemon startup code.
Let's move it into a file and share it among them.
Signed-off-by: NRafael Fonseca <r4f4rfs@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

If the DCO check is run on an empty branch (ie one which has no commits
different from master), it throws an error due to trying to interpret
the empty string as a git commit SHA.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The quotes are forbidden only inside the value, but the value itself may
be enclosed in quotes. Fix the RNG schema and validator and add a test
case.

https://bugzilla.redhat.com/show_bug.cgi?id=1804750Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

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

The "only: branches" does not in fact exclude "master", so it must be
excluded explicitly.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Running the code style syntax-check as part of the build jobs leads to
all jobs failing in the same way. Have a prebuild job for validating
syntax-check to catch code style problems upfront and thus avoid needing
to run all the build jobs.
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>a
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This introduces a CI job for validating DCO sign-off in every commit
message. The CI jobs are not provided any information on what the
baseline commit for the branch was. We can't compare against the forked
repo's master branch, as there's no guarantee the user is keeping master
up2date in their fork. Thus we add the master upstream repo as a git
remote and identify the common ancestor.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

For any given job there is a high likelihood that ccache will be able to
reuse previously built object files. This will result in faster build
pipelines in later updates.
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Whenever there is a change to the translatable strings we need to push
a new libvirt.pot to weblate. This only needs to be done when code
merges into git master, so the job is restricted to that branch.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This patch adds x86_64 native CI jobs for all distros that we currently
build container images for. This is a superset of the Linux jobs run on
current Jenkins and Travis platforms.

The remaining missing platforms are FreeBSD and macOS, neither of which
can use the shared runner container based infrastructure.

We may add further native jobs in the future which are not x86_64 based,
if we get access to suitable hardware, thus the jobs all have an arch
prefix in their name, just like the cross-built jobs do.

As with the cross-arch builds, the native jobs are split into two
groups. One group is run in all situations, while the other group is
only run on the master branch, or branches with a name prefix
'ci-full-'. This avoids the build time getting too long when
developers are testing their code prior to submission, while keeping
full coverage of code that is merged.
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This pulls in the mingw cross build jobs using Fedora 30 as a base,
matching what is done on Jenkins and Travis.
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The pipeline UI will truncate the names of jobs after about 15
characters. As a result with the cross-builds, we truncate the
most important part of the job name. Putting the most important
part first is robust against truncation, and we can drop the
redundant "-cross" stub.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <skultety.erik@gmail.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Currently we have nine different cross build jobs, but as we introduce
more native jobs this is going to result in a very long CI execution
time. For developers testing their personal branches under development
it is generally sufficient to just look at a couple of interesting
scenarios, namely 32-bit and big endian.

This splits the cross build jobs so that by default only the armv7
and s390x archs are built. The remainining archs are setup so that they
are only built for code on the master branch, which will have the effect
of doing post-merge testing. Developers can opt-in to full testing of
their pre-merge code by pushing it to a branch with a name prefix of
"ci-full-".
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Run the bare minimum build that is possible to create the docs, avoiding
compiling code which other jobs will deal with.

The generated website is published as an artifact and thus is browsable
by developers on build completion and can be downloaded as a zip file.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

As we introduce more build jobs, it will be useful to have a grouping of
jobs to more easily visualize the results and potentially control build
ordering.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

We don't need the full git history when running CI jobs. From a code POV
we only need the most recent commit, but we want to be able to run
checks on the commits too. In particular to validate the DCO signoff for
each commit.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

To facilitate future jobs that will use FreeBSD
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Commit 5540acb9 added a minimum size verification for the target
size of ppc64 NVDIMMs but forgot to remove a MAX() size check that
was being used in earlier reviews of that commit. The size
verification makes this check unneeded since we're making sure
that guestArea will always be at least equal to ppc64AlignSize.

Fixes: 5540acb9Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This is the only instance of g_autofree change applicable for
qemu_agent.c
Signed-off-by: NSeeteena Thoufeek <s1seetee@linux.vnet.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This fixes a FreeBSD build error from

  commit a11a0e6e
  Author: Rafael Fonseca <r4f4rfs@gmail.com>
  Date:   Tue Mar 24 17:14:30 2020 +0100

    bhyve: move video default logic to driver
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Move the liveness check prior to the capability check. If the VM is
offline the capabilities are not initialized and thus we'd report the
wrong error.

https://bugzilla.redhat.com/show_bug.cgi?id=1812531Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

The code attempting to clean up after a failed pull mode backup job
wrongly entered monitor but didn't clean up nor exit monitor due to a
logic bug. Fix the condition.

Introduced in a1521f84

https://bugzilla.redhat.com/show_bug.cgi?id=1817327Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Move the liveness check prior to the capability check. If the VM is
offline the capabilities are not initialized and thus we'd report the
wrong error.

https://bugzilla.redhat.com/show_bug.cgi?id=1812531Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NHan Han <hhan@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Host-model CPU definitions (and domain capabilities) will use the
original CPU models (without noTSX in their name) and explicitly disable
hle and rtm features. This way domains with host-model CPUs will be
migratable even to older versions of libvirt which do not support the
noTSX model variants.

The new models will be advertised in host capabilities and they may
be used explicitly with custom CPUs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Tested-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Tested-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

The element specifies whether a particular CPU model can be used when
creating a CPU definition from raw CPUID/MSR data. The @host attribute
determines whether the CPU model can be used (host='on') for creating
CPU definition for host capabilities. Usability of the model for domain
capabilities and host-model CPU definitions is controlled by the @guest
attribute.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Tested-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>

One of the mitigation methods for TAA[1] is to disable TSX
support on the host system.  Linux added a mechanism to disable
TSX globally through the kernel command line, and many Linux
distributions now default to tsx=off.  This makes existing CPU
models that have HLE and RTM enabled not usable anymore.

Add new versions of all CPU models that have the HLE and RTM
features enabled, that can be used when TSX is disabled in the
host system.

On systems disabling the features without those types defined
in cpu-maps users end up without modern CPU types in the list
of usable CPUs to use in the likes of virsh domcapabilities
or tools higher in the stack like virt-manager.

This adds:
-Cascadelake-Server-noTSX
-Icelake-Client-noTSX
-Icelake-Server-noTSX
-Skylake-Server-noTSX-IBRS
-Skylake-Client-noTSX-IBRS

Introduced in QEMU by commit v4.2.0-rc2-3-g9ab2237f19 (function)
                  and commit v4.2.0-rc2-4-g02fa60d101 (names)

References:

    [1] TAA, TSX asynchronous Abort:
        https://software.intel.com/security-software-guidance/insights/deep-dive-intel-transactional-synchronization-extensions-intel-tsx-asynchronous-abort
        https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/tsx_async_abort.html

Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1853200Signed-off-by: NChristian Ehrhardt <christian.ehrhardt@canonical.com>
Message-Id: <20200310104806.2723-2-christian.ehrhardt@canonical.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The PMU feature is enabled by default in ppc64 guests and can't
be disabled via Libvirt or QEMU [1]. The current PMU feature
implementation does not allow PMU to enabled or disabled in the
ppc64 guest. Declaring the PMU feature will make the 'pmu'
property to be passed on to QEMU, but this property isn't
available for ppc64:

qemu-kvm: can't apply global host-powerpc64-cpu.pmu=on: Property '.pmu' not found

A similar error is thrown when trying to disable the PMU.

This patch standardizes the PMU handling for ppc64 guests by:

- throwing an error if the user attempts to set the feature to
'off', given that this feature can't be turned off at all;

- allowing the feature to be declared as 'on' in the domain XML.
This is done by skipping ppc64 guests when creating the command
line for this feature.

[1] https://www.redhat.com/archives/libvir-list/2020-March/msg00874.htmlSigned-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Hyperv features are supported by both x86 and aarch64. The <hyperv/>
declaration in the XML by itself is benign to other architectures,
but any of its 14 current features will break QEMU with an error
like this (from ppc64):

qemu-kvm: Expected key=value format, found hv_relaxed

This is a more extreme case than the one for apic eoi because we
would need an extra 'switch' statement, with all current Hyperv
features in the body of qemuDomainDefValidateFeatures(), to
check if the user attempted to activate any of them. It's easier to
simply fail to launch with any 'hyperv' declaration in the XML for
every arch which is not x86 and aarch64.

A fair disclaimer about Windows and PowerPC: the last Windows version
that ran in the architecture is the hall of famer Windows NT 4.0,
launched in 1996 and with end of extended support for the Server
version in 2004 [1]. I am acknowledging that there might be Windows
NT 4.0 users running in PowerPC, but not enough people running it
under KVM/QEMU to justify Libvirt allowing 'hyperv' to exist in the
domain XML of ppc64 domains.

[1] https://en.wikipedia.org/wiki/Windows_NT_4.0Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

The 'pvspinlock' feature is x86 only. The "<pvspinlock/>" declaration
will always have a value 'on' or 'off', and both will break QEMU when
launching non-x86 guests. This is the error message for
"<pvspinlock state='on'/>" when running a ppc64 guest:

qemu-kvm: Expected key=value format, found +kvm_pv_unhalt

A similar error message is thrown for "<pvspinlock state='off'/>".

This patch prevents non-x86 guests from launching with any
pvspinlock setting with a more informative error message:

error: unsupported configuration: The 'pvspinlock' feature is not
supported for architecture 'ppc64' or machine type 'pseries'
Signed-off-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>