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>
The virt_socket_lib library has a dep on dtrace_gen_headers, but
the virprobe.h file (which includes the libvirt_probes.h) is also
used from virnetserverclient.c and virkeepalive.c files which do
not directly depend on virt_socket_lib. Thus it is possible for
the latter files to be built before the libvirt_probes.h file
has had its content written.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Michal Privoznik [Mon, 29 Sep 2025 08:36:04 +0000 (10:36 +0200)]
NEWS: Fix format of XML elements/attributes in v11.8.0 section
It's a good practice to use a different style of formatting for
literal values like XML element/attribute names, functions, etc.
In this specific case, the 'acpi' and 'nodeset' names should be
formatted using two single quotes instead of double quote.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Ján Tomko [Thu, 17 Jul 2025 17:11:43 +0000 (19:11 +0200)]
tests: qemuxmlconftests: test virtiofsd command line too
Fake the capabilities based on the QEMU version so that we can test
the command line for both the C version of virtiofsd (removed in QEMU
8.0.0) and the Rust version.
Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
Ján Tomko [Thu, 17 Jul 2025 17:32:52 +0000 (19:32 +0200)]
tests: qemuxmlconf: virtiofs: remove locking from the readonly test case
The combination of locking + readonly is bogus, because there has never
been a virtiofsd release that supported both.
Locking was a feature of the C-based virtiofsd that was living in the
QEMU tree until v8.0.0 and the readonly feature was only introduced
in the Rust version of virtiofsd.
Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Laine Stump <laine@redhat.com>
Andrea Bolognani [Thu, 31 Jul 2025 14:50:46 +0000 (16:50 +0200)]
qemu: Fix matching for read/write firmware
We currently always pick a read-only firmware unless we are
explicitly asked for a read/write one, which is probably what
most people expect anyway but doesn't really make sense
otherwise: if no specific requirement has been provided by the
user, both read-only and read/write firmwares should be
allowed to match.
This won't result in any change in practice, since distros are
not shipping read/write builds of edk2 anyway. If they started
doing that, it would be their responsibility to ensure that
they are ordered after the read-only builds.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Andrea Bolognani [Wed, 30 Jul 2025 15:35:23 +0000 (17:35 +0200)]
qemu: Fix matching for stateless/combined firmware
The current code assumes that a stateless firmware has to be
explicitly requested by the user, and should never be picked
otherwise. This means that, for example, domains configured to
use SEV-SNP are forced to explicitly request for the firmware
to be stateless.
Additionally, we assume that only split firmware is suitable
for the stateful use case, whereas a combined firmware image
would also do the job.
As a result of these changes, the failing SEV-SNP test case
that was added recently passes, and so do the test cases
requesting read/write firmware.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Andrea Bolognani [Wed, 30 Jul 2025 12:56:00 +0000 (14:56 +0200)]
tests: Add tests for SEV firmware selection
One of the new test cases demonstrates how firmware
autoselection doesn't currently work correctly for domains
using SEV-SNP: the descriptor for a suitable firmware exists,
and yet it doesn't get picked up.
Another test cases shows that, while firmware autoselection
succeeds for non-SNP SEV domains, the results are not the
expected ones: the generic (stateful) edk2 build is used
instead of the SEV-specific (stateless) one. This will be
addressed in a future patch by updating the descriptors.
Finally, one test case provides coverage for the uncommon
scenario of stateful firmware being explicitly requested by
the user.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Andrea Bolognani [Wed, 30 Jul 2025 15:01:47 +0000 (17:01 +0200)]
tests: Tweak descriptor for combined firmware
This kind of firmware build is not shipped in Fedora, where
most descriptors in our test suite come from, so we had to
make it up. It was based off the Secure Boot-enabled edk2
build, and the filename it points to is the same.
That has been fine so far since it's not actually being picked
up by any of the test cases, but that's going to change soon
and when it does we want to be able to avoid any confusion.
Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Peter Krempa [Tue, 9 Sep 2025 13:56:10 +0000 (15:56 +0200)]
qemuMigrationSrcIsSafeDisk: Allow non-shared qcow2's with raw data file
A qcow2 image which uses a data file and the 'data_file_raw' flag is
effectively a raw image with the qcow2 wrapper used only to store
metadata (block dirty bitmaps).
Since the dirty bitmaps are always migrated using the migration stream
it's technically not required that the qcow2 overlay itself is shared
between the destinations.
Management tools like Kubevirt want to migrate VMs which have a qcow2
overlay with the above config stored in a location that is not shared,
but the data file itself is.
This patch adds code that skips the validation of the overlay since it's
not needed to ensure data consistency in that very specific case.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 8 Sep 2025 16:09:57 +0000 (18:09 +0200)]
qemuBlockGetNamedNodeData: Extract 'data_file_raw' flag
The 'data_file_raw' flag of qcow2 notifies that all data inside the
'data_file' is a raw image so can be used standalone without the
metadata without any problem (except for not updating the dirty
bitmaps).
Our migration safety checks will allow skipping the migration safety
check for these files as during migration we know it's safe to re-create
this on the destination in a location that isn't shared.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Tue, 9 Sep 2025 13:43:52 +0000 (15:43 +0200)]
qemuMigrationSrcIsSafeDisk: Check also data file properties for migrability
If the qcow2 data file feature (which separates the data into a separate
file from the metadata) is in use the migration safety check ought to
consider both the metadata and the data file for safe migration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Peter Krempa [Mon, 8 Sep 2025 15:50:22 +0000 (17:50 +0200)]
qemuMigrationSrcIsSafeDisk: Extract safe migration checks for one storage source
Further split up the code originally in 'qemuMigrationSrcIsSafe' to
separate checks concerning a single storage source.
The code will then be reused to check the safe migration state also for
the data file (qcow2 feature that allows store of data separated from
the qcow2 metadata).
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Ján Tomko [Wed, 10 Sep 2025 07:48:41 +0000 (09:48 +0200)]
build: bump minimum glib version to 2.68
We removed support for Debian 11 which only had 2.66.8.
Next stop: 2.72 after we drop Ubuntu 22.04
For libvirt, the update to the 2.68 GLib release:
* introduces g_string_replace
* deprecates g_memdup in favor of g_memdup2
* removes the need for some warning workarounds
* deprecates g_time_zone_new in favor of g_time_zone_new_identifier
which returns NULL on error instead of returning UTC
Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Thu, 11 Sep 2025 11:20:24 +0000 (13:20 +0200)]
ch: Propagate lifecycle events
We already have a thread that listens on cloud-hypervisor's
monitor for incoming events and processes them. What is missing
though, is emitting of corresponding lifecycle events.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 10 Sep 2025 09:43:53 +0000 (11:43 +0200)]
ch: Unlock domain in virCHEventStopProcess() on all exit paths
The aim of virCHEventStopProcess() is to clean up after stopped
domain by calling virCHProcessStop(). But in order to do that it
needs to acquire a job and in order to do that it needs to lock
the domain object. Well, the object is not unlocked in all exit
paths, i.e. when job acquiring fails the domain object is left
locked.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Wed, 10 Sep 2025 08:21:48 +0000 (10:21 +0200)]
ch: Avoid memory leak in virCHProcessEvents()
The aim of virCHProcessEvents() is to read data (in JSON format)
from CH monitor and then process them. To parse incoming data
virJSONValueFromString() is used. But the corresponding
virJSONValue is freed only when processing of an even succeeds.
If processing an event fails, then the memory is not freed
leading to a memory leak.
334 (24 direct, 310 indirect) bytes in 1 blocks are definitely lost in loss record 1,975 of 2,040
at 0x4919EF3: calloc (vg_replace_malloc.c:1675)
by 0x4FEB249: g_malloc0 (in /usr/lib64/libglib-2.0.so.0.8400.3)
by 0x4A66162: virJSONValueNewObject (virjson.c:533)
by 0x4A67E74: virJSONValueFromJsonC (virjson.c:1413)
by 0x4A681A5: virJSONValueFromString (virjson.c:1484)
by 0xB8CD9D7: virCHProcessEvents (ch_events.c:179)
by 0xB8CDCDC: virCHReadProcessEvents (ch_events.c:251)
by 0xB8CDEBB: virCHEventHandlerLoop (ch_events.c:284)
by 0x4AC1EB4: virThreadHelper (virthread.c:256)
by 0x5441DE3: start_thread (in /usr/lib64/libc.so.6)
by 0x54C25F3: clone (in /usr/lib64/libc.so.6)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Mon, 25 Aug 2025 03:32:39 +0000 (23:32 -0400)]
conf: auto-add a pcie-root-port when needed while plugging in pcie-to-pci-bridge
This will almost surely never come up during any normal operation[*],
which is likely why this wasn't done when pcie-to-pci-bridge support
was added back in the before-fore times. It's pretty simple to support
though - a pcie-to-pci-bridge plugs into a pcie-root-port just like
any other pcie device, and if there isn't an open slot on an existing
pcie-root-port, we can just add one.
([*] in real life, a pcie-to-pci-bridge is only auto-added by libvirt
itself, while this function is dealing with the followup to *user
added* devices. Also each pcie-to-pci-bridge has 32 slots, and it's
unlikely a domain with pcie support would be wanting more than 32
conventional PCI (i.e. not PCIe) devices)
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Tue, 26 Aug 2025 18:41:32 +0000 (14:41 -0400)]
conf: improve error message when a PCI controller can't be auto-added
Log a slightly different message when the missing-but-required slot is
conventional PCI vs PCIe. Also correct/improve the comments about why
auto-add of a PCI controller isn't supported when we're trying to
create a slot for various different pci controllers.
Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Mon, 11 Aug 2025 06:11:25 +0000 (02:11 -0400)]
conf: add forgotten clause to virDomainPCIControllerConectTypeToModel()
When building the PCI topology of a domain that has PCI devices with
no assigned PCI addresses, the function virDomainPCIAddressSetGrow()
will attempt to add a new PCI controller with the appropriate type of
slot to connect a device that doesn't have a PCI address.
In some cases this isn't possible (for example, if the device you are
attempting to add to the topology requires a type of connection only
provided by some controller that *itself* requires a connection of a
type not available for the given architecture/machinetype, e.g. if you
want to add a pcie-root-port to a domain with a machine type that has
a pci-root (no PCIE)). In those cases, an error message is logged by
using virDomainPCIControllerConectTypeToModel() to extract the type of
device from the "flags" that are sent to virDomainPCIAddressSetGrow().
However, if virDomainPCIControllerConectTypeToModel() doesn't find a
device type in the connection flags, it will return -1, and
virDomainPCIAddressSetGrow() will log the very generic:
Cannot automatically add a new PCI bus for a device with connect flags nnnn
Both of these functions were written prior to libvirt adding support
for the pcie-to-pci-bridge controller, and when that support was added
(in 2018), a new if() clause wasn't added to
virDomainPCIControllerConectTypeToModel(). Seven (!) years later, this
omission was noticed by someone adding a new test case to regression
testing.
This patches remedies the earlier omission, so that now when someone
tries to add a pcie-to-pci-bridge controller to a domain that doesn't
have PCIE, the message will be:
a PCI slot is needed to connect a PCI controller model='pcie-to-pci-bridge', but none is available, and it cannot be automatically added
This is still not an ideal error message, but is arguably better.
(NB: Unfortunately it isn't possible to use a switch() statement with
no default case (in order to catch a similar error in the future),
since we are converting from bitmapped flags. Fortunately, we haven't
needed to add a new PCI controller type in the last 7 1/2 years :-)
Resolves: https://issues.redhat.com/browse/RHEL-62032 Fixes: 542f05e7756cc5614eb2ee7b0bac9aabb7aa016c Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Laine Stump [Sat, 23 Aug 2025 04:09:41 +0000 (00:09 -0400)]
qemu: fix multiple missing setup/teardown of passt process for interface type='vhostuser'
passt networking support was originally added only for <interface
type='user'>, and all of the codepaths leading to qemuPasst*()
functions were protected with
if (net->type == VIR_DOMAIN_NET_TYPE_USER &&
net->backend.type == VIR_DOMAIN_NET_BACKEND_PASST)
When support was later added to use a vhost-user socket to connect
between the passt process and qemu process, *some* of the conditionals
similar to the above were changed to be
As a matter of fact, enough of these places were changed to make
passt+vhostuser work. However I missed a few places that resulted in
the passt process not being properly shutdown/cleaned up when the
interface type was vhostuser, and also as far as I can see from
examining the code, the passt process wasn't being added to the cgroup
for the domain.
We could fix these problems by adding the extra condition to all the
missing places (checking for either 'user' or 'vhostuser' as well as
for backend type of 'passt'), but since validation already guarantees
that if backend type='passt' then the interface type MUST be either
'user' or 'vhostuser', it's really just adding extra code for no good
purpose (and would leave open the possibility of the same problem
recurring in the future if a different interface type begins using
passt as well). So the better solution is to not bother checking
net->type at all in those locations - if backend type is 'passt' then
we call the passt-related code.
Resolves: https://issues.redhat.com/browse/RHEL-80285
Resolves: https://issues.redhat.com/browse/RHEL-92842 Fixes: 1e9054b9c79d721a55f413c2983c5370044f8f60 Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
projects / thirdparty / libvirt.git / log
