[PATCH v2 0/3] qemu: Add support for virtio sound model
by Rayhan Faizel
virtio-sound-pci and virtio-sound-device were recently introduced
in QEMU 8.2.0.
The full documentation of the virtio sound implementation in QEMU
can be found here:
https://www.qemu.org/docs/master/system/devices/virtio-snd.html
Example:
<sound model='virtio' streams='2'/>
[Changes in v2]
- Added missing break statement that went overlooked.
Rayhan Faizel (3):
qemu_capabilities: Add QEMU_CAPS_DEVICE_VIRTIO_SOUND capability
conf: Introduce support for virtio-sound devices
qemu: Generate command line for sound devices with model 'virtio'
docs/formatdomain.rst | 11 ++++-
src/conf/domain_conf.c | 25 +++++++++++
src/conf/domain_conf.h | 4 ++
src/conf/domain_postparse.c | 13 +++++-
src/conf/schemas/domaincommon.rng | 11 +++++
src/libxl/libxl_domain.c | 1 +
src/qemu/qemu_capabilities.c | 3 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 25 ++++++++++-
src/qemu/qemu_domain_address.c | 9 ++++
src/qemu/qemu_validate.c | 8 ++++
.../caps_8.2.0_aarch64.xml | 1 +
.../caps_8.2.0_armv7l.xml | 1 +
.../caps_8.2.0_loongarch64.xml | 1 +
.../qemucapabilitiesdata/caps_8.2.0_s390x.xml | 1 +
.../caps_8.2.0_x86_64.xml | 1 +
.../caps_9.0.0_x86_64.xml | 1 +
.../arm-vexpressa9-virtio.aarch64-latest.args | 1 +
.../arm-vexpressa9-virtio.aarch64-latest.xml | 3 ++
.../qemuxmlconfdata/arm-vexpressa9-virtio.xml | 3 +-
.../sound-device-virtio.x86_64-latest.args | 36 +++++++++++++++
.../sound-device-virtio.x86_64-latest.xml | 44 +++++++++++++++++++
tests/qemuxmlconfdata/sound-device-virtio.xml | 28 ++++++++++++
tests/qemuxmlconftest.c | 1 +
24 files changed, 227 insertions(+), 6 deletions(-)
create mode 100644 tests/qemuxmlconfdata/sound-device-virtio.x86_64-latest.args
create mode 100644 tests/qemuxmlconfdata/sound-device-virtio.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/sound-device-virtio.xml
--
2.34.1
4 months, 1 week
[PATCH] rpc: ensure temporary GSource is removed from client event loop
by Daniel P. Berrangé
Users are seeing periodic segfaults from libvirt client apps,
especially thread heavy ones like virt-manager. A typical
stack trace would end up in the virNetClientIOEventFD method,
with illegal access to stale stack data. eg
==238721==ERROR: AddressSanitizer: stack-use-after-return on address 0x75cd18709788 at pc 0x75cd3111f907 bp 0x75cd181ff550 sp 0x75cd181ff548
WRITE of size 4 at 0x75cd18709788 thread T11
#0 0x75cd3111f906 in virNetClientIOEventFD /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:1634:15
#1 0x75cd3210d198 (/usr/lib/libglib-2.0.so.0+0x5a198) (BuildId: 0a2311dfbbc6c215dc36f4b6bdd2b4b6fbae55a2)
#2 0x75cd3216c3be (/usr/lib/libglib-2.0.so.0+0xb93be) (BuildId: 0a2311dfbbc6c215dc36f4b6bdd2b4b6fbae55a2)
#3 0x75cd3210ddc6 in g_main_loop_run (/usr/lib/libglib-2.0.so.0+0x5adc6) (BuildId: 0a2311dfbbc6c215dc36f4b6bdd2b4b6fbae55a2)
#4 0x75cd3111a47c in virNetClientIOEventLoop /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:1722:9
#5 0x75cd3111a47c in virNetClientIO /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:2002:10
#6 0x75cd3111a47c in virNetClientSendInternal /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:2170:11
#7 0x75cd311198a8 in virNetClientSendWithReply /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclient.c:2198:11
#8 0x75cd31111653 in virNetClientProgramCall /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/rpc/virnetclientprogram.c:318:9
#9 0x75cd31241c8f in callFull /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/remote/remote_driver.c:6054:10
#10 0x75cd31241c8f in call /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/remote/remote_driver.c:6076:12
#11 0x75cd31241c8f in remoteNetworkGetXMLDesc /usr/src/debug/libvirt/libvirt-10.2.0/build/src/remote/remote_client_bodies.h:5959:9
#12 0x75cd31410ff7 in virNetworkGetXMLDesc /usr/src/debug/libvirt/libvirt-10.2.0/build/../src/libvirt-network.c:952:15
The root cause is a bad assumption in the virNetClientIOEventLoop
method. This method is run by whichever thread currently owns the
buck, and is responsible for handling I/O. Inside a for(;;) loop,
this method creates a temporary GSource, adds it to the event loop
and runs g_main_loop_run(). When I/O is ready, the GSource callback
(virNetClientIOEventFD) will fire and call g_main_loop_quit(), and
return G_SOURCE_REMOVE which results in the temporary GSource being
destroyed. A g_autoptr() will then remove the last reference.
What was overlooked, is that a second thread can come along and
while it can't enter virNetClientIOEventLoop, it will register an
idle source that uses virNetClientIOWakeup to interrupt the
original thread's 'g_main_loop_run' call. When this happens the
virNetClientIOEventFD callback never runs, and so the temporary
GSource is not destroyed. The g_autoptr() will remove a reference,
but by virtue of still being attached to the event context, there
is an extra reference held causing GSource to be leaked. The
next time 'g_main_loop_run' is called, the original GSource will
trigger its callback, and access data that was allocated on the
stack by the previous thread, and likely SEGV.
To solve this, the thread calling 'g_main_loop_run' must call
g_source_destroy, immediately upon return, to guarantee that
the temporary GSource is removed.
CVE-2024-4418
Reported-by: Martin Shirokov <shirokovmartin(a)gmail.com>
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
src/rpc/virnetclient.c | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/rpc/virnetclient.c b/src/rpc/virnetclient.c
index 68098b1c8d..147b0d661a 100644
--- a/src/rpc/virnetclient.c
+++ b/src/rpc/virnetclient.c
@@ -1657,7 +1657,7 @@ static int virNetClientIOEventLoop(virNetClient *client,
#endif /* !WIN32 */
int timeout = -1;
virNetMessage *msg = NULL;
- g_autoptr(GSource) G_GNUC_UNUSED source = NULL;
+ g_autoptr(GSource) source = NULL;
GIOCondition ev = 0;
struct virNetClientIOEventData data = {
.client = client,
@@ -1721,6 +1721,18 @@ static int virNetClientIOEventLoop(virNetClient *client,
g_main_loop_run(client->eventLoop);
+ /*
+ * If virNetClientIOEventFD ran, this GSource will already be
+ * destroyed due to G_SOURCE_REMOVE. It is harmless to re-destroy
+ * it, since we still own a reference.
+ *
+ * If virNetClientIOWakeup ran, it will have interrupted the
+ * g_main_loop_run call, before virNetClientIOEventFD could
+ * run, and thus the GSource is still registered, and we need
+ * to destroy it since it is referencing stack memory for 'data'
+ */
+ g_source_destroy(source);
+
#ifndef WIN32
ignore_value(pthread_sigmask(SIG_SETMASK, &oldmask, NULL));
#endif /* !WIN32 */
--
2.43.0
4 months, 1 week
[PATCH v4 20/22] hw/i386/pc: Remove deprecated pc-i440fx-2.3 machine
by Philippe Mathieu-Daudé
The pc-i440fx-2.3 machine was deprecated for the 8.2
release (see commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
time to remove it.
Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
---
docs/about/deprecated.rst | 4 ++--
docs/about/removed-features.rst | 2 +-
hw/i386/pc.c | 25 -------------------------
hw/i386/pc_piix.c | 19 -------------------
4 files changed, 3 insertions(+), 47 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 75bf0f4886..cb6ca372f2 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,8 +219,8 @@ deprecated; use the new name ``dtb-randomness`` instead. The new name
better reflects the way this property affects all random data within
the device tree blob, not just the ``kaslr-seed`` node.
-``pc-i440fx-2.3`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up to ``pc-i440fx-2.12`` (since 9.1)
-''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+``pc-i440fx-2.4`` up to ``pc-i440fx-2.12`` (since 9.1)
+''''''''''''''''''''''''''''''''''''''''''''''''''''''
These old machine types are quite neglected nowadays and thus might have
various pitfalls with regards to live migration. Use a newer machine type
diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
index 4664974a8b..0caa6a63e4 100644
--- a/docs/about/removed-features.rst
+++ b/docs/about/removed-features.rst
@@ -816,7 +816,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
This machine has been renamed ``fuloong2e``.
-``pc-0.10`` up to ``pc-i440fx-2.2`` (removed in 4.0 up to 9.0)
+``pc-0.10`` up to ``pc-i440fx-2.3`` (removed in 4.0 up to 9.0)
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
These machine types were very old and likely could not be used for live
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index a1b0e94523..2e2146f42b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -256,31 +256,6 @@ GlobalProperty pc_compat_2_4[] = {
};
const size_t pc_compat_2_4_len = G_N_ELEMENTS(pc_compat_2_4);
-GlobalProperty pc_compat_2_3[] = {
- PC_CPU_MODEL_IDS("2.3.0")
- { TYPE_X86_CPU, "arat", "off" },
- { "qemu64" "-" TYPE_X86_CPU, "min-level", "4" },
- { "kvm64" "-" TYPE_X86_CPU, "min-level", "5" },
- { "pentium3" "-" TYPE_X86_CPU, "min-level", "2" },
- { "n270" "-" TYPE_X86_CPU, "min-level", "5" },
- { "Conroe" "-" TYPE_X86_CPU, "min-level", "4" },
- { "Penryn" "-" TYPE_X86_CPU, "min-level", "4" },
- { "Nehalem" "-" TYPE_X86_CPU, "min-level", "4" },
- { "n270" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { "Penryn" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { "Conroe" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { "Nehalem" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { "Westmere" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { "SandyBridge" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { "IvyBridge" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { "Haswell" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { "Haswell-noTSX" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { "Broadwell" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { "Broadwell-noTSX" "-" TYPE_X86_CPU, "min-xlevel", "0x8000000a" },
- { TYPE_X86_CPU, "kvm-no-smi-migration", "on" },
-};
-const size_t pc_compat_2_3_len = G_N_ELEMENTS(pc_compat_2_3);
-
GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
{
GSIState *s;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 30bcd86ee6..370d130a6d 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -421,14 +421,6 @@ static void pc_set_south_bridge(Object *obj, int value, Error **errp)
* hw_compat_*, pc_compat_*, or * pc_*_machine_options().
*/
-static void pc_compat_2_3_fn(MachineState *machine)
-{
- X86MachineState *x86ms = X86_MACHINE(machine);
- if (kvm_enabled()) {
- x86ms->smm = ON_OFF_AUTO_OFF;
- }
-}
-
#ifdef CONFIG_ISAPC
static void pc_init_isa(MachineState *machine)
{
@@ -812,17 +804,6 @@ static void pc_i440fx_2_4_machine_options(MachineClass *m)
DEFINE_I440FX_MACHINE(v2_4, "pc-i440fx-2.4", NULL,
pc_i440fx_2_4_machine_options)
-static void pc_i440fx_2_3_machine_options(MachineClass *m)
-{
- pc_i440fx_2_4_machine_options(m);
- m->hw_version = "2.3.0";
- compat_props_add(m->compat_props, hw_compat_2_3, hw_compat_2_3_len);
- compat_props_add(m->compat_props, pc_compat_2_3, pc_compat_2_3_len);
-}
-
-DEFINE_I440FX_MACHINE(v2_3, "pc-i440fx-2.3", pc_compat_2_3_fn,
- pc_i440fx_2_3_machine_options);
-
#ifdef CONFIG_ISAPC
static void isapc_machine_options(MachineClass *m)
{
--
2.41.0
4 months, 1 week
[PATCH v4 01/22] hw/i386/pc: Deprecate 2.4 to 2.12 pc-i440fx machines
by Philippe Mathieu-Daudé
Similarly to the commit c7437f0ddb "docs/about: Mark the
old pc-i440fx-2.0 - 2.3 machine types as deprecated",
deprecate the 2.4 to 2.12 machines.
Suggested-by: Thomas Huth <thuth(a)redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd(a)linaro.org>
Reviewed-by: Thomas Huth <thuth(a)redhat.com>
Reviewed-by: Zhao Liu <zhao1.liu(a)intel.com>
---
docs/about/deprecated.rst | 4 ++--
hw/i386/pc_piix.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 7b548519b5..47234da329 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -219,8 +219,8 @@ deprecated; use the new name ``dtb-randomness`` instead. The new name
better reflects the way this property affects all random data within
the device tree blob, not just the ``kaslr-seed`` node.
-``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2)
-'''''''''''''''''''''''''''''''''''''''''''''''''''''
+``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up to ``pc-i440fx-2.12`` (since 9.1)
+''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
These old machine types are quite neglected nowadays and thus might have
various pitfalls with regards to live migration. Use a newer machine type
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 18ba076609..817d99c0ce 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -727,6 +727,7 @@ DEFINE_I440FX_MACHINE(v3_0, "pc-i440fx-3.0", NULL,
static void pc_i440fx_2_12_machine_options(MachineClass *m)
{
pc_i440fx_3_0_machine_options(m);
+ m->deprecation_reason = "old and unattended - use a newer version instead";
compat_props_add(m->compat_props, hw_compat_2_12, hw_compat_2_12_len);
compat_props_add(m->compat_props, pc_compat_2_12, pc_compat_2_12_len);
}
@@ -832,7 +833,6 @@ static void pc_i440fx_2_3_machine_options(MachineClass *m)
{
pc_i440fx_2_4_machine_options(m);
m->hw_version = "2.3.0";
- m->deprecation_reason = "old and unattended - use a newer version instead";
compat_props_add(m->compat_props, hw_compat_2_3, hw_compat_2_3_len);
compat_props_add(m->compat_props, pc_compat_2_3, pc_compat_2_3_len);
}
--
2.41.0
4 months, 1 week
[PATCH] scripts/meson-dist.py: Git builddir from env too
by Michal Privoznik
When meson runs a dist script it set both MESON_BUILD_ROOT and
MESON_DIST_ROOT envvars [1]. But for some reason, we took the
former as an argument and obtained the latter via env.
Well, obtain both via env.
1: https://mesonbuild.com/Reference-manual_builtin_meson.html#mesonadd_dist_...
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Another option is to pass both directories as arguments. But this
inconsistent solution bothers me. Especially since I want to copy the
script somewhere else (stay tuned to learn more).
meson.build | 4 ++--
scripts/meson-dist.py | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/meson.build b/meson.build
index 1518afa1cb..5aa50e0d64 100644
--- a/meson.build
+++ b/meson.build
@@ -2195,8 +2195,8 @@ if git
foreach file : dist_files
meson.add_dist_script(
- meson_python_prog.full_path(), python3_prog.full_path(), meson_dist_prog.full_path(),
- meson.project_build_root(), file
+ meson_python_prog.full_path(), python3_prog.full_path(),
+ meson_dist_prog.full_path(), file
)
endforeach
endif
diff --git a/scripts/meson-dist.py b/scripts/meson-dist.py
index bb751b97d3..39dd4fbab0 100755
--- a/scripts/meson-dist.py
+++ b/scripts/meson-dist.py
@@ -4,9 +4,9 @@ import os
import shutil
import sys
-meson_build_root = sys.argv[1]
-file_name = sys.argv[2]
+file_name = sys.argv[1]
+meson_build_root = os.environ['MESON_BUILD_ROOT']
meson_dist_root = os.environ['MESON_DIST_ROOT']
shutil.copy(os.path.join(meson_build_root, file_name),
--
2.43.2
4 months, 1 week
[PATCH 0/4] Enable removing features from CPU models and remove mpx
by Jiri Denemark
See 3/4 for details.
Jiri Denemark (3):
conf: Change return value of some CPU feature APIs
cpu: Add removedPolicy parameter to virCPUUpdate
qemu: Enable removing features from CPU models
Tim Wiederhake (1):
cpu_map: Drop 'mpx' from x86 cpu models
src/conf/cpu_conf.c | 12 +--
src/conf/cpu_conf.h | 4 +-
src/cpu/cpu.c | 10 ++-
src/cpu/cpu.h | 6 +-
src/cpu/cpu_arm.c | 3 +-
src/cpu/cpu_loongarch.c | 3 +-
src/cpu/cpu_ppc64.c | 3 +-
src/cpu/cpu_riscv64.c | 3 +-
src/cpu/cpu_s390.c | 10 +--
src/cpu/cpu_x86.c | 83 +++++++++----------
src/cpu_map/x86_Cascadelake-Server-noTSX.xml | 2 +-
src/cpu_map/x86_Cascadelake-Server.xml | 2 +-
src/cpu_map/x86_Icelake-Server-noTSX.xml | 2 +-
src/cpu_map/x86_Icelake-Server.xml | 2 +-
src/cpu_map/x86_Skylake-Client-IBRS.xml | 2 +-
src/cpu_map/x86_Skylake-Client-noTSX-IBRS.xml | 2 +-
src/cpu_map/x86_Skylake-Client.xml | 2 +-
src/cpu_map/x86_Skylake-Server-IBRS.xml | 2 +-
src/cpu_map/x86_Skylake-Server-noTSX-IBRS.xml | 2 +-
src/cpu_map/x86_Skylake-Server.xml | 2 +-
src/qemu/qemu_capabilities.c | 5 +-
src/qemu/qemu_domain.c | 6 +-
src/qemu/qemu_process.c | 36 +++++++-
tests/cputest.c | 4 +-
.../x86_64-cpuid-Core-i5-6600-guest.xml | 1 +
.../x86_64-cpuid-Core-i5-6600-host.xml | 1 +
.../x86_64-cpuid-Core-i5-6600-json.xml | 1 +
.../x86_64-cpuid-Core-i7-7600U-guest.xml | 1 +
.../x86_64-cpuid-Core-i7-7600U-host.xml | 1 +
.../x86_64-cpuid-Core-i7-7600U-json.xml | 1 +
.../x86_64-cpuid-Core-i7-7700-guest.xml | 1 +
.../x86_64-cpuid-Core-i7-7700-host.xml | 1 +
.../x86_64-cpuid-Core-i7-7700-json.xml | 1 +
.../x86_64-cpuid-Core-i7-8550U-guest.xml | 1 +
.../x86_64-cpuid-Core-i7-8550U-host.xml | 1 +
.../x86_64-cpuid-Core-i7-8550U-json.xml | 1 +
.../x86_64-cpuid-Core-i7-8700-guest.xml | 1 +
.../x86_64-cpuid-Core-i7-8700-host.xml | 1 +
.../x86_64-cpuid-Core-i7-8700-json.xml | 1 +
.../x86_64-cpuid-Ice-Lake-Server-guest.xml | 1 +
.../x86_64-cpuid-Ice-Lake-Server-host.xml | 1 +
.../x86_64-cpuid-Ice-Lake-Server-json.xml | 1 +
.../x86_64-cpuid-Xeon-E3-1225-v5-guest.xml | 1 +
.../x86_64-cpuid-Xeon-E3-1225-v5-host.xml | 1 +
.../x86_64-cpuid-Xeon-E3-1225-v5-json.xml | 1 +
.../x86_64-cpuid-Xeon-E3-1245-v5-guest.xml | 1 +
.../x86_64-cpuid-Xeon-E3-1245-v5-host.xml | 1 +
.../x86_64-cpuid-Xeon-E3-1245-v5-json.xml | 1 +
.../x86_64-cpuid-Xeon-Gold-5115-guest.xml | 1 +
.../x86_64-cpuid-Xeon-Gold-5115-host.xml | 1 +
.../x86_64-cpuid-Xeon-Gold-5115-json.xml | 1 +
.../x86_64-cpuid-Xeon-Gold-6130-guest.xml | 1 +
.../x86_64-cpuid-Xeon-Gold-6130-host.xml | 1 +
.../x86_64-cpuid-Xeon-Gold-6130-json.xml | 1 +
.../x86_64-cpuid-Xeon-Gold-6148-guest.xml | 1 +
.../x86_64-cpuid-Xeon-Gold-6148-host.xml | 1 +
.../x86_64-cpuid-Xeon-Gold-6148-json.xml | 1 +
.../x86_64-cpuid-Xeon-Platinum-8268-guest.xml | 1 +
.../x86_64-cpuid-Xeon-Platinum-8268-host.xml | 1 +
.../x86_64-cpuid-Xeon-Platinum-8268-json.xml | 1 +
.../x86_64-cpuid-Xeon-Platinum-9242-guest.xml | 1 +
.../x86_64-cpuid-Xeon-Platinum-9242-host.xml | 1 +
.../x86_64-cpuid-Xeon-Platinum-9242-json.xml | 1 +
..._64-cpuid-baseline-Cascadelake+Icelake.xml | 1 +
...puid-baseline-Cascadelake+Skylake-IBRS.xml | 1 +
..._64-cpuid-baseline-Cascadelake+Skylake.xml | 1 +
...-cpuid-baseline-Cooperlake+Cascadelake.xml | 1 +
...6_64-cpuid-baseline-Cooperlake+Icelake.xml | 1 +
...4-cpuid-baseline-Skylake-Client+Server.xml | 1 +
.../domaincapsdata/qemu_4.2.0-q35.x86_64.xml | 1 +
tests/domaincapsdata/qemu_4.2.0.x86_64.xml | 1 +
.../domaincapsdata/qemu_5.0.0-q35.x86_64.xml | 1 +
tests/domaincapsdata/qemu_5.0.0.x86_64.xml | 1 +
...-Icelake-Server-pconfig.x86_64-latest.args | 2 +-
...-host-model-fallback-kvm.x86_64-4.2.0.args | 2 +-
...-host-model-fallback-kvm.x86_64-5.0.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-4.2.0.args | 2 +-
.../cpu-host-model-kvm.x86_64-5.0.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-4.2.0.args | 2 +-
...ost-model-nofallback-kvm.x86_64-5.0.0.args | 2 +-
80 files changed, 174 insertions(+), 97 deletions(-)
--
2.44.0
4 months, 1 week
[PATCH v2 0/4] implement 'ras' feature support
by Kristina Hanicova
This is v2 of:
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/VX...
changes since v1:
* edited documentation
* added validation for when the feature is ON as well as OFF
(the first version checked just for the case when the feature was ON)
Kristina Hanicova (4):
qemu: introduce QEMU_CAPS_MACHINE_VIRT_RAS capability
conf: parse and format machine virt ras feature
qemu: validate machine virt ras feature
qemu: format machine virt ras feature and test it
docs/formatdomain.rst | 6 ++++
src/conf/domain_conf.c | 6 +++-
src/conf/domain_conf.h | 1 +
src/conf/schemas/domaincommon.rng | 5 +++
src/qemu/qemu_capabilities.c | 2 ++
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 5 +++
src/qemu/qemu_validate.c | 16 ++++++++++
.../caps_5.2.0_aarch64.xml | 1 +
.../caps_6.0.0_aarch64.xml | 1 +
.../caps_6.2.0_aarch64.xml | 1 +
.../caps_7.0.0_aarch64+hvf.xml | 1 +
.../caps_7.0.0_aarch64.xml | 1 +
.../caps_8.2.0_aarch64.xml | 1 +
.../caps_8.2.0_armv7l.xml | 1 +
.../aarch64-features-ras.aarch64-latest.args | 31 +++++++++++++++++++
.../aarch64-features-ras.aarch64-latest.xml | 1 +
.../qemuxmlconfdata/aarch64-features-ras.xml | 26 ++++++++++++++++
tests/qemuxmlconftest.c | 2 ++
19 files changed, 108 insertions(+), 1 deletion(-)
create mode 100644 tests/qemuxmlconfdata/aarch64-features-ras.aarch64-latest.args
create mode 120000 tests/qemuxmlconfdata/aarch64-features-ras.aarch64-latest.xml
create mode 100644 tests/qemuxmlconfdata/aarch64-features-ras.xml
--
2.42.0
4 months, 1 week
Release of libvirt-10.3.0
by Jiri Denemark
Somehow I forgot to make rc2 on Tuesday, but the only commits after rc1
at that time were translations so I guess it's not a big deal.
The 10.3.0 release of both libvirt and libvirt-python is tagged and
signed tarballs are available at
https://download.libvirt.org/
https://download.libvirt.org/python/
Thanks everybody who helped with this release by sending patches,
reviewing, testing, or providing feedback. Your work is greatly
appreciated.
* New features
* qemu: Proper support for USB network device
USB address is now automatically assigned to USB network devices thus they
can be used without manual configuration.
* conf: Introduce memReserve attribute to <controller/>
Some PCI devices have large non-prefetchable memory. This can be a problem
in case when such device needs to be hotplugged as the firmware can't
foresee such situation. The user thus can override the value calculated at
start to accomodate for such devices.
* Improvements
* Improve validation of USB devices
Certain USB device types ('sound', 'fs', 'chr', 'ccid' and 'net') were not
properly handled in the check whether the VM config supports USB and thus
would result in poor error messages.
* virsh: Fix behaviour of ``--name`` and ``--parent`` used together when listing checkpoint and snapshots
The ``checkpoint-list`` and ``snapshot-list`` commands would ignore the
``--name`` option to print only the name when used with ``--parent``.
* Extend libvirt-guests to shutdown only persistent VMs
Users can now choose to shutdown only persistent VMs when the host is being
shut down.
* Bug fixes
* qemu: Fix migration with custom XML
Libvirt 10.2.0 would sometimes complain about incompatible CPU definition
when trying to migrate or save a domain and passing a custom XML even
though such XML was properly generated as migratable. Hitting this bug
depends on the guest CPU definition and the host on which a particular
domain was running.
* qemu: Fix TLS hostname verification failure in certain non-shared storage migration scenarios
In certain scenarios (parallel migration, newly also post-copy migration)
libvirt would wrongly pass an empty hostname to QEMU to be used for TLS
certificate hostname validation, which would result into failure of the
non-shared storage migration step::
error: internal error: unable to execute QEMU command 'blockdev-add': Certificate does not match the hostname
* Create OVS ports as transient
Libvirt now creates OVS ports as transient which prevents them from
reappearing or going stale on sudden reboots.
* Clear OVS QoS settings when domain shuts down
Libvirt now clears QoS settings on domain shutdown, so they no longer pile
up in OVS database.
Enjoy.
Jirka
4 months, 1 week
[PATCH RESEND] NEWS: Document my contributions for upcoming release
by Michal Privoznik
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Rebased version of the patch sent earlier, because the file was changed
meanwhile.
NEWS.rst | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 7ced82e3da..554ca559a2 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -22,6 +22,13 @@ v10.3.0 (unreleased)
USB address is now automatically assigned to USB network devices thus they
can be used without manual configuration.
+ * conf: Introduce memReserve to <controller/>
+
+ Some PCI devices have large non-prefetchable memory. This is not a problem
+ for coldplug because firmware sets up such devices properly. But it may be
+ a problem for hotplug devices. To resolve this, new ``memReserve``
+ attribute is introduced which allows overriding value computed by firmware.
+
* **Improvements**
* Improve validation of USB devices
@@ -35,6 +42,11 @@ v10.3.0 (unreleased)
The ``checkpoint-list`` and ``snapshot-list`` commands would ignore the
``--name`` option to print only the name when used with ``--parent``.
+ * Extend libvirt-guests to shutdown only persistent VMs
+
+ Users can now chose to shutdown only persistent VMs when the host is being
+ shut down.
+
* **Bug fixes**
* qemu: Fix migration with custom XML
@@ -54,6 +66,16 @@ v10.3.0 (unreleased)
error: internal error: unable to execute QEMU command 'blockdev-add': Certificate does not match the hostname
+ * Create OVS ports as transient
+
+ Libvirt now creates OVS ports as transient which prevents them from
+ reappearing or going stale on sudden reboots.
+
+ * Clear OVS QoS settings when domain shuts down
+
+ Libvirt now clears QoS settings on domain shutdown, so they no longer pile
+ up in OVS database.
+
v10.2.0 (2024-04-02)
====================
--
2.43.2
4 months, 1 week
Revisiting parallel save/restore
by Jim Fehlig
Hi All,
While Fabiano has been working on improving save/restore performance in qemu,
I've been tinkering with the same in libvirt. The end goal is to introduce a new
VIR_DOMAIN_SAVE_PARALLEL flag for save/restore, along with a
VIR_DOMAIN_SAVE_PARAM_PARALLEL_CONNECTIONS parameter to specify the number of
concurrent channels used for the save/restore. Recall Claudio previously posted
a patch series implementing parallel save/restore completely in libvirt, using
qemu's multifd functionality [1].
A good starting point on this journey is supporting the new mapped-ram
capability in qemu 9.0 [2]. Since mapped-ram is a new on-disk format, I assume
we'll need a new QEMU_SAVE_VERSION 3 when using it? Otherwise I'm not sure how
to detect if a saved image is in mapped-ram format vs the existing, sequential
stream format.
IIUC, mapped-ram cannot be used with the exiting 'fd:' migration URI and instead
must use 'file:'. Does qemu advertise support for that? I couldn't find it. If
not, 'file:' (available in qemu 8.2) predates mapped-ram, so in theory we could
live without the advertisement.
It's also not clear when we want to enable the mapped-ram capability. Should it
always be enabled if supported by the underlying qemu? One motivation for
creating the mapped-ram was to support direct-io of the migration stream in
qemu, in which case it could be tied to VIR_DOMAIN_SAVE_BYPASS_CACHE. E.g. the
mapped-ram capability is enabled when user specifies
VIR_DOMAIN_SAVE_BYPASS_CACHE && user-provided path results in a seekable fd &&
qemu supports mapped-ram?
Looking ahead, should the mapped-ram capability be required for supporting the
VIR_DOMAIN_SAVE_PARALLEL flag? As I understand, parallel save/restore was
another motivation for creating the mapped-ram feature. It allows multifd
threads to write exclusively to the offsets provided by mapped-ram. Can multiple
multifd threads concurrently write to an fd without mapped-ram?
Regards,
Jim
[1]
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/3Y...
[2]
https://gitlab.com/qemu-project/qemu/-/blob/master/docs/devel/migration/m...
4 months, 1 week