Peter Krempa [Tue, 28 Oct 2025 16:13:17 +0000 (17:13 +0100)]
qemuDomainBlocksStatsGather: Fix blockstats gathering after refactor
Commit 58aa005f3e95114 which refactored how block stats are stored
intended to change the code path where stats for all devices are totaled
together by allocating new stats object and using that but the commit
forgot to actually change the pointers inside the loop.
Unfortunately this was not caught by the compiler as there were
pre-existing pointers of the same type with the same name, which
resulted into a NULL dereference.
Stefan Kober [Mon, 6 Oct 2025 15:18:11 +0000 (17:18 +0200)]
NEWS: ch: announce network hotplug feature
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Mon, 6 Oct 2025 15:18:10 +0000 (17:18 +0200)]
ch: implement network device hot detach
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Mon, 6 Oct 2025 15:18:09 +0000 (17:18 +0200)]
ch: implement network device hot attach
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Stefan Kober [Mon, 6 Oct 2025 15:18:08 +0000 (17:18 +0200)]
ch: add net device alias assignment
On-behalf-of: SAP stefan.kober@sap.com Signed-off-by: Stefan Kober <stefan.kober@cyberus-technology.de> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Hector Cao [Tue, 14 Oct 2025 15:28:34 +0000 (17:28 +0200)]
apparmor: Allow AMD-SEV device access for AMD-SEV VM
AMD-SEV virtual machines interact with the underlying
AMD-SEV technology through the character device /dev/sev.
Currently, the AppArmor profile does not include the rule
required to allow this access.
There are two main approaches to address this limitation:
1) Add the required rule to the libvirt-qemu abstraction.
2) Dynamically add the rule only when the VM is an AMD-SEV
guest.
Since AMD-SEV guests represent a niche use case, it is more
appropriate to apply the rule dynamically rather than granting
access to all VMs through a global abstraction change.
This commit implements option (2) by modifying the virt-aa-helper
binary to insert the necessary rule into the AppArmor dynamic
profile when the VM is identified as an AMD-SEV guest.
The added entry in the generated libvirt-<uuid>.files file
will look like:
...
"/dev/sev" rw,
...
Signed-off-by: Hector Cao <hector.cao@canonical.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
A domain that runs with TCG emulation does not need kvm device, so drop
it from default device ACL.
Dynamically grant access to /dev/kvm based on domain type.
Signed-off-by: Praveen K Paladugu <prapal@linux.microsoft.com> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Update default to 0xFFFFFFFF ("never notify" in qemu) and make retries
attribute optional.
Signed-off-by: Friedrich Oslage <friedrich@oslage.de> Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Tue, 21 Oct 2025 16:22:15 +0000 (18:22 +0200)]
qemumonitorjsontes: Properly free blockstats
In the patch converting block stats to objects in 58aa005f3e9 I forgot
to change the allocation of the hash table in qemumonitorjsontest which
doesn't use the wrapper. This problem didn't manifest itself with newer
glib versions.
Use 'g_object_unref' instead of 'g_free'.
Fixes: 58aa005f3e9 Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Peter Krempa [Wed, 1 Oct 2025 14:26:01 +0000 (16:26 +0200)]
qemuMonitorJSONGetAllBlockStatsInfo: Directly probe data from 'query-named-block-nodes'
Currently the data which was probed for statistics from
'query-named-block-nodes' was updated in a separate call in
qemuMonitorJSONBlockStatsUpdateCapacityBlockdev.
This patch moves and adapts the code so that everything is probed in
qemuMonitorJSONGetAllBlockStatsInfo.
qemuMonitorJSONBlockStatsUpdateCapacityBlockdev is now an empty function
and will be removed later.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 1 Oct 2025 14:16:58 +0000 (16:16 +0200)]
qemuMonitorJSONBlockStatsUpdateCapacityData: Merge into caller
It's called just from
qemuMonitorJSONBlockStatsUpdateCapacityBlockdevWorker. Merging it in
makes the code much simpler especially when combined with a change to
APIs that can't fail.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Wed, 1 Oct 2025 12:36:12 +0000 (14:36 +0200)]
qemuMigrationCookieAddNBD: Use qemuBlockGetNamedNodeData to fetch the capacities
'qemuMonitorBlockStatsUpdateCapacityBlockdev' uses the same command
internally.
Upcoming patches will want to merge qemuMonitorBlockStatsUpdateCapacityBlockdev
into qemuMonitorGetAllBlockStatsInfo and qemuMigrationCookieAddNBD is
the only place that doesn't call qemuMonitorGetAllBlockStatsInfo.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
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>
projects / thirdparty / libvirt.git / log
