Plans for 11.4.0 release (freeze on 2025-05-27)
by Jiri Denemark
We are getting close to 11.4.0 release of libvirt. To aim for the
release on Monday 02 Jun I suggest entering the freeze on Tuesday 27 May
and tagging RC2 on Friday 30 May.
I hope this works for everyone.
Jirka
3 hours, 9 minutes
[PATCH] virConnectAuthCallbackDefault: Return failure if 'virGetPassword' returns NULL
by Peter Krempa
From: Peter Krempa <pkrempa(a)redhat.com>
virGetPassword can return NULL on linux or BSD if it fails. The caller
in virConnectAuthCallbackDefault does dereference it unconditionally.
Return failure if virGetPassword returns NULL.
Fixes: db72866310d1e520efa8ed2d4589bdb5e76a1c95
Closes: https://gitlab.com/libvirt/libvirt/-/issues/777
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/libvirt.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/libvirt.c b/src/libvirt.c
index 581fc6deea..375d3fa7ef 100644
--- a/src/libvirt.c
+++ b/src/libvirt.c
@@ -158,7 +158,9 @@ virConnectAuthCallbackDefault(virConnectCredentialPtr cred,
if (fflush(stdout) != 0)
return -1;
- bufptr = virGetPassword();
+ if (!(bufptr = virGetPassword()))
+ return -1;
+
if (STREQ(bufptr, ""))
VIR_FREE(bufptr);
break;
--
2.49.0
13 hours, 21 minutes
[PATCH] NEWS: Mention removal of compile time helper program lookup, virito-net ABI check and FDC capabilities
by Peter Krempa
From: Peter Krempa <pkrempa(a)redhat.com>
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
---
NEWS.rst | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index fd577021b3..884fcad2d8 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -35,6 +35,24 @@ v11.4.0 (unreleased)
<nvram/>
</os>
+ * All helper programs are now detected from ``$PATH`` during runtime
+
+ All of the code was now converted to dynamically look up helper programs
+ in ``$PATH`` rather than doing the lookup at build time and then compiling
+ in the result.
+
+ Programs ``mount``, ``umount``, ``mkfs``, ``modprobe``, ``rmmod``,
+ ``numad``, ``dmidecode``, ``ip``, ``tc``, ``mdevctl``, ``mm-ctl``,
+ ``iscsiadm``, ``ovs-vsctl``, ``pkttyagent``, ``bhyveload``, ``bhyvectl``,
+ ``bhyve``, ``ifconfig``, ``vzlist``, ``vzctl``, ``vzmigrate``, and the
+ tools from the lvm suite (``vgchange``, ``lvcreate``, etc..) are now not
+ needed during build and will still work properly if placed in ``$PATH``.
+
+ * qemu: Improve accuracy of FDC/floppy device support statement in capabilities XML
+
+ The data is now based on the presence of the controller in qemu rather than
+ just a denylist of machine types where floppies not work.
+
* **Bug fixes**
* qemu: Fix failure when reverting to internal snapshots
@@ -52,6 +70,13 @@ v11.4.0 (unreleased)
destination host to crash when trying to resume failed post-copy
migration.
+ * qemu: Treat the ``queues`` configuration of ``virtio-net`` as guest ABI
+
+ The queue count itself isn't a device frontend property but libvirt uses
+ it to calculate ``vectors`` option of the device which is a guest OS visible
+ property, thus ``queues`` must not change during migration. The ABI stability
+ check now handles this properly.
+
v11.3.0 (2025-05-02)
====================
--
2.49.0
19 hours, 23 minutes
[PATCH 0/3] util: Fix virFileIsSharedFSOverride on nonexistent paths
by Jiri Denemark
Jiri Denemark (3):
util: Document limitation of virFileCanonicalizePath
util: Introduce virFileGetExistingParent helper
util: Fix virFileIsSharedFSOverride on nonexistent paths
src/util/virfile.c | 76 +++++++++++++++++++++++++++-------------------
1 file changed, 45 insertions(+), 31 deletions(-)
--
2.49.0
22 hours, 19 minutes
[PATCH 00/15] storage_file_probe: Fix ancient bug in qcow2 header extensions parser and refactor the image probing callbacks
by Peter Krempa
Patch 3 fixes an almost 15 year old bug in the qcow2 header extension
parser which breaks when the qcow2 image has more than 1 header
extension. For us it caused problems for qcow2 images with data file and
backing file which we didn't use before, and the only field we cared
about was always put first by qemu.
Ironically we did have a test file that had such config but it was
missed in the test output.
Patches 1, 2 are refinment of debug tools I used to see what's
happening.
Patch 4 adds bitmaps to some test images. We don't parse them but just
to be sure.
The rest of the series refactors the metadata parser callbacks with the
end goal to not parse the qcow2 header extensions twice.
Peter Krempa (15):
qcow2GetExtensions: Add debug logs for interesting fields in qcow2
header extension parser
virstoragetest: Reformat output to hilight dataFile relationship
storage_file_probe: qcow2GetExtensions: Fix qcow2 header extension
parsing
virstoragetest: Add qcow2 bitmaps to some images
storage_file_probe: Add image specific callback taking the whole
virStorageSource
storage_file_probe: Refactor cowGetBackingStore into
cowGetImageSpecific
storage_file_probe: Refactor qedGetBackingStore into
qedGetImageSpecific
storage_file_probe: Refactor vmdk4GetBackingStore into
vmdk4GetImageSpecific
storage_file_probe: Refactor qcowXGetBackingStore into specific
callbacks for qcow and qcow2
storage_file_probe: Move logic from qcow2GetClusterSize to
qcow2GetImageSpecific
storage_file_probe: Move qcow2GetFeatures(ProcessGroup) functions
storage_file_probe: Call qcow2GetFeatures from qcow2GetImageSpecific
storage_file_probe: Parse all qcow2 extensions at once
storage_file_probe: Move setting of 'compat' attribute to
qcow2GetFeatures
storage_file_probe: Remove unused image probing callbacks
src/storage_file/storage_file_probe.c | 439 ++++++++----------
tests/virstoragetest.c | 20 +-
.../virstoragetestdata/images/datafile.qcow2 | Bin 327680 -> 393256 bytes
.../images/qcow2_qcow2-qcow2_qcow2-auto.qcow2 | Bin 196616 -> 327720 bytes
.../images/qcow2datafile-datafile.qcow2 | Bin 196616 -> 327720 bytes
tests/virstoragetestdata/out/directory-dir | 1 +
tests/virstoragetestdata/out/directory-none | 1 +
tests/virstoragetestdata/out/directory-raw | 1 +
.../out/qcow2-auto_qcow2-qcow2_raw-raw | 1 +
.../out/qcow2-auto_raw-raw-relative | 1 +
tests/virstoragetestdata/out/qcow2-datafile | 15 +-
.../out/qcow2-protocol-backing-file | 2 +
.../out/qcow2-protocol-backing-nbd | 2 +
.../out/qcow2-qcow2_nbd-raw | 2 +
.../out/qcow2-qcow2_qcow2-auto | 2 +
.../out/qcow2-qcow2_qcow2-qcow2_qcow2-auto | 3 +
.../out/qcow2-qcow2_qcow2-qcow2_raw-auto | 3 +
.../out/qcow2-qcow2_qcow2-qcow2_raw-raw | 3 +
.../out/qcow2-qcow2_raw-raw-relative | 2 +
tests/virstoragetestdata/out/qcow2-symlinks | 3 +
.../out/qcow2datafile-qcow2_qcow2-datafile | 24 +-
tests/virstoragetestdata/out/qed-auto_raw | 1 +
tests/virstoragetestdata/out/qed-qed_raw | 2 +
tests/virstoragetestdata/out/raw-auto | 1 +
tests/virstoragetestdata/out/raw-raw | 1 +
25 files changed, 263 insertions(+), 267 deletions(-)
--
2.49.0
22 hours, 34 minutes
[PATCH 0/3] bhyve: implement domainInterfaceStats and domainMemoryStats
by Roman Bogorodskiy
Roman Bogorodskiy (3):
bhyve: implement domainInterfaceStats
virprocess: implement virProcessGetStatInfo() for FreeBSD
bhyve: implement domainMemoryStats
src/bhyve/bhyve_driver.c | 84 +++++++++++++++++++++++++++++++
src/util/virprocess.c | 104 +++++++++++++++++++++++++++++----------
2 files changed, 162 insertions(+), 26 deletions(-)
--
2.49.0
23 hours, 17 minutes
Re: [RFC PATCH v3 4/6] qemucapabilitiestest: Adds Arm CCA support
by Peter Krempa
On Thu, May 29, 2025 at 05:10:48 +0000, Kazuhiro Abe (Fujitsu) wrote:
>
> On 5/20/25 17:54, Peter Krempa wrote:
> > On Tue, May 20, 2025 at 17:28:26 +0900, Kazuhiro Abe wrote:
> > > From: Akio Kakuno <fj3333bs(a)fujitsu.com>
> > >
> > > - This test was added to check qemu capabilities for Arm
> > > CCA support.
> >
> > IF
> >
> > > This test was created using the method described in the
> > > documentation.
> > >
> > > Signed-off-by: Kazuhiro Abe <fj1078ii(a)aa.jp.fujitsu.com>
> > > ---
> > > .../caps_9.1.0_aarch64.replies | 36222
> > ++++++++++++++++
> > > .../caps_9.1.0_aarch64.xml | 530 +
> > > 2 files changed, 36752 insertions(+)
> > > create mode 100644
> > > tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies
> > > create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_aarch64.xml
> >
> > Note that I'll be commenting only on the capability testing related matter, not the
> > rest of the series.
> >
> > > diff --git a/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies
> > > b/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies
> > > new file mode 100644
> > > index 0000000000..906a21f0c6
> > > --- /dev/null
> > > +++ b/tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies
> > > @@ -0,0 +1,36222 @@
> > > +{
> > > + "execute": "qmp_capabilities",
> > > + "id": "libvirt-1"
> > > +}
> > > +
> > > +{
> > > + "return": {},
> > > + "id": "libvirt-1"
> > > +}
> > > +
> > > +{
> > > + "execute": "query-version",
> > > + "id": "libvirt-2"
> > > +}
> > > +
> > > +{
> > > + "return": {
> > > + "qemu": {
> > > + "micro": 91,
> > > + "minor": 1,
> > > + "major": 9
> >
> > This is from 9.2.0-rc1. So firstly the file is named wrong, because it was supposed
> > to be 'caps_9.2.0_aarch64.replies' instead.
> >
> > Also except for the currently developed release we require that the .replies files
> > are generated from the final release versions and not the RCs or any other
> > non-final code.
> >
> > The libvirt tree already has qemu caps for 9.2.0 and 10.0.0 for aarch64.
> >
> > What makes these special?
> >
> > If there's a reason to have specific capabilities please add a 'variant'
> > per tests/qemucapabilitiesdata/README.rst
>
> Thanks for your comment.
>
> These were generated from a special QEMU version which support ARM CCA based on 9.2.
> So as a temporary measure, I will add a variant to the replies file,
> and the name will be caps_9.2.0_aarch64+armrme.replies.
I'd expect that now that qemu-10.0 is out you'd be targetting at least
qemu-10.1 [1] as ...
>
> Note that, once the patch about Arm CCA support is merged,
> we will change the replies file name.
... it's not yet merged as you are saying.
[1] We do allow capabilities captured from the currently in development
tree but:
- they must be based on a commit from official qemu git
- you will have to update them to the final version once qemu-N+1
releases.
But since it's not merged yet your patch will need to stay RFC. Please
make sure thoug to note it in the capabilities patch that it's not the
final version yet so that there's no confusion.
Your patch looked like it was something which already exists based on
the commit message and I didn't read the cover letter because I wasn't
too interested in the series itself, I'm just making sure that
capabilities dumps are handled properly so that I don't have to deal
with it later.
1 day, 3 hours
[RFC PATCH v3 0/6] RFC: Add Arm CCA support for getting capability information and running Realm VM
by Kazuhiro Abe
Hi, all.
This patch adds Arm CCA support to QEMU driver for aarch64 system.
CCA is an abbreviation for Arm Confidential Compute Architecture
feature, it enhances the virtualization capabilities of
the platform by separating the management of resources from access
to those resources.
We are not yet at the stage where we can merge this patch as host
Linux/QEMU support is not yet merged, but I would like to receive
reviews and comments on the overall direction.
Changes in v3:
Supports two launch VM options: personalization-value and
measurement-log.
The measurement-log was added to allow us to check if the data
loaded into the guest RAM is a good image.
The Realm Personalization Value (RPV) was added to allow us to
distinguish between realms that have the same initial measurement
results.
This was added as a new Realm startup option in Linaro QEMU after
the v2 patch was posted. That's why we made this change.
[summary]
At this stage, all you can do is getting the CCA capability with
the virsh domcapabilities command and start the CCA VM with
the virsh create command.
capability info uses QEMU QMP to query QEMU options. The option
that exists now is for selecting a hash algorithm.
QEMU QMP sections currently only contains a single member, but
is wrapped in sections for expansion.
[Capability example]
Execution results of 'virsh domcapability" on QEMU
<domaincapabilities>
...
<features>
...
</sgx>
<cca supported='yes'>
<enum name='measurement-algo'>
<value>sha256</value>
<value>sha512</value>
</enum>
</cca>
<hyperv supported='yes'>
...
</features>
</domaincapabilities>
[XML example]
<domain>
...
<launchsecurity type='cca'>
<measurement-algo>sha256</measurement-algo>
</launchsecurity>
...
</domain>
[limitations/tests]
To obtain capability info, it is necessary to support the QEMU QMP
command, which QEMU does not yet support. We added a QMP
command to retrieve CCA info for test (See "[software version]"
below). I need to check qemu_firmware.c to see if my CPU firmware
supports CCA. Since it's not implemented yet, I'll wait until a Linux
distributor provides me with a JSON file for CCA.
We have confirmed that the added tests (qemucapabilitiestest,
domaincapstest and qemuxmlconftest) and the CCA VM startup test
(starting the CCA VM from the virsh create command) passed.
The "personalization-value" and "measurement-log" parameters that
exist in the current Linaro QEMU cca/latest branch will not be
specified as CCA VM startup parameters with the virsh create
command.
[software version]
I followed the steps in Linaro's blog below.
https://linaro.atlassian.net/wiki/spaces/QEMU/pages/29051027459/Building+...
The QEMU used was enhanced with CCA QMP command and found at:
https://github.com/Kazuhiro-Abe-fj/linaro_qemu/tree/cca-latest-qmp
which is based on Linaro QEMU (cca/latest)
https://git.codelinaro.org/linaro/dcap/qemu/-/tree/cca/latest?ref_type=heads
RFC v1:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/V4...
RFC v2:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/message/5...
Signed-off-by: Kazuhiro Abe <fj1078ii(a)aa.jp.fujitsu.com>
Akio Kakuno (6):
src: Add ARM CCA support in qemu driver to launch VM
src: Add ARM CCA support in domain capabilities command
src: Add ARM CCA support in domain schema
qemucapabilitiestest: Adds Arm CCA support
domaincapstest: Adds Arm CCA support
qemuxmlconftest: Adds Arm CCA support
docs/formatdomain.rst | 43 +
docs/formatdomaincaps.rst | 27 +-
src/conf/domain_capabilities.c | 48 +
src/conf/domain_capabilities.h | 12 +
src/conf/domain_conf.c | 25 +
src/conf/domain_conf.h | 9 +
src/conf/domain_validate.c | 1 +
src/conf/schemas/domaincaps.rng | 36 +
src/conf/schemas/domaincommon.rng | 26 +
src/conf/virconftypes.h | 2 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 145 +
src/qemu/qemu_capabilities.h | 4 +
src/qemu/qemu_cgroup.c | 2 +
src/qemu/qemu_command.c | 29 +
src/qemu/qemu_driver.c | 2 +
src/qemu/qemu_firmware.c | 1 +
src/qemu/qemu_monitor.c | 10 +
src/qemu/qemu_monitor.h | 3 +
src/qemu/qemu_monitor_json.c | 98 +
src/qemu/qemu_monitor_json.h | 4 +
src/qemu/qemu_namespace.c | 2 +
src/qemu/qemu_process.c | 4 +
src/qemu/qemu_validate.c | 4 +
src/security/security_dac.c | 2 +
.../qemu_9.1.0-virt.aarch64.xml | 244 +
tests/domaincapsdata/qemu_9.1.0.aarch64.xml | 244 +
.../caps_9.1.0_aarch64.replies | 36222 ++++++++++++++++
.../caps_9.1.0_aarch64.xml | 530 +
.../launch-security-cca.aarch64-latest.args | 30 +
.../launch-security-cca.aarch64-latest.xml | 24 +
tests/qemuxmlconfdata/launch-security-cca.xml | 16 +
tests/qemuxmlconftest.c | 2 +
33 files changed, 37851 insertions(+), 1 deletion(-)
create mode 100644 tests/domaincapsdata/qemu_9.1.0-virt.aarch64.xml
create mode 100644 tests/domaincapsdata/qemu_9.1.0.aarch64.xml
create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_aarch64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_9.1.0_aarch64.xml
create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest.args
create mode 100644 tests/qemuxmlconfdata/launch-security-cca.aarch64-latest.xml
create mode 100644 tests/qemuxmlconfdata/launch-security-cca.xml
--
2.43.5
1 day, 5 hours
[libvirt PATCHv2 0/7] qemu: introduce amd-iommu support
by Ján Tomko
Ján Tomko (7):
qemu: introduce QEMU_CAPS_AMD_IOMMU
qemu: introduce QEMU_CAPS_PCI_ID
qemu: add IOMMU model amd
docs: formatdomain: document intel-only IOMMU attributes
conf: add passthrough and xtsup attributes for IOMMU
conf: reject some attributes not applicable to intel IOMMU
qemu: format pt and xstup on the command line
docs/formatdomain.rst | 22 +++-
src/conf/domain_conf.c | 31 +++++
src/conf/domain_conf.h | 3 +
src/conf/domain_validate.c | 22 ++++
src/conf/schemas/domaincommon.rng | 11 ++
src/qemu/qemu_capabilities.c | 10 ++
src/qemu/qemu_capabilities.h | 2 +
src/qemu/qemu_command.c | 30 +++++
src/qemu/qemu_domain_address.c | 4 +
src/qemu/qemu_validate.c | 22 ++++
.../caps_10.0.0_x86_64+amdsev.replies | 102 +++++++++++------
.../caps_10.0.0_x86_64+amdsev.xml | 1 +
.../caps_10.0.0_x86_64.replies | 106 ++++++++++++------
.../caps_10.0.0_x86_64.xml | 2 +
.../caps_6.2.0_x86_64.replies | 102 +++++++++++------
.../caps_6.2.0_x86_64.xml | 1 +
.../caps_7.0.0_x86_64.replies | 80 +++++++------
.../caps_7.0.0_x86_64.xml | 1 +
.../caps_7.1.0_x86_64.replies | 102 +++++++++++------
.../caps_7.1.0_x86_64.xml | 1 +
.../caps_7.2.0_x86_64+hvf.replies | 102 +++++++++++------
.../caps_7.2.0_x86_64+hvf.xml | 1 +
.../caps_7.2.0_x86_64.replies | 102 +++++++++++------
.../caps_7.2.0_x86_64.xml | 1 +
.../caps_8.0.0_x86_64.replies | 80 +++++++------
.../caps_8.0.0_x86_64.xml | 1 +
.../caps_8.1.0_x86_64.replies | 102 +++++++++++------
.../caps_8.1.0_x86_64.xml | 1 +
.../caps_8.2.0_x86_64.replies | 102 +++++++++++------
.../caps_8.2.0_x86_64.xml | 1 +
.../caps_9.0.0_x86_64.replies | 80 +++++++------
.../caps_9.0.0_x86_64.xml | 1 +
.../caps_9.1.0_x86_64.replies | 102 +++++++++++------
.../caps_9.1.0_x86_64.xml | 1 +
.../caps_9.2.0_x86_64+amdsev.replies | 102 +++++++++++------
.../caps_9.2.0_x86_64+amdsev.xml | 1 +
.../caps_9.2.0_x86_64.replies | 102 +++++++++++------
.../caps_9.2.0_x86_64.xml | 1 +
.../amd-iommu.x86_64-latest.args | 35 ++++++
.../amd-iommu.x86_64-latest.xml | 1 +
tests/qemuxmlconfdata/amd-iommu.xml | 39 +++++++
tests/qemuxmlconftest.c | 2 +
42 files changed, 1161 insertions(+), 454 deletions(-)
create mode 100644 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.args
create mode 120000 tests/qemuxmlconfdata/amd-iommu.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/amd-iommu.xml
--
2.49.0
1 day, 19 hours
[PATCH] qemu: Fix error when migration with shared TPM storage is unsupported
by Jiri Denemark
From: Jiri Denemark <jdenemar(a)redhat.com>
The VIR_ERR_NO_SUPPORT error is supposed to be used for unsupported
driver APIs. It is incorrectly used when swtpm does not support
migration with shared storage resulting in a rather strange error
message:
this function is not supported by the connection driver: the running
swtpm does not support migration with shared storage
The correct VIR_ERR_OPERATION_UNSUPPORTED error code provides a much
better message:
Operation not supported: the running swtpm does not support
migration with shared storage
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/qemu/qemu_migration.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 1f91ad1117..2400750ee4 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -1723,7 +1723,7 @@ qemuMigrationSrcIsAllowed(virDomainObj *vm,
if (qemuTPMHasSharedStorage(driver, vm->def) &&
!qemuTPMCanMigrateSharedStorage(vm->def)) {
- virReportError(VIR_ERR_NO_SUPPORT, "%s",
+ virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s",
_("the running swtpm does not support migration with shared storage"));
return false;
}
--
2.49.0
1 day, 22 hours
