Instead of simply dumping the list of authors as obtained
from git, we can be a bit smarter and filter out maintainers
so that their names don't appear twice.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We can't do this in general, but for maintainers we have
the data in AUTHORS.in to use as a source of truth.
This gets rid of several duplicated lines in the generated
AUTHORS file.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The basic mailmap syntax works for simple cases, but
sometimes it requires two entiries or doesn't work at all;
switch to the more complex syntax in those cases.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Based on which of the two files has been updated most
recently, and what name is used for recent commits.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
While technically correct (you have to send patches for
your name to appear on the list) the remark was clearly
intended for a time before AUTHORS was partially generated
from the git log.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
SASL authentication is configured server-side, so the sample
configuration file should be shipped along with the daemon
rather than with the libraries.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
This doesn't seem very useful at the moment, but it will make
sense once we introduce another HPT-related setting.
The output XML is decoupled from the input XML in preparation
of future changes as well; while doing so, we can shave a few
lines off the latter.
This commit is best viewed with 'git show -w'.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We're going to introduce a second HPT-related setting soon,
at which point using a single location to store everything is
no longer going to cut it.
This mostly, but not completely, reverts 3dd1eb3b26.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Since e6be524508 we include the executed command along
with the reply in *.replies files, which breaks the
renumbering logic implemented in qemucapsfixreplies.
Adapt the script so that it works with the new format.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We build on Fedora Rawhide, same as on the CentOS CI
environment.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we use pre-built Docker images, it's very easy
to extend our test matrix; adding CentOS 7 is a good start.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Instead of starting from the minimal Ubuntu 18.04 base
image and installing all requirements at build time,
use a Docker image that has been specifically tailored
at building libvirt and thus already includes all
required packages.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This will make further changes easier; all coverage
lost due to this will be reintroduced later on.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We already perform a full build as part of distcheck, so
we can speed things up a bit by skipping the first
compilation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Without a proper separator, all commands in the error path
end up being interpreted as a single command, which is not
what we want.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The new name is arguably more informative, especially now
that we have MACOS_CMD and knowing that MINGW_CMD will
be introduced later on.
We still use DOCKER_CMD when calling Docker, and we assign
the actual script on a per-image basis. Having this
separation will help us when we introduce MinGW builds.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It mirrors the existing DOCKER_CMD, both in how it's defined
as part of the environment and how it's called by passing it
directly to the shell.
In addition to making the configuration more consistent, this
also allows us to move from having the macOS build script
divided into four steps, some of which have slightly different
semantics and the relationship between which is not immediately
obvious without consulting the documentation, to a single
straightforward shell invocation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
All variable parts are taken from the environment, so we
can exploit inheritance and avoid duplication. This will
become more important as we start building on additional
platforms.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Upgrading takes quite a bit of time, doesn't offer any
real value and causes a lot of grief. Let's just skip it.
We need to install xz explicitly now, since it's required
to make dist and no longer being dragged in by Python 3.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Now that we have separate sections for each build
configuration, there's no reason to set PATH in the global
environment.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
numpy (needed by cgal) started having the same issue with
linking as python, which makes upgrade and thus the entire
build fail on macOS.
Instead of playing more tricks with linking/unlinking, just
uninstall the problematic packages (and those dragging them
in) before doing anything else.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Now that mocking NUMA information works on FreeBSD, there are
no longer any test cases that need to be restricted to Linux
only.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
While the current amount of mocking works just fine on most of
our target platforms, it somehow causes issues when using Clang
on FreeBSD.
Work around the issue by mocking a couple more functions. It's
not pretty, but it makes qemuxml2argvtest pass on FreeBSD at
long last.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
There are only a couple remaining issues preventing it from
working on FreeBSD. Let's fix them.
With the mocking in place, qemumemlocktest and qemuxml2xmltest
can finally succeed on FreeBSD.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Clang complains about it:
error: second argument to 'va_arg' is of promotable type
'mode_t' (aka 'unsigned short'); this va_arg has undefined
behavior because arguments will be promoted to 'int'
[-Werror,-Wvarargs]
mode = va_arg(ap, mode_t);
^~~~~~
Work around the issue by passing int to va_arg() and casting
its return value to mode_t afterwards.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We want to make sure our wrapper is used instead in order
to keep the test suite working.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We're using virFileCanonicalizePath() everywhere now, so
mocking this function has become entirely pointless.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The latter is impossible to mock on platforms that use the
gnulib implementation, such as FreeBSD, while the former
doesn't suffer from this limitation.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
It's a trivial wrapper around canonicalize_file_name(),
which we need in order to fully mock file access on non-Linux
platforms.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Even though we just introduced the rom.enabled attribute to
properly cover the use case, there might be guests out there
that use the only previously available way of disabling PCI
ROM loading by not opting in to schema validation.
To make sure such guests will keep working going forward,
introduce a test case covering the legacy workaround.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The attribute can be used to disable ROM loading completely
for a device.
This might be needed because, even when the guest is configured
such that the PCI ROM will not be loaded in the PCI BAR, some
hypervisors (eg. QEMU) might still make it available to the
guest in a form (eg. fw_cfg) that some firmwares (eg. SeaBIOS)
will consume, thus not achieving the desired result.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1425058
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The attribute can be used to disable ROM loading completely
for a device.
This might be needed because, even when the guest is configured
such that the PCI ROM will not be loaded in the PCI BAR, some
hypervisors (eg. QEMU) might still make it available to the
guest in a form (eg. fw_cfg) that some firmwares (eg. SeaBIOS)
will consume, thus not achieving the desired result.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The current private XML parsing code relies on the assumption
that NUMA node IDs start from 0 and are densely allocated,
neither of which is necessarily the case.
Change it so that the bitmap size is dynamically calculated by
looking at NUMA node IDs instead, which ensures all nodes will
be able to fit and thus the bitmap will be parsed successfully.
Update one of the test cases so that it would fail with the
previous approach, but passes with the new one.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1490158
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
vircapstest has code to add a full host NUMA topology, that
is, one that includes all information about nodes and CPUs
including IDs; testQemuCapsInit(), which is used to create a
mock virCapsPtr for QEMU tests, however, just fakes it by
setting nnumaCell_max to some number.
While the latter approach has served us well so far, we're
going to need all the information to be filled in soon. In
order to do that, we can just move the existing code from
vircapstest to testutils and, with some renaming and
trivial tweaking, use it as-is.
Interestingly, the NUMA topology generated by the function
is rigged up so that the NUMA nodes aren't (necessarily)
numbered starting from 0, which is a nice way to spot
mistaken assumptions in our codebase.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Up until now we have only formatted non-default GIC versions on
the command line, in order to maintain compatibility with older
QEMU versions that didn't implement the gic-version option to
begin with; however, doing so is entirely unnecessary for newer
QEMU versions, where the option is available. Moreover, having
the GIC version formatted on the command line at all times
ensures that QEMU changing its own defaults doesn't affect the
ABI of libvirt guests.
A few test cases are removed to avoid extra churn. It doesn't
matter for coverage, as those scenarios are already covered by
other parts of the test suite.
This patch is better viewed with 'git show -w'.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
I haven't been able to come up with a single scenario in which
the code in question would be executed; even if there was one,
it would be due to the user specifying a *partial* PCI topology
in the guest XML, which is of course entirely unsupportable and
thus providing even the slightest hint that doing so is in any
way a good idea is actively harmful.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Now that support for the pcie-to-pci-bridge controller has
been implemented, adding the QEMU_CAPS_DEVICE_PCIE_PCI_BRIDGE
capability to the existing test is enough to cause the guest
to use pcie-to-pci-bridge instead of dmi-to-pci-bridge.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Both pcie-to-pci-bridge and dmi-to-pci-bridge can be used to
create a traditional PCI topology in a pure PCIe guest such as
those using the x86_64/q35 or aarch64/virt machine type;
however, the former should be preferred, as it doesn't need to
obey limitation of real hardware and is completely
architecture-agnostic.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1520821
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Just like the existing areMultipleRootsSupported, this will
allow us to change the results of the driver-agnostic PCI
address allocation logic based on whether the QEMU binary
supports certain features.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The new controller will not yet be used automatically by
libvirt, but at this point it's already possible to configure
a guest to use it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This capability will be set when the pcie-pci-bridge device
is available in the QEMU binary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We're going to add a similarly-named attribute later, and we'd
like to be consistent.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This test shows what happens when you add a traditional PCI
device such as pci-serial to a pure PCIe machine type such
as aarch64/virt.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Instead of first listing the models on their own, and then
listing them again grouped by the libvirt release they were
introduced in, have a single list.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When GIC support was introduced (QEMU 2.6 timeframe) we needed
to make sure both GICv2 hardware and GICv3 hardware were handled
correctly, and that was achieved by having separate capabilities
data for each.
Now that we have capabilities data for several QEMU versions we
can stop storing data for GICv2 and GICv3 hardware separately,
and instead have GICv2 data for QEMU <= 2.10 and GICv3 data for
QEMU >= 2.12, without losing any coverage.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Test cases in qemucapabilitiestest are ordered by architecture
first, then by QEMU version. Use the same order here.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The QEMU binary is compiled from the v2.12.0-rc0 tag.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We're going to use the same test case to exercise all optional
pSeries features, so a more generic name is needed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
While RHEL / CentOS are still using Python 2 for the time being,
Fedora has already switched to Python 3 as the default Python
interpreter a while ago, so on that OS it doesn't make sense to
drag in Python 2 anymore.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
While RHEL / CentOS are still using Python 2 for the time being,
Fedora has already switched to Python 3 as the default Python
interpreter a while ago, so on that OS it doesn't make sense to
drag in Python 2 anymore; the same applies to future RHEL versions.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Our build process no longer depends on Python 2, so we can
finally allow Python 3 to satisfy our requirement for a Python
interpreter.
Since several distributions have now switched to installing
Python 3 by default and Python 2 is on its way out, prefer the
former when both are available.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Although it was never formally specified, it was always expected
that the mingw RPM build would happen on Fedora, if anything
because RHEL / CentOS don't ship the necessary mingw dependencies.
Make this fact explicit by erroring out if that's not the case,
the same way we already do in the main spec file.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Some of our scripts are known to work both with Python 2 and
Python 3, so for them we shouldn't be forcing any specific
version of the interpreter when they're called directly; we
always use $(PYTHON) explicitly in our build rules anyway.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The script already works perfectly fine with Python 2, but that's
more by chance than by design: we have a single occurrence of
print(), and it just so happens that its only argument is an
expression. Importing print_function makes the script more future,
err, past proof.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This deals with cls.version possibly being None.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We use text operations on the contents after reading them.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The keys() method no longer returns a list, so converting the
return value would be necessary before calling sort() on it;
alternatively, we can just call sorted(), which returns a
sorted list.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
For list concatenation to work, the value returned by the
keys() method must be converted to a list first.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
All of these have been replaced with methods.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
As of 2499d1a095 we don't link against libpolkit anymore, so
we only need the polkit package to be available during build.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Commit 596fc3e389 introduced the ability to detect xenstore
using pkg-config for systems with Xen 4.9, but accidentally broke
detection for all other systems. Fix the logic so that it works
in all cases.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
This is the only Python script which we invoke directly, which
works pretty fine in general but becomes a problem if the user
has explicitly overridden Python binary detection at configure
time.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This time around it's not enough to just pick the latest commit,
because with aed87bb2aa6ed83b49574eb982e3bdd4c36acf17 keycodemapdb
renamed the 'rfb' keycode to 'qnum' and we need to accept the new
name while maintaining backwards compatibility.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We've implemented all existing checks, and more, in the new
function, so we can finally drop the old one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
The existing function is renamed and called from the new one, so
that even while we're in the process of implementing new checks
all the existing ones will be performed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
Make sure we install the same packages lcitool would install on
the CentOS CI so that we have consistent results. The package
list is current as of libvirt-jenkins-ci commit ad84090b6f96.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This function was introduced in commit 41f5c2ca27 as a way
to probe the same property for multiple devices at once.
Although the resulting representation is very compact, it
doesn't provide any extra features compared to the existing
virQEMUCapsProcessStringFlags() mechanism, which is already
used for pretty much all device properties.
Drop the custom function and datatypes and start using the
standard ones instead.
Note that, in theory, the end result is not identical
because we're no longer probing properties for
virtio-serial-pci
virtio-9p-pci
virtio-rng-pci
virtio-input-host-pci
virtio-keyboard-pci
virtio-mouse-pci
virtio-tablet-pci
However, chances of any of those devices being compiled
into a QEMU binary where
virtio-balloon-pci
virtio-blk-pci
virtio-scsi-pci
virtio-net-pci
virtio-gpu-pci
are compiled out are slim enough that it doesn't make any
difference in practice, as the lack of test suite churn
shows.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
In some cases, we are probing multiple devices for the same
property and setting the corresponding capability if it's
found on any of the devices: when that happens, we can quit
early after finding the first property and avoiding a bunch
of string comparisons.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Andrea Bolognani