Introduce two utility functions to parse a kernel command
line string according to the kernel code parsing rules in
order to enable the caller to perform operations such as
verifying whether certain argument=value combinations are
present or retrieving an argument's value.
Signed-off-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

This was mostly boilerplate conversion, but in one case I needed to
define several differently named char* to take the place of a single
char *tmp that was re-used multiple times, and in another place there
was a single char* that was used at the toplevel of the function, and
then later used repeatedly inside a for loop, so I defined a new
separate char* inside the loop.
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Now that we have support for IPv6 in the iptables helpers, and a new
option in the XML schema, we can wire up support for it in the network
driver.
Reviewed-by: NLaine Stump <laine@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Historically IPv6 did not support NAT, so when IPv6 was added to
libvirt's virtual networks, when requesting <forward mode="nat"/>
libvirt will NOT apply NAT to IPv6 traffic, only IPv4 traffic.

This is an annoying historical design decision as it means we
cannot enable IPv6 automatically. We thus need to introduce a
new attribute

   <forward mode="nat">
     <nat ipv6="yes"/>
   </forward>
Reviewed-by: NLaine Stump <laine@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

IPv6 does support masquerade since Linux 3.9.0 / ip6tables 1.4.18,
which is Fedora 18 / RHEL-7 vintage, which covers all our supported
Linux versions.
Reviewed-by: NLaine Stump <laine@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

In v6.4.0-rc1~143 I've introduced a check that is supposed to
return from the function early, if given path is not a dm target.
While the idea is still valid, the implementation had a flaw.
It calls stat() over given path and the uses major(sb.st_dev) to
learn the major of the device. This is then passed to
dm_is_dm_major() which returns true or false depending whether
the device is under devmapper's control or not.

The problem with this approach is in how the major of the device
is obtained - paths managed by devmapper are special files and
thus we want to be using st_rdev instead of st_dev to obtain the
major number. Well, that's what virIsDevMapperDevice() does
already so might as well us that.

Fixes: 01626c66
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1839992Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

When introducing virdevmapper.c (in v4.3.0-rc1~427) I didn't
realize there is a function that calls in devmapper. The function
is called virIsDevMapperDevice() and lives in virutil.c. Now that
we have a special file for handling devmapper move it there.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The repository is now obsolete, and it never had proper GitLab CI
support anyway.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

There are many different settings that required to config a KVM guest
for real time, low latency workoads. The documentation included here is
based on guidance developed & tested by the Red Hat KVM real time team.
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Compilers are not very good at detecting this problem. Fixed by manual
inspection of compilation warnings after replacing 'VIR_FREE' with an
empty macro.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com

If one of the early checks to get screen resolution fails 'screenData'
would be passed to VIR_FREE uninitialized. Unfortunately the compiler
isn't able to detect this when VIR_FREE is implemented using
g_clear_pointer.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com

'uri_out' may be passed to VIR_FREE uninitialized if 'conn' is NULL.
Unfortunately the compiler isn't able to detect this problem when
VIR_FREE is implemented using g_clear_pointer. Initialize the variable.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com

Use VIR_FREE directly.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com

Use g_free directly to free the returned pointer from
virTestLogContentAndReset rather than store it in a temp variable which
was necessary when we only allowed VIR_FREE.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com

The path is formatted but then just freed without any use since
introduction of the test function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com

We can free 'def->name' directly.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com

Debian sid is currently broken on mipsel, so use Debian 10 for
that architecture; at the same time, move the ppc64le build from
Debian 10 to Debian sid to keep things balanced.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

The ci-* targets need to know where our container images are stored
and how they are called to work, so now that we use the GitLab
container registry instead of Quay some changes are necessary.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Instead of using pre-built containers hosted on Quay, build
containers as part of the GitLab CI pipeline and upload them to the
GitLab container registry for later use.

This will not significantly slow down builds, because containers are
only rebuilt when the corresponding Dockerfile has been modified.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This removes a lot of repetition and makes the configuration much
easier to read.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This needs to be set for every repository for Cirrus CI integration
to work.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NYi Li <yili@winhong.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Right now we're dividing the jobs into three stages: prebuild, which
includes DCO checking as well as building artifacts such as the
website, and native_build/cross_build, which do exactly what you'd
expect based on their names.

This organization is nice from the logical point of view, but results
in poor utilization of the available CI resources: in particular, the
fact that cross_build jobs can only start after all native_build jobs
have finished means that if even a single one of the latter takes a
bit longer the pipeline will stall, and with native builds taking
anywhere from less than 10 minutes to more than 20, this happens all
the time.

Building artifacts in a separate pipeline stage also doesn't have any
advantages, and only delays further stages by a couple of minutes.
The only job that really makes sense in its own stage is the DCO
check, because it's extremely fast (less than 1 minute) and, if that
fails, we can avoid kicking off all other jobs.

Reducing the number of stages results in significant speedups:
specifically, going from three stages to two stages reduces the
overall completion time for a full CI pipeline from ~45 minutes[1]
to ~30 minutes[2].

[1] https://gitlab.com/abologna/libvirt/-/pipelines/154751893
[2] https://gitlab.com/abologna/libvirt/-/pipelines/154771173Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This is pretty straightforward and self explanatory.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1837990Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

For the case where -fw_cfg uses a file, we need to set the
seclabels on it to allow QEMU the access. While QEMU allows
writing into the file (if specified on the command line), so far
we are enabling reading only and thus we can use read only label
(in case of SELinux).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

This capability tracks whether QEMU supports -fw_cfg command line
option, more specifically whether it allows specifying filename.

There are some releases of QEMU which support -fw_cfg but not
filename. If this is ever a problem we can refine the capability
later on.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

There are recommendations and limitations to the name of the
config blobs we need to follow [1].

We don't want users to change any value only add new blobs. This
means, that the name must have "opt/" prefix and at the same time
must not begin with "opt/ovmf" nor "opt/org.qemu" as these are
reserved for OVMF or QEMU respectively.

1: docs/specs/fw_cfg.txt from qemu.git
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

QEMU has -fw_cfg which allows users to tweak how firmware
configures itself and/or provide new configuration blobs.
Introduce new <sysinfo/> type "fwcfg" that will hold these
new blobs.

It's possible to either specify new value as a string or
provide a filename which contents then serve as the value.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Setting OEM strings for a domain was introduced in
v4.1.0-rc1~315. However, any application that wanted to use them
(e.g. to point to an URL where a config file is stored) had to
'dmidecode -u --oem-string N' (where N is index of the string).
Well, we can expose them under our <sysinfo/> XML and if the
domain is running Libvirt inside it can be obtained using
virConnectGetSysinfo() API.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Since nobody sets custom dmidecode path anymore, we can drop all
code that exists only because of that.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Problem with custom dmidecode scripts is that they are hard to
modify, especially if we will want them to act differently based
on passed arguments. So far, we have two scripts which do no more
than 'cat $sysinfo' where $sysinfo is saved dmidecode output.

The virCommandSetDryRun() can be used to trick
virSysinfoReadDMI() thinking it executed real dmidecode.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

There is no real need to have two separate functions. They can be
merged together which not only saves couple of lines, but
prepares the structure of the code for future expansion. See next
commits.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Some variables defined in the function can be freed
automatically when going out of scope. This renders @result
variable and cleanup label needless.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

When trying to decode DMI table, just before constructing
virCommand() the decoder is looked for in PATH using
virFindFileInPath(). Well, this is not necessary because
virCommandRun() will do this too (in virExec()).
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Virtually every variable defined in the function can be freed
automatically when going out of scope.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Since we now use Cirrus CI for macOS jobs, we no longer need to
keep Travis CI around.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

We use cirrus-run to trigger Cirrus CI jobs from GitLab CI jobs,
making it possible to extend our platform coverage to include
FreeBSD without having to maintain our own runners; additionally,
we'll be able to ditch Travis CI and, since results for Cirrus CI
jobs are reflected back to the GitLab CI jobs that triggered them,
we will be able to get all information from a single dashboard.

The FreeBSD and macOS job definitions can be improved further: for
example, we will want to enable caching to speed up builds, and
ultimately we should figure out a way to generate at least part of
them, notably the list of packages to be installed, using lcitool.
All of that will happen in later patches: for now, this is good
enough to start using Cirrus CI.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>