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

Domains are now allowed to be pinned to host CPUs with IDs up to 16383.
The new limit is as arbitrary as the old one. It's just bigger.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Protected virtualization/IBM Secure Execution for Linux protects
guest memory and state from the host.

Add some basic information about technology and a brief guide
on setting up secure guests with libvirt.
Signed-off-by: NViktor Mihajlovski <mihajlov@linux.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Update document with changes in qemu capability caching and the added
secure guest support checking for AMD SEV in virt-host-validate.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Add checking in virt-host-validate for secure guest support
on x86 for AMD Secure Encrypted Virtualization.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Add checking in virt-host-validate for secure guest support
on s390 for IBM Secure Execution.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Tested-by: NViktor Mihajlovski <mihajlov@linux.ibm.com>
Reviewed-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Implement secure guest check for AMD SEV (Secure Encrypted
Virtualization) in order to invalidate the qemu capabilities
cache in case the availability of the feature changed.

For AMD SEV the verification consists of:
 - checking if /sys/module/kvm_amd/parameters/sev contains the
   value '1': meaning SEV is enabled in the host kernel;
 - checking if /dev/sev exists
Signed-off-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

This patch introduces a common function to verify if the
availability of the so-called Secure Guest feature on the host
has changed in order to invalidate the qemu capabilities cache.
It can be used as an entry point for verification on different
architectures.

For s390 the verification consists of:
- checking if /sys/firmware/uv is available: meaning the HW
facility is available and the host OS supports it;
- checking if the kernel cmdline contains 'prot_virt=1': meaning
the host OS wants to use the feature.

Whenever the availability of the feature does not match the secure
guest flag in the cache then libvirt will re-build it in order to
pick up the new set of capabilities available.
Signed-off-by: NPaulo de Rezende Pinatti <ppinatti@linux.ibm.com>
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Tested-by: NViktor Mihajlovski <mihajlov@linux.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

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>