September 2022 - Devel - libvirt List Archives

[PATCH] cpu_map: Add -noMPX models for x86 Icelake Server
by Lena Voytek 09 Jan '23

09 Jan '23

Intel has removed MPX capabilities from 10nm Icelake CPUs[1], which is reflected by the new models through the line marking mpx as removed. The original Icelake Server models have been left alone to avoid regressions. This adds: -Icelake-Server-noMPX -Icelake-Server-noTSX-noMPX References: [1] Memory Protection Extensions support removal https://www.intel.com/content/www/us/en/support/articles/000059823/processo… Fixes: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1978064 https://gitlab.com/libvirt/libvirt/-/issues/304 Signed-off-by: Lena Voytek <lena.voytek(a)canonical.com> --- src/cpu_map/index.xml | 2 + src/cpu_map/x86_Icelake-Server-noMPX.xml | 93 +++++++++++++++++++ .../x86_Icelake-Server-noTSX-noMPX.xml | 91 ++++++++++++++++++ 3 files changed, 186 insertions(+) create mode 100644 src/cpu_map/x86_Icelake-Server-noMPX.xml create mode 100644 src/cpu_map/x86_Icelake-Server-noTSX-noMPX.xml diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml index 351c2ae4fa..62c3d44a5c 100644 --- a/src/cpu_map/index.xml +++ b/src/cpu_map/index.xml @@ -54,6 +54,8 @@ <include filename='x86_Icelake-Client-noTSX.xml'/> <include filename='x86_Icelake-Server.xml'/> <include filename='x86_Icelake-Server-noTSX.xml'/> + <include filename='x86_Icelake-Server-noMPX.xml'/> + <include filename='x86_Icelake-Server-noTSX-noMPX.xml'/> <include filename='x86_Cooperlake.xml'/> <include filename='x86_Snowridge.xml'/> diff --git a/src/cpu_map/x86_Icelake-Server-noMPX.xml b/src/cpu_map/x86_Icelake-Server-noMPX.xml new file mode 100644 index 0000000000..feaf21f91f --- /dev/null +++ b/src/cpu_map/x86_Icelake-Server-noMPX.xml @@ -0,0 +1,93 @@ +<cpus> + <model name='Icelake-Server-noMPX'> + <decode host='on' guest='on'/> + <signature family='6' model='106'/>  + <vendor name='Intel'/> + <feature name='3dnowprefetch'/> + <feature name='abm'/> + <feature name='adx'/> + <feature name='aes'/> + <feature name='apic'/> + <feature name='arat'/> + <feature name='avx'/> + <feature name='avx2'/> + <feature name='avx512-vpopcntdq'/> + <feature name='avx512bitalg'/> + <feature name='avx512bw'/> + <feature name='avx512cd'/> + <feature name='avx512dq'/> + <feature name='avx512f'/> + <feature name='avx512vbmi'/> + <feature name='avx512vbmi2'/> + <feature name='avx512vl'/> + <feature name='avx512vnni'/> + <feature name='bmi1'/> + <feature name='bmi2'/> + <feature name='clflush'/> + <feature name='clflushopt'/> + <feature name='clwb'/> + <feature name='cmov'/> + <feature name='cx16'/> + <feature name='cx8'/> + <feature name='de'/> + <feature name='erms'/> + <feature name='f16c'/> + <feature name='fma'/> + <feature name='fpu'/> + <feature name='fsgsbase'/> + <feature name='fxsr'/> + <feature name='gfni'/> + <feature name='hle'/> + <feature name='intel-pt' removed='yes'/> + <feature name='invpcid'/> + <feature name='la57'/> + <feature name='lahf_lm'/> + <feature name='lm'/> + <feature name='mca'/> + <feature name='mce'/> + <feature name='mmx'/> + <feature name='movbe'/> + <feature name='mpx' removed='yes'/> + <feature name='msr'/> + <feature name='mtrr'/> + <feature name='nx'/> + <feature name='pae'/> + <feature name='pat'/> + <feature name='pcid'/> + <feature name='pclmuldq'/> + <feature name='pdpe1gb'/> + <feature name='pge'/> + <feature name='pku'/> + <feature name='pni'/> + <feature name='popcnt'/> + <feature name='pse'/> + <feature name='pse36'/> + <feature name='rdrand'/> + <feature name='rdseed'/> + <feature name='rdtscp'/> + <feature name='rtm'/> + <feature name='sep'/> + <feature name='smap'/> + <feature name='smep'/> + <feature name='spec-ctrl'/> + <feature name='ssbd'/> + <feature name='sse'/> + <feature name='sse2'/> + <feature name='sse4.1'/> + <feature name='sse4.2'/> + <feature name='ssse3'/> + <feature name='syscall'/> + <feature name='tsc'/> + <feature name='tsc-deadline'/> + <feature name='umip'/> + <feature name='vaes'/> + <feature name='vme'/> + <feature name='vpclmulqdq'/> + <feature name='wbnoinvd'/> + <feature name='x2apic'/> + <feature name='xgetbv1'/> + <feature name='xsave'/> + <feature name='xsavec'/> + <feature name='xsaveopt'/> + </model> +</cpus> diff --git a/src/cpu_map/x86_Icelake-Server-noTSX-noMPX.xml b/src/cpu_map/x86_Icelake-Server-noTSX-noMPX.xml new file mode 100644 index 0000000000..e55da83ddf --- /dev/null +++ b/src/cpu_map/x86_Icelake-Server-noTSX-noMPX.xml @@ -0,0 +1,91 @@ +<cpus> + <model name='Icelake-Server-noTSX-noMPX'> + <decode host='on' guest='off'/> + <signature family='6' model='106'/>  + <vendor name='Intel'/> + <feature name='3dnowprefetch'/> + <feature name='abm'/> + <feature name='adx'/> + <feature name='aes'/> + <feature name='apic'/> + <feature name='arat'/> + <feature name='avx'/> + <feature name='avx2'/> + <feature name='avx512-vpopcntdq'/> + <feature name='avx512bitalg'/> + <feature name='avx512bw'/> + <feature name='avx512cd'/> + <feature name='avx512dq'/> + <feature name='avx512f'/> + <feature name='avx512vbmi'/> + <feature name='avx512vbmi2'/> + <feature name='avx512vl'/> + <feature name='avx512vnni'/> + <feature name='bmi1'/> + <feature name='bmi2'/> + <feature name='clflush'/> + <feature name='clflushopt'/> + <feature name='clwb'/> + <feature name='cmov'/> + <feature name='cx16'/> + <feature name='cx8'/> + <feature name='de'/> + <feature name='erms'/> + <feature name='f16c'/> + <feature name='fma'/> + <feature name='fpu'/> + <feature name='fsgsbase'/> + <feature name='fxsr'/> + <feature name='gfni'/> + <feature name='intel-pt' removed='yes'/> + <feature name='invpcid'/> + <feature name='la57'/> + <feature name='lahf_lm'/> + <feature name='lm'/> + <feature name='mca'/> + <feature name='mce'/> + <feature name='mmx'/> + <feature name='movbe'/> + <feature name='mpx' removed='yes'/> + <feature name='msr'/> + <feature name='mtrr'/> + <feature name='nx'/> + <feature name='pae'/> + <feature name='pat'/> + <feature name='pcid'/> + <feature name='pclmuldq'/> + <feature name='pdpe1gb'/> + <feature name='pge'/> + <feature name='pku'/> + <feature name='pni'/> + <feature name='popcnt'/> + <feature name='pse'/> + <feature name='pse36'/> + <feature name='rdrand'/> + <feature name='rdseed'/> + <feature name='rdtscp'/> + <feature name='sep'/> + <feature name='smap'/> + <feature name='smep'/> + <feature name='spec-ctrl'/> + <feature name='ssbd'/> + <feature name='sse'/> + <feature name='sse2'/> + <feature name='sse4.1'/> + <feature name='sse4.2'/> + <feature name='ssse3'/> + <feature name='syscall'/> + <feature name='tsc'/> + <feature name='tsc-deadline'/> + <feature name='umip'/> + <feature name='vaes'/> + <feature name='vme'/> + <feature name='vpclmulqdq'/> + <feature name='wbnoinvd'/> + <feature name='x2apic'/> + <feature name='xgetbv1'/> + <feature name='xsave'/> + <feature name='xsavec'/> + <feature name='xsaveopt'/> + </model> +</cpus> -- 2.34.1

5 10

[libvirt PATCH v2] Add basically RISC-V support
by Yu Gu 29 Nov '22

29 Nov '22

This patch provides basic support for the RISC-V architecture, so libvirt can run in RISC-V machine. Signed-off-by: Yu Gu <guyu2876(a)gmail.com> --- po/POTFILES | 1 + src/cpu/cpu.c | 2 + src/cpu/cpu.h | 2 + src/cpu/cpu_riscv64.c | 118 +++++++++++++++++++++++++++++++ src/cpu/cpu_riscv64.h | 28 ++++++++ src/cpu/cpu_riscv64_data.h | 40 +++++++++++ src/cpu/meson.build | 1 + src/cpu_map/index.xml | 4 ++ src/cpu_map/meson.build | 1 + src/cpu_map/riscv64_vendors.xml | 3 + src/util/virarch.c | 2 + src/util/virhostcpu.c | 2 +- src/util/virsysinfo.c | 121 ++++++++++++++++++++++++++++++++ 13 files changed, 324 insertions(+), 1 deletion(-) create mode 100644 src/cpu/cpu_riscv64.c create mode 100644 src/cpu/cpu_riscv64.h create mode 100644 src/cpu/cpu_riscv64_data.h create mode 100644 src/cpu_map/riscv64_vendors.xml diff --git a/po/POTFILES b/po/POTFILES index 169e2a41dc..a52795e7c1 100644 --- a/po/POTFILES +++ b/po/POTFILES @@ -72,6 +72,7 @@ src/cpu/cpu_map.c src/cpu/cpu_ppc64.c src/cpu/cpu_s390.c src/cpu/cpu_x86.c +src/cpu/cpu_riscv64.c src/datatypes.c src/driver.c src/esx/esx_driver.c diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c index d97ef5e873..8fdc42e719 100644 --- a/src/cpu/cpu.c +++ b/src/cpu/cpu.c @@ -27,6 +27,7 @@ #include "cpu_ppc64.h" #include "cpu_s390.h" #include "cpu_arm.h" +#include "cpu_riscv64.h" #include "capabilities.h" @@ -39,6 +40,7 @@ static struct cpuArchDriver *drivers[] = { &cpuDriverPPC64, &cpuDriverS390, &cpuDriverArm, + &cpuDriverRISCV64, }; diff --git a/src/cpu/cpu.h b/src/cpu/cpu.h index 41a62ce486..6e0a06fce4 100644 --- a/src/cpu/cpu.h +++ b/src/cpu/cpu.h @@ -27,6 +27,7 @@ #include "cpu_x86_data.h" #include "cpu_ppc64_data.h" #include "cpu_arm_data.h" +#include "cpu_riscv64_data.h" typedef struct _virCPUData virCPUData; @@ -36,6 +37,7 @@ struct _virCPUData { virCPUx86Data x86; virCPUppc64Data ppc64; virCPUarmData arm; + virCPUriscv64Data riscv64; /* generic driver needs no data */ } data; }; diff --git a/src/cpu/cpu_riscv64.c b/src/cpu/cpu_riscv64.c new file mode 100644 index 0000000000..21f7178cc2 --- /dev/null +++ b/src/cpu/cpu_riscv64.c @@ -0,0 +1,118 @@ +/* + * cpu_riscv64.c: CPU driver for riscv64(x) CPUs + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * <http://www.gnu.org/licenses/>. + */ + +#include <config.h> + +#include "cpu.h" + + +#define VIR_FROM_THIS VIR_FROM_CPU + +static const virArch archs[] = { VIR_ARCH_RISCV64 }; + +static virCPUCompareResult +virCPUriscv64Compare(virCPUDef *host G_GNUC_UNUSED, + virCPUDef *cpu G_GNUC_UNUSED, + bool failMessages G_GNUC_UNUSED) +{ + /* riscv64 relies on QEMU to perform all runability checking. Return + * VIR_CPU_COMPARE_IDENTICAL to bypass Libvirt checking. + */ + return VIR_CPU_COMPARE_IDENTICAL; +} + +static int +virCPUriscv64Update(virCPUDef *guest, + const virCPUDef *host, + bool relative) +{ + g_autoptr(virCPUDef) updated = NULL; + size_t i; + + if (!relative) + return 0; + + if (guest->mode == VIR_CPU_MODE_CUSTOM) { + if (guest->match == VIR_CPU_MATCH_MINIMUM) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("match mode %s not supported"), + virCPUMatchTypeToString(guest->match)); + } else { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("optional CPU features are not supported")); + } + return -1; + } + + if (!host) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("unknown host CPU model")); + return -1; + } + + if (!(updated = virCPUDefCopyWithoutModel(guest))) + return -1; + + updated->mode = VIR_CPU_MODE_CUSTOM; + if (virCPUDefCopyModel(updated, host, true) < 0) + return -1; + + for (i = 0; i < guest->nfeatures; i++) { + if (virCPUDefUpdateFeature(updated, + guest->features[i].name, + guest->features[i].policy) < 0) + return -1; + } + + virCPUDefStealModel(guest, updated, false); + guest->mode = VIR_CPU_MODE_CUSTOM; + guest->match = VIR_CPU_MATCH_EXACT; + + return 0; +} + + +static int +virCPUriscv64ValidateFeatures(virCPUDef *cpu) +{ + size_t i; + + for (i = 0; i < cpu->nfeatures; i++) { + if (cpu->features[i].policy == VIR_CPU_FEATURE_OPTIONAL) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("only cpu feature policies 'require' and " + "'disable' are supported for %s"), + cpu->features[i].name); + return -1; + } + } + + return 0; +} + +struct cpuArchDriver cpuDriverRISCV64 = { + .name = "riscv64", + .arch = archs, + .narch = G_N_ELEMENTS(archs), + .compare = virCPUriscv64Compare, + .decode = NULL, + .encode = NULL, + .baseline = NULL, + .update = virCPUriscv64Update, + .validateFeatures = virCPUriscv64ValidateFeatures, +}; diff --git a/src/cpu/cpu_riscv64.h b/src/cpu/cpu_riscv64.h new file mode 100644 index 0000000000..67528415fe --- /dev/null +++ b/src/cpu/cpu_riscv64.h @@ -0,0 +1,28 @@ +/* + * cpu_riscv64.h: CPU driver for 64-bit RISC-V CPUs + * + * Copyright (C) Copyright (C) IBM Corporation, 2010 + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see + * <http://www.gnu.org/licenses/>. + */ + +#ifndef __VIR_CPU_RISCV64_H__ +# define __VIR_CPU_RISCV64_H__ + +# include "cpu.h" + +extern struct cpuArchDriver cpuDriverRISCV64; + +#endif diff --git a/src/cpu/cpu_riscv64_data.h b/src/cpu/cpu_riscv64_data.h new file mode 100644 index 0000000000..819b9e8fde --- /dev/null +++ b/src/cpu/cpu_riscv64_data.h @@ -0,0 +1,40 @@ +/* + * cpu_riscv64_data.h: 64-bit riscv64 CPU specific data + * + * Copyright (C) 2012 IBM Corporation. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; If not, see + * <http://www.gnu.org/licenses/>. + */ + +#ifndef __VIR_CPU_RISCV64_DATA_H__ +# define __VIR_CPU_RISCV64_DATA_H__ + +# include <stdint.h> + +typedef struct _virCPUriscv64Prid virCPUriscv64Prid; +struct _virCPUriscv64Prid { + uint32_t value; + uint32_t mask; +}; + +# define VIR_CPU_riscv64_DATA_INIT { 0 } + +typedef struct _virCPUriscv64Data virCPUriscv64Data; +struct _virCPUriscv64Data { + size_t len; + virCPUriscv64Prid *prid; +}; + +#endif diff --git a/src/cpu/meson.build b/src/cpu/meson.build index b4ad95e46d..eba1d45743 100644 --- a/src/cpu/meson.build +++ b/src/cpu/meson.build @@ -5,6 +5,7 @@ cpu_sources = [ 'cpu_ppc64.c', 'cpu_s390.c', 'cpu_x86.c', + 'cpu_riscv64.c', ] cpu_lib = static_library( diff --git a/src/cpu_map/index.xml b/src/cpu_map/index.xml index d533a28865..f2c4b1c62a 100644 --- a/src/cpu_map/index.xml +++ b/src/cpu_map/index.xml @@ -89,6 +89,10 @@ <include filename='ppc64_POWERPC_e6500.xml'/> </arch> + <arch name='riscv64'> + <include filename='riscv64_vendors.xml'/> + </arch> + <arch name='arm'> <include filename='arm_vendors.xml'/> <include filename='arm_features.xml'/> diff --git a/src/cpu_map/meson.build b/src/cpu_map/meson.build index 99264289e2..1a02df8268 100644 --- a/src/cpu_map/meson.build +++ b/src/cpu_map/meson.build @@ -19,6 +19,7 @@ cpumap_data = [ 'ppc64_POWERPC_e5500.xml', 'ppc64_POWERPC_e6500.xml', 'ppc64_vendors.xml', + 'riscv64_vendors.xml', 'x86_486.xml', 'x86_athlon.xml', 'x86_Broadwell-IBRS.xml', diff --git a/src/cpu_map/riscv64_vendors.xml b/src/cpu_map/riscv64_vendors.xml new file mode 100644 index 0000000000..478a23a467 --- /dev/null +++ b/src/cpu_map/riscv64_vendors.xml @@ -0,0 +1,3 @@ +<cpus> + <vendor name='RISC-V'/> +</cpus> \ No newline at end of file diff --git a/src/util/virarch.c b/src/util/virarch.c index 2134dd6a9d..3d14ecd193 100644 --- a/src/util/virarch.c +++ b/src/util/virarch.c @@ -190,6 +190,8 @@ virArch virArchFromHost(void) return VIR_ARCH_ALPHA; case PROCESSOR_ARCHITECTURE_PPC: return VIR_ARCH_PPC; + case PROCESSOR_ARCHITECTURE_RISCV: + return VIR_ARCH_RISCV64; case PROCESSOR_ARCHITECTURE_SHX: return VIR_ARCH_SH4; case PROCESSOR_ARCHITECTURE_ARM: diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c index c1e8dc8078..08c2290f00 100644 --- a/src/util/virhostcpu.c +++ b/src/util/virhostcpu.c @@ -544,7 +544,7 @@ virHostCPUParseFrequency(FILE *cpuinfo, char line[1024]; /* No sensible way to retrieve CPU frequency */ - if (ARCH_IS_ARM(arch)) + if (ARCH_IS_ARM(arch) || ARCH_IS_RISCV(arch)) return 0; if (ARCH_IS_X86(arch)) diff --git a/src/util/virsysinfo.c b/src/util/virsysinfo.c index 376d5d4816..e281d928c7 100644 --- a/src/util/virsysinfo.c +++ b/src/util/virsysinfo.c @@ -623,6 +623,125 @@ virSysinfoReadS390(void) return g_steal_pointer(&ret); } +#if 0 +static int +virSysinfoParseRISCVSystem(const char *base, virSysinfoSystemDef **sysdef) +{ + int ret = -1; + virSysinfoSystemDef *def; + + def = g_new0(virSysinfoSystemDef, 1); + +#if 0 + if (!virSysinfoParseS390Line(base, "Manufacturer", &def->manufacturer)) + goto cleanup; + + if (!virSysinfoParseS390Line(base, "Type", &def->family)) + goto cleanup; +#endif + def->manufacturer = g_strndup("Virt-RISC-V", sizeof("Virt RISC-V")); + + if (!def->manufacturer && !def->product && !def->version && + !def->serial && !def->uuid && !def->sku && !def->family) { + g_clear_pointer(&def, virSysinfoSystemDefFree); + } + + *sysdef = g_steal_pointer(&def); + ret = 0; + cleanup: + virSysinfoSystemDefFree(def); + return ret; +} +#endif + +static int +virSysinfoParseRISCVProcessor(const char *base, virSysinfoDef *ret) +{ + const char *tmp_base; + char *manufacturer = NULL; + char *procline = NULL; + char *ncpu = NULL; + int result = -1; + virSysinfoProcessorDef *processor; + + if (!(tmp_base = virSysinfoParseS390Line(base, "uarch", &manufacturer))) + goto error; + + /* Find processor N: line and gather the processor manufacturer, + version, serial number, and family */ + while ((tmp_base = strstr(tmp_base, "processor ")) + && (tmp_base = virSysinfoParseS390Line(tmp_base, "processor ", + &procline))) { + VIR_EXPAND_N(ret->processor, ret->nprocessor, 1); + processor = &ret->processor[ret->nprocessor - 1]; + processor->processor_manufacturer = g_strdup(manufacturer); + + VIR_FREE(procline); + } + + /* now, for each processor found, extract the frequency information */ + tmp_base = base; + + while ((tmp_base = strstr(tmp_base, "hart")) && + (tmp_base = virSysinfoParseS390Line(tmp_base, "hart", &ncpu))) { + unsigned int n; + char *mhz = NULL; + + if (virStrToLong_uip(ncpu, NULL, 10, &n) < 0) + goto error; + + if (n >= ret->nprocessor) { + VIR_DEBUG("CPU number '%u' out of range", n); + goto cleanup; + } + + VIR_FREE(ncpu); + } + + cleanup: + result = 0; + + error: + VIR_FREE(manufacturer); + VIR_FREE(procline); + VIR_FREE(ncpu); + return result; +} + +virSysinfoDef * +virSysinfoReadRISCV(void) +{ + g_autoptr(virSysinfoDef) ret = NULL; + g_autofree char *outbuf = NULL; + + ret = g_new0(virSysinfoDef, 1); + + /* Gather info from /proc/cpuinfo */ + if (virFileReadAll(CPUINFO, CPUINFO_FILE_LEN, &outbuf) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Failed to open %s"), CPUINFO); + return NULL; + } + + if (virSysinfoParseRISCVProcessor(outbuf, ret) < 0) + return NULL; + + /* Free buffer before reading next file */ + VIR_FREE(outbuf); + +#if 0 + /* Gather info from /proc/sysinfo */ + if (virFileReadAll(SYSINFO, 8192, &outbuf) < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Failed to open %s"), SYSINFO); + return NULL; + } + + if (virSysinfoParseRISCVSystem(outbuf, &ret->system) < 0) + return NULL; +#endif + return g_steal_pointer(&ret); +} static int virSysinfoParseBIOS(const char *base, virSysinfoBIOSDef **bios) @@ -1243,6 +1362,8 @@ virSysinfoRead(void) return virSysinfoReadPPC(); #elif defined(__arm__) || defined(__aarch64__) return virSysinfoReadARM(); +#elif defined(__riscv) && __riscv_xlen == 64 + return virSysinfoReadRISCV(); #elif defined(__s390__) || defined(__s390x__) return virSysinfoReadS390(); #elif !defined(WIN32) && \ -- 2.37.3

2 2

questions regarding modular daemons
by Jim Fehlig 24 Nov '22

24 Nov '22

Hi All, I've procrastinated long enough and finally decided to switch to modular daemons in openSUSE Factory libvirt package. For the most part, the Factory spec file mimics the upstream one. I enabled with_modular_daemons and would like to confirm the results of my testing. When upgrading an existing installation running the monolithic daemon, the monolithic daemon is still enabled after the upgrade. I suppose this behavior is expected, and fine IMO. However, when installing the "modularized" packages on a system with no prior installation, the monolithic daemon is still installed and potentially enabled in posttrans. Having both the monolithic and modular daemons installed, along with all associated systemd socket and service files, is a bit confusing to users IMO. E.g. should one enable libvirtd sockets, virtqemud sockets, both? Is the intention, over time, to remove the monolithic daemon? Perhaps we could start by isolating the monolithic daemon in the libvirt-daemon subpackage and moving the other daemons (virtproxyd, virtlogd, virtlockd, etc) to a new subpackage? The modular daemons could then drop the libvirt-daemon dependency, allowing installation without the monolithic daemon. TIA for your comments. Regards, Jim

2 2

[PATCH] cpu_map: Add cpu feature amx
by Lin Yang 04 Nov '22

04 Nov '22

AMX was introduced in QEMU commit 1f16764f7d4515bfd5e4ae0aae814fa280a7d0c8 and following commits. --- src/cpu_map/sync_qemu_i386.py | 3 +++ src/cpu_map/x86_features.xml | 9 +++++++++ 2 files changed, 12 insertions(+) diff --git a/src/cpu_map/sync_qemu_i386.py b/src/cpu_map/sync_qemu_i386.py index 4dd9f3b84d..6a46f87cff 100755 --- a/src/cpu_map/sync_qemu_i386.py +++ b/src/cpu_map/sync_qemu_i386.py @@ -72,6 +72,9 @@ def translate_feature(name): "CPUID_7_0_EDX_SPEC_CTRL": "spec-ctrl", "CPUID_7_0_EDX_SPEC_CTRL_SSBD": "ssbd", "CPUID_7_0_EDX_STIBP": "stibp", + "CPUID_7_0_EDX_AMX_BF16": "amx-bf16", + "CPUID_7_0_EDX_AMX_TILE": "amx-tile", + "CPUID_7_0_EDX_AMX_INT8": "amx-int8", "CPUID_7_1_EAX_AVX512_BF16": "avx512-bf16", "CPUID_7_1_EAX_AVX_VNNI": "avx-vnni", "CPUID_8000_0008_EBX_AMD_SSBD": "amd-ssbd", diff --git a/src/cpu_map/x86_features.xml b/src/cpu_map/x86_features.xml index 4cf3ff0804..102d39f626 100644 --- a/src/cpu_map/x86_features.xml +++ b/src/cpu_map/x86_features.xml @@ -347,6 +347,15 @@ <feature name='pconfig'> <cpuid eax_in='0x07' ecx_in='0x00' edx='0x00040000'/> </feature> + <feature name='amx-bf16'> + <cpuid eax_in='0x07' ecx_in='0x00' edx='0x00400000'/> + </feature> + <feature name='amx-tile'> + <cpuid eax_in='0x07' ecx_in='0x00' edx='0x01000000'/> + </feature> + <feature name='amx-int8'> + <cpuid eax_in='0x07' ecx_in='0x00' edx='0x02000000'/> + </feature> <feature name='spec-ctrl'> <cpuid eax_in='0x07' ecx_in='0x00' edx='0x04000000'/> </feature> -- 2.34.1

3 4

[libvirt RFC 00/24] basic snapshot delete implementation
by Pavel Hrdina 25 Oct '22

25 Oct '22

I'm sending it as RFC even though it's somehow completed and works, it probably needs some documentation and most likely unit testing. This implements virDomainSnapshotDelete API to support external snapshots. The support doesn't include flags VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN and VIR_DOMAIN_SNAPSHOT_DELETE_CHILDREN_ONLY as it would add more complexity and IMHO these flags should not existed at all. The last patch is just here to show how we could support deleting external snapshot if all children are internal only, without this patch the user would have to call children-only and then with another call delete the external snapshot itself. There are some limitation that will be needing the mentioned documentation. If parent snapshot is internal the external snapshot cannot be deleted, workaround is to delete any internal parent snapshots and after that the external can be deleted. Pavel Hrdina (24): qemu_block: extract block commit code to separate function qemu_block: move qemuDomainBlockPivot out of qemu_driver qemu_block: extract qemuBlockCommit impl to separate function qemu_block: add sync option to qemuBlockCommitImpl qemu_monitor: introduce qemuMonitorJobFinalize qemu_monitor: allow setting autofinalize for block commit qemu_block: introduce qemuBlockFinalize qemu_blockjob: process QEMU_MONITOR_JOB_STATUS_PENDING signal qemu_snapshot: refactor qemuSnapshotDelete qemu_snapshot: extract single snapshot deletion to separate function qemu_snapshot: extract children snapshot deletion to separate function qemu_snapshot: rework snapshot children deletion qemu_snapshot: move snapshot discard out of qemu_domain.c qemu_snapshot: introduce qemuSnapshotDiscardMetadata qemu_snapshot: call qemuSnapshotDiscardMetadata from qemuSnapshotDiscard qemu_snapshot: pass update_parent into qemuSnapshotDiscardMetadata qemu_snapshot: move metadata changes to qemuSnapshotDiscardMetadata qemu_snapshot: introduce qemuSnapshotDeleteValidate function qemu_snapshot: refactor validation of snapshot delete qemu_snapshot: prepare data for external snapshot deletion qemu_snapshot: implement deletion of external snapshot qemu_snapshot: update metadata when deleting snapshots qemu_snapshot: when deleting snapshot invalidate parent snapshot qemu_snapshot: allow deletion of external snapshot with internal snapshot children src/conf/snapshot_conf.c | 5 + src/conf/snapshot_conf.h | 1 + src/qemu/qemu_backup.c | 1 + src/qemu/qemu_block.c | 356 ++++++++++++++++ src/qemu/qemu_block.h | 30 ++ src/qemu/qemu_blockjob.c | 13 +- src/qemu/qemu_blockjob.h | 1 + src/qemu/qemu_domain.c | 95 +---- src/qemu/qemu_domain.h | 9 - src/qemu/qemu_driver.c | 306 +------------- src/qemu/qemu_monitor.c | 21 +- src/qemu/qemu_monitor.h | 8 +- src/qemu/qemu_monitor_json.c | 26 +- src/qemu/qemu_monitor_json.h | 8 +- src/qemu/qemu_snapshot.c | 764 +++++++++++++++++++++++++++++++---- src/qemu/qemu_snapshot.h | 4 + tests/qemumonitorjsontest.c | 2 +- 17 files changed, 1151 insertions(+), 499 deletions(-) -- 2.37.2

2 52

[PATCH v3 0/5] network: firewalld: fix routed network
by Eric Garver 24 Oct '22

24 Oct '22

This series fixes routed networks when a newer firewalld (>= 1.0.0) is present [1]. Firewalld 1.0.0 included a change that disallows implicit forwarding between zones [2]. libvirt was relying on this behavior to allow routed networks to function. Firewalld policies are added. Policies have been supported since firewalld 0.9.0. If the running firewall does not support policies, then it will fallback to the current zone only behavior. My goal is to get libvirt to a fully native firewalld backend; no iptables rules. This series is phase 1 of that effort. The next steps are: 1. introduce a "libvirt-nat" zone and policies - the current "libvirt" zone will become obsolete 2. go full native firewalld, do not use iptables directly - currently a hybrid of iptables + firewalld is used v3: - rebase, retest, resend v2: - keep existing libvirt zone as is - remove "<forward />" in libvirt-routed zone because this feature requires firewalld >= 0.9.0. Has no impact since the added policies allow forwarding libvirt-routed <--> ANY zone (including itself). - add probe for policies: virFirewallDGetPolicies(), virFirewallDPolicyExists() [1]: https://bugzilla.redhat.com/show_bug.cgi?id=2055706 [2]: https://github.com/firewalld/firewalld/issues/177 Eric Garver (5): util: add virFirewallDGetPolicies() util: add virFirewallDPolicyExists() network: firewalld: add zone for routed networks network: firewalld: add policies for routed networks network: firewalld: add support for routed networks src/libvirt_private.syms | 2 + src/network/bridge_driver_linux.c | 11 +++- src/network/libvirt-routed-in.policy | 11 ++++ src/network/libvirt-routed-out.policy | 12 +++++ src/network/libvirt-routed.zone | 10 ++++ src/network/libvirt-to-host.policy | 20 ++++++++ src/network/meson.build | 20 ++++++++ src/util/virfirewalld.c | 72 +++++++++++++++++++++++++++ src/util/virfirewalld.h | 2 + 9 files changed, 159 insertions(+), 1 deletion(-) create mode 100644 src/network/libvirt-routed-in.policy create mode 100644 src/network/libvirt-routed-out.policy create mode 100644 src/network/libvirt-routed.zone create mode 100644 src/network/libvirt-to-host.policy -- 2.35.3

3 7

Re: [PATCH RFC v2 00/13] IOMMUFD Generic interface
by Alex Williamson 21 Oct '22

21 Oct '22

[Cc+ Steve, libvirt, Daniel, Laine] On Tue, 20 Sep 2022 16:56:42 -0300 Jason Gunthorpe <jgg(a)nvidia.com> wrote: > On Tue, Sep 13, 2022 at 09:28:18AM +0200, Eric Auger wrote: > > Hi, > > > > On 9/13/22 03:55, Tian, Kevin wrote: > > > We didn't close the open of how to get this merged in LPC due to the > > > audio issue. Then let's use mails. > > > > > > Overall there are three options on the table: > > > > > > 1) Require vfio-compat to be 100% compatible with vfio-type1 > > > > > > Probably not a good choice given the amount of work to fix the remaining > > > gaps. And this will block support of new IOMMU features for a longer time. > > > > > > 2) Leave vfio-compat as what it is in this series > > > > > > Treat it as a vehicle to validate the iommufd logic instead of immediately > > > replacing vfio-type1. Functionally most vfio applications can work w/o > > > change if putting aside the difference on locked mm accounting, p2p, etc. > > > > > > Then work on new features and 100% vfio-type1 compat. in parallel. > > > > > > 3) Focus on iommufd native uAPI first > > > > > > Require vfio_device cdev and adoption in Qemu. Only for new vfio app. > > > > > > Then work on new features and vfio-compat in parallel. > > > > > > I'm fine with either 2) or 3). Per a quick chat with Alex he prefers to 3). > > > > I am also inclined to pursue 3) as this was the initial Jason's guidance > > and pre-requisite to integrate new features. In the past we concluded > > vfio-compat would mostly be used for testing purpose. Our QEMU > > integration fully is based on device based API. > > There are some poor chicken and egg problems here. > > I had some assumptions: > a - the vfio cdev model is going to be iommufd only > b - any uAPI we add as we go along should be generally useful going > forward > c - we should try to minimize the 'minimally viable iommufd' series > > The compat as it stands now (eg #2) is threading this needle. Since it > can exist without cdev it means (c) is made smaller, to two series. > > Since we add something useful to some use cases, eg DPDK is deployable > that way, (b) is OK. > > If we focus on a strict path with 3, and avoid adding non-useful code, > then we have to have two more (unwritten!) series beyond where we are > now - vfio group compartmentalization, and cdev integration, and the > initial (c) will increase. > > 3 also has us merging something that currently has no usable > userspace, which I also do dislike alot. > > I still think the compat gaps are small. I've realized that > VFIO_DMA_UNMAP_FLAG_VADDR has no implementation in qemu, and since it > can deadlock the kernel I propose we purge it completely. Steve won't be happy to hear that, QEMU support exists but isn't yet merged. > P2P is ongoing. > > That really just leaves the accounting, and I'm still not convinced at > this must be a critical thing. Linus's latest remarks reported in lwn > at the maintainer summit on tracepoints/BPF as ABI seem to support > this. Let's see an actual deployed production configuration that would > be impacted, and we won't find that unless we move forward. I'll try to summarize the proposed change so that we can get better advice from libvirt folks, or potentially anyone else managing locked memory limits for device assignment VMs. Background: when a DMA range, ex. guest RAM, is mapped to a vfio device, we use the system IOMMU to provide GPA to HPA translation for assigned devices. Unlike CPU page tables, we don't generally have a means to demand fault these translations, therefore the memory target of the translation is pinned to prevent that it cannot be swapped or relocated, ie. to guarantee the translation is always valid. The issue is where we account these pinned pages, where accounting is necessary such that a user cannot lock an arbitrary number of pages into RAM to generate a DoS attack. Duplicate accounting should be resolved by iommufd, but is outside the scope of this discussion. Currently, vfio tests against the mm_struct.locked_vm relative to rlimit(RLIMIT_MEMLOCK), which reads task->signal->rlim[limit].rlim_cur, where task is the current process. This is the same limit set via the setrlimit syscall used by prlimit(1) and reported via 'ulimit -l'. Note that in both cases above, we're dealing with a task, or process limit and both prlimit and ulimit man pages describe them as such. iommufd supposes instead, and references existing kernel implementations, that despite the descriptions above these limits are actually meant to be user limits and therefore instead charges pinned pages against user_struct.locked_vm and also marks them in mm_struct.pinned_vm. The proposed algorithm is to read the _task_ locked memory limit, then attempt to charge the _user_ locked_vm, such that user_struct.locked_vm cannot exceed the task locked memory limit. This obviously has implications. AFAICT, any management tool that doesn't instantiate assigned device VMs under separate users are essentially untenable. For example, if we launch VM1 under userA and set a locked memory limit of 4GB via prlimit to account for an assigned device, that works fine, until we launch VM2 from userA as well. In that case we can't simply set a 4GB limit on the VM2 task because there's already 4GB charged against user_struct.locked_vm for VM1. So we'd need to set the VM2 task limit to 8GB to be able to launch VM2. But not only that, we'd need to go back and also set VM1's task limit to 8GB or else it will fail if a DMA mapped memory region is transient and needs to be re-mapped. Effectively any task under the same user and requiring pinned memory needs to have a locked memory limit set, and updated, to account for all tasks using pinned memory by that user. How does this affect known current use cases of locked memory management for assigned device VMs? Does qemu://system by default sandbox into per VM uids or do they all use the qemu user by default. I imagine qemu://session mode is pretty screwed by this, but I also don't know who/where locked limits are lifted for such VMs. Boxes, who I think now supports assigned device VMs, could also be affected. > So, I still like 2 because it yields the smallest next step before we > can bring all the parallel work onto the list, and it makes testing > and converting non-qemu stuff easier even going forward. If a vfio compatible interface isn't transparently compatible, then I have a hard time understanding its value. Please correct my above description and implications, but I suspect these are not just theoretical ABI compat issues. Thanks, Alex

6 33

[RFC PATCH 0/6] qemu: add support for query-stats-schemas
by Amneesh Singh 19 Oct '22

19 Oct '22

This patch adds an API for query-stats-schemas and uses it to work with the pre-existing API for query-stats to display those stats. [1/6]: This patch adds a simple API for query-stats-schemas and an extractor function to deserialise it into a GHashTable. The GHashTable here is a pair of the name of the stat and the schema for it. Some fields in the latter like the exponent, base and bucket-size are not utilised in this patchset but they will be useful in the subsequent patches which add the support for the histograms. [2/6]: Add query-stats-schemas to the qemu capabilities. [3/6]: This patch adds the schema hashtable to the virDomainObjectPrivate. This decision was made due to QEMU upstream not having vCPUs to generate the schema, so that they could be stored as the file cache. This might be changed in the future if there is workaround upstream or if libvirt ends up using a dummy VM just to query the schema. [4/6]: This patch simply adds a utility function to traverse the schemas to find the object that corresponds to the provided QOM path. [5/6]: This patch adds vCPU stats in addition to the pre-existing ones using a helper function. Histograms are ignored for now but they will be added in the next patchset. [6/6]: This patch adds a new stat worker for QEMU called "Vm" due to the stats being for the "vm" target. It utilises the same helper function as above. Comments are much appreciated. Amneesh Singh (6): qemu_monitor: add qemuMonitorQueryStatsSchema qemu_capabilities: add "query-stats-schemas" QMP command to the QEMU capabilities qemu_domain: add statsSchema to qemuDomainObjPrivate qemu_monitor: add qemuMonitorGetStatsByQOMPath qemu_driver: add the vCPU stats by KVM to the current stats qemu_driver: add new stats worker qemuDomainGetStatsVm include/libvirt/libvirt-domain.h | 1 + src/libvirt-domain.c | 3 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_domain.c | 41 ++++++ src/qemu/qemu_domain.h | 5 + src/qemu/qemu_driver.c | 127 ++++++++++++++++++ src/qemu/qemu_monitor.c | 67 +++++++++ src/qemu/qemu_monitor.h | 39 ++++++ src/qemu/qemu_monitor_json.c | 93 +++++++++++++ src/qemu/qemu_monitor_json.h | 4 + .../caps_7.1.0.x86_64.xml | 1 + tools/virsh-domain-monitor.c | 7 + 13 files changed, 391 insertions(+) -- 2.37.1

3 11

[PATCH 0/3] ppc64: QEMU 7.1 caps + use CAPS_LATEST in xml2argv
by Daniel Henrique Barboza 13 Oct '22

13 Oct '22

Hi, This series updates the remaining pseries tests in qemuxml2argvtest.c to use CAPS_LATEST instead of using a capability list for each test. First patch is the usual capability bump for the new QEMU release. Second patch converts the most simple cases of DO_TEST() to use DO_TEST_CAPS_LATEST(). The patch is rather big but the changes are trivial. Third patch is a change I figured it was worth making to avoid using DO_TEST() in the pseries feature parse error tests. After applying this series, there is no more DO_TEST() tests with 'pseries' in the name in qemuxml2argvtest.c. Daniel Henrique Barboza (3): tests: qemucapabilities: bump ppc64 caps with qemu 7.1.0 tests: change qemuxml2argv pseries tests to TEST_CAPS_LATEST tests: refactor pseries features parse failure tests tests/domaincapsdata/qemu_7.1.0.ppc64.xml | 147 + .../caps_7.1.0.ppc64.replies | 35113 ++++++++++++++++ .../qemucapabilitiesdata/caps_7.1.0.ppc64.xml | 1109 + ...s.args => pseries-basic.ppc64-latest.args} | 11 +- .../pseries-console-native.args | 1 - .../pseries-console-native.ppc64-latest.args | 1 + ... pseries-console-virtio.ppc64-latest.args} | 11 +- ...s => pseries-cpu-compat.ppc64-latest.args} | 10 +- ...gs => pseries-cpu-exact.ppc64-latest.args} | 10 +- ....args => pseries-cpu-le.ppc64-latest.args} | 11 +- ...es-default-phb-numa-node.ppc64-latest.err} | 0 .../qemuxml2argvdata/pseries-features-ccf.xml | 15 +- .../pseries-features-cfpc.xml | 15 +- .../pseries-features-hpt-pagesize.xml | 17 +- .../qemuxml2argvdata/pseries-features-htm.xml | 15 +- .../qemuxml2argvdata/pseries-features-ibs.xml | 15 +- .../pseries-features-nested-hv.xml | 15 +- .../pseries-features-sbbc.xml | 15 +- ...rgs => pseries-features.ppc64-latest.args} | 7 +- .../pseries-hostdevs-1.ppc64-latest.args | 36 + .../pseries-hostdevs-2.ppc64-latest.args | 36 + .../qemuxml2argvdata/pseries-hostdevs-3.args | 32 - .../pseries-hostdevs-3.ppc64-latest.args | 35 + .../pseries-many-buses-1.args | 30 - ...=> pseries-many-buses-1.ppc64-latest.args} | 14 +- .../pseries-many-buses-2.args | 30 - ...=> pseries-many-buses-2.ppc64-latest.args} | 14 +- .../pseries-many-devices.args | 61 - .../pseries-many-devices.ppc64-latest.args | 64 + ...m.args => pseries-nvram.ppc64-latest.args} | 9 +- ...=> pseries-panic-address.ppc64-latest.err} | 0 .../pseries-panic-missing.ppc64-latest.args | 34 + ...pseries-panic-no-address.ppc64-latest.args | 34 + .../pseries-phb-default-missing.args | 30 - ...ies-phb-default-missing.ppc64-latest.args} | 12 +- ...> pseries-phb-numa-node.ppc64-latest.args} | 16 +- .../qemuxml2argvdata/pseries-phb-simple.args | 30 - ...s => pseries-phb-simple.ppc64-latest.args} | 12 +- .../pseries-serial+console-native.args | 1 - ...es-serial+console-native.ppc64-latest.args | 1 + .../pseries-serial-compat.args | 1 - .../pseries-serial-compat.ppc64-latest.args | 1 + ...> pseries-serial-native.ppc64-latest.args} | 9 +- ...s => pseries-serial-pci.ppc64-latest.args} | 9 +- ...s => pseries-serial-usb.ppc64-latest.args} | 11 +- .../qemuxml2argvdata/pseries-usb-default.args | 31 - .../pseries-usb-default.ppc64-latest.args | 34 + tests/qemuxml2argvdata/pseries-usb-kbd.args | 32 - .../pseries-usb-kbd.ppc64-latest.args | 35 + tests/qemuxml2argvdata/pseries-usb-multi.args | 32 - .../pseries-usb-multi.ppc64-latest.args | 35 + ...eries-vio-user-assigned.ppc64-latest.args} | 19 +- ...ned.args => pseries-vio.ppc64-latest.args} | 19 +- tests/qemuxml2argvtest.c | 213 +- 54 files changed, 36978 insertions(+), 572 deletions(-) create mode 100644 tests/domaincapsdata/qemu_7.1.0.ppc64.xml create mode 100644 tests/qemucapabilitiesdata/caps_7.1.0.ppc64.replies create mode 100644 tests/qemucapabilitiesdata/caps_7.1.0.ppc64.xml rename tests/qemuxml2argvdata/{pseries-panic-no-address.args => pseries-basic.ppc64-latest.args} (58%) delete mode 120000 tests/qemuxml2argvdata/pseries-console-native.args create mode 120000 tests/qemuxml2argvdata/pseries-console-native.ppc64-latest.args rename tests/qemuxml2argvdata/{pseries-console-virtio.args => pseries-console-virtio.ppc64-latest.args} (57%) rename tests/qemuxml2argvdata/{pseries-cpu-compat.args => pseries-cpu-compat.ppc64-latest.args} (58%) rename tests/qemuxml2argvdata/{pseries-cpu-exact.args => pseries-cpu-exact.ppc64-latest.args} (59%) rename tests/qemuxml2argvdata/{pseries-cpu-le.args => pseries-cpu-le.ppc64-latest.args} (58%) rename tests/qemuxml2argvdata/{pseries-default-phb-numa-node.err => pseries-default-phb-numa-node.ppc64-latest.err} (100%) mode change 120000 => 100644 tests/qemuxml2argvdata/pseries-features-ccf.xml mode change 120000 => 100644 tests/qemuxml2argvdata/pseries-features-cfpc.xml mode change 120000 => 100644 tests/qemuxml2argvdata/pseries-features-hpt-pagesize.xml mode change 120000 => 100644 tests/qemuxml2argvdata/pseries-features-htm.xml mode change 120000 => 100644 tests/qemuxml2argvdata/pseries-features-ibs.xml mode change 120000 => 100644 tests/qemuxml2argvdata/pseries-features-nested-hv.xml mode change 120000 => 100644 tests/qemuxml2argvdata/pseries-features-sbbc.xml rename tests/qemuxml2argvdata/{pseries-features.args => pseries-features.ppc64-latest.args} (68%) create mode 100644 tests/qemuxml2argvdata/pseries-hostdevs-1.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/pseries-hostdevs-2.ppc64-latest.args delete mode 100644 tests/qemuxml2argvdata/pseries-hostdevs-3.args create mode 100644 tests/qemuxml2argvdata/pseries-hostdevs-3.ppc64-latest.args delete mode 100644 tests/qemuxml2argvdata/pseries-many-buses-1.args rename tests/qemuxml2argvdata/{pseries-hostdevs-2.args => pseries-many-buses-1.ppc64-latest.args} (57%) delete mode 100644 tests/qemuxml2argvdata/pseries-many-buses-2.args rename tests/qemuxml2argvdata/{pseries-hostdevs-1.args => pseries-many-buses-2.ppc64-latest.args} (58%) delete mode 100644 tests/qemuxml2argvdata/pseries-many-devices.args create mode 100644 tests/qemuxml2argvdata/pseries-many-devices.ppc64-latest.args rename tests/qemuxml2argvdata/{pseries-nvram.args => pseries-nvram.ppc64-latest.args} (63%) rename tests/qemuxml2argvdata/{pseries-panic-address.err => pseries-panic-address.ppc64-latest.err} (100%) create mode 100644 tests/qemuxml2argvdata/pseries-panic-missing.ppc64-latest.args create mode 100644 tests/qemuxml2argvdata/pseries-panic-no-address.ppc64-latest.args delete mode 100644 tests/qemuxml2argvdata/pseries-phb-default-missing.args rename tests/qemuxml2argvdata/{pseries-basic.args => pseries-phb-default-missing.ppc64-latest.args} (58%) rename tests/qemuxml2argvdata/{pseries-phb-numa-node.args => pseries-phb-numa-node.ppc64-latest.args} (53%) delete mode 100644 tests/qemuxml2argvdata/pseries-phb-simple.args rename tests/qemuxml2argvdata/{pseries-panic-missing.args => pseries-phb-simple.ppc64-latest.args} (58%) delete mode 120000 tests/qemuxml2argvdata/pseries-serial+console-native.args create mode 120000 tests/qemuxml2argvdata/pseries-serial+console-native.ppc64-latest.args delete mode 120000 tests/qemuxml2argvdata/pseries-serial-compat.args create mode 120000 tests/qemuxml2argvdata/pseries-serial-compat.ppc64-latest.args rename tests/qemuxml2argvdata/{pseries-serial-native.args => pseries-serial-native.ppc64-latest.args} (61%) rename tests/qemuxml2argvdata/{pseries-serial-pci.args => pseries-serial-pci.ppc64-latest.args} (60%) rename tests/qemuxml2argvdata/{pseries-serial-usb.args => pseries-serial-usb.ppc64-latest.args} (57%) delete mode 100644 tests/qemuxml2argvdata/pseries-usb-default.args create mode 100644 tests/qemuxml2argvdata/pseries-usb-default.ppc64-latest.args delete mode 100644 tests/qemuxml2argvdata/pseries-usb-kbd.args create mode 100644 tests/qemuxml2argvdata/pseries-usb-kbd.ppc64-latest.args delete mode 100644 tests/qemuxml2argvdata/pseries-usb-multi.args create mode 100644 tests/qemuxml2argvdata/pseries-usb-multi.ppc64-latest.args rename tests/qemuxml2argvdata/{pseries-vio.args => pseries-vio-user-assigned.ppc64-latest.args} (52%) rename tests/qemuxml2argvdata/{pseries-vio-user-assigned.args => pseries-vio.ppc64-latest.args} (52%) -- 2.37.3

2 7

[PATCH 0/3] fix some issue in concurrency scenarios
by Jiang Jiacheng 12 Oct '22

12 Oct '22

Jiang Jiacheng (3): qemu: Init address before qemuProcessShutdownOrReboot during reconnect process qemu: get the stackManager lock before getting nested lock qemu: back up the path in qemuMonitorOpen src/qemu/qemu_conf.c | 6 +++++- src/qemu/qemu_driver.c | 3 +++ src/qemu/qemu_monitor.c | 5 ++++- src/qemu/qemu_process.c | 10 +++++----- 4 files changed, 17 insertions(+), 7 deletions(-) -- 2.33.0

2 7