[libvirt PATCH v2] Add basically RISC-V support
by Yu Gu
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
1 year, 11 months
questions regarding modular daemons
by Jim Fehlig
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
1 year, 12 months
[PATCH] cpu_map: Add cpu feature amx
by Lin Yang
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
2 years
[libvirt RFC 00/24] basic snapshot delete implementation
by Pavel Hrdina
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 years
[PATCH v3 0/5] network: firewalld: fix routed network
by Eric Garver
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
2 years
Re: [PATCH RFC v2 00/13] IOMMUFD Generic interface
by Alex Williamson
[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
2 years, 1 month
[RFC PATCH 0/6] qemu: add support for query-stats-schemas
by Amneesh Singh
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
2 years, 1 month
[PATCH 0/3] ppc64: QEMU 7.1 caps + use CAPS_LATEST in xml2argv
by Daniel Henrique Barboza
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 years, 1 month
[PATCH 0/3] fix some issue in concurrency scenarios
by Jiang Jiacheng
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 years, 1 month
[PATCH] Fix race condition when detaching a device
by Pierre LIBEAU
Qemu reply to libvirt "DeviceNotFound" and libvirt didn't clean on the
side the live configuration.
qemuMonitorDelDevice() return -2 to qemuDomainDeleteDevice() and during
this action in qemuDomainDetachDeviceLive() the remove is never call.
Ref #359
Signed-off-by: Pierre LIBEAU <pierre.libeau(a)corp.ovh.com>
---
src/qemu/qemu_hotplug.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 9b508dc8f0..52a14a4476 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -93,6 +93,8 @@ qemuDomainResetDeviceRemoval(virDomainObj *vm);
*
* Returns: 0 on success,
* -1 otherwise.
+ * -2 device does not exist in qemu, but it still
+ * exists in libvirt
*/
static int
qemuDomainDeleteDevice(virDomainObj *vm,
@@ -124,7 +126,6 @@ qemuDomainDeleteDevice(virDomainObj *vm,
* domain XML is queried right after detach API the
* device would still be there. */
VIR_DEBUG("Detaching of device %s failed and no event arrived", alias);
- rc = 0;
}
}
@@ -6055,7 +6056,11 @@ qemuDomainDetachDeviceLive(virDomainObj *vm,
if (!async)
qemuDomainMarkDeviceForRemoval(vm, info);
- if (qemuDomainDeleteDevice(vm, info->alias) < 0) {
+ int rc;
+ rc = qemuDomainDeleteDevice(vm, info->alias);
+ if (rc < 0) {
+ if (rc == -2)
+ ret = qemuDomainRemoveDevice(driver, vm, &detach);
if (virDomainObjIsActive(vm))
qemuDomainRemoveAuditDevice(vm, &detach, false);
goto cleanup;
--
2.37.3
2 years, 1 month
