Jiri Denemark [Thu, 6 Nov 2025 13:10:06 +0000 (14:10 +0100)]
cputest: Read more MSRs in cpu-data.py
The features defined in our CPU map use quite a bit more than just the
two MSRs the script is currently trying to read. Let's read all of them
to get complete host CPU data.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Thu, 6 Nov 2025 12:40:14 +0000 (13:40 +0100)]
cputest: Ignore missing MSRs in cpu-data.py
The current code made sense when we were reading only one MSR, but since
we started reading more MSRs, the host CPU would have to support all of
them otherwise the function would just return an empty dict.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Thu, 6 Nov 2025 09:55:10 +0000 (10:55 +0100)]
sync_qemu_models_i386: Support adding models to an empty group
When adding a new CPU vendor, we create a new empty group in
src/cpu_map/index.xml and want to use the sync_qemu_models_i386.py
script to add models there.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Jiri Denemark [Wed, 5 Nov 2025 14:49:22 +0000 (15:49 +0100)]
sync_qemu_models_i386: Print current model for unknown features
This way one can just grep for all warnings in the script output and
still be able to see for which CPU model is defined using features the
script doesn't know about.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We've already checked the upper bound of the array, but we should
none the less sanity check that the requested array element is
not NULL before dereferencing it.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
"enabled" here indicates "kvm" is the enabled accelertor.
If query-accelerators command is not available, fallback to existing
mechnisms for querying kvm and hvf capabilities.
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>
src: report error from failing to add timer/FD watches
The virEventAddHandle/Timeout APIs are unusual in that they do not
report errors on failure, because they call through to function
callbacks which might be provided externally to libvirt and thus
won't be using libvirt's error reporting APIs.
This is a rather unfortunate design characteristic as we can see
most callers forgot about this special behaviour and so we are
lacking error reporting in many cases.
Reviewed-by: Peter Krempa <pkrempa@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa [Thu, 11 Sep 2025 15:07:11 +0000 (17:07 +0200)]
qemu_monitor: Extract 'timed_stats' of block devices
The 'timed_stats' block is a set of statistics gathered in configurable
time intervals. The stats include latency timings of reads/writes as
well as the depth of the request queues.
Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Peter Krempa [Mon, 3 Nov 2025 12:23:48 +0000 (13:23 +0100)]
qemu: capabilities: Fix logic for formatting 'reconnect' parameter
In commit e4d058866e9 I've converted the code to use the modern
'reconnect-ms' parameter instead of 'reconnect' but messed up the logic
for the time when 'reconnect' will be removed.
We need to check QEMU_CAPS_NETDEV_STREAM_RECONNECT_MILISECONDS
individually and not based on QEMU_CAPS_NETDEV_STREAM_RECONNECT.
Fix the logic as upstream qemu now removed 'reconnect'.
Fixes: e4d058866e9563756349de6b3f451a53e64ca872 Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Fri, 24 Oct 2025 12:17:56 +0000 (14:17 +0200)]
qemu: Ignore "ht" CPU feature
The feature does not do anything, QEMU will always set it according to
the CPU topology completely ignoring what we asked for. Unfortunately,
the way the state of "ht" is reported changed in QEMU 10.0.0 (commit c6bd2dd634208).
QEMU older than 10.0.0 would just report whatever was specified on the
command line totally ignoring the actual state of the feature visible to
a guest. But after the change QEMU reports ht=on in case it enabled "ht"
based on the CPU topology. In all other cases QEMU still reports the
state requested on the command line.
As a result of this change a domain with multiple CPU threads started on
QEMU < 10.0.0 could not be migrated to QEMU >= 10.0.0 unless "ht" was
explicitly enabled in the domain XML because libvirt would see "ht"
enabled on the destination, but disabled on the source (the guest would
see "ht" enabled in both cases anyway). Outgoing migration of domains
started on QEMU >= 10.0.0 is not affected.
To fix this issue we can completely ignore "ht" both in the domain XML
and in the CPU properties reported by QEMU. With this fix incoming
migration to QEMU >= 10.0.0 works again.
Jiri Denemark [Fri, 24 Oct 2025 15:16:32 +0000 (17:16 +0200)]
qemu_monitor: Filter CPU features reported by QEMU
Some features may be on our ignore list because they do nothing even
though QEMU still supports them and reports their state. But as the
features do nothing, the state reported by QEMU may not correspond to
what the guest sees. To avoid possible confusion we may just pretend
QEMU did not report any of the features on our ignore list.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Fri, 24 Oct 2025 13:36:18 +0000 (15:36 +0200)]
qemu_process: Always fix CPUs on reconnect
We fix CPUs (i.e., remove ignored CPU features) only when libvirt/QEMU
combo used to start the domain is very old and doesn't support
query-cpu-model-expansion, in which case the CPU definition may contain
features that are unknown to QEMU. But even if both libvirt and QEMU are
new enough, we still want to remove features that do nothing to minimize
confusion or to avoid false migration issues.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Fri, 24 Oct 2025 13:27:03 +0000 (15:27 +0200)]
qemu_domain: Fix qemuDomainFixupCPUs
The function was apparently created when the list of ignored CPU
features contained just cmt and related features. The list grew quite a
bit since then and this function stopped making sense as it would remove
all ignored features from CPU definitions but only if cmt was present.
The issue with cmt is long gone and this function was not really doing
anything. Surprisingly this didn't cause any real issues as we don't
update CPU definitions with features unknown to QEMU. But we may still
want to remove ignored features even though QEMU knows about them for
compatibility reasons.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Jiri Denemark [Fri, 24 Oct 2025 13:07:45 +0000 (15:07 +0200)]
cpu_conf: Make virCPUDefFilterFeatures return void
The only thing that can fail inside virCPUDefFilterFeatures is
VIR_DELETE_ELEMENT_INPLACE macro. The macro just calls
virDeleteElementsN, which reports a warning when all elements to be
removed are not within the array bounds and returns -1. The function
succeeds otherwise. But since VIR_DELETE_ELEMENT_INPLACE sets the number
of elements to be removed to 1 and we call it with i < cpu->nfeatures,
the safety check in virDeleteElementsN will never fail. And even if we
theoretically called it with wrong arguments, it just wouldn't do
anything.
Thus we can safely assume VIR_DELETE_ELEMENT_INPLACE always succeeds in
virCPUDefFilterFeatures and avoid reporting any errors to simplify
callers.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
Michal Privoznik [Thu, 23 Oct 2025 13:33:04 +0000 (15:33 +0200)]
ch: Load ch.conf from SYSCONFDIR
Config files for system instances of our drivers (e.g.
"ch:///system", "qemu:///system", etc.) live under /etc/libvirt.
But for some reason, the CH driver was trying to load the config
file from /var/lib/libvirt/ch/ even though the file is installed
under /etc/libvirt per the following line from src/meson.build:
Michal Privoznik [Fri, 31 Oct 2025 09:43:27 +0000 (10:43 +0100)]
drvch: Demote example section to a subsection
In our drvch.rst there's a section with example XML. Demote it to
a subsection ('-') since the whole document starts with section
('=') and this paragraph is really just a child of the root.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Fri, 31 Oct 2025 09:39:05 +0000 (10:39 +0100)]
docs: Document supported URIs for CH driver
Our docs suggest that only session mode is supported for CH
drvier. Well, that's clearly not case. Document the system URI
and refer to other (remote) supported transport modes (yeah, that
works too).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Wed, 29 Oct 2025 11:43:39 +0000 (12:43 +0100)]
domain_conf: Avoid memory leak in virDomainMemoryDefFree()
In my one of my recent commits I've introduced new member to
virDomainMemoryDef struct. While allocated in
virDomainMemoryDefParseXML() its counterpart for freeing is
missing in virDomainMemoryDefFree(). Add it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Michal Privoznik [Mon, 27 Oct 2025 13:28:08 +0000 (14:28 +0100)]
qemu_command: Generate virtio options for memory device
Thanks to previous refactors (namely v11.1.0-rc1~142) this is
trivial. There's all the infrastructure needed to generate virtio
options onto cmd line, all that's left to do is set a pointer to
appropriate struct member.
Resolves: https://issues.redhat.com/browse/RHEL-7493 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Mon, 27 Oct 2025 10:38:57 +0000 (11:38 +0100)]
conf: Introduce virtio options for virtio memory models
Both virtio-mem and virtio-pmem memory models are virtio devices
and as such support setting various virtio knobs (iommu, ats,
packed, page_per_vq) common to other virtio devices.
Introduce <driver/> element as a child to <memory/> element, just
like we do for other virtio devices, where aforementioned knobs
live.
NB, this is without docs changes, since we do not document which
virtio devices support these knobs and each one is already
documented.
Also, the virtio-options.xml test needed some additional
adjustment (apart from adding virtio-mem device) to enable memory
hotplug.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Mon, 27 Oct 2025 14:05:47 +0000 (15:05 +0100)]
qemu: Use virDomainMemoryIsVirtioModel()
Instead of having these big switch()-es that enumerate all memory
models (but act only on virtio models), let's use
virDomainMemoryIsVirtioModel() helper instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Michal Privoznik [Mon, 27 Oct 2025 10:55:46 +0000 (11:55 +0100)]
domain_conf: Make virDomainMemoryDefFormat() return void
The only thing that's possibly making virDomainMemoryDefFormat()
fail is call to virDomainMemorySourceDefFormat() but that always
returns zero. Make both functions return void so callers are not
confused.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
bhyve: do not allow more than one NVMe device per controller
As bhyve does not have explicit notion of controllers, and for NVMe
devices it allows to specify one a single source for for a given PCI
address, it effectively means that there could be only one device per
controller.
Update validation code to check this case.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
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>
projects / thirdparty / libvirt.git / log
