[PATCH v2] virnetdevtap: Fix memory leak in virNetDevTapReattachBridge
by liu.song13＠zte.com.cn
From: QiangWei Zhang <zhang.qiangwei(a)zte.com.cn>
Variable 'master' needs to be free because it will be reassigned in
virNetDevOpenvswitchInterfaceGetMaster().
The leaked stack:
Direct leak of 11 byte(s) in 1 object(s) allocated from:
#0 0x7f7dad8ba6df in __interceptor_malloc (/lib64/libasan.so.8+0xba6df)
#1 0x7f7dad715728 in g_malloc (/lib64/libglib-2.0.so.0+0x60728)
#2 0x7f7dad72d8b2 in g_strdup (/lib64/libglib-2.0.so.0+0x788b2)
#3 0x7f7dacb63088 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321
#4 0x7f7dacb63088 in virNetDevGetName ../src/util/virnetdev.c:823
#5 0x7f7dacb63886 in virNetDevGetMaster ../src/util/virnetdev.c:909
#6 0x7f7dacb90288 in virNetDevTapReattachBridge ../src/util/virnetdevtap.c:527
#7 0x7f7dacd5cd67 in virDomainNetNotifyActualDevice ../src/conf/domain_conf.c:30505
#8 0x7f7da3a10bc3 in qemuProcessNotifyNets ../src/qemu/qemu_process.c:3290
#9 0x7f7da3a375c6 in qemuProcessReconnect ../src/qemu/qemu_process.c:9211
#10 0x7f7dacc0cc53 in virThreadHelper ../src/util/virthread.c:256
#11 0x7f7dac2875d4 in start_thread (/lib64/libc.so.6+0x875d4)
#12 0x7f7dac3091bb in __GI___clone3 (/lib64/libc.so.6+0x1091bb)
Fixes: de938b92c9d3a47647164aa643c20d2fc96cd2bc
Signed-off-by: QiangWei Zhang <zhang.qiangwei(a)zte.com.cn>
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/util/virnetdevtap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/util/virnetdevtap.c b/src/util/virnetdevtap.c
index 1dc77f0f5c..f26afb2ce0 100644
--- a/src/util/virnetdevtap.c
+++ b/src/util/virnetdevtap.c
@@ -541,6 +541,9 @@ virNetDevTapReattachBridge(const char *tapname,
/* IFLA_MASTER for a tap on an OVS switch is always "ovs-system" */
if (STREQ_NULLABLE(master, "ovs-system")) {
useOVS = true;
+
+ /* master needs to be released here because it will be reassigned */
+ g_clear_pointer(&master, g_free);
if (virNetDevOpenvswitchInterfaceGetMaster(tapname, &master) < 0)
return -1;
}
--
2.27.0
2 weeks, 1 day
[PATCH v2] virnetdevtap: Fix memory leak in virNetDevTapReattachBridge
by liu.song13＠zte.com.cn
From: QiangWei Zhang <zhang.qiangwei(a)zte.com.cn>
Variable 'master' needs to be free because it will be reassigned in
virNetDevOpenvswitchInterfaceGetMaster().
The leaked stack:
Direct leak of 11 byte(s) in 1 object(s) allocated from:
#0 0x7f7dad8ba6df in __interceptor_malloc (/lib64/libasan.so.8+0xba6df)
#1 0x7f7dad715728 in g_malloc (/lib64/libglib-2.0.so.0+0x60728)
#2 0x7f7dad72d8b2 in g_strdup (/lib64/libglib-2.0.so.0+0x788b2)
#3 0x7f7dacb63088 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321
#4 0x7f7dacb63088 in virNetDevGetName ../src/util/virnetdev.c:823
#5 0x7f7dacb63886 in virNetDevGetMaster ../src/util/virnetdev.c:909
#6 0x7f7dacb90288 in virNetDevTapReattachBridge ../src/util/virnetdevtap.c:527
#7 0x7f7dacd5cd67 in virDomainNetNotifyActualDevice ../src/conf/domain_conf.c:30505
#8 0x7f7da3a10bc3 in qemuProcessNotifyNets ../src/qemu/qemu_process.c:3290
#9 0x7f7da3a375c6 in qemuProcessReconnect ../src/qemu/qemu_process.c:9211
#10 0x7f7dacc0cc53 in virThreadHelper ../src/util/virthread.c:256
#11 0x7f7dac2875d4 in start_thread (/lib64/libc.so.6+0x875d4)
#12 0x7f7dac3091bb in __GI___clone3 (/lib64/libc.so.6+0x1091bb)
Fixes: de938b92c9d3a47647164aa643c20d2fc96cd2bc
Signed-off-by: QiangWei Zhang <zhang.qiangwei(a)zte.com.cn>
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>
---
src/util/virnetdevtap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/util/virnetdevtap.c b/src/util/virnetdevtap.c
index 1dc77f0f5c..f26afb2ce0 100644
--- a/src/util/virnetdevtap.c
+++ b/src/util/virnetdevtap.c
@@ -541,6 +541,9 @@ virNetDevTapReattachBridge(const char *tapname,
/* IFLA_MASTER for a tap on an OVS switch is always "ovs-system" */
if (STREQ_NULLABLE(master, "ovs-system")) {
useOVS = true;
+
+ /* master needs to be released here because it will be reassigned */
+ g_clear_pointer(&master, g_free);
if (virNetDevOpenvswitchInterfaceGetMaster(tapname, &master) < 0)
return -1;
}
--
2.27.0
2 weeks, 1 day
Question about SEV* guests and automatic firmware selection
by Jim Fehlig
Hi All,
While investigating an internal bug report, we noticed that a minimal firmware
auto-selection configuration along with SEV* fails to find a match. E.g. the
following config
<domain type="kvm">
<os firmware="efi">
<type arch="x86_64" machine="q35">hvm</type>
<boot dev="hd"/>
</os>
<launchSecurity type="sev">
<policy>0x07</policy>
</launchSecurity>
...
</domain>
Fails with "Unable to find 'efi' firmware that is compatible with the current
configuration". A firmware that should match has the following json description
{
"description": "UEFI firmware for x86_64, with AMD SEV",
"interface-types": [
"uefi"
],
"mapping": {
"device": "flash",
"mode": "stateless",
"executable": {
"filename": "/usr/share/qemu/ovmf-x86_64-sev.bin",
"format": "raw"
}
},
"targets": [
{
"architecture": "x86_64",
"machines": [
"pc-q35-*"
]
}
],
"features": [
"acpi-s4",
"amd-sev",
"amd-sev-es",
"amd-sev-snp",
"verbose-dynamic"
],
"tags": [
]
}
Auto-selection works fine if I specify a 'stateless' firmware, e.g. amend the
above config with
<os firmware="efi">
<type arch="x86_64" machine="q35">hvm</type>
<loader stateless="yes"/>
<boot dev="hd"/>
</os>
Being unfamiliar with the firmware auto-selection code, I tried the below naive
hack, which only led to test failures and the subsequent runtime error "unable
to find any master var store for loader: /usr/share/qemu/ovmf-x86_64-sev.bin".
Should auto-selection work with the minimal config, or is it expected that user
also specify a stateless firmware?
Regards,
Jim
diff --git a/src/qemu/qemu_firmware.c b/src/qemu/qemu_firmware.c
index 2d0ec0b4fa..660b74141a 100644
--- a/src/qemu/qemu_firmware.c
+++ b/src/qemu/qemu_firmware.c
@@ -1293,15 +1293,17 @@ qemuFirmwareMatchDomain(const virDomainDef *def,
return false;
}
- if (loader && loader->stateless == VIR_TRISTATE_BOOL_YES) {
- if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) {
- VIR_DEBUG("Discarding loader without stateless flash");
- return false;
- }
- } else {
- if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_SPLIT) {
- VIR_DEBUG("Discarding loader without split flash");
- return false;
+ if (loader) {
+ if (loader->stateless == VIR_TRISTATE_BOOL_YES) {
+ if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_STATELESS) {
+ VIR_DEBUG("Discarding loader without stateless flash");
+ return false;
+ }
+ } else if (loader->stateless == VIR_TRISTATE_BOOL_NO) {
+ if (flash->mode != QEMU_FIRMWARE_FLASH_MODE_SPLIT) {
+ VIR_DEBUG("Discarding loader without split flash");
+ return false;
+ }
}
}
2 weeks, 2 days
[PATCH RESEND 0/6] Add support for configuring PCI high memory MMIO size
by Matthew R. Ochs
Resending: Series has been re-based over latest upstream.
This patch series adds support for configuring the PCI high memory MMIO
window size for aarch64 virt machine types. This feature has been merged
into the QEMU upstream master branch [1] and will be available in QEMU 10.0.
It allows users to configure the size of the high memory MMIO window above
4GB, which is particularly useful for systems with large amounts of PCI
memory requirements.
The feature is exposed through the domain XML as a new PCI feature:
<features>
<pci>
<highmem-mmio-size unit='G'>512</highmem-mmio-size>
</pci>
</features>
When enabled, this configures the size of the PCI high memory MMIO window
via QEMU's highmem-mmio-size machine property. The feature is only
available for aarch64 virt machine types and requires QEMU support.
This series depends on [2] and should be applied on top of those patches.
For your convenience, this series is also available on Github [3].
[1] https://github.com/qemu/qemu/commit/f10104aeae3a17f181d5bb37b7fd7dad7fe86cba
[2] https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/Z4...
[3] git fetch https://github.com/nvmochs/libvirt.git pci_highmem_mmio_size
Signed-off-by: Matthew R. Ochs <mochs(a)nvidia.com>
Matthew R. Ochs (6):
domain: Add PCI configuration feature infrastructure
schema: Add PCI configuration feature schema
conf: Add PCI configuration XML parsing and formatting
qemu: Add capability for PCI high memory MMIO size
qemu: Add command line support for PCI high memory MMIO size
tests: Add tests for machine PCI features
src/conf/domain_conf.c | 103 ++++++++++++++++++
src/conf/domain_conf.h | 6 +
src/conf/schemas/domaincommon.rng | 9 ++
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 6 +
src/qemu/qemu_validate.c | 15 +++
.../caps_10.0.0_aarch64.replies | 10 ++
.../caps_10.0.0_aarch64.xml | 1 +
...rch64-virt-machine-pci.aarch64-latest.args | 31 ++++++
...arch64-virt-machine-pci.aarch64-latest.xml | 30 +++++
.../aarch64-virt-machine-pci.xml | 20 ++++
tests/qemuxmlconftest.c | 2 +
13 files changed, 236 insertions(+)
create mode 100644 tests/qemuxmlconfdata/aarch64-virt-machine-pci.aarch64-latest.args
create mode 100644 tests/qemuxmlconfdata/aarch64-virt-machine-pci.aarch64-latest.xml
create mode 100644 tests/qemuxmlconfdata/aarch64-virt-machine-pci.xml
--
2.46.0
2 weeks, 2 days
[PATCH v2 0/4] Fix build without libnl
by Michal Privoznik
v2 of:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/VY...
diff to v1:
1) Patch 1/5 from the original is dropped, no symbol addition to the
private syms file,
2) The "virnetlink.h" is included more often in patch 3/4,
3) Some fixes around virNetlinkBridgeVlanFilterSet() stub
Michal Prívozník (4):
virnetlink: Provide stub for virNetlinkBridgeVlanFilterSet()
virnetdevbridge.c: Fix comments in virNetDevBridgeSetupVlans()
virnetdevbridge: Include virnetlink.h more often
virnetlink: Split virNetlinkBridgeVlanFilterSet()
src/util/virnetdevbridge.c | 18 ++++-----
src/util/virnetlink.c | 83 ++++++++++++++++++++++++++++++++++----
src/util/virnetlink.h | 5 ++-
3 files changed, 88 insertions(+), 18 deletions(-)
--
2.49.0
2 weeks, 2 days
[PATCH 0/5] Fix build without libnl
by Michal Privoznik
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/770
While the original issue report describes scenario where libnl devel
package wasn't installed, it's perfectly reproducible with
-Dlibnl=disabled passed to meson.
Michal Prívozník (5):
libvirt_private.syms: Export virNetlinkBridgeVlanFilterSet
virnetlink: Provide stub for virNetlinkBridgeVlanFilterSet()
virnetdevbridge.c: Fix comments in virNetDevBridgeSetupVlans()
virnetdevbridge: Include virnetlink.h always
virnetlink: Split virNetlinkBridgeVlanFilterSet()
src/libvirt_private.syms | 2 +
src/util/virnetdevbridge.c | 18 ++++-----
src/util/virnetlink.c | 82 ++++++++++++++++++++++++++++++++++----
src/util/virnetlink.h | 5 ++-
4 files changed, 89 insertions(+), 18 deletions(-)
--
2.49.0
2 weeks, 2 days
[PATCH 0/2] virtio-net queue handling fixes
by Peter Krempa
Peter Krempa (2):
virNetDevTapCreate: Use error message hinting to multiqueue use only
when opening multiple queues
virDomainNetDefCheckABIStability: Consider virtio 'queues' ABI
src/conf/domain_conf.c | 11 +++++++++++
src/util/virnetdevtap.c | 2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
--
2.49.0
2 weeks, 2 days
Re: [PATCH v4 00/27] hw/i386/pc: Remove deprecated 2.6 and 2.7 PC
machines
by Igor Mammedov
On Thu, 8 May 2025 15:35:23 +0200
Philippe Mathieu-Daudé <philmd(a)linaro.org> wrote:
> Since v3:
> - Addressed Thomas and Zhao review comments
> - Rename fw_cfg_init_mem_[no]dma() helpers
> - Remove unused CPU properties
> - Remove {multi,linux}boot.bin
> - Added R-b tags
>
> Since v2:
> - Addressed Mark review comments and added his R-b tags
>
> The versioned 'pc' and 'q35' machines up to 2.12 been marked
> as deprecated two releases ago, and are older than 6 years,
> so according to our support policy we can remove them.
>
> This series only includes the 2.6 and 2.7 machines removal,
> as it is a big enough number of LoC removed. Rest will
> follow.
CCing libvirt folks
series removes some properties that has been used as compat
knobs with 2.6/2.7 machine types that are being removed.
However libvirt might still use them,
please check if being removed properties are safe to remove
as is | should be deprecated 1st | should be left alone
from an immediate user perspective.
>
> Based-on: <20250506143905.4961-1-philmd(a)linaro.org>
>
[...]
2 weeks, 2 days
