It may happen that xenlight pkgconfig file does not contain
'xenfirmwaredir' and/or 'libexec_bin' variables, which is okay
and we have code that deals with this situation. But that code is
executed when the queried value is an empty string. This may not
always be the case and we should specifically set 'default_value'
so that the empty string is returned if pkgconfig variable
doesn't exist.
Fixes: 968479adcf
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The BPF_CGROUP_DEVICE constant was introduced to Linux in
commit ebc614f687369f9df99828572b1d85a7c2de3d92
Author: Roman Gushchin <roman.gushchin@linux.dev>
Date: Sun Nov 5 08:15:32 2017 -0500
bpf, cgroup: implement eBPF-based device controller for cgroup v2
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The BPF_PROG_QUERY constant was introduced to Linux in
commit defd9c476fa6b01b4eb5450452bfd202138decb7
Author: Alexei Starovoitov <ast@kernel.org>
Date: Mon Oct 2 22:50:26 2017 -0700
libbpf: sync bpf.h
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The VHOST_VSOCK_SET_GUEST_CID constant was introduced to Linux in
commit 433fc58e6bf2c8bd97e57153ed28e64fd78207b8
Author: Asias He <asias@redhat.com>
Date: Thu Jul 28 15:36:34 2016 +0100
VSOCK: Introduce vhost_vsock.ko
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The linux/magic.h header has existed since
commit e18fa700c9a31360bc8f193aa543b7ef7b39a06b
Author: Jeff Garzik <jeff@garzik.org>
Date: Sun Sep 24 11:13:19 2006 -0400
Move several *_SUPER_MAGIC symbols to include/linux/magic.h.
This is old enough that all our supported platforms can be assumed
to have this header.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The DEVLINK_CMD_ESWITCH_GET constant was introduced to Linux in
commit adf200f31c000d707e4afe238ed1d1199e0cce7c
Author: Jiri Pirko <jiri@mellanox.com>
Date: Thu Feb 9 15:54:33 2017 +0100
devlink: fix the name of eswitch commands
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The headers required by virnetdevbridge.c have all exited since
before Linux moved to git. It is sufficient to check for just
one of them in order to give an error message about needing
kernel headers installed.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The GET_VLAN_VID_CMD constant has existed since before Linux moved
to git.
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETHTOOL_GCOALESCE constant has existed since before Linux moved
to git.
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETHTOOL_GFEATURES constant was introduced to Linux in
commit 5455c6998d34dc983a8693500e4dffefc3682dc5
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue Feb 15 16:59:17 2011 +0000
net: Introduce new feature setting ops
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETH_FLAG_RXHASH constant was introduced to Linux in
commit b00fabb4020d17bda4bea59507e09fadf573088d
Author: stephen hemminger <shemminger@vyatta.com>
Date: Mon Mar 29 14:47:27 2010 +0000
netdev: ethtool RXHASH flag
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETH_FLAG_NTUPLE constant was introduced to Linux in
commit 15682bc488d4af8c9bb998844a94281025e0a333
Author: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Date: Wed Feb 10 20:03:05 2010 -0800
ethtool: Introduce n-tuple filter programming support
This is old enough that all our supported platforms can be assumed
to have this feature.
A typo in the existing condition "NTUBLE" instead of "NTUPLE" meant the
code was never enabled in the first place, which is an illustration of
why it is worth eliminating redundant conditional checks.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETH_FLAG_TXVLAN/RXVLAN constants were introduced to Linux in
commit d5dbda23804156ae6f35025ade5307a49d1db6d7
Author: Jesse Gross <jesse@nicira.com>
Date: Wed Oct 20 13:56:07 2010 +0000
ethtool: Add support for vlan accleration.
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETH_FLAG_LRO constant was introduced to Linux in
commit 3ae7c0b2e3747b50c3a6c63ebb67469e0a6b3203
Author: Jeff Garzik <jeff@garzik.org>
Date: Wed Aug 15 16:00:51 2007 -0700
[ETHTOOL]: Add ETHTOOL_[GS]FLAGS sub-ioctls
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETHTOOL_GFLAGS constant was introduced to Linux in
commit 3ae7c0b2e3747b50c3a6c63ebb67469e0a6b3203
Author: Jeff Garzik <jeff@garzik.org>
Date: Wed Aug 15 16:00:51 2007 -0700
[ETHTOOL]: Add ETHTOOL_[GS]FLAGS sub-ioctls
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETHTOOL_GGRO constant was introduced to Linux in
commit b240a0e5644eb817c4a397098a40e1ad42a615bc
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon Dec 15 23:44:31 2008 -0800
ethtool: Add GGRO and SGRO ops
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETHTOOL_GGSO constant was introduced to Linux in
commit 37c3185a02d4b85fbe134bf5204535405dd2c957
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jun 22 03:07:29 2006 -0700
[NET]: Added GSO toggle
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The unshare() syscall was introduced to Linux in
commit 2da436e00f9a5fdd0fb6b31e4b2b2ba82e8f5ab8
Author: JANAK DESAI <janak@us.ibm.com>
Date: Tue Feb 7 12:59:03 2006 -0800
[PATCH] unshare system call -v5: system call registration for i386
This is old enough that all our supported platforms can be assumed
to have this feature. Furthermore, the virprocess.c file was already
using unshare() with nothing more than a #ifdef __linux__ check.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The LO_FLAGS_AUTOCLEAR constant was introduced to Linux in
commit 96c5865559cee0f9cbc5173f3c949f6ce3525581
Author: David Woodhouse <dwmw2@infradead.org>
Date: Wed Feb 6 01:36:27 2008 -0800
Allow auto-destruction of loop devices
This is old enough that all our supported platforms can be assumed
to have this feature. For added fun this whole meson check was
semantically insane because EPOLL_CLOEXEC is not a valid arg
to unshare().
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The EPOLL_CLOEXEC constant was introduced to Linux in
commit a0998b50c3f0b8fdd265c63e0032f86ebe377dbf
Author: Ulrich Drepper <drepper@redhat.com>
Date: Wed Jul 23 21:29:27 2008 -0700
flag parameters: epoll_create
This is old enough that all our supported platforms can be assumed
to have this feature. For added fun this whole meson check was
semantically insane because EPOLL_CLOEXEC is not a valid arg
to unshare().
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The LOOP_CTL_GET_FREE constant was introduced to Linux in
commit 770fe30a46a12b6fb6b63fbe1737654d28e84844
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Sun Jul 31 22:08:04 2011 +0200
loop: add management interface for on-demand device allocation
This is old enough that all our supported platforms can be assumed
to have this feature. As a plus point, this meson check is going
to start failing with future GCC. It fails to set _GNU_SOURCE, thus
'unshare' is not defined by the header, and its relying on an
implicit function decl. For added fun this whole meson check was
semantically insane because LOOP_CTL_GET_FREE is not a valid arg
to unshare().
Fixes https://fedoraproject.org/wiki/Toolchain/PortingToModernC
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Bump the minimal required version to 0.56.0. Looking into our CI
this is the oldest version we install.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The get_pkgconfig_variable() method is deprecated in 0.56.0 and
we're recommended to use get_variable(pkgconfig : ...) instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The path() method is deprecated in 0.55.0 and we're recommended
to use full_path() instead. Interestingly, we were already doing
do in couple of places, but not all of them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The source_root() method is deprecated in 0.56.0 and we're
recommended to use project_source_root() instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The build_root() method is deprecated in 0.56.0 and we're
recommended to use project_build_root() instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
According to repology.org:
RHEL-8: 0.9.4
RHEL-9: 0.9.6
Debian 11: 0.9.5
openSUSE Leap 15.3: 0.8.7
Ubuntu 20.04: 0.9.3
And the rest of distros has something newer anyways. Requiring
0.8.1 or newer allows us to drop the terrible hack where we
rename functions at meson level using #define. Note, 0.8.0 is
the version of libssh where the rename happened. It also allows
us to stick with SHA-256 hash algorithm for public keys.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The bhyve driver still has some frames larger than 2048 bytes, so we
need to keep the limit as is.
The CI failure was masked by the Freebsd-13 failing for unrelated
reasons.
This reverts commit 46302172d4
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
After recent cleanups we can now restrict the maximum stack frame size
to 2k.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The sheepdog project is unmaintained, with last commit in 2018 and
numerous unanswered issues reported.
Remove the libvirt storage driver support for it to follow the removal
of the client support in qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
One specfile containing both native and mingw builds is the
new best practice for Fedora. This reduces the maint burden
and ensures the mingw packages don't fall behind.
Note this adds many more BuildRequires for anyone building
on Fedora, which will now need installing.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Released almost 5 years ago, gnutls-3.6.0 brings some important
features (which are utilized in next commit). Hence, require that
version at least.
Per repology, currently shipped versions are:
RHEL-8: 3.6.16
RHEL-9: 3.7.3
Debian 11: 3.7.1
Debian 12: 3.7.6
openSUSE Leap 15.3: 3.6.7
Ubuntu LTS 20.04: 3.6.13
Ubuntu LTS 22.04: 3.7.3
FreeBSD 12: 3.7.6
Fedora 34: 3.7.4
Fedora 35: 3.7.6
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We have our own implementation of setns() which was introduced in
v1.2.9-rc1~190 and extended afterwards. The reason was that back
in 2014 we were dealing with glibc that in some of its older
versions did not provide the function. Mostly for non-intel
arches. Nevertheless, glibc now offers the function for all
architectures we care about (aarch64 being the freshest
architecture where the function was introduced, in glibc-2.17).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This was originally introduced in c2fb8bfee3, reportedly to
support symbol versioning on Solaris; more recently, 30b301c6ea
ported it to meson.
Up until the previous commit this has resulted in passing
-M .../libvirt/build/src/libvirt.syms
to the linker on macOS, but the implementation of the -M option
on that platform's linker is literally
else if ( strcmp(arg, "-M") == 0 ) {
// FIX FIX
}
so in practice we've been providing an additional input file,
which the linker understandably ignores after printing a warning
since it's not in any format that it recognizes.
Considering that LLVM's linker, which is now used by default on
FreeBSD, supports the same --version-script option as the GNU
linker, that we have introduced special handling for macOS, and
that we don't target Solaris, we can simply drop the branch at
this point.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
macOS libraries don't support symbol versioning, so the only
result that we achieve by passing additional flags to the linker
is a bunch of messages like
ld: warning: ignoring file .../libvirt/build/src/libvirt.syms,
building for macOS-x86_64 but attempting to link with file built
for unknown-unsupported file format ( 0x23 0x20 0x57 0x41 ... )
being produced during the build.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Instead of creating an empty object and then setting keys one
at a time, it is possible to pass a dict object to
configuration_data(). This is nicer because it doesn't require
repeating the name of the cfg_data object over and over.
There is one exception: the 'conf' object, where we store values
that are used directly by C code. In that case, using a dict
object is not feasible for two reasons: first of all, replacing
the set_quoted() calls would result in awkward code with a lot
of calls to format(); moreover, since code that modifies it is
sprinkled all over the place, refactoring it would probably
make things more complicated rather than simpler.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
libparted_dep is not used if -Dstorage_disk=disabled. Do not
bother looking for this library if the disk storage backend was
not requested.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
rbd_dep is not used if -Dstorage_rbd=disabled. Do not bother looking for
the libraries that compose it if the rbd storage backend was not requested.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This makes it possible to reduce the number of cases we have to
consider, because 'sles' declares itself to be like 'suse' and
both 'rhel' and 'centos' declare themselves to be like 'fedora'.
We have to move the check for Ubuntu before the one for Debian,
however, because 'ubuntu' declares itself to be like 'debian'
and it would end up with the wrong defaults otherwise.
Suggested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
I introduced support for these vim plugins several years ago
but have since moved away from them. These days developers
are likely better served by lsp-based tooling, which doesn't
require additional per-project configuration.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we have support for fuse-3 we can detect it during the
configure phase. Even better, we can detect fuse-3 first and
fallback to old fuse only if the newer version doesn't exist.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The current implementation of the workaround for yajl's broken
pkg-config file accidentally overwrites the value of includedir
that is later used by the installation process. Rename the
local variable to avoid this issue.
Fixes: c97075e1e4
Closes: https://gitlab.com/libvirt/libvirt/-/issues/271
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
If the user has already provided us with the configuration they
want, there's no point in trying to come up with a reasonable
OS-specific default.
Suggested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Or that neither is. The current implementation, where if only
one of the two is provided the other one will be based on
OS-specific defaults is more likely to cause confusion than it
is to be helpful.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
QEMU might not be installed on the build system, in which case
the user and group will not be present. We should avoid falling
back to root:root in that case, and assume the user and group
are going to be present in the target system instead.
Suggested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
It might be part of some non-mandatory package on certain
distros, and our logic deals just fine with its contents not
being available.
Fixes: 4c69d64efa
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
An update to meson 0.61.1 meant that it started showing warnings due to the fact
that the default for run_command's 'check' parameter is going to change. It
unveiled the fact that we were even missing that parameter in some calls where
we expected different outcome. To make sure the behaviour does not change
specify the parameter explicitly. In places where we check for the return code
the parameter should be 'false' so that meson does not fail. In all other cases
the parameter should be set to 'true' to make sure possible failure also stops
meson.
The warning in meson was added in https://github.com/mesonbuild/meson/pull/9304
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
While it's true that our virCommand subsystem is happy with
non-absolute paths, the dnsmasq capability code is not. It stores
the path to dnsmasq within and makes it accessible via
dnsmasqCapsGetBinaryPath(). While strictly speaking no caller
necessarily needs canonicalized path, let's find dnsmasq once and
cache the result.
Therefore, when constructing the capabilities structure look up
the binary path. If DNSMASQ already contains an absolute path
then virFindFileInPath() will simply return a copy.
With this code in place, the virFileIsExecutable() check can be
removed from dnsmasqCapsRefreshInternal() because
virFindFileInPath() already made sure the binary is executable.
But introducing virFindFileInPath() means we have to mock it in
test suite because dnsmasqCaps are created in
networkxml2conftest.
Moreover, we don't need to check for dnsmasq in configure.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Detect these commands in docs/meson.build, i.e. only when
users enable documentation.
Signed-off-by: Ivan Teterevkov <ivan.teterevkov@nutanix.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Meson reports
WARNING: pkgconfig variable 'cflags' not defined for dependency yajl.
which makes sense, because "cflags" is not one of the variables
reported by
$ pkg-config --print-variables yajl
and
$ pkg-config --variable=cflags yajl
doesn't work either.
The breakage was introduced when we switched from calling
pkg-config directly to using get_pkgconfig_variable() in 7.5.0
and, somehow, it went undetected until now.
Use "includedir", which is a proper pkg-config variable,
instead.
Fixes: c32c5ca29a
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
We no longer use them anywhere.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We need libparted to be available at build time otherwise we
can't link against it; we don't, however, need the parted
command to be present until runtime and, just as is the case
for other commands, we already perform a lookup through the
virCommand API so making sure it's available at build time
is unnecessary.
This doesn't make any difference for platform such as Fedora
and CentOS, where both the library and the command are in the
same package, but others like Debian, Ubuntu and openSUSE
have separate packages for the two components and this change
means that we can install one less package at build time.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
If remote driver was disabled there is no need to check whether
host has a XDR library installed.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/196
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The way our wireshark dissector works is by providing decoders
for primitive types (like integers, string, double, etc.) and
then parsing virsomethingprotocol.x files and generating complex
decoders for RPC. This obviously means that XDR is required for
the dissector, but corresponding check was missing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The Homebrew package explicitly enables this driver despite us
disabling it by default on macOS, so it must be functional to
at least some extent and certainly can't be causing any build
failures.
Additionally, if the user has explicitly asked for the network
driver to be enabled but libvirtd is disabled for whatever
reason, we should error out instead of silently disabling the
network driver.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The cpuset_getaffinity() function is checked in sys/cpuset.h to see if
BSD CPU affinity APIs are available. This check requires including
sys/param.h to work properly, otherwise the test program fails with
unrelated errors like:
/usr/include/sys/cpuset.h:155:1: error: unknown type name
'__BEGIN_DECLS'
__BEGIN_DECLS
^
/usr/include/sys/cpuset.h:156:12: error: unknown type name 'cpusetid_t';
did you mean 'cpuset_t'?
int cpuset(cpusetid_t *);
and so forth.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Recently, FreeBSD has got sched_get/setaffinity(3) implementations and
the sched.h header as well [1]. To make these routines visible,
users have to define _WITH_CPU_SET_T.
This breaks current detection. Specifically, meson sees the
sched_getaffinity() symbol and defines WITH_SCHED_GETAFFINITY. This
define unlocks Linux implementation of virProcessSetAffinity() and other
functions, which fails to build on FreeBSD because cpu_set_t is not
visible as _WITH_CPU_SET_T is not defined.
For now, change detection to the following:
- Instead of checking sched_getaffinity(), check if 'cpu_set_t' is
available through sched.h
- Explicitly check the sched.h header instead of assuming its presence
if WITH_SCHED_SETSCHEDULER is defined
1:
https://cgit.freebsd.org/src/commit/?id=43736b71dd051212d5c55be9fa21c45993017fbbhttps://cgit.freebsd.org/src/commit/?id=160b4b922b6021848b6b48afc894d16b879b7af2https://cgit.freebsd.org/src/commit/?id=90fa9705d5cd29cf11c5dc7319299788dec2546a
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
There is no guarantee that QEMU and libvirt have been configured
with the same prefix.
In particular, Homebrew on macOS will pass a different, private
prefix for each package version and then use symlinks to make
the files for a specific version appear in the usual locations.
This works perfectly fine as long as one package doesn't try to
go poking around another package's data - which is exactly what
libvirt needs to do in order to read and parse the QEMU interop
data.
qemu_datadir can now be explicitly provided to make this and
other uncommon scenarios work. The common scenario, where QEMU
and libvirt both use the same prefix, is unaffected.
https://gitlab.com/libvirt/libvirt/-/issues/168
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can't hardcode /usr here, because the user might have
configured whatever arbitrary prefix.
Everything appeared to be okay because when joining paths
Meson will drop any component that precedes an absolute path
and libdir happens to be absolute, but we should still do
things correctly instead of relying on this.
Fixes: 2ad009eadd
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
At this point, we're no longer using the availability of the
ZFS programs at build time to decide whether to enable ZFS
support, so the only purpose of these find_program() calls is
to record their absolute paths.
However, the virCommand facilities that we're ultimately using
to run them are already capable of performing this lookup at
runtime, and in fact that's exactly what we already do in the
case of, for example, vstorage.
Drop the build time lookups and always perform them at runtime.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Commit 73a2ff3616 already improved the situation a lot. This
pushes things even further.
If the user or, more likely, the distro packager explicitly
asked for ZFS support to be enabled, then we should comply with
that request regardless of whether the necessary programs are
available at build time.
This is particularly important in the context of Debian, where
ZFS cannot be a build dependency of libvirt due to licensing
issues but it can still be an optional runtime dependency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
The first part of the version string contains the name that the
rst2html5 command was invoked as, which can differ based on the
operating system: on FreeBSD, for example, it's rst2html5.py
instead of just rst2html5.
Fix our detection logic so that it works regardless of the
specific name used for the docutils-provided rst2html5 command.
Fixes: cf0c9e1865
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
When building with "CC=clang", "-Db_sanitize=address,undefined", and
"-Dbuildtype=debug", the following error occurs:
../src/conf/nwfilter_conf.c:2190:1: error: stack frame size of 10616
bytes in function 'virNWFilterRuleDefFixup' [-Werror,-Wframe-larger-than=]
virNWFilterRuleDefFixup(virNWFilterRuleDef *rule)
^
1 error generated.
Enforcing stack frame only makes sense on normal builds when stack usage
is deterministic.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Currently, the ZFS storage backend is enabled only if both zfs
and zpool binaries were found during configure phase. This is not
consistent with our attempts to move dependencies on binaries
from compile to runtime. And also it is inconsistent with other
backends, e.g. vstorage.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now, that there is no user of $PROG_PATH macros the meson script
can be changed so that it doesn't set those macros. It's
redundant as $PROG macro contains the same value.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 345996c620 disabled the
-Wunused-but-set-variable warning on CLang, beacuse it warned
on variables that were unread, but we relied on the side effects
of their destructors.
Reinstate the warning now that all the occurrences have been fixed.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Clang has previously had trouble with G_DEFINE_AUTOPTR_CLEANUP_FUNC
generated code, thinking it was unused. We turn off -Wunused-function
to avoid tripping up on that with CLang.
New Clang has started having trouble with g_autoptr now too. In usage
scenarios where the variable is set, but never again read, it thinks
it is unused not realizing the destructor has useful side effects.
For this we have to skip -Wunused-but-set-variable on CLang.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
test-lib.sh needs these to be set.
Export them so that the virsh-* tests can be run using:
builddir$ ./run srcdir/tests/virsh-snapshot
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
When building with sanitizers on Fedora we get a wierd error
message
In file included from /usr/include/string.h:519,
from ../src/internal.h:28,
from ../src/util/virsocket.h:21,
from ../src/util/virsocketaddr.h:21,
from ../src/util/virnetdevip.h:21,
from ../src/util/virnetdevip.c:21:
In function ‘memcpy’,
inlined from ‘virNetDevGetifaddrsAddress’ at ../src/util/virnetdevip.c:702:13,
inlined from ‘virNetDevIPAddrGet’ at ../src/util/virnetdevip.c:754:16:
/usr/include/bits/string_fortified.h:29:10: error: ‘__builtin_memcpy’ offset [2, 27] from the object at ‘addr’ is out of the bounds of referenced subobject ‘ss_family’ with type ‘short unsigned int’ at offset 0 [-Werror=array-bounds]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/bits/socket.h:175,
from /usr/include/sys/socket.h:33,
from ../src/util/virsocket.h:66,
from ../src/util/virsocketaddr.h:21,
from ../src/util/virnetdevip.h:21,
from ../src/util/virnetdevip.c:21:
../src/util/virnetdevip.c: In function ‘virNetDevIPAddrGet’:
/usr/include/bits/socket.h:193:5: note: subobject ‘ss_family’ declared here
193 | __SOCKADDR_COMMON (ss_); /* Address family, etc. */
| ^~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
The code is correct, and this only happens when building at -O2.
The docs for -Warray-bounds say that a value of "2" is known to
be liable to generate false positives. Rather than downgrade the
check everywhere, we do it selectively for sanitizers.
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We have several other options that depend on result of `driver_remote`
option check so we need to do it early to have the result available.
Fixes: https://gitlab.com/libvirt/libvirt/-/issues/185
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When 'driver_remote' is 'auto', the 'enabled()' method does not
evaluate to true, causing the libssh/libssh2 checks to be skipped.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
With the traditional libvirtd, the virConnectOpen call will probe active
drivers server side to find which one to use when the URI is NULL/empty.
With the modular daemons though, the remote client does not know which
daemon to connect in the first place, so we can't rely on virConnectOpen
probing. Currently the virtproxyd daemon has code to probe for a
possible driver by looking at which sockets are listening or which
binaries are installed. The remote client can thus connect to virtproxyd
which in turn can connect to a real hypervisor driver.
The virtproxyd probing code though isn't something that needs to live in
virtproxyd. By moving it into the remote client we can get probing
client side in all scenarios and avoid the extra trip via virtproxyd in
the common case.
Tested-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Platforms supported by libvirt have the following Xen versions
openSUSE Leap 15.2: 4.13
openSUSE Leap 15.3: 4.14
Fedora 33: 4.14
Ubuntu 18.04: 4.9
Ubuntu 20.04: 4.11
Debian Stable: 4.11
Bumping the minimum version doesn't allow us to drop much code, but it
does provide better alignment with libvirt's platform support statement.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When enabling sanitizers, clang adds some function symbols when
instrumenting the code. The exact names of those functions are an
implementation detail and should therefore not be added to any
syms file. This patch prevents build failures due to those symbols
not present in the syms file when building with sanitizers enabled.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When enabling sanitizers, gcc adds some instrumentation to the code
that may enlarge stack frames. Some function's stack frames are already
close to the limit of 4096 and are enlarged past that threshold,
e.g. virLXCProcessStart which reaches a frame size of 4624 bytes.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We are already compiling libvirt with -Wvla - so it does not make
too much sense to still allow people to use alloca() instead. Thus
put it on the list of things we want to warn about. Fortunately,
there is currently no warning with this flag, so the current
sources should be clean.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The flag has a typo in it, it's "...-than=..." and not "...-then=...",
so this was in fact never used. Since we're also using -Wvla (without
size), we should already get warnings about any variable length arrays
anyway, so the additional "-Wvla-larger-than" does not make much sense
and thus we can simply drop this.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Cloud-Hypervisor is a KVM virtualization using hypervisor. It
functions similarly to qemu and the libvirt Cloud-Hypervisor driver
uses a very similar structure to the libvirt driver.
The biggest difference from the libvirt perspective is that the
"monitor" socket is seperated into two sockets one that commands are
issued to and one that events are notified from. The current
implementation only uses the command socket (running over a REST API
with json encoded data) with future changes to add support for the
event socket (to better handle shutdowns from inside the VM).
This patch adds support for the following initial VM actions using the
Cloud-Hypervsior API:
* vm.create
* vm.delete
* vm.boot
* vm.shutdown
* vm.reboot
* vm.pause
* vm.resume
To use the Cloud-Hypervisor driver, the v15.0 release of
Cloud-Hypervisor is required to be installed.
Some additional notes:
* The curl handle is persistent but not useful to detect ch process
shutdown/crash (a future patch will address this shortcoming)
* On a 64-bit host Cloud-Hypervisor needs to support PVH and so can
emulate 32-bit mode but it isn't fully tested (a 64-bit kernel and
32-bit userspace is fine, a 32-bit kernel isn't validated)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: William Douglas <william.douglas@intel.com>
These checks look different than most similar ones for no
particular reason.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
