A virtio device such as
<controller type='scsi' model='virtio-scsi'/>
will be translated to one of four different QEMU devices
based on the address type. This behavior is the same for
all virtio devices, but unfortunately we have separate
ad-hoc code dealing with each and every one of them: not
only this is pointless duplication, but it turns out
that most of that code is not robust against new address
types being introduced and some of it is outright buggy.
Introduce a new function, qemuBuildVirtioDevStr(), which
deals with the issue in a generic fashion, and rewrite
all existing code to use it.
This fixes a bunch of issues such as virtio-serial-pci
being used with virtio-mmio addresses and virtio-gpu
not being usable at all with virtio-mmio addresses.
It also introduces a couple of minor regressions,
namely no longer erroring out when attempting to
use virtio-balloon and virtio-input devices with
virtio-s390 addresses; that said, virtio-s390 has
been superseded by virtio-ccw such a long time ago
that recent QEMU releases have dropped support for
the former entirely, so re-implementing such
device-specific validation is not worth it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The appropriate time to ensure the required capabilities are
present is validate rather than command line generation: add
a new qemuDomainDeviceDefValidateInput() function and move
all existing checks there.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far we've only formatted it for virtio-blk-pci and
virtio-blk-ccw, but other virtio-blk devices also support
the corresponding option; moreover, we've always formatted
it for all virtio-scsi devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are several functions where we pointlessly duplicate
parts of the format string and pass the same arguments:
refactor them so that the common parts are formatted separately
from the variable parts.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
A few qemuxml2xml tests for virtio-input devices are
missing the capabilities used for the corresponding
qemuxml2argv tests: this wasn't a problem until now
because capabilities were only checked at command line
generation time, but we're going to change that later.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The new tests use DO_TEST_CAPS_ARCH_LATEST() with an input
XML describing a very simple headless guest and cover most
architectures and machine types we care about.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can add aarch64, ppc64 and riscv64 to the list of
supported architectures for the macro, since we have
capabilities data for all of them.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
virtio-serial is an alias for virtio-serial-pci, which
should not have been used for a PCIe-less aarch64/virt
guest but it ended up being used anyway because the
virtio-mmio capability was missing and the algorithm
is buggy.
Fix the test case so that we can fix the algorithm next.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's a single user for it which takes an existing
virPCIDeviceAddress, passes its various bits to the
function which in turn constructs a virPCIDevice and
then copies the string representation for the caller
to use: we can use virPCIDeviceAddressAsString()
instead and avoid creating the virPCIDevice in the
first place. Since the function ends up having no
users after the change, we can just drop it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The struct is called virPCIDeviceAddress and the
functions operating on it should be named accordingly.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
These are simple predicates, which makes bool a more
appropriate return type than int.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function is called on a virDomainDeviceInfo, so it
should be declared along with it.
Moving this function requires moving and making public
virDomainDeviceCCWAddressIsValid() as well, but that's
perfectly fine since the same reasoning above also
applies to it, due to virDomainDeviceCCWAddress being
(correctly) declared in device_conf.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's used in virDomainDeviceInfo, which makes
domain_conf the wrong place to declare it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We would have used virtio for networking anyway, but it's
better to be explicit; for graphics, none of the existing
models work right now but virtio is the only one which
has a non-PCI variant, so it's as good a default as any
Spotted-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
None of the existing models is suitable for use with
RISC-V virt guests, and we don't want information about
the serial console to be missing from the XML.
The name is based on comments in qemu/hw/riscv/virt.c:
RISC-V machine with 16550a UART and VirtIO MMIO
and in qemu/hw/char/serial.c:
QEMU 16550A UART emulation
along with the output of dmesg in the guest:
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
10000000.uart: ttyS0 at MMIO 0x10000000 (irq = 13,
base_baud= 230400) is a 16550A
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The architecture is new enough that we don't need to
concern ourselves with backwards compatibility in any
capacity.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Turn
virPCIDeviceAddressIsEmpty()
virDeviceInfoPCIAddressIsWanted()
virDeviceInfoPCIAddressIsPresent()
from inline functions to regular functions.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The affected functions are
virDeviceInfoPCIAddressWanted()
virDeviceInfoPCIAddressPresent()
which get renamed to
virDeviceInfoPCIAddressIsWanted()
virDeviceInfoPCIAddressIsPresent()
to comply with the naming convention used for other
predicates.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
With the current implementation, adding a new architecture
and not updating preferredMachines accordingly will not
cause a build failure, making it very likely that subtle
bugs will be introduced in the process. Rework the code
so that such issues will be caught by the compiler.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This proves libvirt can now handle high socket_id and
core_id values correctly and ensures we won't introduce
regressions in this area.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
While in most cases the values are going to be much
smaller than our arbitrary 4096 limit, there is really
no guarantee that would be the case: in fact, a few
aarch64 servers have been spotted in the wild with
core_id as high as 6216.
Take advantage of virBitmap's ability to automatically
alter its size at runtime to accomodate such values.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The latter are no longer used by libvirt, and the former
never were; moreover, both have a corresponding *_list
file which we can manipulate very conveniently using our
bitmap APIs, so dropping them makes sure in the future
developers will look into that rather than trying to
parse the kernel binary bitmaps.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We already have a function which parses
thread_siblings_list for a CPU and returns the
corresponding bitmap, and a bunch of utility functions
that perform operations on bitmaps such as counting
the number of set bits: use those to implement the
function instead of having an additional ad-hoc parser
for thread_siblings.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Some of the data dumps didn't include them; luckily,
we're not actually missing any information since we
can recreate them by looking at the corresponding
thread_sibilings files.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Most distributions we build RPMs on don't ship a
recent enough version of libiscsi, so we can't enable
the driver unconditionally. Add an explicit dependency
on the runtime package while at it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Commit 34a6962c41 added a BuildRequires for the
iscsi-direct backend, but we need the headers rather
than the runtime package to be available in order to
link against the library.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
If all we achieve is reducing the depth by one for a single
test case, the additional complexity (not to mention breaking
the principle of least surprise) is not worth it: let's use
simpler, more predictable code instead.
This basically reverts fec6e4c48c (with a few adjustments).
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Despite being standardized in POSIX.1-2008, the 'm'
sscanf() modifier is currently not available on FreeBSD.
Reimplement parsing without sscanf() to work around the
issue.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We finally get rid of the strncpy()-like semantics
and implement our own, more sensible ones instead.
As a bonus, this also fixes compilation on MinGW.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
We're going to change virStrncpy() in a way that
requires the source string to be NULL-terminated, so
we'll no longer be able to use in this context.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Currently, the functions return a pointer to the
destination buffer on success or NULL on failure.
Not only does this kind of error handling look quite
alien in the context of libvirt, where most functions
return zero on success and a negative int on failure,
but it's also somewhat pointless because unless there's
been a failure the returned pointer will be the same
one passed in by the user, thus offering no additional
value.
Change the functions so that they return an int
instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The strncpy() function has this quirk where it will copy
*up* to the requested number of bytes, that is, it will
stop early if it encounters a NULL byte in the source
string.
This makes it legal to pass the size of the destination
buffer (minus one byte needed for the string terminator)
as the number of bytes to copy and still get something
somewhat reasonable out of the operation; unfortunately,
it also makes the function difficult to reason about
and way too easy to misuse.
We want to move away from the way strncpy() behaves and
towards better defined semantics, where virStrncpy()
will always copy *exactly* the number of bytes it's
been asked to copy; before we can do that, though, we
have to change a few of the callers.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
virStrncpy() allows us to copy a substring, but if we're
going to copy the entire thing it's much more convenient
to use virStrcpy() instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
virStrcpy() and friends are useful when the destination
buffer has already been allocated, eg. as part of a struct;
if we have to allocate it on the spot, VIR_STRDUP() is a
better choice.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
This convenience macro was created for the simple cases
where the length of the source string and the size of the
destination buffer can be figued out with strlen() and
sizeof() respectively, so we should use it wherever
possible instead of open-coding parts of it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The way virStrncpy() is called here will never result in
buffer overflow, but it won't prevent or detect truncation
either, despite what the error message might suggest. Use
virStrcpyStatic(), which does all of the above, instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
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>
Andrea Bolognani