Peter Krempa [Wed, 15 Oct 2025 13:24:15 +0000 (15:24 +0200)]
qemuxmlconftest: Add example for "sgio='filtered'" disk option
The test suite validates only the error with the "sgio='unfiltered'"
setting which isn't supported by the qemu driver. Validate also the
'filtered' used explicitly (the default behaviour if unspecified is the
same as 'filtered').
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 13 Oct 2025 13:27:16 +0000 (15:27 +0200)]
docs: snapshot: Add a note that blockjobs ought to be avoided with 'manual' snapshots
Using a blockjob will reactivate the block nodes in qemu and thus e.g.
qcow2 metadata such as bitmaps may become marked as dirty. Users of
'manual' snapshots ought to avoid those.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 9 Jun 2025 13:50:42 +0000 (15:50 +0200)]
qemu: snapshot: Allow snapshot consisting only of 'manual'-y handled disks
The 'manual' snapshot mode is meant for disks where the users wants to
take a snapshot via means outside of libvirt, e.g. on a SAN network.
Allow creating a snapshot which consists entirely of 'manual' disks. For
now this effectively means that the VM will be paused but in the future
more logic can be added to ensure consistency.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Fri, 6 Jun 2025 10:33:04 +0000 (12:33 +0200)]
qemu: snapshot: Deactivate block nodes on manually snapshotted disks
If the user wants to manually preserve state of the disk we need, apart
from pausing the machine to quiesce all writes, also deactivate the
block nodes of the device. This ensures that qemu writes out metadata
(e.g. block dirty bitmaps) which are normally stored only in memory,
thus allowing a consistent snapshot including the metadata.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Fri, 25 Jul 2025 14:13:39 +0000 (16:13 +0200)]
qemu: migration: Don't reactivate block nodes after migration failure any more
The other code paths which do want to issue block jobs can reactivate
the nodes when necessary so we don't need to do that unconditionally
after failed/cancelled migration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Thu, 24 Jul 2025 12:49:55 +0000 (14:49 +0200)]
qemu: monitor: Track inactive state of block nodes in 'qemuBlockNamedNodeData'
New qemus report if given block node is active. We'll be using this data
to decide if we need to reactivate them prior to blockjobs. Extract the
data as 'inactive' as it's simpler to track and we care only about
inactive nodes.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Wed, 15 Oct 2025 08:49:20 +0000 (10:49 +0200)]
qemu: Drop reconnectBlockjobs from _qemuDomainObjPrivate struct
The 'reconnectBlockjobs' member of the _qemuDomainObjPrivate
struct is basically unused after v8.7.0-rc1~110. It's not even
formatted into the status XML, just parsed. This makes needless
noise. Just drop the member.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Mon, 29 Sep 2025 12:54:23 +0000 (14:54 +0200)]
qemu_process: Populate hyperv features for host-model
Pretty straightforward. The only "weird" thing here is that
'hv-time' enlightenment is exposed as a <timer/> under <clock/>
element. Since it's required by 'hv-stimer' and
'hv-stimer-direct' it needs to be enabled too.
Resolves: https://issues.redhat.com/browse/RHEL-114003 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Mon, 29 Sep 2025 08:20:41 +0000 (10:20 +0200)]
conf: Introduce hyperv host-model mode
So far we have two modes for hyperv features:
1) custom, where users have to enable features explicitly, and
2) passthrough, where hypervisor enables features automagically.
Problem with 'custom' mode is that some features are not plain
on/off switches but expect int/string value. Until very recently,
these were not reported in domcaps. And even if they were it's a
bit cumbersome.
Problem with 'passthrough' mode is that users don't get to see
the expanded list of enlightenments enabled.
Therefore, mimic what we're already doing with CPUs: have
'host-model' which gets expanded at domain startup and is fixed
throughout domain's run.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu_capabilities: Format and parse new hyperv domcaps members
After previous commit the virDomainCapsFeatureHyperv struct
gained new members. Since virQEMUCaps struct holds a pointer to
such struct we must format and parse it to/from capabilities XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 30 Sep 2025 13:05:10 +0000 (15:05 +0200)]
conf: Report default hyperv values in domain capabilities
So far the set of available Hyper-V enlightenments are reported
in domain capabilities. Well, some enlightenments are more than
just simple on/off switch. For instance, the 'spinlocks'
enlightenment expects a number, or 'vendor_id' expects a string.
All of these have some default values (at least in QEMU) and are
used when the passthrough mode is set.
Allow querying these defaults in domain capabilities XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
docs: Drop remark on now unsupported version of QEMU
In formatdomaincaps.rst under section documenting hyperv features
there's a paragraph describing behaviour with QEMU older than
6.1.0. Well, as of v11.2.0-rc1~216 the minimum required version
is 6.2.0 rendering the paragraph needless. Drop it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 30 Sep 2025 08:27:27 +0000 (10:27 +0200)]
conf: More hyperv related members into a single struct
So far, we have an array of integers (hyperv_features), an uint
(hyperv_spinlocks), a string (hyperv_vendor_id) and some tristate
switches scattered across virDomainDef. Soon, new knobs will be
introduced and keeping the current state would only worsen
readability.
Introduce virDomainHypervFeatures struct to place hyperv related
features there.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Tue, 30 Sep 2025 08:47:21 +0000 (10:47 +0200)]
libxl: Simplify setting HyperV features
Inside of libxlMakeDomBuildInfo() there's a huge switch() for
each virDomainHyperv case. Instead of checking whether feature is
enabled in each 'case', let's just check it at the beginning of
each loop.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Mon, 29 Sep 2025 14:05:31 +0000 (16:05 +0200)]
domain_conf: Use virXMLFormatElement() to format hyperv features
Not only is it more modern that old virBufferAsprintf() of
opening and closing tag, it's also aware of child elements buffer
and thus formats a singleton properly.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are two places in our code base which can use freshly
introduced virXPathTristateBool():
qemuStorageSourcePrivateDataParse() and
qemuDomainObjPrivateXMLParseBlockjobs().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Fri, 10 Oct 2025 13:22:34 +0000 (15:22 +0200)]
wireshark: Adapt to wireshark-4.6.0
The main difference is that wmem_packet_scope() is gone [1] but
the packet_info struct has 'pool` member which points to the
allocator used for given packet.
Unfortunately, while we were given pointer to packet_info at the
entry level to our dissector (dissect_libvirt() ->
tcp_dissect_pdus() -> dissect_libvirt_message()) it was never
propagated to generated/primitive dissectors.
But not all dissectors need to allocate memory, so mark the new
argument as unused. And while our generator could be rewritten so
that the argument is annotated as unused iff it's really unused,
I couldn't bother rewriting it. It's generated code after all.
Too much work for little gain.
Another significant change is that val_to_str() now requires new
argument: pointer to allocator to use because it always allocates
new memory [2][3].
Michal Privoznik [Fri, 10 Oct 2025 17:13:48 +0000 (19:13 +0200)]
wireshark: Don't leak column strings
One of the problems of using val_to_str() is that it may return a
const string from given table ('vs'), OR return an allocated one.
Since the caller has no idea which case it is, it resides to safe
option and don't free returned string. But that might lead to a
memleak. This behaviour is fixed with wireshark-4.6.0 and support
for it will be introduced soon. But first, make vir_val_to_str()
behave like fixed val_to_str() from newer wireshark: just always
allocate the string.
Now, if val_to_str() needs to allocate new memory it obtains
allocator by calling wmem_packet_scope() which is what we may do
too.
Hand in hand with that, we need to free the memory using the
correct allocator, hence wmem_free(). But let's put it into a
wrapper vir_wmem_free() because just like val_to_str(), it'll
need additional argument when adapting to new wireshark.
Oh, and freeing the memory right after col_add_fstr() is safe as
it uses vsnprintf() under the hood to format passed args.
One last thing, the wmem.h file used to live under epan/wmem/ but
then in v3.5.0~240 [1] was moved to wsutil/wmem/.
1: https://gitlab.com/wireshark/wireshark/-/commit/7f9c1f5f92c131354fc8b2b88d473706786064c0 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Fri, 10 Oct 2025 16:23:18 +0000 (18:23 +0200)]
wireshark: Introduce and use vir_val_to_str()
Wireshark offers val_to_str() function which converts numeric
value to string by looking up value ('val') in an array ('vs') of
<val, string> pairs. If no corresponding string is found, then
the value is formatted using given 'fmt' string.
Starting from wireshark-4.6.0 not only this function gained
another argument but also returns a strdup()-ed string. To keep
our code simple, let's introduce a wrapper so which can be then
adjusted as needed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Fri, 10 Oct 2025 17:16:54 +0000 (19:16 +0200)]
wireshark: Don't special case retval of get_program_data() in dissect_libvirt_message()
The get_program_data() function returns a pointer (in this
specific case to an array of procedure strings) which, if
non-NULL is then passed val_to_str(). Well, if val_to_str() sees
NULL it is treated gracefully, i.e. like if the numeric value
'proc' wasn't found in the array.
Therefore, there's no need to special case call to
col_append_fstr(). Both result into the same behaviour.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Now, per RFC 4506 enums are also encoded as signed integers. This
means, that only 'prog', 'vers' and 'serial' are really unsigned
integers. The others ('proc', 'type' and 'status') are encoded as
signed integers. Fix their type when dissecting.
While at it, also follow latest trend in wireshark and switch
from guint32 to uint32_t.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Soon, other parts of the wireshark code will need to
differentiate wrt wireshark version. Therefore, move the
WIRESHARK_VERSION macro definition among with its deps into
packet-libvirt.h.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Michal Privoznik [Mon, 13 Oct 2025 08:34:51 +0000 (10:34 +0200)]
wireshark: Drop needless declaration of proto_register_libvirt() and proto_reg_handoff_libvirt()
Both proto_register_libvirt() and proto_reg_handoff_libvirt() are
declared in packet-libvirt.h which is included from plugin.c.
There's no need to provide another declaration in plugin.c.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Current implementation uses a single command to flush the old rules and
create new ones. This is not optimal because if flush fails for some
non-critical reasons (e.g. because the anchor didn't previously exist),
it will block rules creation and network start.
Split this command into two: one for flush, and one for rules creation.
Also, don't fail if the flush command fails.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Laine Stump <laine@redhat.com>
Peter Krempa [Tue, 7 Oct 2025 09:42:41 +0000 (11:42 +0200)]
qemu-replies-tool: Fix logic error when dumping device properties
In a recent refactor the block of code outputting device properties was
mis-indented causing it to only work on device properties which have no
'default-value'.
Fixes: 301e1ba244f Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
locking: use & install test_libvirt_sanlock.sug for both QEMU & LibXL
The RPM specfile was referencing test_libvirt_sanlock.aug in the common
file list, for both QEMU and LibXL. This makes sense since the
sanlock.conf file is cloned for both drivers. The libvirt_sanlock.aug
file, however, was missing a reference to the LibXL copy of the config.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The commit was mistaken, as sanlock is enabled for libxl too,
however, the install of test_libvirt_sanlock.aug was missing
when QEMU was disabled, causing the RPM build failure.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Andrea Bolognani [Tue, 16 Jan 2024 17:51:42 +0000 (18:51 +0100)]
qemu: Don't add memballoon by default on RISC-V
The idea of adding devices such as USB controllers or memory
balloons by default comes from attempting to match QEMU's own
defaults at a time when x86 was the only game in town.
The unfortunate consequence of this is that, if the user does
NOT want the device in question to be present, they have to
create a special XML element with model=none to stop libvirt.
This is counter-intuitive.
For architectures for which we've added support more recently,
such as aarch64 and loongarch64, we've generally chosen to do
the sensible thing and create very minimal guests by default.
The user is of course still able to ask for additional hardware
if they so desire.
When adding RISC-V support, we accidentally forgot to skip the
creation of the default memory balloon. Address that oversight.
This is technically a breaking change, but it's fairly safe to
apply it because:
* it doesn't affect existing guests;
* virt-manager will automatically add the memballoon device
by default anyway;
* RISC-V is still not widely used.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Andrea Bolognani [Tue, 19 Aug 2025 15:25:21 +0000 (17:25 +0200)]
news: Update for USB controller model selection improvements
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
There are still a couple of scenarios in which we end up
using the Intel-specific piix3-uhci (USB1) controller for
non-x86 guests.
Remove these uses, leaving the generic pci-ohci (USB1)
controller as either the fallback or default for situations
where no better choice can be made.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Fri, 25 Jul 2025 15:47:03 +0000 (17:47 +0200)]
qemu: Remove fallback to piix3-uhci for Arm virt guests
This is another case where the current behavior can be traced
back to the fact that x86 was the only architecture to really
be taken into account for a long time: in reality, using an
Intel-specific USB1 controller for a modern, PCIe-native,
virtualization-friendly Arm guest just doesn't make any sense.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Thu, 25 Sep 2025 12:04:15 +0000 (14:04 +0200)]
qemu: Don't special-case realview/versatilebp for USB
We have special behavior for these two machine types, and
more specifically for the USB controller that they get added
by default - something that doesn't generally happen on Arm.
Not only this is inconsistent with other machine types for
the architecture, it also means that the model for the USB
controller that gets added automatically (pci-ohci, USB1) is
worse than the default one for user-added USB controllers
(qemu-xhci, USB3) which is just silly.
Bring these machine types in line with the rest of the
architecture.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Tue, 19 Aug 2025 13:18:42 +0000 (15:18 +0200)]
qemu: Unify USB controllers across Arm architectures
Currently we differentiate between 64-bit and 32-bit
architectures, which doesn't seem very reasonable
considering that the same machine types are available
in both cases. Remove this inconsistency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Wed, 24 Jan 2024 09:59:49 +0000 (10:59 +0100)]
qemu: Use qemu-xhci with no fallback on RISC-V
Similar to loongarch64, the current behavior is a result
of the way the existing code was written rather than a
consequence of an intentional choice. Make the two
architectures behave the same way, as they should have
from the start.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Thu, 25 Sep 2025 11:55:15 +0000 (13:55 +0200)]
qemu: Use qemu-xhci with no fallback on loongarch64
The architecture was introduced at a time when USB3 in
general, and qemu-xhci in particular, had already been
well established for years. Having USB1 controllers as a
fallback was something that happened by mistake due to
the way the pre-existing code was organized rather than
because of a conscious decision. Make things work the
way they should have in the first place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Thu, 25 Sep 2025 13:29:44 +0000 (15:29 +0200)]
qemu: Clean up qemuDomainDefaultUSBControllerModelAutoAdded()
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Mon, 12 Feb 2024 19:05:42 +0000 (20:05 +0100)]
qemu: Clean up qemuDomainDefaultUSBControllerModel()
Switch from the current approach, in which an initial and
likely poor default is picked and then a better one later
overwrites it, to the more common and easy to reason about
pattern where the value is returned directly as soon as
possible.
To make things easier to understand and more maintainable,
the various architectures for which we have explicit
handling are each taken care of separately, with no falling
through to the default behavior.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
In addition to the code in qemuDomainControllerDefPostParse(),
which we have just factored into its own function, we also have
some code in qemuDomainDefAddDefaultDevices() that deals with
choosing the USB controller model for a couple of specific
machine types.
Once again, extract the logic to a dedicated helper. The
behavior is unchanged.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Mon, 12 Feb 2024 12:58:06 +0000 (13:58 +0100)]
qemu: Add qemuDomainDefaultUSBControllerModel()
Extract the logic from qemuDomainControllerDefPostParse() to
a dedicated helper. The behavior is unchanged.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Tue, 13 Feb 2024 18:24:03 +0000 (19:24 +0100)]
qemu: Validate USB controllers earlier
Right now we call qemuValidateDomainDeviceDefControllerUSB()
quite late, just as we're generating the QEMU command line.
The original intention was likely to prevent configurations
from being rejected, even though a default USB controller
model could not be found, because using -usb could be used
as a last resort.
As it turns out, this premise was always flawed: in order
for -usb to work, the underlying device still needs to be
compiled into QEMU, and if that was the case then the
earlier code would have detected its presence and set the
model name accordingly.
More recently, we have dropped the use of -usb altogether
so there's simply no longer anything to fall back to.
With all this in mind, we can move the validation step much
earlier, making for a better user experience as any issues
will be reported when the domain is defined rather than when
an attempt is made to start it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Mon, 22 Sep 2025 16:24:17 +0000 (18:24 +0200)]
qemu: Skip USB controller validation when model=none
This is not useful right now, because the function is simply
not called at all for model=none USB controllers, but that's
going to change in a moment, when we start calling the
function during validation instead of command line generation.
Making this change ahead of time means that we can simply
move the code verbatim later.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Mon, 22 Sep 2025 16:00:41 +0000 (18:00 +0200)]
qemu: Validate PCI support for USB controllers
Attempting to use a USB controller that's a PCI device with
a machine type that doesn't support PCI should result in an
error.
Note that, while all USB controllers supported by the libvirt
QEMU driver today are PCI devices, QEMU itself implements
machine types that come with non-PCI USB controllers. Having
a separate helper with a switch/case statement ensures that
things will need to be updated accordingly if libvirt will
ever grow support for those USB controllers.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Mon, 22 Sep 2025 15:41:37 +0000 (17:41 +0200)]
qemu: Rename function argument
This makes the signature consistent with that of other
qemuValidateDomainDeviceDefController*() functions, which
are passed a virDomainDef along with the existing
virDomainControllerDef. Later changes to this function
will require access to the additional data structure.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
We have just changed PostParse so that MODEL_USB_NONE will be
used instead of MODEL_USB_DEFAULT, so this code is no longer
doing anything.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Thu, 18 Sep 2025 14:33:41 +0000 (16:33 +0200)]
qemu: Don't generate alias for model=none USB controllers
That obviously doesn't make sense, since the value is used
to indicate the absence of a USB controller.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Mon, 12 Feb 2024 19:18:46 +0000 (20:18 +0100)]
qemu: Always default to no USB controller on s390x
When support for s390x was introduced in libvirt, it naturally
followed the conventions established at the time for x86, which
were to have a USB controller added by default.
Later, in 2013, commit 3a82f628a964 made the default USB
controller model for s390x VIR_DOMAIN_CONTROLLER_MODEL_USB_NONE,
effectively overriding the architecture-independent default.
However, an exception was carved out at the time: if the USB
controller had an address assigned to it, then it would be left
alone.
A couple of years later, commit 09ab9dcc85ec changed things
again in two ways: for starters, libvirt would no longer
automatically attempt to add a USB controller to newly-defined
s390x guests; moreover, the command line generator was changed
so that the legacy USB controller (-usb) would never be used
on s390x.
In other words, unless a model name is explicitly provided for
the USB controller, which is something that only actually works
when using a recent QEMU version (see commit f9ed4d385ab8),
s390x guests will never have USB controllers attached to them.
Remove the exception carved out a decade ago and always
reflect this fact accurately in the guest XML.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Thu, 10 Jul 2025 14:38:04 +0000 (16:38 +0200)]
qemu: Add sanity checks for auto-added PCI controllers
These checks enforce some expectations that were, until now,
documented solely through comments or not spelled out at all.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Thu, 10 Jul 2025 14:42:32 +0000 (16:42 +0200)]
qemu: Update qemuDomainSupportsPCI()
The sparc architecture doesn't support PCI, and neither do the
isapc and microvm machine types on x86 architectures.
One of the isapc/microvm tests starts failing as a consequence
of this change, which is expected; somewhat surprisingly,
another test for the same machine types goes from an early/hard
failure (PARSE_ERROR) to a late/soft one (FAILURE) instead.
This will be rectified by a later commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Fri, 11 Jul 2025 13:38:37 +0000 (15:38 +0200)]
qemu: Validate presence of PCI support
The qemuValidateDomainDeviceDefControllerPCI() function is
called if PCI controllers are present in the domain
configuration, which shouldn't happen if the machine type
doesn't support PCI. If we somehow find ourselves in that
scenario, reporting an error would be the right thing to do.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu: Prevent use of PCI devices when PCI is not supported
At the moment, we check whether the machine type supports PCI
before attempting to allocate PCI addresses, and if it does
not, we simply skip the step entirely.
This means that an attempt to use a PCI device with a machine
type that has no PCI support won't be rejected by libvirt, and
only once the QEMU process is started the problem will be made
apparent.
Validate things ahead of time instead, rejecting any such
configurations.
Note that we only do this for new domains, because otherwise
existing domains that are configured incorrectly would disappear
and we generally try really hard to avoid that.
A few tests start failing after this change, demonstrating that
things are now working as desired.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
This centralizes the knowledge about which network interface
models are PCI devices and thus need to have a PCI address
allocated by libvirt, and expands said knowledge to include
the fact that models such as spapr-vlan and smc91c111 are
not PCI devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Mon, 22 Sep 2025 13:09:29 +0000 (15:09 +0200)]
qemu: Don't add PCI, USB or memballoon to microvm
The microvm machine type doesn't support PCI, so adding PCI
controllers to it doesn't make sense, nor does adding a
USB controller or a memballon since both are PCI devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
The isapc machine type doesn't support PCI, so adding a
memballoon (which is a PCI device) to it doesn't make sense.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Fri, 11 Jul 2025 13:39:01 +0000 (15:39 +0200)]
tests: Add coverage for PCI use with isapc and microvm
Neither machine type supports PCI, so attempting to add a
PCI controller should fail. It currently doesn't, and we're
going to address that in an upcoming commit.
Note that the domain gets a PCI memballoon device added
automatically. That also shouldn't happen, and will similarly
be fixed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
qemu: Fix PCI/USB handling for Arm realview boards
Only the -eb variants of the realview board support PCI
devices, so those are the only ones that should automatically
get a USB controller (addDefaultUSB). libvirt will currently
add one for the other realview variants too, but that will
result in QEMU reporting an error due to lack of PCI support
as soon as the domain is started.
Additionally, they should get a PCI controller added
automatically (addPCIRoot) too, same as versatilepb.
Finally, qemuDomainSupportsPCI() should correctly report the
fact that these machine types support PCI.
As a consequence of these fixes, the USB controllers now
correctly get assigned PCI addresses across the board.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
QEMU implements 4 different "realview" machine types:
$ qemu-system-aarch64 -machine help 2>&1 | grep realview
realview-eb ARM RealView Emulation Baseboard (ARM926EJ-S)
realview-eb-mpcore ARM RealView Emulation Baseboard (ARM11MPCore)
realview-pb-a8 ARM RealView Platform Baseboard for Cortex-A8
realview-pbx-a9 ARM RealView Platform Baseboard Explore for Cortex-A9
Of these, only the -eb variants support PCI devices and are
thus relevant when it comes to USB controllers.
Our logic treats all these machine types the same, which is
incorrect. An upcoming commit will fix the issue; in
preparation for that, make some adjustments to the test suite.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
We assign the USB controller model without first checking
whether the corresponding QEMU device is available, and that
results in a late error instead of an early one.
Be consistent with how we do things in all other cases and
check the presence of the capability before attempting to set
the model.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
tests: Fix some usb-controller-*-unavailable cases
These tests are intended to show what happens when the device
that libvirt would use by default is not available in QEMU by
dropping the corresponding capabilities, but we're not doing
that correctly at the moment and so we still get the default
USB controller instead of a failure.
Specifically, we should be dropping all capabilities related
to devices that might be used as default or automatic USB
controllers for the machine type so that libvirt will report
an error, but for these few tests we are currently only
listing a subset of the capabilities that we should be
dropping.
Note that the usb-controller-automatic-unavailable tests are
still behaving the same despite dropping all the expected
capabilities: the reason is that, for that scenario, we're
not currently checking whether the device is available before
using it. That's a separate issue that will be addressed in an
upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Fri, 18 Jul 2025 14:27:48 +0000 (16:27 +0200)]
tests: Expand coverage for automatic/default USB controllers
We're missing a significant number of scenarios, including
those involving fairly common machine types and architectures.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
This matches the existing q35 test, and in general makes more
sense as a name since these tests are providing coverage for
USB controllers getting automatically added by libvirt for new
domains, rather than implicit (i.e. built-in, non-removable)
devices.
Note that, in the case of physical i440fx machines, the USB
controller is actually part of the chipset and would thus
qualify as implicit; the corresponding QEMU machine type,
however, allows for it to be removed, so the new name is still
more appropriate when discussing virtual hardware.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
These tests are all about USB controllers and anything else
is a distraction that we can happily live without.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Thu, 10 Jul 2025 12:57:27 +0000 (14:57 +0200)]
tests: Don't set PCI address in usb-controller-default tests
We want to ensure that libvirt will automatically allocate the
PCI address, and setting it ourselves ahead of time will
prevent that from happening.
In the case of q35, this change will cause additional PCI
controllers to show up. That's desirable, as it demonstrates
the behavior libvirt users will actually see.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
tests: Don't use memballoon=none for minimal tests
It's redundant (these machine types don't get a memballoon added
automatically anyway), plus the test is supposed to show what
happens when a minimal configuration is fed to libvirt and
including additional elements goes against that.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Tue, 22 Jul 2025 12:54:54 +0000 (14:54 +0200)]
tests: Drop coverage for versatilepb on aarch64
We already test the machine type on armv7l and realview on
aarch64, so these handful of test cases can be dropped without
negatively impacting our coverage.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Andrea Bolognani [Fri, 25 Jul 2025 15:33:58 +0000 (17:33 +0200)]
tests: Fix typo in usb-controller-nec-xhci-autoassign
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
tests: validate an XML config with USB vendor/product set
The USB vendor/product is usually translated into a device/bus at
startup using the hostdev logic. We don't run the latter in the
unit test suite, but we can fake it by hardcoding a translation.
This demonstrates that we format the command line with the normal
device/bus properties, even when vendor/product is set.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
projects / thirdparty / libvirt.git / log
