[PATCH v1] virBitmapNextClearBit: Correct virBitmapNextClearBit function header comment
by Aaron M. Brown
This patch corrects the header comment for virBitmapNextClearBIt.
Currently, the header comment reads:
`@pos can be -1 to search for the first set bit.`
However, this statement is false.
We can prove this by referencing the virbitmaptest functions, i.e
virbitmaptest.c:223, in which i = 0
if (virBitmapNextClearBIt(bitmap, -1) != 0)
return -1
Because this is a zero set, this case would fail if the header statement was true as is.
Signed-off-by: Aaron M. Brown <aaronmbr(a)linux.ibm.com>
---
src/util/virbitmap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virbitmap.c b/src/util/virbitmap.c
index 8a3f33c806..1a3e75671c 100644
--- a/src/util/virbitmap.c
+++ b/src/util/virbitmap.c
@@ -948,7 +948,7 @@ virBitmapLastSetBit(virBitmap *bitmap)
* @pos: the position after which to search for a clear bit
*
* Search for the first clear bit after position @pos in bitmap @bitmap.
- * @pos can be -1 to search for the first set bit. Position starts
+ * @pos can be -1 to search for the first clear bit. Position starts
* at 0.
*
* Returns the position of the found bit, or -1 if no bit found.
--
2.39.5 (Apple Git-154)
2 days, 12 hours
[PATCH 0/2] virnetdevvportprofile: Misc cleanups
by Michal Privoznik
*** BLURB HERE ***
Michal Prívozník (2):
virnetdevvportprofile: Drop explicit enum virNetDevVPortProfile
declaration
virnetdevvportprofile: Turn 'virtPortType' of virNetDevVPortProfile
into proper enum type
src/conf/netdev_vport_profile_conf.c | 11 +++++------
src/hypervisor/virhostdev.c | 1 +
src/qemu/qemu_migration_cookie.c | 2 ++
src/util/virnetdevvportprofile.c | 19 ++++++++++++++++---
src/util/virnetdevvportprofile.h | 4 ++--
5 files changed, 26 insertions(+), 11 deletions(-)
--
2.49.1
2 days, 15 hours
[PATCH 0/5] secdriver: Misc cleanups
by Michal Privoznik
*** BLURB HERE ***
Michal Prívozník (5):
security: Drop some G_GNUC_UNUSED attributes
security_selinux: Drop needless checks for seclabel->model ==
"selinux"
security_dac: Drop needless checks for seclabel->model == "dac"
security_apparmor: Drop needless checks for seclabel->model ==
"apparmor"
security_dac: Drop needles typecast in virSecurityDACGenLabel()
src/security/security_apparmor.c | 18 +---------
src/security/security_dac.c | 14 ++------
src/security/security_selinux.c | 59 +++-----------------------------
3 files changed, 8 insertions(+), 83 deletions(-)
--
2.49.1
2 days, 16 hours
[PATCH v2 0/4] Some parsing functions refactor
by Kirill Shchetiniuk
This patch series is supposed to refactor the existing logic of
some parsing functions, changing the previous approach of getting
the string fisrt and then parsing the string itself. Now the
parsing logic is implemented by using the appropriate virXMLProp*
functions.
Changelog fromm v1:
1. 'ret' temp value is now 'rc'
2. code style fixes
3. 'id' param is now parsed as not mandatory
Kirill Shchetiniuk (4):
conf: virNetDevVPortProfileParse refactor
util: virSecretLookupParseSecret refactor
conf: virDomainChrDefParseTargetXML refactor
qemu: qemuDomainObjPrivateXMLParseVcpu refactor
src/conf/domain_conf.c | 16 +---
src/conf/netdev_vport_profile_conf.c | 112 +++++++++++----------------
src/qemu/qemu_domain.c | 16 +---
src/util/virsecret.c | 19 ++---
4 files changed, 55 insertions(+), 108 deletions(-)
--
2.49.0
2 days, 20 hours
[PATCH 0/4] qemu: add support for RBD namespace
by Peter Krempa
After recent inquiry on libvirt-users I've necromanced this already very
old series that I still had laying around.
This series:
- turns virStorageSource's 'protocol' to real enum
- removes virStorageSource's 'volume'
- wires in the RBD support
Han Han (1):
qemu: Add support for RBD namespace.
Peter Krempa (3):
conf: Turn 'protocol' field of virStorageSource into proper enum type
virStorageFileBackendGlusterInit: Refactor cleanup
virStorageSource: Eliminate 'volume' field
docs/formatdomain.rst | 6 ++
src/conf/domain_conf.c | 36 ++-------
src/conf/domain_validate.c | 2 +-
src/conf/storage_source_conf.c | 79 ++++++++++++++++++-
src/conf/storage_source_conf.h | 10 ++-
src/libvirt_private.syms | 1 +
src/libxl/libxl_conf.c | 4 +-
src/libxl/xen_xl.c | 4 +-
src/qemu/qemu_block.c | 41 ++++++----
src/qemu/qemu_domain.c | 2 +-
src/qemu/qemu_snapshot.c | 4 +-
.../storage_file_backend_gluster.c | 63 ++++++++-------
src/storage_file/storage_source.c | 2 -
.../storage_source_backingstore.c | 56 ++++---------
.../disk-network-rbd.x86_64-latest.args | 4 +-
.../disk-network-rbd.x86_64-latest.xml | 4 +-
tests/qemuxmlconfdata/disk-network-rbd.xml | 4 +-
17 files changed, 185 insertions(+), 137 deletions(-)
--
2.49.0
2 days, 23 hours
Clarification Needed: virsh snapshot-delete Behavior with External
Snapshots (--disk-only)
by P, Rajasekar
Hello libvirt community,
I am seeking clarification on the behavior of `virsh snapshot-delete` when used with external snapshots (created with the `--disk-only` option).
**Environment:**
- libvirt version: 10.5.0
- Kernel version: 5.14.0-503.22.1.el9_5.x86_64
- Disk image format: qcow2
- Host OS: RHEL 9.5
**Steps to reproduce:**
1. Create an external snapshot:
virsh snapshot-create-as --domain <vm> --name snap1 --disk-only --atomic
2. Delete the snapshot:
virsh snapshot-delete <vm> --snapshotname snap1
**Observed behavior:**
- Changes from the overlay (snapshot) file are merged into the base image.
- The snapshot metadata is removed from libvirt.
- The snapshot file remains on disk (appears orphaned).
**Questions:**
- Is the observed automatic merge of the overlay file into the base image during `snapshot-delete` the intended behavior for external snapshots in recent libvirt versions? Or we need separate `blockcommit` step.
- Should the snapshot file be deleted automatically, or is manual cleanup required?
- Is there any official documentation that clarifies this behavior for external snapshots, as most documentation seems to focus on internal snapshots?
Thank you for your help and clarification!
Best regards,
Raj.
3 days, 2 hours
[RFC PATCH 0/8] Add support for Grace ACPI Extended GPU Memory (EGM) devices
by Ian May
The Grace SOC introduces Extended GPU Memory (EGM) [3], a feature that enables
GPUs to efficiently access system memory within and across nodes. This patch
series adds support for virtualizing EGM (vEGM) in libvirt, allowing VMs to
utilize dedicated EGM memory regions through ACPI.
RFC Status
==========
This patch series is submitted as an RFC to gather feedback from the libvirt
community on the overall approach and implementation details. While kernel EGM
driver support and QEMU acpi-egm-memory device support are not yet upstream,
reference implementations are available [1][2] to enable testing and validation
of the libvirt integration.
Any community feedback is appreciated.
Background and Use Cases
=========================
EGM allows host memory to be partitioned into two regions:
1. Standard memory for Host OS usage
2. EGM region assigned to VMs as their system memory
This technology enables various high-performance computing scenarios [3]:
- Large memory pools for AI/ML workloads
- High-performance computing applications
- Memory extension for systems with limited main memory
- GPU-accelerated workloads requiring large addressable memory
Implementation Overview
=======================
This 8-patch series adds a new device type 'acpi-egm-memory' with the following structure:
1. Schema definition - Add XML schema definition for the new ACPI EGM memory device
2. XML parsing - Implement XML parsing and internal data structures
3. Capability detection - Add QEMU capability detection for EGM support
4. Validation - Add validation logic for EGM device configuration
5. Command generation - Implement QEMU command line generation
6. Resource management - Setup required cgroup and namespace configurations
7. Documentation - Add comprehensive documentation
8. Testing - Add qemuxmlconftest for ACPI EGM memory device
XML Configuration
=================
Example usage in domain XML:
<devices>
<hostdev mode="subsystem" type="pci" managed="yes">
<alias name="ua-hostdev0"/>
<source>
<address domain="0x0000" bus="0x01" slot="0x00" function="0x0"/>
</source>
</hostdev>
<acpiEgmMemory>
<alias name="egm0"/>
<pciDev>ua-hostdev0</pciDev>
<numaNode>0</numaNode>
</acpiEgmMemory>
</devices>
This configuration results in appropriate QEMU command line options:
-object memory-backend-file,id=m0,mem-path=/dev/egm0,size=32G,share=on,prealloc=on
-object acpi-egm-memory,id=egm0,pci-dev=ua-hostdev0,node=0
Implementation Notes
====================
The device validation includes checking that referenced PCI devices exist,
NUMA nodes are valid, and device paths are accessible with proper permissions.
Memory backing is configured automatically to use the EGM device path, and
cgroups/namespaces are set up to allow safe access.
Testing
=======
I've tested XML parsing, validation, and qemu command line generation. The
qemuxmlconftest passes for XML handling, though the command generation test
currently fails since QEMU doesn't have acpi-egm-memory support yet, but
the generated args look correct for when it does.
Requirements
============
This feature requires:
- NVIDIA ARM64 Grace platform with EGM support
- Host kernel with EGM driver support [1]
- QEMU with ACPI EGM device support [2]
[1] https://github.com/ianm-nv/NV-Kernels/tree/6.8_ghvirt_egm_may2025
[2] https://github.com/ianm-nv/qemu/tree/6.8_ghvirt_egm_may2025
[3] https://developer.nvidia.com/blog/nvidia-grace-hopper-superchip-architect...
Ian May (8):
conf: Add schema definition for ACPI EGM memory device
conf: Add definitions and XML parsing for ACPI EGM memory device
qemu: Add capability detection for ACPI EGM memory device
qemu: Add validation for ACPI EGM memory device configuration
qemu: Add command line generation for ACPI EGM memory device
qemu: Add cgroup and namespace setup for ACPI EGM memory device
docs: Document ACPI EGM memory device
tests: Add qemuxmlconftest for ACPI EGM memory device
docs/formatdomain.rst | 80 ++++++++++++++
src/ch/ch_domain.c | 1 +
src/conf/domain_conf.c | 102 ++++++++++++++++++
src/conf/domain_conf.h | 11 ++
src/conf/domain_postparse.c | 8 ++
src/conf/domain_validate.c | 23 ++++
src/conf/schemas/domaincommon.rng | 19 ++++
src/conf/virconftypes.h | 2 +
src/libxl/libxl_driver.c | 6 ++
src/lxc/lxc_driver.c | 6 ++
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_cgroup.c | 21 ++++
src/qemu/qemu_command.c | 37 +++++++
src/qemu/qemu_domain.c | 2 +
src/qemu/qemu_domain_address.c | 2 +
src/qemu/qemu_driver.c | 3 +
src/qemu/qemu_hotplug.c | 5 +
src/qemu/qemu_namespace.c | 21 ++++
src/qemu/qemu_postparse.c | 1 +
src/qemu/qemu_validate.c | 99 +++++++++++++++++
src/test/test_driver.c | 4 +
tests/meson.build | 1 +
.../caps_10.0.0_aarch64.xml | 1 +
tests/qemuegmmock.c | 67 ++++++++++++
.../acpi-egm-memory.aarch64-latest.args | 1 +
.../acpi-egm-memory.aarch64-latest.xml | 56 ++++++++++
tests/qemuxmlconfdata/acpi-egm-memory.xml | 27 +++++
tests/qemuxmlconftest.c | 5 +-
29 files changed, 613 insertions(+), 1 deletion(-)
create mode 100644 tests/qemuegmmock.c
create mode 100644 tests/qemuxmlconfdata/acpi-egm-memory.aarch64-latest.args
create mode 100644 tests/qemuxmlconfdata/acpi-egm-memory.aarch64-latest.xml
create mode 100644 tests/qemuxmlconfdata/acpi-egm-memory.xml
--
2.43.0
3 days, 10 hours
[PATCH] news: document fixed nwfilter driver base chain creation
by Daniel P. Berrangé
From: Daniel P. Berrangé <berrange(a)redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
NEWS.rst | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index e5e8626729..c7bfac1db4 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -48,6 +48,14 @@ v11.6.0 (unreleased)
* **Bug fixes**
+ * The nwfilter driver no longer recreates the base iptable/ip6tables chains
+
+ The nwfilter driver had a impl mistake causing it to recreate the
+ base chains for iptables/ip6tables every time a VM was started.
+ This allowed a small window where traffic might not be fully
+ filtered. It now handles iptables/ip6tables the same way as
+ ebtables, creating the base chains only if they did not already
+ exist.
v11.5.0 (2025-07-01)
====================
--
2.50.1
3 days, 17 hours
