[RFC v9 49/50] target/arm: cpu-pauth: new module for ARMv8.3 Pointer Authentication

2021-03-17 Thread Claudio Fontana
Pointer Authentication is an AARCH64-only ARMv8.3 optional
extension, whose cpu properties can be separated out in its own module.

Signed-off-by: Claudio Fontana 
---
 target/arm/cpu.h   | 13 +---
 target/arm/tcg/cpu-pauth.h | 38 ++
 target/arm/cpu.c   |  3 +-
 target/arm/cpu64.c | 34 +---
 target/arm/tcg/cpu-pauth.c | 66 ++
 target/arm/tcg/meson.build |  1 +
 6 files changed, 108 insertions(+), 47 deletions(-)
 create mode 100644 target/arm/tcg/cpu-pauth.h
 create mode 100644 target/arm/tcg/cpu-pauth.c

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 662ac5ee62..e9cfb99ad9 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -203,6 +203,7 @@ typedef struct {
 #ifdef TARGET_AARCH64
 # define ARM_MAX_VQ16
 # include "cpu-sve.h"
+# include "tcg/cpu-pauth.h"
 #else
 # define ARM_MAX_VQ1
 #endif /* TARGET_AARCH64 */
@@ -211,18 +212,6 @@ typedef struct ARMVectorReg {
 uint64_t d[2 * ARM_MAX_VQ] QEMU_ALIGNED(16);
 } ARMVectorReg;
 
-/* ARMv8.3 Pointer Authentication Extension (AARCH64-only) */
-
-#ifdef TARGET_AARCH64
-void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp);
-/* In AArch32 mode, PAC keys do not exist at all.  */
-typedef struct ARMPACKey {
-uint64_t lo, hi;
-} ARMPACKey;
-#else
-static inline void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp) { }
-#endif
-
 typedef struct CPUARMState {
 /* Regs for current mode.  */
 uint32_t regs[16];
diff --git a/target/arm/tcg/cpu-pauth.h b/target/arm/tcg/cpu-pauth.h
new file mode 100644
index 00..5b130cdada
--- /dev/null
+++ b/target/arm/tcg/cpu-pauth.h
@@ -0,0 +1,38 @@
+/*
+ * QEMU AArch64 Pointer Authentication Extensions
+ *
+ * Copyright (c) 2013 Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see
+ * 
+ */
+
+#ifndef CPU_PAUTH_H
+#define CPU_PAUTH_H
+
+/* ARMv8.3 pauth is an AARCH64 option, only include this for TARGET_AARCH64 */
+
+/* called by arm_cpu_finalize_features in realizefn */
+bool cpu_pauth_finalize(ARMCPU *cpu, Error **errp);
+
+/* add the CPU Pointer Authentication properties */
+void cpu_pauth_add_props(Object *obj);
+
+/* Pointer Authentication Code Key */
+
+typedef struct ARMPACKey {
+uint64_t lo, hi;
+} ARMPACKey;
+
+#endif /* CPU_PAUTH_H */
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 6cf688d772..cf4676e52c 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -843,8 +843,7 @@ void arm_cpu_finalize_features(ARMCPU *cpu, Error **errp)
  * is in use, so the user will not be able to set them.
  */
 if (tcg_enabled()) {
-arm_cpu_pauth_finalize(cpu, &local_err);
-if (local_err != NULL) {
+if (!cpu_pauth_finalize(cpu, &local_err)) {
 error_propagate(errp, local_err);
 return;
 }
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 70345fbecb..9bc5ddfc09 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -245,36 +245,6 @@ static void aarch64_a72_initfn(Object *obj)
 define_arm_cp_regs(cpu, cortex_a72_a57_a53_cp_reginfo);
 }
 
-void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp)
-{
-int arch_val = 0, impdef_val = 0;
-uint64_t t;
-
-/* TODO: Handle HaveEnhancedPAC, HaveEnhancedPAC2, HaveFPAC. */
-if (cpu->prop_pauth) {
-if (cpu->prop_pauth_impdef) {
-impdef_val = 1;
-} else {
-arch_val = 1;
-}
-} else if (cpu->prop_pauth_impdef) {
-error_setg(errp, "cannot enable pauth-impdef without pauth");
-error_append_hint(errp, "Add pauth=on to the CPU property list.\n");
-}
-
-t = cpu->isar.id_aa64isar1;
-t = FIELD_DP64(t, ID_AA64ISAR1, APA, arch_val);
-t = FIELD_DP64(t, ID_AA64ISAR1, GPA, arch_val);
-t = FIELD_DP64(t, ID_AA64ISAR1, API, impdef_val);
-t = FIELD_DP64(t, ID_AA64ISAR1, GPI, impdef_val);
-cpu->isar.id_aa64isar1 = t;
-}
-
-static Property arm_cpu_pauth_property =
-DEFINE_PROP_BOOL("pauth", ARMCPU, prop_pauth, true);
-static Property arm_cpu_pauth_impdef_property =
-DEFINE_PROP_BOOL("pauth-impdef", ARMCPU, prop_pauth_impdef, false);
-
 /* -cpu max: if KVM is enabled, like -cpu host (best possible with this host);
  * otherwise, a CPU with as many features enabled as our emulation supports.
  * The version of '-cpu max' for 

[RFC v9 46/50] target/arm: arch_dump: restrict ELFCLASS64 to AArch64

2021-03-17 Thread Claudio Fontana
this will allow us to restrict more code to TARGET_AARCH64

Signed-off-by: Claudio Fontana 
---
 target/arm/helper-a64.h |  2 ++
 target/arm/helper.h |  1 -
 target/arm/arch_dump.c  | 12 +++-
 target/arm/cpu.c|  1 -
 target/arm/cpu64.c  |  4 
 target/arm/tcg/helper.c | 13 +++--
 6 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/target/arm/helper-a64.h b/target/arm/helper-a64.h
index c139fa81f9..342f55d577 100644
--- a/target/arm/helper-a64.h
+++ b/target/arm/helper-a64.h
@@ -119,3 +119,5 @@ DEF_HELPER_FLAGS_2(st2g_stub, TCG_CALL_NO_WG, void, env, 
i64)
 DEF_HELPER_FLAGS_2(ldgm, TCG_CALL_NO_WG, i64, env, i64)
 DEF_HELPER_FLAGS_3(stgm, TCG_CALL_NO_WG, void, env, i64, i64)
 DEF_HELPER_FLAGS_3(stzgm_tags, TCG_CALL_NO_WG, void, env, i64, i64)
+
+DEF_HELPER_FLAGS_2(rebuild_hflags_a64, TCG_CALL_NO_RWG, void, env, int)
diff --git a/target/arm/helper.h b/target/arm/helper.h
index ff8148ddc6..37dd9797a1 100644
--- a/target/arm/helper.h
+++ b/target/arm/helper.h
@@ -94,7 +94,6 @@ DEF_HELPER_FLAGS_1(rebuild_hflags_m32_newel, TCG_CALL_NO_RWG, 
void, env)
 DEF_HELPER_FLAGS_2(rebuild_hflags_m32, TCG_CALL_NO_RWG, void, env, int)
 DEF_HELPER_FLAGS_1(rebuild_hflags_a32_newel, TCG_CALL_NO_RWG, void, env)
 DEF_HELPER_FLAGS_2(rebuild_hflags_a32, TCG_CALL_NO_RWG, void, env, int)
-DEF_HELPER_FLAGS_2(rebuild_hflags_a64, TCG_CALL_NO_RWG, void, env, int)
 
 DEF_HELPER_FLAGS_5(probe_access, TCG_CALL_NO_WG, void, env, tl, i32, i32, i32)
 
diff --git a/target/arm/arch_dump.c b/target/arm/arch_dump.c
index 0184845310..9d1a7dae56 100644
--- a/target/arm/arch_dump.c
+++ b/target/arm/arch_dump.c
@@ -23,6 +23,8 @@
 #include "elf.h"
 #include "sysemu/dump.h"
 
+#ifdef TARGET_AARCH64
+
 /* struct user_pt_regs from arch/arm64/include/uapi/asm/ptrace.h */
 struct aarch64_user_regs {
 uint64_t regs[31];
@@ -141,7 +143,6 @@ static int 
aarch64_write_elf64_prfpreg(WriteCoreDumpFunction f,
 return 0;
 }
 
-#ifdef TARGET_AARCH64
 static off_t sve_zreg_offset(uint32_t vq, int n)
 {
 off_t off = sizeof(struct aarch64_user_sve_header);
@@ -229,7 +230,6 @@ static int aarch64_write_elf64_sve(WriteCoreDumpFunction f,
 
 return 0;
 }
-#endif
 
 int arm_cpu_write_elf64_note(WriteCoreDumpFunction f, CPUState *cs,
  int cpuid, void *opaque)
@@ -272,15 +272,15 @@ int arm_cpu_write_elf64_note(WriteCoreDumpFunction f, 
CPUState *cs,
 return ret;
 }
 
-#ifdef TARGET_AARCH64
 if (cpu_isar_feature(aa64_sve, cpu)) {
 ret = aarch64_write_elf64_sve(f, env, cpuid, s);
 }
-#endif
 
 return ret;
 }
 
+#endif /* TARGET_AARCH64 */
+
 /* struct pt_regs from arch/arm/include/asm/ptrace.h */
 struct arm_user_regs {
 uint32_t regs[17];
@@ -449,12 +449,14 @@ ssize_t cpu_get_note_size(int class, int machine, int 
nr_cpus)
 size_t note_size;
 
 if (class == ELFCLASS64) {
+#ifdef TARGET_AARCH64
 note_size = AARCH64_PRSTATUS_NOTE_SIZE;
 note_size += AARCH64_PRFPREG_NOTE_SIZE;
-#ifdef TARGET_AARCH64
 if (cpu_isar_feature(aa64_sve, cpu)) {
 note_size += AARCH64_SVE_NOTE_SIZE(&cpu->env);
 }
+#else
+g_assert(0);
 #endif
 } else {
 note_size = ARM_PRSTATUS_NOTE_SIZE;
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index c5a4917035..6cf688d772 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1402,7 +1402,6 @@ static void arm_cpu_class_init(ObjectClass *oc, void 
*data)
 cc->asidx_from_attrs = arm_asidx_from_attrs;
 cc->vmsd = &vmstate_arm_cpu;
 cc->virtio_is_big_endian = arm_cpu_virtio_is_big_endian;
-cc->write_elf64_note = arm_cpu_write_elf64_note;
 cc->write_elf32_note = arm_cpu_write_elf32_note;
 #endif
 
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 971a4474b9..b0026e7ae9 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -623,6 +623,10 @@ static void aarch64_cpu_class_init(ObjectClass *oc, void 
*data)
 cc->gdb_arch_name = aarch64_gdb_arch_name;
 cc->dump_state = aarch64_cpu_dump_state;
 
+#ifndef CONFIG_USER_ONLY
+cc->write_elf64_note = arm_cpu_write_elf64_note;
+#endif /* !CONFIG_USER_ONLY */
+
 object_class_property_add_bool(oc, "aarch64", aarch64_cpu_get_aarch64,
aarch64_cpu_set_aarch64);
 object_class_property_set_description(oc, "aarch64",
diff --git a/target/arm/tcg/helper.c b/target/arm/tcg/helper.c
index 548c94e057..05a8563cea 100644
--- a/target/arm/tcg/helper.c
+++ b/target/arm/tcg/helper.c
@@ -18,6 +18,9 @@
 #include "cpregs.h"
 #include "tcg-cpu.h"
 
+uint32_t rebuild_hflags_a64(CPUARMState *env, int el, int fp_el,
+ARMMMUIdx mmu_idx);
+
 static int vfp_gdb_get_reg(CPUARMState *env, GByteArray *buf, int reg)
 {
 ARMCPU *cpu = env_archcpu(env);
@@ -1152,8 +1155,10 @@ static uint32_t rebuild_hflags_a32(CPUARMState *env, int 
fp_el,
 return rebuild_hflags_common_32(env, fp_el, mmu_idx, flags);
 }
 
-static uint32_t rebuild_hflags_a64

[RFC v9 34/50] tests: device-introspect-test: cope with ARM TCG-only devices

2021-03-17 Thread Claudio Fontana
Skip the test_device_intro_concrete for now for ARM KVM-only build,
as on ARM we currently build devices for ARM that are not
compatible with a KVM-only build.

We can remove this workaround when we fix this in KConfig etc,
and we only list and build machines that are compatible with KVM
for KVM-only builds.

Signed-off-by: Claudio Fontana 
Cc: Philippe Mathieu-Daudé 
---
 tests/qtest/device-introspect-test.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/tests/qtest/device-introspect-test.c 
b/tests/qtest/device-introspect-test.c
index bbec166dbc..1ff15e2247 100644
--- a/tests/qtest/device-introspect-test.c
+++ b/tests/qtest/device-introspect-test.c
@@ -329,12 +329,30 @@ int main(int argc, char **argv)
 qtest_add_func("device/introspect/none", test_device_intro_none);
 qtest_add_func("device/introspect/abstract", test_device_intro_abstract);
 qtest_add_func("device/introspect/abstract-interfaces", 
test_abstract_interfaces);
+
+/*
+ * XXX currently we build also boards for ARM that are incompatible with 
KVM.
+ * We therefore need to check this explicitly, and only test virt for 
kvm-only
+ * arm builds.
+ * After we do the work of Kconfig etc to ensure that only KVM-compatible 
boards
+ * are built for the kvm-only build, we could remove this.
+ */
+#ifndef CONFIG_TCG
+{
+const char *arch = qtest_get_arch();
+if (strcmp(arch, "arm") == 0 || strcmp(arch, "aarch64") == 0) {
+goto add_machine_test_done;
+}
+}
+#endif /* !CONFIG_TCG */
 if (g_test_quick()) {
 qtest_add_data_func("device/introspect/concrete/defaults/none",
 g_strdup(common_args), test_device_intro_concrete);
 } else {
 qtest_cb_for_every_machine(add_machine_test_case, true);
 }
+goto add_machine_test_done;
 
+ add_machine_test_done:
 return g_test_run();
 }
-- 
2.26.2




[RFC v9 47/50] target/arm: cpu-exceptions: new module

2021-03-17 Thread Claudio Fontana
extract the exception handling code from cpu-sysemu,
and split it into general arm code and an AArch64-specific part.

Signed-off-by: Claudio Fontana 
---
 target/arm/cpu-exceptions-aa64.h |  32 +
 target/arm/cpu.h |   4 -
 target/arm/arch_dump.c   |   1 +
 target/arm/cpu-exceptions-aa64.c | 552 +
 target/arm/cpu-exceptions.c  | 481 +++
 target/arm/cpu-sysemu.c  | 976 ---
 target/arm/cpu-user.c|   1 +
 target/arm/cpu64.c   |   1 +
 target/arm/kvm/kvm64.c   |   1 +
 target/arm/tcg/helper-a64.c  |   1 +
 target/arm/tcg/helper.c  |   1 +
 target/arm/meson.build   |   5 +
 12 files changed, 1076 insertions(+), 980 deletions(-)
 create mode 100644 target/arm/cpu-exceptions-aa64.h
 create mode 100644 target/arm/cpu-exceptions-aa64.c
 create mode 100644 target/arm/cpu-exceptions.c

diff --git a/target/arm/cpu-exceptions-aa64.h b/target/arm/cpu-exceptions-aa64.h
new file mode 100644
index 00..2929a83208
--- /dev/null
+++ b/target/arm/cpu-exceptions-aa64.h
@@ -0,0 +1,32 @@
+/*
+ * QEMU AArch64 CPU Exceptions Sysemu code
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see
+ * 
+ */
+
+#ifndef CPU_EXCEPTIONS_AA64_H
+#define CPU_EXCEPTIONS_AA64_H
+
+#include "cpu.h"
+
+int sve_exception_el(CPUARMState *env, int el);
+void aarch64_sync_64_to_32(CPUARMState *env);
+void aarch64_sync_32_to_64(CPUARMState *env);
+void arm_cpu_do_interrupt_aarch64(CPUState *cs);
+
+#endif /* CPU_EXCEPTIONS_AA64_H */
+
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 50a7544d40..ba41053111 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1090,11 +1090,7 @@ static inline void aarch64_sve_change_el(CPUARMState 
*env, int o,
 
 #endif /* TARGET_AARCH64 */
 
-void aarch64_sync_32_to_64(CPUARMState *env);
-void aarch64_sync_64_to_32(CPUARMState *env);
-
 int fp_exception_el(CPUARMState *env, int cur_el);
-int sve_exception_el(CPUARMState *env, int cur_el);
 uint32_t sve_zcr_len_for_el(CPUARMState *env, int el);
 
 /* you can call this signal handler from your SIGBUS and SIGSEGV
diff --git a/target/arm/arch_dump.c b/target/arm/arch_dump.c
index 9d1a7dae56..53ec3696ea 100644
--- a/target/arm/arch_dump.c
+++ b/target/arm/arch_dump.c
@@ -20,6 +20,7 @@
 
 #include "qemu/osdep.h"
 #include "cpu.h"
+#include "cpu-exceptions-aa64.h"
 #include "elf.h"
 #include "sysemu/dump.h"
 
diff --git a/target/arm/cpu-exceptions-aa64.c b/target/arm/cpu-exceptions-aa64.c
new file mode 100644
index 00..5ac52d0a58
--- /dev/null
+++ b/target/arm/cpu-exceptions-aa64.c
@@ -0,0 +1,552 @@
+/*
+ * QEMU AArch64 CPU Exceptions Sysemu code
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see
+ * 
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "cpu.h"
+#include "internals.h"
+#include "sysemu/tcg.h"
+
+#include "cpu-exceptions-aa64.h"
+
+/*
+ * Function used to synchronize QEMU's AArch64 register set with AArch32
+ * register set.  This is necessary when switching between AArch32 and AArch64
+ * execution state.
+ */
+void aarch64_sync_32_to_64(CPUARMState *env)
+{
+int i;
+uint32_t mode = env->uncached_cpsr & CPSR_M;
+
+/* We can blanket copy R[0:7] to X[0:7] */
+for (i = 0; i < 8; i++) {
+env->xregs[i] = env->regs[i];
+}
+
+/*
+ * Unless we are in FIQ mode, x8-x12 come from the user registers r8-r12.
+ * Otherwise, they come from the banked user regs.
+ */
+if (mode == ARM_CPU_MODE_FIQ) {
+for (i = 8; i < 13; i++) {
+env->xregs[i] = env->usr_regs[i - 8];
+}
+} else {
+for (i = 8; i < 13;

[RFC v9 44/50] target/arm: cpu-sve: split TCG and KVM functionality

2021-03-17 Thread Claudio Fontana
put the KVM-specific and TCG-specific functionality
in the respective subdirectories kvm/ and tcg/

Signed-off-by: Claudio Fontana 
---
 target/arm/cpu-sve.h   |   2 +-
 target/arm/kvm/cpu-sve.h   |  30 +++
 target/arm/tcg/cpu-sve.h   |  24 ++
 target/arm/cpu-sve.c   | 166 +++--
 target/arm/cpu.c   |   3 +-
 target/arm/kvm/cpu-sve.c   | 118 ++
 target/arm/tcg/cpu-sve.c   |  80 ++
 target/arm/kvm/meson.build |   1 +
 target/arm/tcg/meson.build |   1 +
 9 files changed, 305 insertions(+), 120 deletions(-)
 create mode 100644 target/arm/kvm/cpu-sve.h
 create mode 100644 target/arm/tcg/cpu-sve.h
 create mode 100644 target/arm/kvm/cpu-sve.c
 create mode 100644 target/arm/tcg/cpu-sve.c

diff --git a/target/arm/cpu-sve.h b/target/arm/cpu-sve.h
index b1be575265..638ebb5665 100644
--- a/target/arm/cpu-sve.h
+++ b/target/arm/cpu-sve.h
@@ -24,7 +24,7 @@
 /* note: SVE is an AARCH64-only option, only include this for TARGET_AARCH64 */
 
 /* called by arm_cpu_finalize_features in realizefn */
-void cpu_sve_finalize_features(ARMCPU *cpu, Error **errp);
+bool cpu_sve_finalize_features(ARMCPU *cpu, Error **errp);
 
 /* add the CPU SVE properties */
 void cpu_sve_add_props(Object *obj);
diff --git a/target/arm/kvm/cpu-sve.h b/target/arm/kvm/cpu-sve.h
new file mode 100644
index 00..053f120940
--- /dev/null
+++ b/target/arm/kvm/cpu-sve.h
@@ -0,0 +1,30 @@
+/*
+ * QEMU AArch64 CPU SVE KVM interface
+ *
+ * Copyright 2021 SUSE LLC
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#ifndef KVM_CPU_SVE_H
+#define KVM_CPU_SVE_H
+
+/* note: SVE is an AARCH64-only option, only include this for TARGET_AARCH64 */
+
+void kvm_cpu_sve_get_supported_lens(ARMCPU *cpu,
+unsigned long *kvm_supported);
+
+void kvm_cpu_sve_enable_lens(unsigned long *sve_vq_map,
+ unsigned long *sve_vq_init, uint32_t max_vq,
+ unsigned long *kvm_supported);
+
+uint32_t kvm_cpu_sve_disable_lens(unsigned long *sve_vq_map,
+  unsigned long *sve_vq_init,
+  unsigned long *kvm_supported, Error **errp);
+
+bool kvm_cpu_sve_validate_lens(unsigned long *sve_vq_map, uint32_t max_vq,
+   unsigned long *kvm_supported, Error **errp,
+   uint32_t sve_max_vq);
+
+#endif /* KVM_CPU_SVE_H */
diff --git a/target/arm/tcg/cpu-sve.h b/target/arm/tcg/cpu-sve.h
new file mode 100644
index 00..49f6ad021b
--- /dev/null
+++ b/target/arm/tcg/cpu-sve.h
@@ -0,0 +1,24 @@
+/*
+ * QEMU AArch64 CPU SVE TCG interface
+ *
+ * Copyright 2021 SUSE LLC
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+
+#ifndef TCG_CPU_SVE_H
+#define TCG_CPU_SVE_H
+
+/* note: SVE is an AARCH64-only option, only include this for TARGET_AARCH64 */
+
+void tcg_cpu_sve_enable_lens(unsigned long *sve_vq_map,
+ unsigned long *sve_vq_init, uint32_t max_vq);
+
+uint32_t tcg_cpu_sve_disable_lens(unsigned long *sve_vq_map,
+  unsigned long *sve_vq_init, Error **errp);
+
+bool tcg_cpu_sve_validate_lens(unsigned long *sve_vq_map, uint32_t max_vq,
+   Error **errp);
+
+#endif /* TCG_CPU_SVE_H */
diff --git a/target/arm/cpu-sve.c b/target/arm/cpu-sve.c
index 538ec3164f..a42a97ccd8 100644
--- a/target/arm/cpu-sve.c
+++ b/target/arm/cpu-sve.c
@@ -26,7 +26,29 @@
 #include "kvm/kvm_arm.h"
 #include "qapi/visitor.h"
 
-void cpu_sve_finalize_features(ARMCPU *cpu, Error **errp)
+#include "tcg/cpu-sve.h"
+#include "kvm/cpu-sve.h"
+
+static bool apply_max_vq(unsigned long *sve_vq_map, unsigned long *sve_vq_init,
+ uint32_t max_vq, Error **errp)
+{
+DECLARE_BITMAP(tmp, ARM_MAX_VQ);
+
+if (!test_bit(max_vq - 1, sve_vq_map) &&
+test_bit(max_vq - 1, sve_vq_init)) {
+error_setg(errp, "cannot disable sve%d", max_vq * 128);
+error_append_hint(errp, "The maximum vector length must be "
+  "enabled, sve-max-vq=%d (%d bits)\n",
+  max_vq, max_vq * 128);
+return false;
+}
+/* Set all bits not explicitly set within sve-max-vq. */
+bitmap_complement(tmp, sve_vq_init, max_vq);
+bitmap_or(sve_vq_map, sve_vq_map, tmp, max_vq);
+return true;
+}
+
+bool cpu_sve_finalize_features(ARMCPU *cpu, Error **errp)
 {
 /*
  * If any vector lengths are explicitly enabled with sve properties,
@@ -44,17 +66,11 @@ void cpu_sve_finalize_features(ARMCPU *cpu, Error **errp)
  * vector length must be enabled.
  */
 DECLARE_BITMAP(kvm_supported, ARM_MAX_VQ);
-DECLARE_BITMAP(tmp, ARM_MAX_VQ);
-uint32_t vq, max_vq = 0;
+uint32_t ma

Re: [PATCH 2/5] hw/arm/aspeed: Do not sysbus-map mmio flash region directly, use alias

2021-03-17 Thread Philippe Mathieu-Daudé
On 3/17/21 7:30 PM, Cédric Le Goater wrote:
> On 3/12/21 7:28 PM, Philippe Mathieu-Daudé wrote:
>> The flash mmio region is exposed as an AddressSpace.
>> AddressSpaces must not be sysbus-mapped, therefore map
>> the region using an alias.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
> 
> That does the trick but you need an extra change in the model. 
> 
> The fixes are in my aspeed-6.0 branch on GH and they survive the last
> patch of your series :
> 
>   [PATCH 5/5] memory: Make sure root MR won't be added as subregion

I wondered about changing DMA_FLASH_ADDR() wasn't sure the tests
would use the flash.

> I will upstream for 6.1.

Thanks!

Phil.



Re: [RFC v9 29/50] target/arm: cleanup cpu includes

2021-03-17 Thread Philippe Mathieu-Daudé
On 3/17/21 7:29 PM, Claudio Fontana wrote:
> cpu.c,
> cpu32.c,
> cpu64.c,
> tcg/sysemu/tcg-cpu.c,
> 
> all need a good cleanup when it comes to included header files.
> 
> Signed-off-by: Claudio Fontana 
> ---
>  target/arm/cpu.c|  8 ++--
>  target/arm/cpu32.c  | 14 --
>  target/arm/cpu64.c  |  6 --
>  target/arm/tcg/sysemu/tcg-cpu.c | 22 +-
>  roms/SLOF   |  2 +-
>  5 files changed, 4 insertions(+), 48 deletions(-)

> diff --git a/roms/SLOF b/roms/SLOF
> index 33a7322de1..e18ddad851 16
> --- a/roms/SLOF
> +++ b/roms/SLOF
> @@ -1 +1 @@
> -Subproject commit 33a7322de13e9dca4b38851a345a58d37e7a441d
> +Subproject commit e18ddad8516ff2cfe36ec130200318f7251aa78c

Besides this dubious change, the rest LGTM :)




[RFC v9 43/50] target/arm: cpu-sve: new module

2021-03-17 Thread Claudio Fontana
extract the SVE-related cpu object properties and functions,
and move them to a separate module.

Disentangle SVE from pauth that is a separate, TCG-only feature.

Signed-off-by: Claudio Fontana 
---
 target/arm/cpu-sve.h |  40 +
 target/arm/cpu.h |  22 +--
 target/arm/cpu-sve.c | 360 +++
 target/arm/cpu.c |   5 +-
 target/arm/cpu64.c   | 333 +---
 target/arm/kvm/kvm-cpu.c |   2 +-
 target/arm/meson.build   |   1 +
 7 files changed, 417 insertions(+), 346 deletions(-)
 create mode 100644 target/arm/cpu-sve.h
 create mode 100644 target/arm/cpu-sve.c

diff --git a/target/arm/cpu-sve.h b/target/arm/cpu-sve.h
new file mode 100644
index 00..b1be575265
--- /dev/null
+++ b/target/arm/cpu-sve.h
@@ -0,0 +1,40 @@
+/*
+ * QEMU AArch64 CPU SVE Extensions for TARGET_AARCH64
+ *
+ * Copyright (c) 2013 Linaro Ltd
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see
+ * 
+ */
+
+#ifndef CPU_SVE_H
+#define CPU_SVE_H
+
+/* note: SVE is an AARCH64-only option, only include this for TARGET_AARCH64 */
+
+/* called by arm_cpu_finalize_features in realizefn */
+void cpu_sve_finalize_features(ARMCPU *cpu, Error **errp);
+
+/* add the CPU SVE properties */
+void cpu_sve_add_props(Object *obj);
+
+/* add the CPU SVE properties specific to the "MAX" CPU */
+void cpu_sve_add_props_max(Object *obj);
+
+/* In AArch32 mode, predicate registers do not exist at all.  */
+typedef struct ARMPredicateReg {
+uint64_t p[DIV_ROUND_UP(2 * ARM_MAX_VQ, 8)] QEMU_ALIGNED(16);
+} ARMPredicateReg;
+
+#endif /* CPU_SVE_H */
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 0554533d13..a7646d56c5 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -173,7 +173,8 @@ typedef struct {
 #define VSTCR_SW VTCR_NSW
 #define VSTCR_SA VTCR_NSA
 
-/* Define a maximum sized vector register.
+/*
+ * Define a maximum sized vector register.
  * For 32-bit, this is a 128-bit NEON/AdvSIMD register.
  * For 64-bit, this is a 2048-bit SVE register.
  *
@@ -201,28 +202,25 @@ typedef struct {
 
 #ifdef TARGET_AARCH64
 # define ARM_MAX_VQ16
-void arm_cpu_sve_finalize(ARMCPU *cpu, Error **errp);
-void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp);
+# include "cpu-sve.h"
 #else
 # define ARM_MAX_VQ1
-static inline void arm_cpu_sve_finalize(ARMCPU *cpu, Error **errp) { }
-static inline void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp) { }
-#endif
+#endif /* TARGET_AARCH64 */
 
 typedef struct ARMVectorReg {
 uint64_t d[2 * ARM_MAX_VQ] QEMU_ALIGNED(16);
 } ARMVectorReg;
 
-#ifdef TARGET_AARCH64
-/* In AArch32 mode, predicate registers do not exist at all.  */
-typedef struct ARMPredicateReg {
-uint64_t p[DIV_ROUND_UP(2 * ARM_MAX_VQ, 8)] QEMU_ALIGNED(16);
-} ARMPredicateReg;
+/* ARMv8.3 Pointer Authentication Extension (AARCH64-only) */
 
+#ifdef TARGET_AARCH64
+void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp);
 /* In AArch32 mode, PAC keys do not exist at all.  */
 typedef struct ARMPACKey {
 uint64_t lo, hi;
 } ARMPACKey;
+#else
+static inline void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp) { }
 #endif
 
 typedef struct CPUARMState {
@@ -1052,7 +1050,6 @@ int aarch64_cpu_gdb_write_register(CPUState *cpu, uint8_t 
*buf, int reg);
 void aarch64_sve_narrow_vq(CPUARMState *env, unsigned vq);
 void aarch64_sve_change_el(CPUARMState *env, int old_el,
int new_el, bool el0_a64);
-void aarch64_add_sve_properties(Object *obj);
 
 /*
  * SVE registers are encoded in KVM's memory in an endianness-invariant format.
@@ -1083,7 +1080,6 @@ static inline void aarch64_sve_narrow_vq(CPUARMState 
*env, unsigned vq) { }
 static inline void aarch64_sve_change_el(CPUARMState *env, int o,
  int n, bool a)
 { }
-static inline void aarch64_add_sve_properties(Object *obj) { }
 #endif
 
 void aarch64_sync_32_to_64(CPUARMState *env);
diff --git a/target/arm/cpu-sve.c b/target/arm/cpu-sve.c
new file mode 100644
index 00..538ec3164f
--- /dev/null
+++ b/target/arm/cpu-sve.c
@@ -0,0 +1,360 @@
+/*
+ * QEMU ARM CPU
+ *
+ * Copyright (c) 2012 SUSE LINUX Products GmbH
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of t

[PATCH 2/2] plugins: Move all typedef and type declaration to the front of the qemu-plugin.h

2021-03-17 Thread Yonggang Luo
Signed-off-by: Yonggang Luo 
---
 include/qemu/qemu-plugin.h | 187 ++---
 1 file changed, 92 insertions(+), 95 deletions(-)

diff --git a/include/qemu/qemu-plugin.h b/include/qemu/qemu-plugin.h
index 97cdfd7761..2cb17f3051 100644
--- a/include/qemu/qemu-plugin.h
+++ b/include/qemu/qemu-plugin.h
@@ -81,27 +81,6 @@ typedef struct qemu_info_t {
 };
 } qemu_info_t;
 
-/**
- * qemu_plugin_install() - Install a plugin
- * @id: this plugin's opaque ID
- * @info: a block describing some details about the guest
- * @argc: number of arguments
- * @argv: array of arguments (@argc elements)
- *
- * All plugins must export this symbol which is called when the plugin
- * is first loaded. Calling qemu_plugin_uninstall() from this function
- * is a bug.
- *
- * Note: @info is only live during the call. Copy any information we
- * want to keep. @argv remains valid throughout the lifetime of the
- * loaded plugin.
- *
- * Return: 0 on successful loading, !0 for an error.
- */
-QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id,
-   const qemu_info_t *info,
-   int argc, char **argv);
-
 /**
  * typedef qemu_plugin_simple_cb_t - simple callback
  * @id: the unique qemu_plugin_id_t
@@ -135,6 +114,98 @@ typedef void 
(*qemu_plugin_vcpu_simple_cb_t)(qemu_plugin_id_t id,
 typedef void (*qemu_plugin_vcpu_udata_cb_t)(unsigned int vcpu_index,
 void *userdata);
 
+/** struct qemu_plugin_tb - Opaque handle for a translation block */
+struct qemu_plugin_tb;
+/** struct qemu_plugin_insn - Opaque handle for a translated instruction */
+struct qemu_plugin_insn;
+
+/**
+ * enum qemu_plugin_cb_flags - type of callback
+ *
+ * @QEMU_PLUGIN_CB_NO_REGS: callback does not access the CPU's regs
+ * @QEMU_PLUGIN_CB_R_REGS: callback reads the CPU's regs
+ * @QEMU_PLUGIN_CB_RW_REGS: callback reads and writes the CPU's regs
+ *
+ * Note: currently unused, plugins cannot read or change system
+ * register state.
+ */
+enum qemu_plugin_cb_flags {
+QEMU_PLUGIN_CB_NO_REGS,
+QEMU_PLUGIN_CB_R_REGS,
+QEMU_PLUGIN_CB_RW_REGS,
+};
+
+enum qemu_plugin_mem_rw {
+QEMU_PLUGIN_MEM_R = 1,
+QEMU_PLUGIN_MEM_W,
+QEMU_PLUGIN_MEM_RW,
+};
+
+/**
+ * typedef qemu_plugin_vcpu_tb_trans_cb_t - translation callback
+ * @id: unique plugin id
+ * @tb: opaque handle used for querying and instrumenting a block.
+ */
+typedef void (*qemu_plugin_vcpu_tb_trans_cb_t)(qemu_plugin_id_t id,
+   struct qemu_plugin_tb *tb);
+
+/**
+ * enum qemu_plugin_op - describes an inline op
+ *
+ * @QEMU_PLUGIN_INLINE_ADD_U64: add an immediate value uint64_t
+ *
+ * Note: currently only a single inline op is supported.
+ */
+
+enum qemu_plugin_op {
+QEMU_PLUGIN_INLINE_ADD_U64,
+};
+
+/**
+ * typedef qemu_plugin_meminfo_t - opaque memory transaction handle
+ *
+ * This can be further queried using the qemu_plugin_mem_* query
+ * functions.
+ */
+typedef uint32_t qemu_plugin_meminfo_t;
+/** struct qemu_plugin_hwaddr - opaque hw address handle */
+struct qemu_plugin_hwaddr;
+
+typedef void
+(*qemu_plugin_vcpu_mem_cb_t)(unsigned int vcpu_index,
+ qemu_plugin_meminfo_t info, uint64_t vaddr,
+ void *userdata);
+
+typedef void
+(*qemu_plugin_vcpu_syscall_cb_t)(qemu_plugin_id_t id, unsigned int vcpu_index,
+ int64_t num, uint64_t a1, uint64_t a2,
+ uint64_t a3, uint64_t a4, uint64_t a5,
+ uint64_t a6, uint64_t a7, uint64_t a8);
+typedef void
+(*qemu_plugin_vcpu_syscall_ret_cb_t)(qemu_plugin_id_t id, unsigned int 
vcpu_idx,
+ int64_t num, int64_t ret);
+
+/**
+ * qemu_plugin_install() - Install a plugin
+ * @id: this plugin's opaque ID
+ * @info: a block describing some details about the guest
+ * @argc: number of arguments
+ * @argv: array of arguments (@argc elements)
+ *
+ * All plugins must export this symbol which is called when the plugin
+ * is first loaded. Calling qemu_plugin_uninstall() from this function
+ * is a bug.
+ *
+ * Note: @info is only live during the call. Copy any information we
+ * want to keep. @argv remains valid throughout the lifetime of the
+ * loaded plugin.
+ *
+ * Return: 0 on successful loading, !0 for an error.
+ */
+QEMU_PLUGIN_EXPORT int qemu_plugin_install(qemu_plugin_id_t id,
+   const qemu_info_t *info,
+   int argc, char **argv);
+
 /**
  * qemu_plugin_uninstall() - Uninstall a plugin
  * @id: this plugin's opaque ID
@@ -205,41 +276,6 @@ void qemu_plugin_register_vcpu_idle_cb(qemu_plugin_id_t id,
 void qemu_plugin_register_vcpu_resume_cb(qemu_plugin_id_t id,
  qemu_plugin_vcpu_simple_cb_t cb);
 
-/** struct qemu_plugin_tb - Opa

[PATCH 0/2] *** This is based on pull request from Alex Bennée ***

2021-03-17 Thread Yonggang Luo
*** BLURB HERE ***
The pull request
https://patchew.org/QEMU/20210317072216.16316-1-alex.ben...@linaro.org/

Yonggang Luo (2):
  plugins: Update qemu-plugins.symbols to match qemu-plugins.h
  plugins: Move all typedef and type declaration to the front of the
qemu-plugin.h

 include/qemu/qemu-plugin.h   | 187 +--
 plugins/qemu-plugins.symbols |  25 +++--
 2 files changed, 104 insertions(+), 108 deletions(-)

-- 
2.29.2.windows.3




[RFC v9 48/50] target/arm: tcg: restrict ZCR cpregs to TARGET_AARCH64

2021-03-17 Thread Claudio Fontana
restrict zcr_el1, zcr_el2, zcr_no_el2, zcr_el3 reginfo,
as well as related SVE functions.

Signed-off-by: Claudio Fontana 
---
 target/arm/cpu.h |  7 ---
 target/arm/tcg/cpu-sve.h |  7 +++
 linux-user/syscall.c |  4 
 target/arm/cpu-exceptions-aa64.c |  1 +
 target/arm/tcg/cpregs.c  | 10 --
 target/arm/tcg/helper-a64.c  |  1 +
 target/arm/tcg/helper.c  |  1 +
 7 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index ba41053111..662ac5ee62 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1047,9 +1047,6 @@ int arm_cpu_write_elf32_note(WriteCoreDumpFunction f, 
CPUState *cs,
 #ifdef TARGET_AARCH64
 int aarch64_cpu_gdb_read_register(CPUState *cpu, GByteArray *buf, int reg);
 int aarch64_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
-void aarch64_sve_narrow_vq(CPUARMState *env, unsigned vq);
-void aarch64_sve_change_el(CPUARMState *env, int old_el,
-   int new_el, bool el0_a64);
 
 static inline bool is_a64(CPUARMState *env)
 {
@@ -1081,10 +1078,6 @@ static inline uint64_t *sve_bswap64(uint64_t *dst, 
uint64_t *src, int nr)
 }
 
 #else
-static inline void aarch64_sve_narrow_vq(CPUARMState *env, unsigned vq) { }
-static inline void aarch64_sve_change_el(CPUARMState *env, int o,
- int n, bool a)
-{ }
 
 #define is_a64(env) (false)
 
diff --git a/target/arm/tcg/cpu-sve.h b/target/arm/tcg/cpu-sve.h
index 49f6ad021b..fc53b26998 100644
--- a/target/arm/tcg/cpu-sve.h
+++ b/target/arm/tcg/cpu-sve.h
@@ -21,4 +21,11 @@ uint32_t tcg_cpu_sve_disable_lens(unsigned long *sve_vq_map,
 bool tcg_cpu_sve_validate_lens(unsigned long *sve_vq_map, uint32_t max_vq,
Error **errp);
 
+/* tcg/helper.c */
+
+void aarch64_sve_narrow_vq(CPUARMState *env, unsigned vq);
+
+void aarch64_sve_change_el(CPUARMState *env, int old_el,
+   int new_el, bool el0_a64);
+
 #endif /* TCG_CPU_SVE_H */
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 1e508576c7..9dbfe6fdc0 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -134,6 +134,10 @@
 #include "fd-trans.h"
 #include "tcg/tcg.h"
 
+#ifdef TARGET_AARCH64
+#include "tcg/cpu-sve.h"
+#endif /* TARGET_AARCH64 */
+
 #ifndef CLONE_IO
 #define CLONE_IO0x8000  /* Clone io context */
 #endif
diff --git a/target/arm/cpu-exceptions-aa64.c b/target/arm/cpu-exceptions-aa64.c
index 5ac52d0a58..ac42cb8626 100644
--- a/target/arm/cpu-exceptions-aa64.c
+++ b/target/arm/cpu-exceptions-aa64.c
@@ -21,6 +21,7 @@
 #include "qemu/osdep.h"
 #include "qemu/log.h"
 #include "cpu.h"
+#include "tcg/cpu-sve.h"
 #include "internals.h"
 #include "sysemu/tcg.h"
 
diff --git a/target/arm/tcg/cpregs.c b/target/arm/tcg/cpregs.c
index a72c9378b2..7376fad2eb 100644
--- a/target/arm/tcg/cpregs.c
+++ b/target/arm/tcg/cpregs.c
@@ -5792,6 +5792,10 @@ static const ARMCPRegInfo debug_lpae_cp_reginfo[] = {
 REGINFO_SENTINEL
 };
 
+#ifdef TARGET_AARCH64
+
+#include "tcg/cpu-sve.h"
+
 static void zcr_write(CPUARMState *env, const ARMCPRegInfo *ri,
   uint64_t value)
 {
@@ -5844,6 +5848,8 @@ static const ARMCPRegInfo zcr_el3_reginfo = {
 .writefn = zcr_write, .raw_writefn = raw_write
 };
 
+#endif /* TARGET_AARCH64 */
+
 static void dbgwvr_write(CPUARMState *env, const ARMCPRegInfo *ri,
  uint64_t value)
 {
@@ -7573,6 +7579,7 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 define_arm_cp_regs(cpu, vhe_reginfo);
 }
 
+#ifdef TARGET_AARCH64
 if (cpu_isar_feature(aa64_sve, cpu)) {
 define_one_arm_cp_reg(cpu, &zcr_el1_reginfo);
 if (arm_feature(env, ARM_FEATURE_EL2)) {
@@ -7585,7 +7592,6 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 }
 }
 
-#ifdef TARGET_AARCH64
 if (cpu_isar_feature(aa64_pauth, cpu)) {
 define_arm_cp_regs(cpu, pauth_reginfo);
 }
@@ -7615,7 +7621,7 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 define_arm_cp_regs(cpu, mte_tco_ro_reginfo);
 define_arm_cp_regs(cpu, mte_el0_cacheop_reginfo);
 }
-#endif
+#endif /* TARGET_AARCH64 */
 
 if (cpu_isar_feature(any_predinv, cpu)) {
 define_arm_cp_regs(cpu, predinv_reginfo);
diff --git a/target/arm/tcg/helper-a64.c b/target/arm/tcg/helper-a64.c
index b75ce80473..157a5bb549 100644
--- a/target/arm/tcg/helper-a64.c
+++ b/target/arm/tcg/helper-a64.c
@@ -20,6 +20,7 @@
 #include "qemu/osdep.h"
 #include "qemu/units.h"
 #include "cpu.h"
+#include "tcg/cpu-sve.h"
 #include "cpu-exceptions-aa64.h"
 #include "exec/gdbstub.h"
 #include "exec/helper-proto.h"
diff --git a/target/arm/tcg/helper.c b/target/arm/tcg/helper.c
index 493f5b066d..2e8b122cc4 100644
--- a/target/arm/tcg/helper.c
+++ b/target/arm/tcg/helper.c
@@ -16,6 +16,7 @@
 #include  /* For crc32 */
 #include "arm_ldst.h"
 #include "cpu-mmu.h"
+#include "tcg/cpu-sve.h"
 #inclu

Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image

2021-03-17 Thread Philippe Mathieu-Daudé
Hi Maciej, Alex,

On 3/12/21 9:04 PM, Maciej W. Rozycki wrote:
> On Fri, 12 Mar 2021, Philippe Mathieu-Daudé wrote:
> 
>>> but your two options to 
>>> choose from are:
>>>
>>> 1. Build for the soft-float ABI (`-msoft-float') where any FP calculations 
>>>are compiled such as to be made by the CPU using integer arithmetic.
>>
>> With the Debian toolchain I get:
>>
>> /usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No
>> such file or directory
>>  #include 
>>   ^~
> 
>  You need to have a soft-float multilib available.  You can use:
> 
> $ gcc -print-multi-lib
> 
> to see what multilibs are available.  You'd have to have one that includes 
> `-msoft-float' and `-mabi=n32' both at a time.  If there's no such one, 
> then you'll have to build your own cross-compiler (including soft-float 
> libc).

For Alex:

I tried Maciej suggestion using:

-- >8 --
diff --git a/tests/docker/dockerfiles/debian10.docker
b/tests/docker/dockerfiles/debian10.docker
index d034acbd256..42933538a49 100644
--- a/tests/docker/dockerfiles/debian10.docker
+++ b/tests/docker/dockerfiles/debian10.docker
@@ -23,6 +23,7 @@ RUN apt update && \
 ccache \
 clang \
 dbus \
+gcc-multilib \
 gdb-multiarch \
 gettext \
 git \
---

Then used qemu/debian-mipsel-cross.

Maciej, I tried your suggestion as follow:

$ mipsel-linux-gnu-gcc --version
mipsel-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ mipsel-linux-gnu-gcc -print-multi-lib
.;
n32;@mabi=n32
64;@mabi=64

soft-float is not listed, but:

$ touch a.c
$ mipsel-linux-gnu-gcc -mabi=n32 -march=r5900 -msoft-float -c a.c
$ file a.o
a.o: ELF 32-bit LSB relocatable, MIPS, N32 MIPS-III version 1 (SYSV),
not stripped
$ readelf -h a.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  REL (Relocatable file)
  Machine:   MIPS R3000
  Version:   0x1
  Entry point address:   0x0
  Start of program headers:  0 (bytes into file)
  Start of section headers:  456 (bytes into file)
  Flags: 0x20920026, pic, cpic, abi2, 5900,
mips3
  Size of this header:   52 (bytes)
  Size of program headers:   0 (bytes)
  Number of program headers: 0
  Size of section headers:   40 (bytes)
  Number of section headers: 13
  Section header string table index: 12

So we can compile, but:

$ mipsel-linux-gnu-gcc -mabi=n32 -march=r5900 -msoft-float -L
/usr/lib/mipsel-linux-gnu tests/tcg/mips/test-r5900-dmult.c
/usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
/usr/lib/../lib32/Scrt1.o: relocations in generic ELF (EM: 3)
/usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
/usr/lib/../lib32/Scrt1.o: error adding symbols: file in wrong format
collect2: error: ld returned 1 exit status

$ mipsel-linux-gnu-readelf -h /usr/lib/mipsel-linux-gnu/Scrt1.o
ELF Header:
  Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF32
  Data:  2's complement, little endian
  Version:   1 (current)
  OS/ABI:UNIX - System V
  ABI Version:   0
  Type:  REL (Relocatable file)
  Machine:   MIPS R3000
  Version:   0x1
  Entry point address:   0x0
  Start of program headers:  0 (bytes into file)
  Start of section headers:  908 (bytes into file)
  Flags: 0x70001007, noreorder, pic, cpic,
o32, mips32r2
  Size of this header:   52 (bytes)
  Size of program headers:   0 (bytes)
  Number of program headers: 0
  Size of section headers:   40 (bytes)
  Number of section headers: 15
  Section header string table index: 14

The multilib documentation is scarce :)

Also I wondered if I could abuse the linker a bit, knowing the resulting
binary would be crap due to ABI mismatch, and got:

$ mipsel-linux-gnu-gcc -march=r5900 -msoft-float -o test-r5900-dmult
test-r5900-dmult.o
collect2: fatal error: ld terminated with signal 11 [Segmentation
fault], core dumped
compilation terminated.
/usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
test-r5900-dmult.o: ABI is incompatible with that of the selected emulation
/usr/lib/gcc-cross/mipsel-li

Re: [PATCH 0/3] tests/acceptance: Handle tests with "cpu" tag

2021-03-17 Thread Wainer dos Santos Moschetta

Added John and Eduardo,

On 3/9/21 3:52 PM, Cleber Rosa wrote:

On Wed, Feb 24, 2021 at 06:26:51PM -0300, Wainer dos Santos Moschetta wrote:

Currently the acceptance tests tagged with "machine" have the "-M TYPE"
automatically added to the list of arguments of the QEMUMachine object.
In other words, that option is passed to the launched QEMU. On this
series it is implemented the same feature but instead for tests marked
with "cpu".


Good!


There is a caveat, however, in case the test needs additional arguments to
the CPU type they cannot be passed via tag, because the tags parser split
values by comma. For example, in tests/acceptance/x86_cpu_model_versions.py,
there are cases where:

   * -cpu is set to 
"Cascadelake-Server,x-force-features=on,check=off,enforce=off"
   * if it was tagged like 
"cpu:Cascadelake-Server,x-force-features=on,check=off,enforce=off"
 then the parser would break it into 4 tags ("cpu:Cascadelake-Server",
 "x-force-features=on", "check=off", "enforce=off")
   * resulting on "-cpu Cascadelake-Server" and the remaining arguments are 
ignored.

For the example above, one should tag it (or not at all) as 
"cpu:Cascadelake-Server"
AND self.vm.add_args('-cpu', 
"Cascadelake-Server,x-force-features=on,check=off,enforce=off"),
and that results on something like:

   "qemu-system-x86_64 (...) -cpu Cascadelake-Server -cpu 
Cascadelake-Server,x-force-features=on,check=off,enforce=off".


There are clearly two problems here:

1) the tag is meant to be succinct, so that it can be used by users
selecting which tests to run.  At the same time, it's a waste
to throw away the other information or keep it duplicate or
incosistent.

2) QEMUMachine doesn't keep track of command line arguments
(add_args() makes it pretty clear what's doing).  But, on this type
of use case, a "set_args()" is desirable, in which case it would
overwrite the existing arguments for a given command line option.


I like the idea of a "set_args()" to QEMUMachine as you describe above 
but it needs further discussion because I can see at least one corner 
case; for example, one can set the machine type as either -machine or 
-M, then what key it should be searched-and-replaced (if any) on the 
list of args?


Unlike your suggestion, I thought on implement the method to deal with a 
single argument at time, as:


    def set_arg(self, arg: Union[str, list], value: str) -> None:
    """
    Set the value of an argument from the list of extra arguments to be
    given to the QEMU binary. If the argument does not exist then it is
    added to the list.

    If the ``arg`` parameter is a list then it will search and 
replace all

    occurencies (if any). Otherwise a new argument is added and it is
    used the first value of the ``arg`` list.
    """
    pass

Does it sound good to you?

Thanks!

Wainer


QEMU is going to ignore the first -cpu argument. See the patch 0003 for a 
reference.


But this would still be creating a QEMU command line with multiple
'-cpu' arguments, right?  I understand this could be useful for
testing the behavior of the parameter parsing (if that's intended) but
it's bad practice to be generating incorrect command line in tests.

Maybe just by tackling issue #2 this could be avoided.

Cheers,
- Cleber.





Re: [PATCH 2/5] hw/arm/aspeed: Do not sysbus-map mmio flash region directly, use alias

2021-03-17 Thread Cédric Le Goater
On 3/13/21 1:05 PM, Philippe Mathieu-Daudé wrote:
> Incorrect subject prefix, should be "hw/ssi/aspeed_smc"

Is this just good practice or something that was agreed upon ? 
We should update checkpatch if so.

Thanks,

C. 


> 
> On 3/12/21 7:28 PM, Philippe Mathieu-Daudé wrote:
>> The flash mmio region is exposed as an AddressSpace.
>> AddressSpaces must not be sysbus-mapped, therefore map
>> the region using an alias.
>>
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>>  include/hw/ssi/aspeed_smc.h | 1 +
>>  hw/ssi/aspeed_smc.c | 4 +++-
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/hw/ssi/aspeed_smc.h b/include/hw/ssi/aspeed_smc.h
>> index 16c03fe64f3..e3c96cecbd8 100644
>> --- a/include/hw/ssi/aspeed_smc.h
>> +++ b/include/hw/ssi/aspeed_smc.h
>> @@ -84,6 +84,7 @@ struct AspeedSMCState {
>>  
>>  MemoryRegion mmio;
>>  MemoryRegion mmio_flash;
>> +MemoryRegion mmio_flash_alias;
>>  
>>  qemu_irq irq;
>>  int irqline;
>> diff --git a/hw/ssi/aspeed_smc.c b/hw/ssi/aspeed_smc.c
>> index 16addee4dc8..aa26578bdac 100644
>> --- a/hw/ssi/aspeed_smc.c
>> +++ b/hw/ssi/aspeed_smc.c
>> @@ -1386,7 +1386,9 @@ static void aspeed_smc_realize(DeviceState *dev, Error 
>> **errp)
>>  memory_region_init_io(&s->mmio_flash, OBJECT(s),
>>&aspeed_smc_flash_default_ops, s, name,
>>s->ctrl->flash_window_size);
>> -sysbus_init_mmio(sbd, &s->mmio_flash);
>> +memory_region_init_alias(&s->mmio_flash_alias, OBJECT(s), name,
>> + &s->mmio_flash, 0, s->ctrl->flash_window_size);
>> +sysbus_init_mmio(sbd, &s->mmio_flash_alias);
>>  
>>  s->flashes = g_new0(AspeedSMCFlash, s->ctrl->max_peripherals);




Re: [PATCH v10 3/7] vt82c686: Introduce abstract TYPE_VIA_ISA and base vt82c686b_isa on it

2021-03-17 Thread BALATON Zoltan

On Wed, 17 Mar 2021, Philippe Mathieu-Daudé wrote:

On 3/17/21 2:17 AM, BALATON Zoltan wrote:

To allow reusing ISA bridge emulation for vt8231_isa move the device
state of vt82c686b_isa emulation in an abstract via_isa class. This
change breaks migration back compatibility but this is not an issue
for Fuloong2E machine which is not versioned or migration supported.

Signed-off-by: BALATON Zoltan 
---
 hw/isa/vt82c686.c| 70 ++--
 include/hw/pci/pci_ids.h |  2 +-
 2 files changed, 40 insertions(+), 32 deletions(-)


Now than "hw/usb: Extract VT82C686 UHCI PCI function into a new unit"
is merged as commit 6f2bcd5fc84, this is acceptable IMHO, so:
Reviewed-by: Philippe Mathieu-Daudé 


Still don't see what does the USB function do with this that does not have 
any reference to USB but thanks. Will you send a pull requests with the 
series?


Regards,
BALATON Zoltan

Re: [PATCH 2/5] hw/arm/aspeed: Do not sysbus-map mmio flash region directly, use alias

2021-03-17 Thread Cédric Le Goater
On 3/17/21 8:00 PM, Philippe Mathieu-Daudé wrote:
> On 3/17/21 7:30 PM, Cédric Le Goater wrote:
>> On 3/12/21 7:28 PM, Philippe Mathieu-Daudé wrote:
>>> The flash mmio region is exposed as an AddressSpace.
>>> AddressSpaces must not be sysbus-mapped, therefore map
>>> the region using an alias.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>
>> That does the trick but you need an extra change in the model. 
>>
>> The fixes are in my aspeed-6.0 branch on GH and they survive the last
>> patch of your series :
>>
>>   [PATCH 5/5] memory: Make sure root MR won't be added as subregion
> 
> I wondered about changing DMA_FLASH_ADDR() wasn't sure the tests
> would use the flash.

The acceptance tests (not merged yet) download firmware images
in which u-boot does DMA accesses to calibrate the reads on the
flash device. 

C.
  
> 
>> I will upstream for 6.1.
> 
> Thanks!
> 
> Phil.
> 




[PATCH 1/2] plugins: Update qemu-plugins.symbols to match qemu-plugins.h

2021-03-17 Thread Yonggang Luo
Reorder the function symbols that consistence with qemu-plugins.h

Signed-off-by: Yonggang Luo 
---
 plugins/qemu-plugins.symbols | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/plugins/qemu-plugins.symbols b/plugins/qemu-plugins.symbols
index 4bdb381f48..a0ac1df62a 100644
--- a/plugins/qemu-plugins.symbols
+++ b/plugins/qemu-plugins.symbols
@@ -5,35 +5,34 @@
   qemu_plugin_register_vcpu_exit_cb;
   qemu_plugin_register_vcpu_idle_cb;
   qemu_plugin_register_vcpu_resume_cb;
-  qemu_plugin_register_vcpu_insn_exec_cb;
-  qemu_plugin_register_vcpu_insn_exec_inline;
-  qemu_plugin_register_vcpu_mem_cb;
-  qemu_plugin_register_vcpu_mem_haddr_cb;
-  qemu_plugin_register_vcpu_mem_inline;
-  qemu_plugin_ram_addr_from_host;
   qemu_plugin_register_vcpu_tb_trans_cb;
   qemu_plugin_register_vcpu_tb_exec_cb;
   qemu_plugin_register_vcpu_tb_exec_inline;
-  qemu_plugin_register_flush_cb;
-  qemu_plugin_register_vcpu_syscall_cb;
-  qemu_plugin_register_vcpu_syscall_ret_cb;
-  qemu_plugin_register_atexit_cb;
+  qemu_plugin_register_vcpu_insn_exec_cb;
+  qemu_plugin_register_vcpu_insn_exec_inline;
   qemu_plugin_tb_n_insns;
-  qemu_plugin_tb_get_insn;
   qemu_plugin_tb_vaddr;
+  qemu_plugin_tb_get_insn;
   qemu_plugin_insn_data;
   qemu_plugin_insn_size;
   qemu_plugin_insn_vaddr;
   qemu_plugin_insn_haddr;
-  qemu_plugin_insn_disas;
   qemu_plugin_mem_size_shift;
   qemu_plugin_mem_is_sign_extended;
   qemu_plugin_mem_is_big_endian;
   qemu_plugin_mem_is_store;
   qemu_plugin_get_hwaddr;
   qemu_plugin_hwaddr_is_io;
-  qemu_plugin_hwaddr_to_raddr;
+  qemu_plugin_hwaddr_phys_addr;
+  qemu_plugin_hwaddr_device_name;
+  qemu_plugin_register_vcpu_mem_cb;
+  qemu_plugin_register_vcpu_mem_inline;
+  qemu_plugin_register_vcpu_syscall_cb;
+  qemu_plugin_register_vcpu_syscall_ret_cb;
+  qemu_plugin_insn_disas;
   qemu_plugin_vcpu_for_each;
+  qemu_plugin_register_flush_cb;
+  qemu_plugin_register_atexit_cb;
   qemu_plugin_n_vcpus;
   qemu_plugin_n_max_vcpus;
   qemu_plugin_outs;
-- 
2.29.2.windows.3




Re: [PULL 00/13] misc patches removing deprecated features

2021-03-17 Thread Peter Maydell
On Tue, 16 Mar 2021 at 16:55, Daniel P. Berrangé  wrote:
>
> The following changes since commit 6e31b3a5c34c6e5be7ef60773e607f189eaa15f3:
>
>   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into 
> staging (2021-03-16 10:53:47 +)
>
> are available in the Git repository at:
>
>   https://gitlab.com/berrange/qemu tags/dep-many-pull-request
>
> for you to fetch changes up to 13bf1a48d1671e26ca2fa13817d388fbdc4215ff:
>
>   block: remove support for using "file" driver with block/char devices 
> (2021-03-16 16:33:52 +)
>
> 
> Remove many old deprecated features
>
> The following features have been deprecated for well over the 2
> release cycle we promise
>
>   ``-drive file=json:{...{'driver':'file'}}`` (since 3.0)
>   ``-vnc acl`` (since 4.0.0)
>   ``-mon ...,control=readline,pretty=on|off`` (since 4.1)
>   ``migrate_set_downtime`` and ``migrate_set_speed`` (since 2.8.0)
>   ``query-named-block-nodes`` result ``encryption_key_missing`` (since 2.10.0)
>   ``query-block`` result ``inserted.encryption_key_missing`` (since 2.10.0)
>   ``migrate-set-cache-size`` and ``query-migrate-cache-size`` (since 2.11.0)
>   ``query-named-block-nodes`` and ``query-block`` result 
> dirty-bitmaps[i].status (since 4.0)
>   ``query-cpus`` (since 2.12.0)
>   ``query-cpus-fast`` ``arch`` output member (since 3.0.0)
>   ``query-events`` (since 4.0)
>   chardev client socket with ``wait`` option (since 4.0)
>   ``acl_show``, ``acl_reset``, ``acl_policy``, ``acl_add``, ``acl_remove`` 
> (since 4.0.0)
>   ``ide-drive`` (since 4.2)
>   ``scsi-disk`` (since 4.2)

Merge conflicts in the docs: could you fix up and resend,
please? They're probably easy to fix, but I have a dozen
pullreqs to process right now, so I am not spending any time
on fixing conflicts...

thanks
-- PMM



Re: [PULL 0/1] 9p queue 2021-03-16

2021-03-17 Thread Peter Maydell
On Tue, 16 Mar 2021 at 11:00, Christian Schoenebeck
 wrote:
>
> The following changes since commit 2615a5e433aeb812c300d3a48e1a88e1303e2339:
>
>   Merge remote-tracking branch 
> 'remotes/stefanha-gitlab/tags/block-pull-request' into staging (2021-03-15 
> 19:23:00 +)
>
> are available in the Git repository at:
>
>   https://github.com/cschoenebeck/qemu.git tags/pull-9p-20210316
>
> for you to fetch changes up to e4fd889f51094a8e76274ca1e9e0ed70375166f0:
>
>   hw/9pfs/9p-synth: Replaced qemu_mutex_lock with QEMU_LOCK_GUARD (2021-03-16 
> 11:41:49 +0100)
>
> 
> 9pfs: code cleanup
>
> * Use lock-guard design pattern instead of manual lock/unlock.
>
> 
> Mahmoud Mandour (1):
>   hw/9pfs/9p-synth: Replaced qemu_mutex_lock with QEMU_LOCK_GUARD
>
>  hw/9pfs/9p-synth.c | 12 

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/6.0
for any user-visible changes.

-- PMM



Re: [PATCH v1 2/5] target/riscv: Use the RiscVException enum for CSR predicates

2021-03-17 Thread Richard Henderson

On 3/17/21 11:39 AM, Alistair Francis wrote:

@@ -1312,8 +1320,8 @@ int riscv_csrrw(CPURISCVState *env, int csrno, 
target_ulong *ret_value,
  return -RISCV_EXCP_ILLEGAL_INST;
  }
  ret = csr_ops[csrno].predicate(env, csrno);
-if (ret < 0) {
-return ret;
+if (ret > 0) {
+return -ret;
  }


I think you want

  if (ret != RISCV_EXCP_NONE) {
 return -ret;
  }

here.  But of course this outer interface is still confused until patches 4+5. 
 So perhaps it doesn't matter.



r~



[PATCH] docs/devel/testing.rst: Fix referencies to unit tests

2021-03-17 Thread Wainer dos Santos Moschetta
With the recent move of the unit tests to tests/unit directory some
instructions under the "Unit tests" section became imprecise, which
are fixed by this change.

Related-to: da668aa15b99 (tests: Move unit tests into a separate directory)
Signed-off-by: Wainer dos Santos Moschetta 
---
 docs/devel/testing.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 1434a50cc4..1da4c4e4c4 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -34,17 +34,17 @@ If you are writing new code in QEMU, consider adding a unit 
test, especially
 for utility modules that are relatively stateless or have few dependencies. To
 add a new unit test:
 
-1. Create a new source file. For example, ``tests/foo-test.c``.
+1. Create a new source file. For example, ``tests/unit/foo-test.c``.
 
 2. Write the test. Normally you would include the header file which exports
the module API, then verify the interface behaves as expected from your
test. The test code should be organized with the glib testing framework.
Copying and modifying an existing test is usually a good idea.
 
-3. Add the test to ``tests/meson.build``. The unit tests are listed in a
+3. Add the test to ``tests/unit/meson.build``. The unit tests are listed in a
dictionary called ``tests``.  The values are any additional sources and
dependencies to be linked with the test.  For a simple test whose source
-   is in ``tests/foo-test.c``, it is enough to add an entry like::
+   is in ``tests/unit/foo-test.c``, it is enough to add an entry like::
 
  {
...
-- 
2.29.2




Re: [RFC PATCH v2 4/5] Add migration support for KVM guest with MTE

2021-03-17 Thread Dr. David Alan Gilbert
* Haibo Xu (haibo...@linaro.org) wrote:
> To make it easier to keep the page tags sync with
> the page data, tags for one page are appended to
> the data during ram save iteration.
> 
> This patch only add the pre-copy migration support.
> Post-copy and compress as well as zero page saving
> are not supported yet.
> 
> Signed-off-by: Haibo Xu 

My guess is that this doesn't work with a lot of other options; e.g.
postcopy and probably compression and a bunch of other things.
Postcopy I can see you'll need some interesting kernel changes for -
you'd need to be able to atomically place a  page with it's tag data.

You probably need to add stuff to migrate_caps_check  to disable
features that you don't support.

> ---
>  include/hw/arm/virt.h|  2 +
>  include/migration/misc.h |  1 +
>  migration/ram.c  | 86 +++-
>  3 files changed, 88 insertions(+), 1 deletion(-)
> 
> diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> index 921416f918..8b28cde8bf 100644
> --- a/include/hw/arm/virt.h
> +++ b/include/hw/arm/virt.h
> @@ -166,6 +166,8 @@ struct VirtMachineState {
>  PCIBus *bus;
>  char *oem_id;
>  char *oem_table_id;
> +/* migrate memory tags */
> +NotifierWithReturn precopy_notifier;
>  };
>  
>  #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM)
> diff --git a/include/migration/misc.h b/include/migration/misc.h
> index bccc1b6b44..005133f471 100644
> --- a/include/migration/misc.h
> +++ b/include/migration/misc.h
> @@ -38,6 +38,7 @@ void precopy_add_notifier(NotifierWithReturn *n);
>  void precopy_remove_notifier(NotifierWithReturn *n);
>  int precopy_notify(PrecopyNotifyReason reason, Error **errp);
>  void precopy_enable_free_page_optimization(void);
> +void precopy_enable_metadata_migration(void);
>  
>  void ram_mig_init(void);
>  void qemu_guest_free_page_hint(void *addr, size_t len);
> diff --git a/migration/ram.c b/migration/ram.c
> index 72143da0ac..e67b798c3b 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -53,10 +53,12 @@
>  #include "block.h"
>  #include "sysemu/sysemu.h"
>  #include "sysemu/cpu-throttle.h"
> +#include "sysemu/kvm.h"
>  #include "savevm.h"
>  #include "qemu/iov.h"
>  #include "multifd.h"
>  #include "sysemu/runstate.h"
> +#include "kvm_arm.h"
>  
>  #if defined(__linux__)
>  #include "qemu/userfaultfd.h"
> @@ -80,6 +82,9 @@
>  #define RAM_SAVE_FLAG_XBZRLE   0x40
>  /* 0x80 is reserved in migration.h start with 0x100 next */
>  #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
> +#define RAM_SAVE_FLAG_MTE  0x200

I think that's using the last free bit in the flags field, which is a
bit painful.

> +#define MTE_GRANULE_SIZE   (16)
>  
>  static inline bool is_zero_range(uint8_t *p, uint64_t size)
>  {
> @@ -317,6 +322,8 @@ struct RAMState {
>  bool ram_bulk_stage;
>  /* The free page optimization is enabled */
>  bool fpo_enabled;
> +/* The RAM meta data(e.t memory tag) is enabled */
> +bool metadata_enabled;
>  /* How many times we have dirty too many pages */
>  int dirty_rate_high_cnt;
>  /* these variables are used for bitmap sync */
> @@ -394,6 +401,15 @@ void precopy_enable_free_page_optimization(void)
>  ram_state->fpo_enabled = true;
>  }
>  
> +void precopy_enable_metadata_migration(void)
> +{
> +if (!ram_state) {
> +return;
> +}
> +
> +ram_state->metadata_enabled = true;
> +}
> +
>  uint64_t ram_bytes_remaining(void)
>  {
>  return ram_state ? (ram_state->migration_dirty_pages * TARGET_PAGE_SIZE) 
> :
> @@ -1134,6 +1150,61 @@ static bool control_save_page(RAMState *rs, RAMBlock 
> *block, ram_addr_t offset,
>  return true;
>  }
>  
> +static int save_normal_page_mte_tags(QEMUFile *f, uint8_t *addr)
> +{
> +uint8_t *tag_buf = NULL;
> +uint64_t ipa;
> +int size = TARGET_PAGE_SIZE / MTE_GRANULE_SIZE;

This function needs to be mostly somewhere aarch specific; or somehow
made more generic.
We shouldn't have RAM_SAVE_FLAG_MTE as well - we should be something
like RAM_SAVE_FLAG_ARCH_METADATA and that way other architectures with
something else glued onto pages can do something similar.
Try and keep migration/ architecture independent.

> +if (kvm_physical_memory_addr_from_host(kvm_state, addr, &ipa)) {
> +/* Buffer for the page tags(one byte per tag) */
> +tag_buf = g_try_malloc0(size);

It feels like you want to allocate tag_buf in setup and free it at the
end rather than doing this in every page.

> +if (!tag_buf) {
> +error_report("%s: Error allocating MTE tag_buf", __func__);
> +return 0;
> +}
> +
> +if (kvm_arm_mte_get_tags(ipa, TARGET_PAGE_SIZE, tag_buf) < 0) {
> +error_report("%s: Can't get MTE tags from guest", __func__);

For any error like this you probably want to say the addresses to make
it easier to debug when it fails.

> +g_free(tag_buf);
> +return 0;
> +}
> +
> + 

of AVR target page size

2021-03-17 Thread Dr. David Alan Gilbert
Hi Michael,
  I noticed your AVR code defines:

  #define TARGET_PAGE_BITS 8

and has an explanation of why.

Note however that's not going to work with the current live
migration/snapshotting code, since you're a couple of bits smaller
than the smallest page size we had so far, and for many years
the RAM migration code has stolen the bottom few bits of the address
as a flag field, and has already used 0x100 up; see migration/ram.c
RAM_SAVE_FLAG_*- and it's actually tricky to change it, because if
you change it then it'll break migration compatibility with existing
qemu's.

Hmm.

Dave

-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Serious doubts about Gitlab CI

2021-03-17 Thread Philippe Mathieu-Daudé
Hi,

For some (unclear) reason I got my free tier Gitlab account renewed and
lost the privilege for users opening account before the quota limit.

I pushed a single branch to my namespace repo to trigger a pipeline.
1h later I was surprised to see the pipeline was stuck, having completed
99 jobs of 119. Looking closer there is a red comment on top of the
pipeline:

 philmd has exceeded its pipeline minutes quota. Unless you buy
 additional pipeline minutes, no new jobs or pipelines in its projects
 will run. [Buy more Pipelines minutes]

So I exhausted my 400 monthly minutes credit.

>From this FAQ:
https://about.gitlab.com/pricing/faq-consumption-cicd/#managing-your-cicd-minutes-usage

Q. What happens if I hit the CI/CD Minutes allotted limit and forget to
purchase additional CI/CD Minutes?

A. You will not be able to run new jobs until you purchase additional
CI/CD Minutes, or until the next month when you receive your monthly
allotted CI/CD Minutes.

Q. Will I be notified before I hit my limit on CI/CD Minutes?

A. You will receive notification banners in-app when your group has less
than 30%, 5% or exceeded your total allotted CI/CD minutes.

I indeed received 3 warnings in 7 minutes.

Now I'm having serious doubts about Gitlab usefulness for the QEMU
community...

Some screenshots FWIW:

https://pasteboard.co/JT51wGR.png
https://pasteboard.co/JT51Rqq.png
https://pasteboard.co/JT52fNL.png

Regards,

Phil.



Re: [PATCH 06/38] target/riscv: SIMD 16-bit Shift Instructions

2021-03-17 Thread Alistair Francis
On Tue, Mar 16, 2021 at 10:31 PM LIU Zhiwei  wrote:
>
>
>
> On 2021/3/17 3:54, Alistair Francis wrote:
> > On Mon, Mar 15, 2021 at 10:40 PM LIU Zhiwei  wrote:
> >>
> >>
> >> On 2021/3/16 5:25, Alistair Francis wrote:
> >>> On Fri, Feb 12, 2021 at 10:16 AM LIU Zhiwei  wrote:
>  Signed-off-by: LIU Zhiwei 
>  ---
> target/riscv/helper.h   |   9 ++
> target/riscv/insn32.decode  |  17 
> target/riscv/insn_trans/trans_rvp.c.inc | 115 
> target/riscv/packed_helper.c| 104 +
> 4 files changed, 245 insertions(+)
> 
>  diff --git a/target/riscv/helper.h b/target/riscv/helper.h
>  index a69a6b4e84..20bf400ac2 100644
>  --- a/target/riscv/helper.h
>  +++ b/target/riscv/helper.h
>  @@ -1184,3 +1184,12 @@ DEF_HELPER_3(rsub8, tl, env, tl, tl)
> DEF_HELPER_3(ursub8, tl, env, tl, tl)
> DEF_HELPER_3(ksub8, tl, env, tl, tl)
> DEF_HELPER_3(uksub8, tl, env, tl, tl)
>  +
>  +DEF_HELPER_3(sra16, tl, env, tl, tl)
>  +DEF_HELPER_3(sra16_u, tl, env, tl, tl)
>  +DEF_HELPER_3(srl16, tl, env, tl, tl)
>  +DEF_HELPER_3(srl16_u, tl, env, tl, tl)
>  +DEF_HELPER_3(sll16, tl, env, tl, tl)
>  +DEF_HELPER_3(ksll16, tl, env, tl, tl)
>  +DEF_HELPER_3(kslra16, tl, env, tl, tl)
>  +DEF_HELPER_3(kslra16_u, tl, env, tl, tl)
>  diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
>  index 358dd1fa10..6f053bfeb7 100644
>  --- a/target/riscv/insn32.decode
>  +++ b/target/riscv/insn32.decode
>  @@ -23,6 +23,7 @@
> %rd7:5
> 
> %sh1020:10
>  +%sh420:4
> %csr20:12
> %rm 12:3
> %nf 29:3 !function=ex_plus_1
>  @@ -59,6 +60,7 @@
> @j     . ... &j  imm=%imm_j   
> %rd
> 
> @sh  ..  .. .  ... . ... &shift  shamt=%sh10  
>  %rs1 %rd
>  +@sh4 ..  .. .  ... . ... &shift  shamt=%sh4 
>   %rs1 %rd
> @csr    .  ... . ...   %csr   
>    %rs1 %rd
> 
> @atom_ld . aq:1 rl:1 .  . ... &atomic rs2=0   
>    %rs1 %rd
>  @@ -635,3 +637,18 @@ rsub8  101  . . 000 . 111 @r
> ursub8 0010101  . . 000 . 111 @r
> ksub8  0001101  . . 000 . 111 @r
> uksub8 0011101  . . 000 . 111 @r
>  +
>  +sra16  0101000  . . 000 . 111 @r
>  +sra16_u011  . . 000 . 111 @r
>  +srai16 0111000  0 . 000 . 111 @sh4
>  +srai16_u   0111000  1 . 000 . 111 @sh4
>  +srl16  0101001  . . 000 . 111 @r
>  +srl16_u0110001  . . 000 . 111 @r
>  +srli16 0111001  0 . 000 . 111 @sh4
>  +srli16_u   0111001  1 . 000 . 111 @sh4
>  +sll16  0101010  . . 000 . 111 @r
>  +slli16 0111010  0 . 000 . 111 @sh4
>  +ksll16 0110010  . . 000 . 111 @r
>  +kslli160111010  1 . 000 . 111 @sh4
>  +kslra160101011  . . 000 . 111 @r
>  +kslra16_u  0110011  . . 000 . 111 @r
>  diff --git a/target/riscv/insn_trans/trans_rvp.c.inc 
>  b/target/riscv/insn_trans/trans_rvp.c.inc
>  index 109f560ec9..848edab7e5 100644
>  --- a/target/riscv/insn_trans/trans_rvp.c.inc
>  +++ b/target/riscv/insn_trans/trans_rvp.c.inc
>  @@ -238,3 +238,118 @@ GEN_RVP_R_OOL(rsub8);
> GEN_RVP_R_OOL(ursub8);
> GEN_RVP_R_OOL(ksub8);
> GEN_RVP_R_OOL(uksub8);
>  +
>  +/* 16-bit Shift Instructions */
>  +static bool rvp_shift_ool(DisasContext *ctx, arg_r *a,
>  +  gen_helper_rvp_r *fn, target_ulong mask)
>  +{
>  +TCGv src1, src2, dst;
>  +
>  +src1 = tcg_temp_new();
>  +src2 = tcg_temp_new();
>  +dst = tcg_temp_new();
>  +
>  +gen_get_gpr(src1, a->rs1);
>  +gen_get_gpr(src2, a->rs2);
>  +tcg_gen_andi_tl(src2, src2, mask);
>  +
>  +fn(dst, cpu_env, src1, src2);
>  +gen_set_gpr(a->rd, dst);
>  +
>  +tcg_temp_free(src1);
>  +tcg_temp_free(src2);
>  +tcg_temp_free(dst);
>  +return true;
>  +}
>  +
>  +typedef void GenGvecShift(unsigned, uint32_t, uint32_t, TCGv_i32,
>  +  uint32_t, uint32_t);
>  +static inline bool
>  +rvp_shift(DisasContext *ctx, arg_r *a, uint8_t vece,
>  +  GenGvecShift *f64, gen_helper_rvp_r *fn,
>  +  uint8_t mask)
>  +{
>  +if (!has_ext(ctx, RVP)) {
> 

Re: [PATCH] yank: Avoid linking into executables that don't want it

2021-03-17 Thread Lukas Straub
On Tue, 16 Mar 2021 14:59:07 +0100
Markus Armbruster  wrote:

> util/yank.c and stubs/yank.c are both in libqemuutil.a, even though
> their external symbols conflict.  The linker happens to pick the
> former.  This links a bunch of unneeded code into the executables that
> actually want the latter: qemu-io, qemu-img, qemu-nbd, and several
> tests.  Amazingly, none of them fails to link.
> 
> To fix this, the non-stub yank.c from sourceset util_ss to sourceset
> qmp_ss.  This requires moving it from util/ to monitor/.
> 
> Suggested-by: Paolo Bonzini 
> Signed-off-by: Markus Armbruster 
> ---
>  {util => monitor}/yank.c | 0
>  MAINTAINERS  | 2 +-
>  monitor/meson.build  | 1 +
>  util/meson.build | 1 -
>  4 files changed, 2 insertions(+), 2 deletions(-)
>  rename {util => monitor}/yank.c (100%)
> 
> diff --git a/util/yank.c b/monitor/yank.c
> similarity index 100%
> rename from util/yank.c
> rename to monitor/yank.c
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5ca3c9f851..d3174c0bb0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2799,7 +2799,7 @@ F: tests/unit/test-uuid.c
>  Yank feature
>  M: Lukas Straub 
>  S: Odd fixes
> -F: util/yank.c
> +F: monitor/yank.c
>  F: stubs/yank.c
>  F: include/qemu/yank.h
>  F: qapi/yank.json
> diff --git a/monitor/meson.build b/monitor/meson.build
> index 6d00985ace..1ce5909c88 100644
> --- a/monitor/meson.build
> +++ b/monitor/meson.build
> @@ -1,4 +1,5 @@
>  qmp_ss.add(files('monitor.c', 'qmp.c', 'qmp-cmds-control.c'))
> +qmp_ss.add(files('yank.c'))
>  
>  softmmu_ss.add(files(
>'hmp-cmds.c',
> diff --git a/util/meson.build b/util/meson.build
> index 984fba965f..fa0298adab 100644
> --- a/util/meson.build
> +++ b/util/meson.build
> @@ -51,7 +51,6 @@ endif
>  if have_system
>util_ss.add(files('crc-ccitt.c'))
>util_ss.add(when: 'CONFIG_GIO', if_true: [files('dbus.c'), gio])
> -  util_ss.add(files('yank.c'))
>util_ss.add(when: 'CONFIG_LINUX', if_true: files('userfaultfd.c'))
>  endif
>  

Looks good to me, applied and fixed commit message.

Regards,
Lukas Straub

-- 



pgpiPpOyxuMXj.pgp
Description: OpenPGP digital signature


Re: [PULL 00/10] VFIO updates for QEMU 6.0

2021-03-17 Thread Peter Maydell
On Tue, 16 Mar 2021 at 17:21, Alex Williamson
 wrote:
>
> This is a resend of the same sent on 2021-03-11 where 00/10 and 02/10
> were eaten by the mail server.  Rebased to current staging and re-tagged.
>
> The following changes since commit 5b7f5586d182b0cafb1f8d558992a14763e2953e:
>
>   Merge remote-tracking branch 
> 'remotes/kraxel/tags/usb-20210315-pull-request' into staging (2021-03-16 
> 13:17:54 +)
>
> are available in the Git repository at:
>
>   git://github.com/awilliam/qemu-vfio.git tags/vfio-update-20210316.0
>
> for you to fetch changes up to 758b96b61d5cbc19204f340012d5a325f0a2105b:
>
>   vfio/migrate: Move switch of dirty tracking into vfio_memory_listener 
> (2021-03-16 10:06:44 -0600)
>
> 
> VFIO update 2021-03-16
>
>  * Fix "listerner" typo (Zenghui Yu)
>
>  * Inclusive language and MAINTAINERS update (Philippe Mathieu-Daudé)
>
>  * vIOMMU unmap notifier fixes (Eric Auger)
>
>  * Migration fixes and optimizations (Shenming Lu)
>
>  * Use host page size for dirty bitmap (Kunkun Jiang)
>
>  * Use log_global_start/stop to switch dirty tracking (Keqian Zhu)
>


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/6.0
for any user-visible changes.

-- PMM



Re: [PULL v3 00/42] Block layer patches and object-add QAPIfication

2021-03-17 Thread Peter Maydell
On Tue, 16 Mar 2021 at 18:12, Kevin Wolf  wrote:
>
> The following changes since commit 6e31b3a5c34c6e5be7ef60773e607f189eaa15f3:
>
>   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into 
> staging (2021-03-16 10:53:47 +)
>
> are available in the Git repository at:
>
>   git://repo.or.cz/qemu/kevin.git tags/for-upstream
>
> for you to fetch changes up to f5dda4c2186975ed75ec07b58bc6031e4867bb45:
>
>   vl: allow passing JSON to -object (2021-03-16 18:52:10 +0100)
>
> 
> Block layer patches and object-add QAPIfication
>
> - QAPIfy object-add and --object
> - stream: Fail gracefully if permission is denied
> - storage-daemon: Fix crash on quit when job is still running
> - curl: Fix use after free
> - char: Deprecate backend aliases, fix QMP query-chardev-backends
> - Fix image creation option defaults that exist in both the format and
>   the protocol layer (e.g. 'cluster_size' in qcow2 and rbd; the qcow2
>   default was incorrectly applied to the rbd layer)
>
> 


CONFLICT (content): Merge conflict in docs/system/deprecated.rst


Please fix up and resend.

thanks
-- PMM



Re: [PULL v2 0/6] QOM and fdc patches patches for 2021-03-16

2021-03-17 Thread Peter Maydell
On Tue, 16 Mar 2021 at 19:23, Markus Armbruster  wrote:
>
> The following changes since commit 6e31b3a5c34c6e5be7ef60773e607f189eaa15f3:
>
>   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into 
> staging (2021-03-16 10:53:47 +)
>
> are available in the Git repository at:
>
>   git://repo.or.cz/qemu/armbru.git tags/pull-qom-fdc-2021-03-16
>
> for you to fetch changes up to 901c36b68c327c5a4e4b3701cd991dd927ac07ae:
>
>   memory: Drop "qemu:" prefix from QOM memory region type names (2021-03-16 
> 15:52:26 +0100)
>
> 
> QOM and fdc patches patches for 2021-03-16
>

CONFLICT (content): Merge conflict in docs/system/removed-features.rst

Please fix up and resend.

thanks
-- PMM



Re: [PATCH 1/2] Fix the segment fault when calling yank_register_instance

2021-03-17 Thread Lukas Straub
On Mon, 15 Mar 2021 18:06:35 +0100
Li Zhang  wrote:

> From: Li Zhang 
> 
> When executing the QMP commands "chardev-change" to change the
> backend device to socket, it will cause a segment fault because
> it assumes chr->label as non-NULL in function yank_register_instance.
> The function qmp_chardev_change calls chardev_new, which label
> is NULL when creating a new chardev. The label will be passed to
> yank_register_instance which causes a segment fault. The callchain
> is as the following:
> chardev_new ->
> qemu_char_open ->
> cc->open ->
> qmp_chardev_open_socket ->
> yank_register_instance

Oh, I didn't consider the chardev-change case. I'll look into it.

Regards,
Lukas Straub

-- 



pgpTi79S8Go4I.pgp
Description: OpenPGP digital signature


Re: [PATCH V2 6/7] net/colo-compare: Add passthrough list to CompareState

2021-03-17 Thread Lukas Straub
On Wed,  3 Mar 2021 12:15:38 +0800
Zhang Chen  wrote:

> From: Zhang Chen 
> 
> Add passthrough list for each CompareState.
> 
> Signed-off-by: Zhang Chen 
> ---
>  net/colo-compare.c | 25 +
>  net/colo-compare.h | 10 ++
>  2 files changed, 35 insertions(+)
> 
> diff --git a/net/colo-compare.c b/net/colo-compare.c
> index a803f8b888..80cea32c20 100644
> --- a/net/colo-compare.c
> +++ b/net/colo-compare.c
> @@ -141,6 +141,7 @@ static int packet_enqueue(CompareState *s, int mode, 
> Connection **con)
>  ConnectionKey key;
>  Packet *pkt = NULL;
>  Connection *conn;
> +PassthroughEntry *bypass, *next;
>  int ret;
>  
>  if (mode == PRIMARY_IN) {
> @@ -160,6 +161,29 @@ static int packet_enqueue(CompareState *s, int mode, 
> Connection **con)
>  }
>  fill_connection_key(pkt, &key);
>  
> +/* Check COLO passthrough connenction */
> +if (!QLIST_EMPTY(&s->passthroughlist)) {
> +QLIST_FOREACH_SAFE(bypass, &s->passthroughlist, node, next) {
> +if (((key.ip_proto == IPPROTO_TCP) && (bypass->l4_protocol == 
> 0)) ||
> +((key.ip_proto == IPPROTO_UDP) && (bypass->l4_protocol == 
> 1))) {
> +if (bypass->src_port == 0 || bypass->src_port == 
> key.dst_port) {
> +if (bypass->src_ip.s_addr == 0 ||
> +bypass->src_ip.s_addr == key.src.s_addr) {
> +if (bypass->dst_port == 0 ||
> +bypass->dst_port == key.src_port) {
> +if (bypass->dst_ip.s_addr == 0 ||
> +bypass->dst_ip.s_addr == key.dst.s_addr) {
> +packet_destroy(pkt, NULL);
> +pkt = NULL;
> +return -1;
> +}
> +}
> +}
> +}
> +}
> +}
> +}
> +

Hi,
Access to s->passthroughlist still needs to be protected by a lock.

Regards,
Lukas Straub

>  conn = connection_get(s->connection_track_table,
>&key,
>&s->conn_list);
> @@ -1224,6 +1248,7 @@ static void colo_compare_complete(UserCreatable *uc, 
> Error **errp)
>  }
>  
>  g_queue_init(&s->conn_list);
> +QLIST_INIT(&s->passthroughlist);
>  
>  s->connection_track_table = g_hash_table_new_full(connection_key_hash,
>connection_key_equal,
> diff --git a/net/colo-compare.h b/net/colo-compare.h
> index 2a9dcac0a7..31644f145b 100644
> --- a/net/colo-compare.h
> +++ b/net/colo-compare.h
> @@ -54,6 +54,15 @@ typedef struct SendEntry {
>  uint8_t *buf;
>  } SendEntry;
>  
> +typedef struct PassthroughEntry {
> +int l4_protocol;
> +int src_port;
> +int dst_port;
> +struct in_addr src_ip;
> +struct in_addr dst_ip;
> +QLIST_ENTRY(PassthroughEntry) node;
> +} PassthroughEntry;
> +
>  /*
>   *  + CompareState ++
>   *  |   |
> @@ -110,6 +119,7 @@ struct CompareState {
>  
>  QEMUBH *event_bh;
>  enum colo_event event;
> +QLIST_HEAD(, PassthroughEntry) passthroughlist;
>  
>  QTAILQ_ENTRY(CompareState) next;
>  };



-- 



pgpNpiPRuTFaG.pgp
Description: OpenPGP digital signature


Re: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp packet

2021-03-17 Thread Lukas Straub
Hi,
This hasn't been merged yet.

Regards,
Lukas Straub

On Mon, 16 Nov 2020 07:32:22 +
"Zhang, Chen"  wrote:

> Queued this series to COLO tree.
> 
> Thanks
> Chen
> 
> > -Original Message-
> > From: Lukas Straub 
> > Sent: Sunday, November 15, 2020 7:19 PM
> > To: qemu-devel 
> > Cc: Zhang, Chen ; Li Zhijian
> > ; Jason Wang 
> > Subject: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp packet
> > 
> > Hello Everyone,
> > This fixes a memory leak for non-tcp packets and optimizes the removal from
> > the queue.
> > 
> > Lukas Straub (2):
> >   net/colo-compare.c: Fix memory leak for non-tcp packet
> >   net/colo-compare.c: Optimize removal of secondary packet
> > 
> >  net/colo-compare.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > --
> > 2.20.1  



-- 



pgpHHrjrElYMm.pgp
Description: OpenPGP digital signature


Re: Win10 always takes 100% cpu power even when idle

2021-03-17 Thread Reinoud Zandijk
Hi,

On Wed, Mar 17, 2021 at 05:05:39PM +, Daniel P. Berrangé wrote:
> Possibly you need some of the hyperv enlightenments enabled too. Though
> I can't recall the precise command line offhand, as I just rely on
> virt-install virt-manager to do the right thing for Windows guests.

HuperV support/emulation is only available under KVM and thus only under
Linux, so that is not going to help :-/

My question is more on what causes this? Say a 10% to 20% cpu usage loss due
to IPI's and interrupts not working as smooth as could be is not nice but
workable, a 200% constant cpu usage that makes it unresponsive and bog slow is
unworkable.

Is some interrupt never cleared correctly and constantly triggered? Is the
pauze/wait for interrupt not implemented correctly? Regardless of which
accelerator, basic TCG doesn't work either. And why don't the BSDs and Linux
as guests suffer from this?

How to trace this? Is there something I could trace that details this
behaviour?

With regards,
Reinoud



signature.asc
Description: PGP signature


Re: of AVR target page size

2021-03-17 Thread Michael Rolnik
Hi Dave.

What is the smallest supported page size?


On Wed, Mar 17, 2021 at 10:14 PM Dr. David Alan Gilbert 
wrote:

> Hi Michael,
>   I noticed your AVR code defines:
>
>   #define TARGET_PAGE_BITS 8
>
> and has an explanation of why.
>
> Note however that's not going to work with the current live
> migration/snapshotting code, since you're a couple of bits smaller
> than the smallest page size we had so far, and for many years
> the RAM migration code has stolen the bottom few bits of the address
> as a flag field, and has already used 0x100 up; see migration/ram.c
> RAM_SAVE_FLAG_*- and it's actually tricky to change it, because if
> you change it then it'll break migration compatibility with existing
> qemu's.
>
> Hmm.
>
> Dave
>
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
>

-- 
Best Regards,
Michael Rolnik


CXL 2.0 memory device design

2021-03-17 Thread Ben Widawsky
Phil, Igor, Markus

TL;DR: What to do about multiple capacities in a single device, and what to do
about interleave?

I've hacked together a basic CXL 2.0 implementation which exposes a CXL "Type 3"
memory device (CXL 2.0 Chapter 2.3). For what we were trying to do this was
sufficient. There are two main capabilities that CXL spec exposes which I've not
implemented that I'd like to start working toward and am realizing that I what I
have so far might not be able to carry forward to that next milestone.

Capability 1. A CXL memory device may have both a volatile, and a persistent
  capacity. https://bwidawsk.net/HDM_decoders.svg (lower right
  side). The current work only supports a single persistent
  capacity.
Capability 2. CXL topologies can be interleaved. Basic example:
  https://bwidawsk.net/HDM_decoders.svg (lower left side)

Memory regions are configured via a CXL spec defined HDM decoder. The HDM
decoder which is minimally implemented supports all the functionality mentioned
above (base, size, interleave, type, etc.). A CXL component may have up to 10
HDMs.

What I have today: https://bwidawsk.net/QEMU_objects.svg
There's a single memory backend device for each host bridge. That backend is
passed to any CXL component that is part of the hierarchy underneath that
hostbridge. In the case of a Type 3 device memory capacity a subregion is
created for that capacity from within the main backend. The device itself
implements the TYPE_MEMORY_DEVICE interface. This allows me to utilize the
existing memory region code to determine the next free address, and warn on
overlaps. It hopefully will help when I'm ready to support hotplug.

Where I've gotten stuck: A Memory Device expects only to have one region of
memory. Trying to add a second breaks pretty much everything.

I'm hoping to start the discussion about what the right way to emulate this in
QEMU. Ideally something upstreamable would be great. I think adding a secondary
(or more) capacity to a memory class device is doable, but probably not the
right approach.

For context, I've posted v3 previously. Here's a link to v4 which has some minor
changes as well as moving back to using subregions instead of aliases:
https://gitlab.com/bwidawsk/qemu/-/tree/cxl-2.0v4

Thanks.
Ben



[PATCH] acpi:piix4, vt82c686: reinitialize acpi PM device on reset

2021-03-17 Thread isaku . yamahata
From: Isaku Yamahata 

Commit 6be8cf56bc8b made sure that SCI is enabled in PM1.CNT
on reset in acpi_only mode by modifying acpi_pm1_cnt_reset() and
that worked for q35 as expected.

The function was introduced by commit
  eaba51c573a (acpi, acpi_piix, vt82c686: factor out PM1_CNT logic)
that forgot to actually call it at piix4 reset time and as result
SCI_EN wasn't set as was expected by 6be8cf56bc8b in acpi_only mode.

So Windows crashes when it notices that SCI_EN is not set and FADT is
not providing information about how to enable it anymore.
Reproducer:
   qemu-system-x86_64 -enable-kvm -M pc-i440fx-6.0,smm=off -cdrom 
any_windows_10x64.iso

Fix it by calling acpi_pm1_cnt_reset() at piix4 reset time.

Occasionally this patch adds reset acpi PM related registers on
piix4/vt582c686 reset time and de-assert sci.
piix4_pm_realize() initializes acpi pm tmr, evt, cnt and gpe.
via_pm_realize() initializes acpi pm tmr, evt and cnt.
reset them on device reset. pm_reset() in ich9.c correctly calls
corresponding reset functions.

Fixes: 6be8cf56bc8b (acpi/core: always set SCI_EN when SMM isn't supported)
Reported-by: Reinoud Zandijk 
Co-developed-by: Igor Mammedov 
Signed-off-by: Igor Mammedov 
Signed-off-by: Isaku Yamahata 
---
CC: imamm...@redhat.com
CC: isaku.yamah...@intel.com
CC: m...@redhat.com
CC: rein...@netbsd.org
CC: isaku.yamah...@gmail.com
CC: berra...@redhat.com
CC: pbonz...@redhat.com
CC: f4...@amsat.org
CC: aurel...@aurel32.net
---
 hw/acpi/piix4.c   | 7 +++
 hw/isa/vt82c686.c | 5 +
 2 files changed, 12 insertions(+)

diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 1efc0ded9f..a00525025b 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -325,6 +325,13 @@ static void piix4_pm_reset(DeviceState *dev)
 /* Mark SMM as already inited (until KVM supports SMM). */
 pci_conf[0x5B] = 0x02;
 }
+
+acpi_pm1_evt_reset(&s->ar);
+acpi_pm1_cnt_reset(&s->ar);
+acpi_pm_tmr_reset(&s->ar);
+acpi_gpe_reset(&s->ar);
+acpi_update_sci(&s->ar, s->irq);
+
 pm_io_space_update(s);
 acpi_pcihp_reset(&s->acpi_pci_hotplug, !s->use_acpi_root_pci_hotplug);
 }
diff --git a/hw/isa/vt82c686.c b/hw/isa/vt82c686.c
index 05d084f698..7bacad03e2 100644
--- a/hw/isa/vt82c686.c
+++ b/hw/isa/vt82c686.c
@@ -167,6 +167,11 @@ static void via_pm_reset(DeviceState *d)
 /* SMBus IO base */
 pci_set_long(s->dev.config + 0x90, 1);
 
+acpi_pm1_evt_reset(&s->ar);
+acpi_pm1_cnt_reset(&s->ar);
+acpi_pm_tmr_reset(&s->ar);
+pm_update_sci(s);
+
 pm_io_space_update(s);
 smb_io_space_update(s);
 }
-- 
2.25.1




Re: [PATCH] docs/devel/testing.rst: Fix referencies to unit tests

2021-03-17 Thread John Snow

typo in the commit summary; "references to"

On 3/17/21 3:48 PM, Wainer dos Santos Moschetta wrote:

With the recent move of the unit tests to tests/unit directory some
instructions under the "Unit tests" section became imprecise, which
are fixed by this change.

Related-to: da668aa15b99 (tests: Move unit tests into a separate directory)


You can probably just use "Fixes", even though nothing is technically 
broken to avoid introducing a new one-off tag type.



Signed-off-by: Wainer dos Santos Moschetta 
---
  docs/devel/testing.rst | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 1434a50cc4..1da4c4e4c4 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -34,17 +34,17 @@ If you are writing new code in QEMU, consider adding a unit 
test, especially
  for utility modules that are relatively stateless or have few dependencies. To
  add a new unit test:
  
-1. Create a new source file. For example, ``tests/foo-test.c``.

+1. Create a new source file. For example, ``tests/unit/foo-test.c``.
  
  2. Write the test. Normally you would include the header file which exports

 the module API, then verify the interface behaves as expected from your
 test. The test code should be organized with the glib testing framework.
 Copying and modifying an existing test is usually a good idea.
  
-3. Add the test to ``tests/meson.build``. The unit tests are listed in a

+3. Add the test to ``tests/unit/meson.build``. The unit tests are listed in a
 dictionary called ``tests``.  The values are any additional sources and
 dependencies to be linked with the test.  For a simple test whose source
-   is in ``tests/foo-test.c``, it is enough to add an entry like::
+   is in ``tests/unit/foo-test.c``, it is enough to add an entry like::
  
   {

 ...






Re: [PULL 0/1] qemu-openbios queue 20210316

2021-03-17 Thread Peter Maydell
On Tue, 16 Mar 2021 at 20:39, Mark Cave-Ayland
 wrote:
>
> The following changes since commit 6e31b3a5c34c6e5be7ef60773e607f189eaa15f3:
>
>   Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into 
> staging (2021-03-16 10:53:47 +)
>
> are available in the Git repository at:
>
>   git://github.com/mcayland/qemu.git tags/qemu-openbios-20210316
>
> for you to fetch changes up to ee2e67da8f882fcdef2c49fcc58e9962aa695f5a:
>
>   Update OpenBIOS images to 4a004110 built from submodule. (2021-03-16 
> 20:03:00 +)
>
> 
> qemu-openbios queue
>


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/6.0
for any user-visible changes.

-- PMM



Re: [RFC PATCH 32/42] docker: Add gentoo-mipsr5900el-cross image

2021-03-17 Thread Maciej W. Rozycki
On Wed, 17 Mar 2021, Philippe Mathieu-Daudé wrote:

> Maciej, I tried your suggestion as follow:
> 
> $ mipsel-linux-gnu-gcc --version
> mipsel-linux-gnu-gcc (Debian 8.3.0-2) 8.3.0
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> $ mipsel-linux-gnu-gcc -print-multi-lib
> .;
> n32;@mabi=n32
> 64;@mabi=64

 OK, so these are for the three ABIs Linux support, plain.  You'd have to 
bootstrap your own compiler and either reconfigure it at least for n32 
with a `-msoft-float' multilib, or build a non-multilib compiler for this 
ABI variant.  Either way including glibc which to the best of my knowledge 
does support soft-float MIPS configurations.

> soft-float is not listed, but:
> 
> $ touch a.c
> $ mipsel-linux-gnu-gcc -mabi=n32 -march=r5900 -msoft-float -c a.c
> $ file a.o
> a.o: ELF 32-bit LSB relocatable, MIPS, N32 MIPS-III version 1 (SYSV),
> not stripped
> $ readelf -h a.o
> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>   Class: ELF32
>   Data:  2's complement, little endian
>   Version:   1 (current)
>   OS/ABI:UNIX - System V
>   ABI Version:   0
>   Type:  REL (Relocatable file)
>   Machine:   MIPS R3000
>   Version:   0x1
>   Entry point address:   0x0
>   Start of program headers:  0 (bytes into file)
>   Start of section headers:  456 (bytes into file)
>   Flags: 0x20920026, pic, cpic, abi2, 5900,
> mips3
>   Size of this header:   52 (bytes)
>   Size of program headers:   0 (bytes)
>   Number of program headers: 0
>   Size of section headers:   40 (bytes)
>   Number of section headers: 13
>   Section header string table index: 12
> 
> So we can compile, but:

 Yes, all code models are always available for compilation (you can choose 
the default though).  We (ab)use this feature for instance to build the 
Linux kernel, which obviously uses the bare metal non-PIC model.

> $ mipsel-linux-gnu-gcc -mabi=n32 -march=r5900 -msoft-float -L
> /usr/lib/mipsel-linux-gnu tests/tcg/mips/test-r5900-dmult.c
> /usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
> /usr/lib/../lib32/Scrt1.o: relocations in generic ELF (EM: 3)
> /usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
> /usr/lib/../lib32/Scrt1.o: error adding symbols: file in wrong format
> collect2: error: ld returned 1 exit status

 Yes, the problem is in the missing runtime, and whatever GCC defaults to 
is not link-compatible.  The message from the linker indicates it couldn't 
have chosen a MIPS emulation at all even.

> $ mipsel-linux-gnu-readelf -h /usr/lib/mipsel-linux-gnu/Scrt1.o
> ELF Header:
>   Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>   Class: ELF32
>   Data:  2's complement, little endian
>   Version:   1 (current)
>   OS/ABI:UNIX - System V
>   ABI Version:   0
>   Type:  REL (Relocatable file)
>   Machine:   MIPS R3000
>   Version:   0x1
>   Entry point address:   0x0
>   Start of program headers:  0 (bytes into file)
>   Start of section headers:  908 (bytes into file)
>   Flags: 0x70001007, noreorder, pic, cpic,
> o32, mips32r2
>   Size of this header:   52 (bytes)
>   Size of program headers:   0 (bytes)
>   Number of program headers: 0
>   Size of section headers:   40 (bytes)
>   Number of section headers: 15
>   Section header string table index: 14

 That is a plain o32 ABI object.

> The multilib documentation is scarce :)

 Ask questions. :)

> Also I wondered if I could abuse the linker a bit, knowing the resulting
> binary would be crap due to ABI mismatch, and got:
> 
> $ mipsel-linux-gnu-gcc -march=r5900 -msoft-float -o test-r5900-dmult
> test-r5900-dmult.o
> collect2: fatal error: ld terminated with signal 11 [Segmentation
> fault], core dumped
> compilation terminated.
> /usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
> test-r5900-dmult.o: ABI is incompatible with that of the selected emulation
> /usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
> failed to merge target specific data of file test-r5900-dmult.o
> /usr/lib/gcc-cross/mipsel-linux-gnu/8/../../../../mipsel-linux-gnu/bin/ld:
> BFD (GNU Binutils for Debian) 2.31.1 assertion fail
> ../../bfd/elfxx-mips.c:3566

 This looks like a linker bug, it's not supposed to report

iotests failing on gitlab CI check-system-fedora job

2021-03-17 Thread Peter Maydell
The check-system-fedora job in the gitlab CI seems to have
started reliably failing on iotests 040 041 127 256 267:
 https://gitlab.com/qemu-project/qemu/-/jobs/1106977551

Could somebody have a look at what's happening, please?
(This is probably a regression that's got into master because
I stopped using "did gitlab CI pass" as a gate because gitlab
was running massively too slowly to be usable for that.)

thanks
-- PMM



Re: of AVR target page size

2021-03-17 Thread Peter Maydell
On Wed, 17 Mar 2021 at 20:17, Dr. David Alan Gilbert
 wrote:
>
> Hi Michael,
>   I noticed your AVR code defines:
>
>   #define TARGET_PAGE_BITS 8
>
> and has an explanation of why.
>
> Note however that's not going to work with the current live
> migration/snapshotting code, since you're a couple of bits smaller
> than the smallest page size we had so far, and for many years
> the RAM migration code has stolen the bottom few bits of the address
> as a flag field, and has already used 0x100 up; see migration/ram.c
> RAM_SAVE_FLAG_*- and it's actually tricky to change it, because if
> you change it then it'll break migration compatibility with existing
> qemu's.

If you want to use low bits as flags for other stuff, you
should have a compile time assert that you have the number
of bits you expect, or otherwise force a compile error.
Otherwise you'll end up with unpleasant surprises like this one...

I think that for the cpu-all.h uses of low bits we would
end up with a compile error for excessively small TARGET_PAGE_BITS
because we define the bits like this:
#define TLB_DISCARD_WRITE   (1 << (TARGET_PAGE_BITS_MIN - 6))
and I expect the compiler will complain if the RHS of the '<<'
is a negative constant. But I don't know if that's deliberate
or a happy accident :-)

thanks
-- PMM



Re: "make check" broken with everything but tools disabled

2021-03-17 Thread John Snow

On 3/16/21 9:28 AM, Markus Armbruster wrote:

Watch this:

 $ mkdir bld-tools
 $ cd bld-tools
 $ ../configure --disable-system --disable-user --enable-tools
 $ make check
 [...]
 make: *** No rule to make target 'tests/qemu-iotests/socket_scm_helper', 
needed by 'check-block'.  Stop.




One more thing to add a CI job to check, I suppose.

--js




Re: Microsoft and Intel NVDIMM ACPI _DSM interfaces status?

2021-03-17 Thread Laszlo Ersek
(Adding Dexuan Cui to the CC list, comments below.)

On 03/17/21 12:49, Stefan Hajnoczi wrote:
> Hi,
> Microsoft and Intel developed two different ACPI NVDIMM _DSM
> interfaces.
>
> The specs for the Intel interface are available here:
> https://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
>
> This is the interface that QEMU emulates. It has been reported that
> Windows 2016 Server and 2019 Server guests do not recognize QEMU's
> emulated NVDIMM devices using the Microsoft driver.

The Microsoft specification seems to be available at:

  https://uefi.org/NVDIMM%20RFIC%20Registry
  ->
  https://uefi.org/RFIC_LIST
  ->
  
https://www.uefi.org/sites/default/files/resources/_DSM%20for%20Virtual%20NVDIMMs%20v1.01.docx

It defines:

- Region Format Interface Code (RFIC) 0x1901,

- with a _DSM command set (for non-root devices) that is identified by
  UUID 5746C5F2-A9A2-4264-AD0E-E4DDC9E09E80.

On the other hand, the Intel document defines:

- RFIC 0x0201,

- with a _DSM command set (for non-root devices) that is identified by
  UUID 4309AC30-0D11-11E4-9191-0800200C9A66.

In the Linux kernel,

- the Microsoft UUID is called UUID_NFIT_DIMM_N_HYPERV (1194c4133195,
  "nfit: Add Hyper-V NVDIMM DSM command set to white list", 2019-01-29),

- while the Intel one is called UUID_NFIT_DIMM (commit b94d5230d06e,
  "libnvdimm, nfit: initial libnvdimm infrastructure and NFIT support",
  2015-06-24).

An interesting excerpt from commit 1194c4133195:

> +* There are 4 "legacy" NVDIMM command sets
> +* (NVDIMM_FAMILY_{INTEL,MSFT,HPE1,HPE2}) that were created before
> +* an EFI working group was established to constrain this
> +* proliferation. The nfit driver probes for the supported command
> +* set by GUID. Note, if you're a platform developer looking to add
> +* a new command set to this probe, consider using an existing set,
> +* or otherwise seek approval to publish the command set at
> +* http://www.uefi.org/RFIC_LIST.

And presently, the "official RFIC list" *only* contains Microsoft's
definition.

So my guess is that the QEMU device model (emulating Intel) predates
both the standardization and the registry, and that the Microsoft driver
only recognizes their own format (RFIC 0x1901 / UUID
5746C5F2-A9A2-4264-AD0E-E4DDC9E09E80).

Back to your email:

On 03/17/21 12:49, Stefan Hajnoczi wrote:
> I'd like to understand the path forward that will allow both Linux and
> Windows guests to successfully use QEMU's emulated NVDIMM device
> (https://gitlab.com/qemu-project/qemu/-/blob/master/hw/acpi/nvdimm.c).
>
> Are/have these two interfaces being/been unified?

I wouldn't think so. In the Linux kernel, UUID_NFIT_DIMM_N_HYPERV is
mapped to NFIT_DEV_DIMM_N_HYPERV is mapped to NVDIMM_FAMILY_HYPERV,
which seems to translate to "DSM mask" and "flags" manipulations...
which I don't understand. :)

FWIW, I believe the Linux kernel implements a "generic set" of NVDIMM
operations, and then it cherry-picks those features/operations that the
hardware (virtual or otherwise) advertizes, or seems to support.

This, and more closely the above-quoted code comment, appear to indicate
that there's no unification, at the interface level. The Linux guest
driver may have some implementation-level unification.

The first link I pasted above,
, refers to "NVST Workgroup
Chairperson". After logging in to my  account, I
managed to resolve "NVST" as follows:

- ACPI Specification Working Group [ASWG]

  - NVDIMM Subteam [NVST]

- https://members.uefi.org/apps/org/workgroup/nvst/description.php

  """
  Public Description

  The NVDIMM Subteam was created to review ACPI and UEFI related
  topics pertaining to persistent memory devices. All relevant ECR's
  need to be reviewed by this subcommittee prior to review by the
  USWG and ASWG. Please contact the group chair with questions or to
  add items to the regular meeting agenda.
  """

Some other abbreviations resolved, for interpreting the blurb:

- USWG: UEFI Spec Working Group

- ECR: Engineering Change Request -- basically a ticket filed for one of
  the UEFI, ACPI, and Platform Init specs, in the (members only) Mantis
  bug tracker, at . ECRs are usually proposed
  as stand-alone documents that are attached to Mantis tickets.


> Should QEMU emulate both of them to make running Windows guests easy?

In my (uneducated) opinion: yes. Microsoft standarized their Region
Format Interface, with their _DSM UUID and all; and right now, that spec
seems to be the *only* officially approved format in the RFIC registry.
So it's plausible to me that, unlike the Linux kernel, Microsoft's
driver doesn't support the -- technically unapproved, nonstandard --
Intel Region Format Interface.

Dexuan, please correct me if I'm wrong.

Thanks,
Laszlo




Re: Can not use hmp block_resize command with -blockdev option

2021-03-17 Thread John Snow

On 3/16/21 11:43 PM, zhao xiaojun wrote:

Hi,
I use -blockdev option to specify a drive when qemu boot and i want to 
resize it with hmp block_resize command. The hmp block_resize comand's 
arguments: block_resize device new_size.
So I query the device by qmp query_block command, but the device filed 
of the result output is NULL string.


result output:
{
   "return": [
     {
       "io-status": "ok",
       "device": "",
         ...
}

I noticed that the qmp block_resize command supports device or node-name 
as argument.


If i can continue use the the hmp block_resize command with the device 
argument?


Regards.


I'm not sure what you're asking: hmp's block_resize doesn't accept 
node-name arguments as you've found. Are you not able to use QMP's 
block_resize?


--js




[PATCH v2 0/6] esp: fix asserts/segfaults discovered by fuzzer

2021-03-17 Thread Mark Cave-Ayland
Recently there have been a number of issues raised on Launchpad as a result of
fuzzing the am53c974 (ESP) device. I spent some time over the past couple of
days checking to see if anything had improved since my last patchset: from
what I can tell the issues are still present, but the cmdfifo related failures
now assert rather than corrupting memory.

This patchset applied to master passes my local tests using the qtest fuzz test
cases added by Alexander for the following Launchpad bugs:

  https://bugs.launchpad.net/qemu/+bug/1919035
  https://bugs.launchpad.net/qemu/+bug/1919036
  https://bugs.launchpad.net/qemu/+bug/1910723
  https://bugs.launchpad.net/qemu/+bug/1909247
  
I'm posting this now just before soft freeze since I see that some of the issues
have recently been allocated CVEs and so it could be argued that even though
they have existed for some time, it is worth fixing them for 6.0.

Signed-off-by: Mark Cave-Ayland 

v2:
- Add Alexander's R-B tag for patch 2 and Phil's R-B for patch 3
- Add patch 4 for additional testcase provided in Alexander's patch 1 comment
- Move current_req NULL checks forward in DMA functions (fixes ASAN bug reported
  at https://bugs.launchpad.net/qemu/+bug/1909247/comments/6) in patch 3
- Add qtest for am53c974 containing a basic set of regression tests using the
  automatic test cases generated by the fuzzer as requested by Paolo


Mark Cave-Ayland (6):
  esp: don't underflow cmdfifo if no message out/command data is present
  esp: don't overflow cmdfifo if TC is larger than the cmdfifo size
  esp: ensure cmdfifo is not empty and current_dev is non-NULL
  esp: don't underflow fifo when writing to the device
  esp: always check current_req is not NULL before use in DMA callbacks
  tests/qtest: add tests for am53c974 device

 hw/scsi/esp.c   |  73 +
 tests/qtest/am53c974-test.c | 122 
 tests/qtest/meson.build |   1 +
 3 files changed, 171 insertions(+), 25 deletions(-)
 create mode 100644 tests/qtest/am53c974-test.c

-- 
2.20.1




[PATCH v2 1/6] esp: don't underflow cmdfifo if no message out/command data is present

2021-03-17 Thread Mark Cave-Ayland
If a guest sends a TI (Transfer Information) command without previously sending
any message out/command phase data then cmdfifo will underflow triggering an
assert reading the IDENTIFY byte.

Buglink: https://bugs.launchpad.net/qemu/+bug/1919035
Signed-off-by: Mark Cave-Ayland 
---
 hw/scsi/esp.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index 507ab363bc..5d3f1ccbc8 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -318,18 +318,24 @@ static void do_busid_cmd(ESPState *s, uint8_t busid)
 
 static void do_cmd(ESPState *s)
 {
-uint8_t busid = fifo8_pop(&s->cmdfifo);
+uint8_t busid;
 uint32_t n;
 
-s->cmdfifo_cdb_offset--;
+if (fifo8_num_used(&s->cmdfifo)) {
+busid = fifo8_pop(&s->cmdfifo);
 
-/* Ignore extended messages for now */
-if (s->cmdfifo_cdb_offset) {
-fifo8_pop_buf(&s->cmdfifo, s->cmdfifo_cdb_offset, &n);
-s->cmdfifo_cdb_offset = 0;
-}
+if (s->cmdfifo_cdb_offset) {
+s->cmdfifo_cdb_offset--;
+
+/* Ignore extended messages for now */
+if (s->cmdfifo_cdb_offset) {
+fifo8_pop_buf(&s->cmdfifo, s->cmdfifo_cdb_offset, &n);
+s->cmdfifo_cdb_offset = 0;
+}
+}
 
-do_busid_cmd(s, busid);
+do_busid_cmd(s, busid);
+}
 }
 
 static void satn_pdma_cb(ESPState *s)
-- 
2.20.1




[PATCH v2 3/6] esp: ensure cmdfifo is not empty and current_dev is non-NULL

2021-03-17 Thread Mark Cave-Ayland
When about to execute a SCSI command, ensure that cmdfifo is not empty and
current_dev is non-NULL. This can happen if the guest tries to execute a TI
(Transfer Information) command without issuing one of the select commands
first.

Buglink: https://bugs.launchpad.net/qemu/+bug/1910723
Buglink: https://bugs.launchpad.net/qemu/+bug/1909247
Signed-off-by: Mark Cave-Ayland 
---
 hw/scsi/esp.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index bbcbfa4a91..ae362c9dfb 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -286,6 +286,9 @@ static void do_busid_cmd(ESPState *s, uint8_t busid)
 trace_esp_do_busid_cmd(busid);
 lun = busid & 7;
 cmdlen = fifo8_num_used(&s->cmdfifo);
+if (!cmdlen || !s->current_dev) {
+return;
+}
 buf = (uint8_t *)fifo8_pop_buf(&s->cmdfifo, cmdlen, &n);
 
 current_lun = scsi_device_find(&s->bus, 0, s->current_dev->id, lun);
-- 
2.20.1




[PATCH v2 2/6] esp: don't overflow cmdfifo if TC is larger than the cmdfifo size

2021-03-17 Thread Mark Cave-Ayland
If a guest transfers the message out/command phase data using DMA with a TC
that is larger than the cmdfifo size then the cmdfifo overflows triggering
an assert. Limit the size of the transfer to the free space available in
cmdfifo.

Buglink: https://bugs.launchpad.net/qemu/+bug/1919036
Signed-off-by: Mark Cave-Ayland 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Alexander Bulekov 
---
 hw/scsi/esp.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index 5d3f1ccbc8..bbcbfa4a91 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -579,6 +579,7 @@ static void esp_do_dma(ESPState *s)
 cmdlen = fifo8_num_used(&s->cmdfifo);
 trace_esp_do_dma(cmdlen, len);
 if (s->dma_memory_read) {
+len = MIN(len, fifo8_num_free(&s->cmdfifo));
 s->dma_memory_read(s->dma_opaque, buf, len);
 fifo8_push_all(&s->cmdfifo, buf, len);
 } else {
-- 
2.20.1




[PATCH v2 6/6] tests/qtest: add tests for am53c974 device

2021-03-17 Thread Mark Cave-Ayland
Use the autogenerated fuzzer test cases as the basis for a set of am53c974
regression tests.

Signed-off-by: Mark Cave-Ayland 
---
 tests/qtest/am53c974-test.c | 122 
 tests/qtest/meson.build |   1 +
 2 files changed, 123 insertions(+)
 create mode 100644 tests/qtest/am53c974-test.c

diff --git a/tests/qtest/am53c974-test.c b/tests/qtest/am53c974-test.c
new file mode 100644
index 00..c90bd4c187
--- /dev/null
+++ b/tests/qtest/am53c974-test.c
@@ -0,0 +1,122 @@
+/*
+ * QTest testcase for am53c974
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or
+ * later. See the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+
+#include "libqos/libqtest.h"
+
+
+static void test_cmdfifo_underflow_ok(void)
+{
+QTestState *s = qtest_init(
+"-device am53c974,id=scsi "
+"-device scsi-hd,drive=disk0 -drive "
+"id=disk0,if=none,file=null-co://,format=raw -nodefaults");
+qtest_outl(s, 0xcf8, 0x80001004);
+qtest_outw(s, 0xcfc, 0x01);
+qtest_outl(s, 0xcf8, 0x8000100e);
+qtest_outl(s, 0xcfc, 0x8a00);
+qtest_outl(s, 0x8a09, 0x4200);
+qtest_outl(s, 0x8a0d, 0x00);
+qtest_outl(s, 0x8a0b, 0x1000);
+qtest_quit(s);
+}
+
+static void test_cmdfifo_overflow_ok(void)
+{
+QTestState *s = qtest_init(
+"-device am53c974,id=scsi "
+"-device scsi-hd,drive=disk0 -drive "
+"id=disk0,if=none,file=null-co://,format=raw -nodefaults");
+qtest_outl(s, 0xcf8, 0x80001004);
+qtest_outw(s, 0xcfc, 0x01);
+qtest_outl(s, 0xcf8, 0x8000100e);
+qtest_outl(s, 0xcfc, 0x0e00);
+qtest_outl(s, 0xe40, 0x03);
+qtest_outl(s, 0xe0b, 0x4100);
+qtest_outl(s, 0xe0b, 0x9000);
+qtest_quit(s);
+}
+
+static void test_target_selected_ok(void)
+{
+QTestState *s = qtest_init(
+"-device am53c974,id=scsi "
+"-device scsi-hd,drive=disk0 -drive "
+"id=disk0,if=none,file=null-co://,format=raw -nodefaults");
+qtest_outl(s, 0xcf8, 0x80001001);
+qtest_outl(s, 0xcfc, 0x0100);
+qtest_outl(s, 0xcf8, 0x8000100e);
+qtest_outl(s, 0xcfc, 0xef80);
+qtest_outl(s, 0xef8b, 0x4100);
+qtest_outw(s, 0xef80, 0x01);
+qtest_outl(s, 0xefc0, 0x03);
+qtest_outl(s, 0xef8b, 0xc100);
+qtest_outl(s, 0xef8b, 0x9000);
+qtest_quit(s);
+}
+
+static void test_fifo_underflow_on_write_ok(void)
+{
+QTestState *s = qtest_init(
+"-device am53c974,id=scsi "
+"-device scsi-hd,drive=disk0 -drive "
+"id=disk0,if=none,file=null-co://,format=raw -nodefaults");
+qtest_outl(s, 0xcf8, 0x80001010);
+qtest_outl(s, 0xcfc, 0xc000);
+qtest_outl(s, 0xcf8, 0x80001004);
+qtest_outw(s, 0xcfc, 0x01);
+qtest_outl(s, 0xc008, 0x0a);
+qtest_outl(s, 0xc009, 0x4100);
+qtest_outl(s, 0xc009, 0x4100);
+qtest_outl(s, 0xc00b, 0x1000);
+qtest_quit(s);
+}
+
+static void test_cancelled_request_ok(void)
+{
+QTestState *s = qtest_init(
+"-device am53c974,id=scsi "
+"-device scsi-hd,drive=disk0 -drive "
+"id=disk0,if=none,file=null-co://,format=raw -nodefaults");
+qtest_outl(s, 0xcf8, 0x80001010);
+qtest_outl(s, 0xcfc, 0xc000);
+qtest_outl(s, 0xcf8, 0x80001004);
+qtest_outw(s, 0xcfc, 0x05);
+qtest_outb(s, 0xc046, 0x02);
+qtest_outl(s, 0xc00b, 0xc100);
+qtest_outl(s, 0xc040, 0x03);
+qtest_outl(s, 0xc040, 0x03);
+qtest_bufwrite(s, 0x0, "\x41", 0x1);
+qtest_outl(s, 0xc00b, 0xc100);
+qtest_outw(s, 0xc040, 0x02);
+qtest_outw(s, 0xc040, 0x81);
+qtest_outl(s, 0xc00b, 0x9000);
+qtest_quit(s);
+}
+
+int main(int argc, char **argv)
+{
+const char *arch = qtest_get_arch();
+
+g_test_init(&argc, &argv, NULL);
+
+if (strcmp(arch, "i386") == 0) {
+qtest_add_func("am53c974/test_cmdfifo_underflow_ok",
+   test_cmdfifo_underflow_ok);
+qtest_add_func("am53c974/test_cmdfifo_overflow_ok",
+   test_cmdfifo_overflow_ok);
+qtest_add_func("am53c974/test_target_selected_ok",
+   test_target_selected_ok);
+qtest_add_func("am53c974/test_fifo_underflow_on_write_ok",
+   test_fifo_underflow_on_write_ok);
+qtest_add_func("am53c974/test_cancelled_request_ok",
+   test_cancelled_request_ok);
+}
+
+return g_test_run();
+}
diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index 66ee9fbf45..a44f612a34 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -63,6 +63,7 @@ qtests_i386 = \
   (config_all_devices.has_key('CONFIG_TPM_TIS_ISA') ? ['tpm-tis-test'] : []) + 
 \
   (config_all_devices.has_key('CONFIG_TPM_TIS_ISA') ? ['tpm-tis-swtpm-test'] : 
[]) +\
   (config_all_devices.has_key('CONFIG_RTL8139_PCI') ? ['rtl8139-test'] : []) + 
 \
+  (config_all_devices.has_key('CONFIG_ESP_PCI') ? ['am53c974-test'] : []) +
 

[PATCH v2 4/6] esp: don't underflow fifo when writing to the device

2021-03-17 Thread Mark Cave-Ayland
When writing to the device make sure that the fifo is not empty, otherwise the
fifo will underflow triggering an assert.

Buglink: https://bugs.launchpad.net/qemu/+bug/1909247
Signed-off-by: Mark Cave-Ayland 
---
 hw/scsi/esp.c | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index ae362c9dfb..bb57125035 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -509,18 +509,20 @@ static void do_dma_pdma_cb(ESPState *s)
 /* Copy FIFO data to device */
 len = MIN(s->async_len, ESP_FIFO_SZ);
 len = MIN(len, fifo8_num_used(&s->fifo));
-memcpy(s->async_buf, fifo8_pop_buf(&s->fifo, len, &n), len);
-s->async_buf += n;
-s->async_len -= n;
-s->ti_size += n;
-
-if (n < len) {
-/* Unaligned accesses can cause FIFO wraparound */
-len = len - n;
+if (len) {
 memcpy(s->async_buf, fifo8_pop_buf(&s->fifo, len, &n), len);
 s->async_buf += n;
 s->async_len -= n;
 s->ti_size += n;
+
+if (n < len) {
+/* Unaligned accesses can cause FIFO wraparound */
+len = len - n;
+memcpy(s->async_buf, fifo8_pop_buf(&s->fifo, len, &n), len);
+s->async_buf += n;
+s->async_len -= n;
+s->ti_size += n;
+}
 }
 
 if (s->async_len == 0) {
@@ -730,10 +732,12 @@ static void esp_do_nodma(ESPState *s)
 
 if (to_device) {
 len = MIN(fifo8_num_used(&s->fifo), ESP_FIFO_SZ);
-memcpy(s->async_buf, fifo8_pop_buf(&s->fifo, len, &n), len);
-s->async_buf += len;
-s->async_len -= len;
-s->ti_size += len;
+if (len) {
+memcpy(s->async_buf, fifo8_pop_buf(&s->fifo, len, &n), len);
+s->async_buf += len;
+s->async_len -= len;
+s->ti_size += len;
+}
 } else {
 len = MIN(s->ti_size, s->async_len);
 len = MIN(len, fifo8_num_free(&s->fifo));
-- 
2.20.1




[PATCH v2 5/6] esp: always check current_req is not NULL before use in DMA callbacks

2021-03-17 Thread Mark Cave-Ayland
After issuing a SCSI command the SCSI layer can call the SCSIBusInfo .cancel
callback which resets both current_req and current_dev to NULL. If any data
is left in the transfer buffer (async_len != 0) then the next TI (Transfer
Information) command will attempt to reference the NULL pointer causing a
segfault.

Buglink: https://bugs.launchpad.net/qemu/+bug/1910723
Buglink: https://bugs.launchpad.net/qemu/+bug/1909247
Signed-off-by: Mark Cave-Ayland 
---
 hw/scsi/esp.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
index bb57125035..d7b81b7608 100644
--- a/hw/scsi/esp.c
+++ b/hw/scsi/esp.c
@@ -505,6 +505,10 @@ static void do_dma_pdma_cb(ESPState *s)
 return;
 }
 
+if (!s->current_req) {
+return;
+}
+
 if (to_device) {
 /* Copy FIFO data to device */
 len = MIN(s->async_len, ESP_FIFO_SZ);
@@ -538,11 +542,9 @@ static void do_dma_pdma_cb(ESPState *s)
 return;
 } else {
 if (s->async_len == 0) {
-if (s->current_req) {
-/* Defer until the scsi layer has completed */
-scsi_req_continue(s->current_req);
-s->data_in_ready = false;
-}
+/* Defer until the scsi layer has completed */
+scsi_req_continue(s->current_req);
+s->data_in_ready = false;
 return;
 }
 
@@ -616,6 +618,9 @@ static void esp_do_dma(ESPState *s)
 }
 return;
 }
+if (!s->current_req) {
+return;
+}
 if (s->async_len == 0) {
 /* Defer until data is available.  */
 return;
@@ -725,6 +730,10 @@ static void esp_do_nodma(ESPState *s)
 return;
 }
 
+if (!s->current_req) {
+return;
+}
+
 if (s->async_len == 0) {
 /* Defer until data is available.  */
 return;
-- 
2.20.1




Re: [PATCH V3] file-posix: allow -EBUSY -EINVAL errors during write zeros on block

2021-03-17 Thread John Snow

On 3/9/21 7:16 PM, ChangLimin wrote:

Since Linux 5.10, write zeros to a multipath device using
ioctl(fd, BLKZEROOUT, range) with cache none or directsync return -EBUSY
permanently.



When do we get -EINVAL? Both of the commits referenced below don't 
specifically mention it, so I am not sure in which circumstances that 
might arise.



Similar to handle_aiocb_write_zeroes_unmap, handle_aiocb_write_zeroes_block
allow -EBUSY and -EINVAL errors during ioctl(fd, BLKZEROOUT, range).

Reference commit in Linux 5.10:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=384d87ef2c954fc58e6c5fd8253e4a1984f5fe02 



Although it will be fixed in 5.12, I think it's good to avoid similar 
problem in the future.
https://lore.kernel.org/linux-block/53689a67-7591-0ad8-3e7d-dca9a626c...@kernel.dk/ 





Wait, if they're fixing the function to actually apply a different 
fallback path, shouldn't we *not* allow EBUSY?



Signed-off-by: ChangLimin 
---
  block/file-posix.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/block/file-posix.c b/block/file-posix.c
index 05079b40ca..4e132db929 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1629,8 +1629,13 @@ static ssize_t 
handle_aiocb_write_zeroes_block(RawPosixAIOData *aiocb)

          } while (errno == EINTR);

          ret = translate_err(-errno);
-        if (ret == -ENOTSUP) {
-            s->has_write_zeroes = false;
+        switch (ret) {
+        case -ENOTSUP:
+            s->has_write_zeroes = false; /* fall through */
+        case -EINVAL:
+        case -EBUSY:
+            return -ENOTSUP;
+            break;


oh, we're not "allowing" them, we're treating the failure *more 
seriously* so that we avoid attempting to call this function ever again 
for this FD.


Can you please add a brief comment here, something like:

/* Linux 5.10/5.11 may return these for multipath devices */


          }
      }
  #endif
--
2.27.0






Re: iotests failing on gitlab CI check-system-fedora job

2021-03-17 Thread Paolo Bonzini

On 17/03/21 23:23, Peter Maydell wrote:

The check-system-fedora job in the gitlab CI seems to have
started reliably failing on iotests 040 041 127 256 267:
  https://gitlab.com/qemu-project/qemu/-/jobs/1106977551

Could somebody have a look at what's happening, please?
(This is probably a regression that's got into master because
I stopped using "did gitlab CI pass" as a gate because gitlab
was running massively too slowly to be usable for that.)


It's caused by adding virtio devices to the m68k target.  Probably it 
can be fixed by moving i386-softmmu to Fedora and m68k-softmmu to Debian.


But really, most of the tests we run are not ever going to fail in 
isolation.  Do we really gain anything by building all or almost all 
targets for each cross (as opposed to just one 32-bit and one 64-bit 
target), or by running check-block many times on similar or identical 
configurations?


Paolo




[PATCH v5 0/4] target/arm: Add support for FEAT_TLBIOS and FEAT_TLBIRANGE

2021-03-17 Thread Rebecca Cran
ARMv8.4 adds the mandatory FEAT_TLBIOS and FEAT_TLBIRANGE. 
They provides TLBI maintenance instructions that extend to the Outer
Shareable domain and that apply to a range of input addresses.

Changes from v4 to v5:

o Split changes to cputlb.c and exec_all.c into a separate commit.
o Return a bool from tlb_flush_page_bits_locked to indicate if a full
 flush has been done.
o Update flush_page_range_bits_* to exit early when a full flush has
 been done.
o Run tb_flush_jmp_cache in a separate loop.
o Don't check for 2 regimes for cases where we know there's only one.


Rebecca Cran (4):
  accel/tcg: Add TLB invalidation support for ranges of addresses
  target/arm: Add support for FEAT_TLBIRANGE
  target/arm: Add support for FEAT_TLBIOS
  target/arm: set ID_AA64ISAR0.TLB to 2 for max AARCH64 CPU type

 accel/tcg/cputlb.c  | 130 ++-
 include/exec/exec-all.h |  45 +++
 target/arm/cpu.h|  10 +
 target/arm/cpu64.c  |   1 +
 target/arm/helper.c | 369 
 5 files changed, 552 insertions(+), 3 deletions(-)

-- 
2.26.2




[PATCH v5 1/4] accel/tcg: Add TLB invalidation support for ranges of addresses

2021-03-17 Thread Rebecca Cran
Add functions to support the FEAT_TLBIRANGE ARMv8.4 feature that adds
TLB invalidation instructions to invalidate ranges of addresses.

Signed-off-by: Rebecca Cran 
---
 accel/tcg/cputlb.c  | 130 +++-
 include/exec/exec-all.h |  45 +++
 2 files changed, 172 insertions(+), 3 deletions(-)

diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
index 8a7b779270a4..dc44967dcf8e 100644
--- a/accel/tcg/cputlb.c
+++ b/accel/tcg/cputlb.c
@@ -709,7 +709,7 @@ void tlb_flush_page_all_cpus_synced(CPUState *src, 
target_ulong addr)
 tlb_flush_page_by_mmuidx_all_cpus_synced(src, addr, ALL_MMUIDX_BITS);
 }
 
-static void tlb_flush_page_bits_locked(CPUArchState *env, int midx,
+static bool tlb_flush_page_bits_locked(CPUArchState *env, int midx,
target_ulong page, unsigned bits)
 {
 CPUTLBDesc *d = &env_tlb(env)->d[midx];
@@ -729,7 +729,7 @@ static void tlb_flush_page_bits_locked(CPUArchState *env, 
int midx,
   TARGET_FMT_lx "/" TARGET_FMT_lx ")\n",
   midx, page, mask);
 tlb_flush_one_mmuidx_locked(env, midx, get_clock_realtime());
-return;
+return true;
 }
 
 /* Check if we need to flush due to large pages.  */
@@ -738,13 +738,14 @@ static void tlb_flush_page_bits_locked(CPUArchState *env, 
int midx,
   TARGET_FMT_lx "/" TARGET_FMT_lx ")\n",
   midx, d->large_page_addr, d->large_page_mask);
 tlb_flush_one_mmuidx_locked(env, midx, get_clock_realtime());
-return;
+return true;
 }
 
 if (tlb_flush_entry_mask_locked(tlb_entry(env, midx, page), page, mask)) {
 tlb_n_used_entries_dec(env, midx);
 }
 tlb_flush_vtlb_page_mask_locked(env, midx, page, mask);
+return false;
 }
 
 typedef struct {
@@ -943,6 +944,129 @@ void 
tlb_flush_page_bits_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
 }
 }
 
+typedef struct {
+target_ulong addr;
+target_ulong length;
+uint16_t idxmap;
+uint16_t bits;
+}  TLBFlushPageRangeBitsByMMUIdxData;
+
+static void
+tlb_flush_page_range_bits_by_mmuidx_async_0(CPUState *cpu,
+target_ulong addr,
+target_ulong length,
+uint16_t idxmap,
+unsigned bits)
+{
+CPUArchState *env = cpu->env_ptr;
+int mmu_idx;
+target_ulong l;
+target_ulong page = addr;
+bool full_flush;
+
+assert_cpu_is_self(cpu);
+
+tlb_debug("page addr:" TARGET_FMT_lx "/%u len: " TARGET_FMT_lx
+  " mmu_map:0x%x\n",
+  addr, bits, length, idxmap);
+
+qemu_spin_lock(&env_tlb(env)->c.lock);
+for (mmu_idx = 0; mmu_idx < NB_MMU_MODES; mmu_idx++) {
+if ((idxmap >> mmu_idx) & 1) {
+for (l = 0; l < length; l += TARGET_PAGE_SIZE) {
+page = addr + l;
+full_flush = tlb_flush_page_bits_locked(env, mmu_idx,
+page, bits);
+if (full_flush) {
+break;
+}
+}
+}
+}
+qemu_spin_unlock(&env_tlb(env)->c.lock);
+
+for (l = 0; l < length; l += TARGET_PAGE_SIZE) {
+tb_flush_jmp_cache(cpu, page);
+}
+}
+
+static void
+tlb_flush_page_range_bits_by_mmuidx_async_1(CPUState *cpu,
+run_on_cpu_data data)
+{
+TLBFlushPageRangeBitsByMMUIdxData *d = data.host_ptr;
+
+tlb_flush_page_range_bits_by_mmuidx_async_0(cpu, d->addr, d->length,
+d->idxmap, d->bits);
+
+g_free(d);
+}
+
+void tlb_flush_page_range_bits_by_mmuidx(CPUState *cpu,
+ target_ulong addr,
+ target_ulong length,
+ uint16_t idxmap,
+ unsigned bits)
+{
+TLBFlushPageRangeBitsByMMUIdxData d;
+TLBFlushPageRangeBitsByMMUIdxData *p;
+
+/* This should already be page aligned */
+addr &= TARGET_PAGE_BITS;
+
+d.addr = addr & TARGET_PAGE_MASK;
+d.idxmap = idxmap;
+d.bits = bits;
+d.length = length;
+
+if (qemu_cpu_is_self(cpu)) {
+tlb_flush_page_range_bits_by_mmuidx_async_0(cpu, addr, length,
+idxmap, bits);
+} else {
+p = g_new(TLBFlushPageRangeBitsByMMUIdxData, 1);
+
+/* Allocate a structure, freed by the worker.  */
+*p = d;
+async_run_on_cpu(cpu, tlb_flush_page_range_bits_by_mmuidx_async_1,
+ RUN_ON_CPU_HOST_PTR(p));
+}
+}
+
+void tlb_flush_page_range_bits_by_mmuidx_all_cpus_synced(CPUState *src_cpu,
+ target_ulong addr,
+ target_ulong 

[PATCH v5 2/4] target/arm: Add support for FEAT_TLBIRANGE

2021-03-17 Thread Rebecca Cran
ARMv8.4 adds the mandatory FEAT_TLBIRANGE. It provides TLBI
maintenance instructions that apply to a range of input addresses.

Signed-off-by: Rebecca Cran 
---
 target/arm/cpu.h|   5 +
 target/arm/helper.c | 294 
 2 files changed, 299 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 193a49ec7fac..32b78a4ef587 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -4038,6 +4038,11 @@ static inline bool isar_feature_aa64_pauth_arch(const 
ARMISARegisters *id)
 return FIELD_EX64(id->id_aa64isar1, ID_AA64ISAR1, APA) != 0;
 }
 
+static inline bool isar_feature_aa64_tlbirange(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->id_aa64isar0, ID_AA64ISAR0, TLB) == 2;
+}
+
 static inline bool isar_feature_aa64_sb(const ARMISARegisters *id)
 {
 return FIELD_EX64(id->id_aa64isar1, ID_AA64ISAR1, SB) != 0;
diff --git a/target/arm/helper.c b/target/arm/helper.c
index d9220be7c5a0..ce913deff490 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -4759,6 +4759,217 @@ static void tlbi_aa64_vae3is_write(CPUARMState *env, 
const ARMCPRegInfo *ri,
   ARMMMUIdxBit_SE3, bits);
 }
 
+#ifdef TARGET_AARCH64
+static uint64_t tlbi_aa64_range_get_length(CPUARMState *env,
+   uint64_t value)
+{
+unsigned int page_shift;
+unsigned int page_size_granule;
+uint64_t num;
+uint64_t scale;
+uint64_t exponent;
+uint64_t length;
+
+num = extract64(value, 39, 4);
+scale = extract64(value, 44, 2);
+page_size_granule = extract64(value, 46, 2);
+
+page_shift = page_size_granule * 2 + 10;
+
+if (page_size_granule == 0) {
+qemu_log_mask(LOG_GUEST_ERROR, "Invalid page size granule %d\n",
+  page_size_granule);
+return 0;
+}
+
+exponent = (5 * scale) + 1;
+length = (num + 1) << (exponent + page_shift);
+
+return length;
+}
+
+static void tlbi_aa64_rvae1_write(CPUARMState *env, const ARMCPRegInfo *ri,
+  uint64_t value)
+{
+/*
+ * Invalidate by VA range, EL1&0.
+ * Currently handles all of RVAE1, RVAAE1, RVAALE1 and RVALE1,
+ * since we don't support flush-for-specific-ASID-only or
+ * flush-last-level-only.
+ */
+ARMMMUIdx mask;
+int bits;
+uint64_t pageaddr;
+uint64_t length;
+
+CPUState *cs = env_cpu(env);
+mask = vae1_tlbmask(env);
+if (regime_has_2_ranges(ctz32(mask))) {
+pageaddr = sextract64(value, 0, 37) << TARGET_PAGE_BITS;
+} else {
+pageaddr = extract64(value, 0, 37) << TARGET_PAGE_BITS;
+}
+length = tlbi_aa64_range_get_length(env, value);
+bits = tlbbits_for_regime(env, mask, pageaddr);
+
+if (tlb_force_broadcast(env)) {
+tlb_flush_page_range_bits_by_mmuidx_all_cpus_synced(cs, pageaddr,
+length, mask,
+bits);
+} else {
+tlb_flush_page_range_bits_by_mmuidx(cs, pageaddr, length, mask,
+bits);
+}
+}
+
+static void tlbi_aa64_rvae1is_write(CPUARMState *env, const ARMCPRegInfo *ri,
+uint64_t value)
+{
+/*
+ * Invalidate by VA range, Inner/Outer Shareable EL1&0.
+ * Currently handles all of RVAE1IS, RVAE1OS, RVAAE1IS, RVAAE1OS,
+ * RVAALE1IS, RVAALE1OS, RVALE1IS and RVALE1OS, since we don't support
+ * flush-for-specific-ASID-only, flush-last-level-only or inner/outer
+ * shareable specific flushes.
+ */
+ARMMMUIdx mask;
+int bits;
+uint64_t pageaddr;
+uint64_t length;
+
+CPUState *cs = env_cpu(env);
+mask = vae1_tlbmask(env);
+if (regime_has_2_ranges(ctz32(mask))) {
+pageaddr = sextract64(value, 0, 37) << TARGET_PAGE_BITS;
+} else {
+pageaddr = extract64(value, 0, 37) << TARGET_PAGE_BITS;
+}
+length = tlbi_aa64_range_get_length(env, value);
+bits = tlbbits_for_regime(env, mask, pageaddr);
+
+tlb_flush_page_range_bits_by_mmuidx_all_cpus_synced(cs, pageaddr,
+length, mask,
+bits);
+}
+
+static void tlbi_aa64_rvae2_write(CPUARMState *env, const ARMCPRegInfo *ri,
+  uint64_t value)
+{
+/*
+ * Invalidate by VA range, EL2.
+ * Currently handles all of RVAE2, RVAAE2, RVAALE2 and RVALE2,
+ * since we don't support flush-for-specific-ASID-only or
+ * flush-last-level-only.
+ */
+ARMMMUIdx mask;
+bool secure;
+int bits;
+uint64_t pageaddr;
+uint64_t length;
+
+CPUState *cs = env_cpu(env);
+secure = arm_is_secure_below_el3(env);
+pageaddr = extract64(value, 0, 37) << TARGET_PAGE_BITS;
+length = tlbi_aa64_range_get_length(env, value);
+mask = secure ? ARMMMUIdxBit_SE2 : ARMMMU

[PATCH v5 4/4] target/arm: set ID_AA64ISAR0.TLB to 2 for max AARCH64 CPU type

2021-03-17 Thread Rebecca Cran
Indicate support for FEAT_TLBIOS and FEAT_TLBIRANGE by setting
ID_AA64ISAR0.TLB to 2 for the max AARCH64 CPU type.

Signed-off-by: Rebecca Cran 
Reviewed-by: Richard Henderson 
---
 target/arm/cpu64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index f0a9e968c9c1..f42803ecaf1d 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -651,6 +651,7 @@ static void aarch64_max_initfn(Object *obj)
 t = FIELD_DP64(t, ID_AA64ISAR0, DP, 1);
 t = FIELD_DP64(t, ID_AA64ISAR0, FHM, 1);
 t = FIELD_DP64(t, ID_AA64ISAR0, TS, 2); /* v8.5-CondM */
+t = FIELD_DP64(t, ID_AA64ISAR0, TLB, 2); /* FEAT_TLBIRANGE */
 t = FIELD_DP64(t, ID_AA64ISAR0, RNDR, 1);
 cpu->isar.id_aa64isar0 = t;
 
-- 
2.26.2




[PATCH v5 3/4] target/arm: Add support for FEAT_TLBIOS

2021-03-17 Thread Rebecca Cran
ARMv8.4 adds the mandatory FEAT_TLBIOS. It provides TLBI
maintenance instructions that extend to the Outer Shareable domain.

Signed-off-by: Rebecca Cran 
---
 target/arm/cpu.h|  5 ++
 target/arm/helper.c | 75 
 2 files changed, 80 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 32b78a4ef587..272fde83ca4e 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -4043,6 +4043,11 @@ static inline bool isar_feature_aa64_tlbirange(const 
ARMISARegisters *id)
 return FIELD_EX64(id->id_aa64isar0, ID_AA64ISAR0, TLB) == 2;
 }
 
+static inline bool isar_feature_aa64_tlbios(const ARMISARegisters *id)
+{
+return FIELD_EX64(id->id_aa64isar0, ID_AA64ISAR0, TLB) != 0;
+}
+
 static inline bool isar_feature_aa64_sb(const ARMISARegisters *id)
 {
 return FIELD_EX64(id->id_aa64isar1, ID_AA64ISAR1, SB) != 0;
diff --git a/target/arm/helper.c b/target/arm/helper.c
index ce913deff490..5b10f179b761 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -7211,6 +7211,78 @@ static const ARMCPRegInfo tlbirange_reginfo[] = {
 REGINFO_SENTINEL
 };
 
+static const ARMCPRegInfo tlbios_reginfo[] = {
+{ .name = "TLBI_VMALLE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 1, .opc2 = 0,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_vmalle1is_write },
+{ .name = "TLBI_ASIDE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 1, .opc2 = 2,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_vmalle1is_write },
+{ .name = "TLBI_RVAE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 1,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae1is_write },
+{ .name = "TLBI_RVAAE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 3,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae1is_write },
+   { .name = "TLBI_RVALE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 5,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae1is_write },
+{ .name = "TLBI_RVAALE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 7,
+  .access = PL1_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae1is_write },
+{ .name = "TLBI_ALLE2OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 1, .opc2 = 0,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle2is_write },
+   { .name = "TLBI_ALLE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 1, .opc2 = 4,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle1is_write },
+{ .name = "TLBI_VMALLS12E1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 1, .opc2 = 6,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle1is_write },
+{ .name = "TLBI_IPAS2E1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 4, .opc2 = 0,
+  .access = PL2_W, .type = ARM_CP_NOP },
+{ .name = "TLBI_RIPAS2E1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 4, .opc2 = 3,
+  .access = PL2_W, .type = ARM_CP_NOP },
+{ .name = "TLBI_IPAS2LE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 4, .opc2 = 4,
+  .access = PL2_W, .type = ARM_CP_NOP },
+{ .name = "TLBI_RIPAS2LE1OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 4, .opc2 = 7,
+  .access = PL2_W, .type = ARM_CP_NOP },
+   { .name = "TLBI_RVAE2OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 5, .opc2 = 1,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae2is_write },
+   { .name = "TLBI_RVALE2OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 4, .crn = 8, .crm = 5, .opc2 = 5,
+  .access = PL2_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae2is_write },
+{ .name = "TLBI_ALLE3OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 8, .crm = 1, .opc2 = 0,
+  .access = PL3_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_alle3is_write },
+   { .name = "TLBI_RVAE3OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 8, .crm = 5, .opc2 = 1,
+  .access = PL3_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae3is_write },
+   { .name = "TLBI_RVALE3OS", .state = ARM_CP_STATE_AA64,
+  .opc0 = 1, .opc1 = 6, .crn = 8, .crm = 5, .opc2 = 5,
+  .access = PL3_W, .type = ARM_CP_NO_RAW,
+  .writefn = tlbi_aa64_rvae3is_write },
+REGINFO_SENTINEL
+};
+
 static uint64_t rndr_readfn(CPUARMState *env, const ARMCPRegInfo *ri)
 {
 Error *err = NULL;
@@ -8583,6 +8655,9 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 if (cpu

Re: [PATCH v5 0/4] target/arm: Add support for FEAT_TLBIOS and FEAT_TLBIRANGE

2021-03-17 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20210317233301.4130-1-rebe...@nuviainc.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20210317233301.4130-1-rebe...@nuviainc.com
Subject: [PATCH v5 0/4] target/arm: Add support for FEAT_TLBIOS and 
FEAT_TLBIRANGE

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20210317233301.4130-1-rebe...@nuviainc.com -> 
patchew/20210317233301.4130-1-rebe...@nuviainc.com
Switched to a new branch 'test'
39b3c36 target/arm: set ID_AA64ISAR0.TLB to 2 for max AARCH64 CPU type
e3bc253 target/arm: Add support for FEAT_TLBIOS
94e5cc1 target/arm: Add support for FEAT_TLBIRANGE
85f8baf accel/tcg: Add TLB invalidation support for ranges of addresses

=== OUTPUT BEGIN ===
1/4 Checking commit 85f8baff74da (accel/tcg: Add TLB invalidation support for 
ranges of addresses)
WARNING: line over 80 characters
#238: FILE: include/exec/exec-all.h:354:
+static inline void 
tlb_flush_page_range_bits_by_mmuidx_all_cpus_synced(CPUState *src_cpu,

WARNING: line over 80 characters
#239: FILE: include/exec/exec-all.h:355:
+   
target_ulong addr,

ERROR: line over 90 characters
#240: FILE: include/exec/exec-all.h:356:
+   
target_ulong length,

WARNING: line over 80 characters
#241: FILE: include/exec/exec-all.h:357:
+   
uint16_t idxmap,

WARNING: line over 80 characters
#242: FILE: include/exec/exec-all.h:358:
+   
unsigned bits)

total: 1 errors, 4 warnings, 217 lines checked

Patch 1/4 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

2/4 Checking commit 94e5cc1394b4 (target/arm: Add support for FEAT_TLBIRANGE)
3/4 Checking commit e3bc253926cd (target/arm: Add support for FEAT_TLBIOS)
4/4 Checking commit 39b3c36068b4 (target/arm: set ID_AA64ISAR0.TLB to 2 for max 
AARCH64 CPU type)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20210317233301.4130-1-rebe...@nuviainc.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: Microsoft and Intel NVDIMM ACPI _DSM interfaces status?

2021-03-17 Thread Dan Williams
On Wed, Mar 17, 2021 at 4:49 AM Stefan Hajnoczi  wrote:
>
> Hi,
> Microsoft and Intel developed two different ACPI NVDIMM _DSM interfaces.
>
> The specs for the Intel interface are available here:
> https://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
>
> This is the interface that QEMU emulates. It has been reported that
> Windows 2016 Server and 2019 Server guests do not recognize QEMU's
> emulated NVDIMM devices using the Microsoft driver.
>
> I'd like to understand the path forward that will allow both Linux and
> Windows guests to successfully use QEMU's emulated NVDIMM device
> (https://gitlab.com/qemu-project/qemu/-/blob/master/hw/acpi/nvdimm.c).
>
> Are/have these two interfaces being/been unified?

No, they service 2 different classes of NVDIMMs. The Microsoft
specification was defined for NVDIMM-N devices that are the
traditional battery/super-capacitor backed DDR with sometimes an equal
amount of flash to squirrel away data to non-volatile media on power
loss. The Intel one is for a persistent media class of device where
there is no need to communicate health attributes like "energy source
died" or "restore from flash" failed.

> Should QEMU emulate both of them to make running Windows guests easy?

Depends on how tolerant Windows is to different format-interface-code
implementations and what QEMU should return on each of the functions
it decides to implement.

Note that QEMU only implements a small subset of the Intel commands,
i.e. just enough to provision namespaces in the NVDIMM label area.
"NVDIMM label area" is a concept that is newer than the NVDIMM-N
definition which is why you don't see labels mentioned in the
Microsoft specification. Since then ACPI has developed common label
area access methods, see "6.5.10 NVDIMM Label Methods" in the ACPI 6.4
specification.

Note that you'll also see "9.20.8 NVDIMM Device Methods" in that spec
for some health management commands that overlap what the Microsoft
and Intel specs communicate. Linux does not support them since any
platform that might support them will also support the Intel
specification so there's no driving need for Linux to migrate. I do
not know the status of that command support in Windows, or the HPE
command support in Windows for that matter.

If you need to support guests that expect the Hyper-V command
definition, and will fail to attach NVDIMM support in the absence of
that definition then QEMU needs UUID_NFIT_DIMM_N_HYPERV support, note
that is a different command set than even UUID_NFIT_DIMM_N_MSFT
(include/acpi/acuuid.h). That would also require changes to virtual
ACPI NFIT to advertise the correlated format interface code. There may
be more... you would need someone from Hyper-V land to enumerate all
that is expected.



Re: [PATCH v2 1/6] esp: don't underflow cmdfifo if no message out/command data is present

2021-03-17 Thread Alexander Bulekov
On 210317 2302, Mark Cave-Ayland wrote:
> If a guest sends a TI (Transfer Information) command without previously 
> sending
> any message out/command phase data then cmdfifo will underflow triggering an
> assert reading the IDENTIFY byte.
> 
> Buglink: https://bugs.launchpad.net/qemu/+bug/1919035
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/scsi/esp.c | 22 ++
>  1 file changed, 14 insertions(+), 8 deletions(-)

Tested-by: Alexander Bulekov 



Re: [PATCH v2 3/6] esp: ensure cmdfifo is not empty and current_dev is non-NULL\

2021-03-17 Thread Alexander Bulekov
On 210317 2302, Mark Cave-Ayland wrote:
> When about to execute a SCSI command, ensure that cmdfifo is not empty and
> current_dev is non-NULL. This can happen if the guest tries to execute a TI
> (Transfer Information) command without issuing one of the select commands
> first.
> 
> Buglink: https://bugs.launchpad.net/qemu/+bug/1910723
> Buglink: https://bugs.launchpad.net/qemu/+bug/1909247
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/scsi/esp.c | 3 +++
>  1 file changed, 3 insertions(+)
> 

Tested-by: Alexander Bulekov 

> diff --git a/hw/scsi/esp.c b/hw/scsi/esp.c
> index bbcbfa4a91..ae362c9dfb 100644
> --- a/hw/scsi/esp.c
> +++ b/hw/scsi/esp.c
> @@ -286,6 +286,9 @@ static void do_busid_cmd(ESPState *s, uint8_t busid)
>  trace_esp_do_busid_cmd(busid);
>  lun = busid & 7;
>  cmdlen = fifo8_num_used(&s->cmdfifo);
> +if (!cmdlen || !s->current_dev) {
> +return;
> +}
>  buf = (uint8_t *)fifo8_pop_buf(&s->cmdfifo, cmdlen, &n);
>  
>  current_lun = scsi_device_find(&s->bus, 0, s->current_dev->id, lun);
> -- 
> 2.20.1
> 



Re: [PATCH v2 4/6] esp: don't underflow fifo when writing to the device

2021-03-17 Thread Alexander Bulekov
On 210317 2302, Mark Cave-Ayland wrote:
> When writing to the device make sure that the fifo is not empty, otherwise the
> fifo will underflow triggering an assert.
> 
> Buglink: https://bugs.launchpad.net/qemu/+bug/1909247
> Signed-off-by: Mark Cave-Ayland 
> ---
>  hw/scsi/esp.c | 28 
>  1 file changed, 16 insertions(+), 12 deletions(-)
> 

Tested-by: Alexander Bulekov 



Re: [PATCH v2 5/6] esp: always check current_req is not NULL before use in DMA callbacks

2021-03-17 Thread Alexander Bulekov
On 210317 2302, Mark Cave-Ayland wrote:
> After issuing a SCSI command the SCSI layer can call the SCSIBusInfo .cancel
> callback which resets both current_req and current_dev to NULL. If any data
> is left in the transfer buffer (async_len != 0) then the next TI (Transfer
> Information) command will attempt to reference the NULL pointer causing a
> segfault.
> 
> Buglink: https://bugs.launchpad.net/qemu/+bug/1910723
> Buglink: https://bugs.launchpad.net/qemu/+bug/1909247
> Signed-off-by: Mark Cave-Ayland 
> ---

Tested-by: Alexander Bulekov 



Re: [PATCH v2 6/6] tests/qtest: add tests for am53c974 device

2021-03-17 Thread Alexander Bulekov
On 210317 2302, Mark Cave-Ayland wrote:
> Use the autogenerated fuzzer test cases as the basis for a set of am53c974
> regression tests.
> 
> Signed-off-by: Mark Cave-Ayland 
> ---

Reviewed-by: Alexander Bulekov 

Thanks



RE: [PATCH V2 6/7] net/colo-compare: Add passthrough list to CompareState

2021-03-17 Thread Zhang, Chen



> -Original Message-
> From: Lukas Straub 
> Sent: Thursday, March 18, 2021 5:16 AM
> To: Zhang, Chen 
> Cc: Jason Wang ; qemu-dev  de...@nongnu.org>; Eric Blake ; Dr. David Alan
> Gilbert ; Markus Armbruster ;
> Zhang Chen 
> Subject: Re: [PATCH V2 6/7] net/colo-compare: Add passthrough list to
> CompareState
> 
> On Wed,  3 Mar 2021 12:15:38 +0800
> Zhang Chen  wrote:
> 
> > From: Zhang Chen 
> >
> > Add passthrough list for each CompareState.
> >
> > Signed-off-by: Zhang Chen 
> > ---
> >  net/colo-compare.c | 25 +  net/colo-
> compare.h
> > | 10 ++
> >  2 files changed, 35 insertions(+)
> >
> > diff --git a/net/colo-compare.c b/net/colo-compare.c index
> > a803f8b888..80cea32c20 100644
> > --- a/net/colo-compare.c
> > +++ b/net/colo-compare.c
> > @@ -141,6 +141,7 @@ static int packet_enqueue(CompareState *s, int
> mode, Connection **con)
> >  ConnectionKey key;
> >  Packet *pkt = NULL;
> >  Connection *conn;
> > +PassthroughEntry *bypass, *next;
> >  int ret;
> >
> >  if (mode == PRIMARY_IN) {
> > @@ -160,6 +161,29 @@ static int packet_enqueue(CompareState *s, int
> mode, Connection **con)
> >  }
> >  fill_connection_key(pkt, &key);
> >
> > +/* Check COLO passthrough connenction */
> > +if (!QLIST_EMPTY(&s->passthroughlist)) {
> > +QLIST_FOREACH_SAFE(bypass, &s->passthroughlist, node, next) {
> > +if (((key.ip_proto == IPPROTO_TCP) && (bypass->l4_protocol == 
> > 0))
> ||
> > +((key.ip_proto == IPPROTO_UDP) && (bypass->l4_protocol == 
> > 1)))
> {
> > +if (bypass->src_port == 0 || bypass->src_port == 
> > key.dst_port) {
> > +if (bypass->src_ip.s_addr == 0 ||
> > +bypass->src_ip.s_addr == key.src.s_addr) {
> > +if (bypass->dst_port == 0 ||
> > +bypass->dst_port == key.src_port) {
> > +if (bypass->dst_ip.s_addr == 0 ||
> > +bypass->dst_ip.s_addr == key.dst.s_addr) {
> > +packet_destroy(pkt, NULL);
> > +pkt = NULL;
> > +return -1;
> > +}
> > +}
> > +}
> > +}
> > +}
> > +}
> > +}
> > +
> 
> Hi,
> Access to s->passthroughlist still needs to be protected by a lock.
> 

OK, will fix it in next version.

Thanks
Chen

> Regards,
> Lukas Straub
> 
> >  conn = connection_get(s->connection_track_table,
> >&key,
> >&s->conn_list); @@ -1224,6 +1248,7 @@
> > static void colo_compare_complete(UserCreatable *uc, Error **errp)
> >  }
> >
> >  g_queue_init(&s->conn_list);
> > +QLIST_INIT(&s->passthroughlist);
> >
> >  s->connection_track_table =
> g_hash_table_new_full(connection_key_hash,
> >
> > connection_key_equal, diff --git a/net/colo-compare.h
> > b/net/colo-compare.h index 2a9dcac0a7..31644f145b 100644
> > --- a/net/colo-compare.h
> > +++ b/net/colo-compare.h
> > @@ -54,6 +54,15 @@ typedef struct SendEntry {
> >  uint8_t *buf;
> >  } SendEntry;
> >
> > +typedef struct PassthroughEntry {
> > +int l4_protocol;
> > +int src_port;
> > +int dst_port;
> > +struct in_addr src_ip;
> > +struct in_addr dst_ip;
> > +QLIST_ENTRY(PassthroughEntry) node; } PassthroughEntry;
> > +
> >  /*
> >   *  + CompareState ++
> >   *  |   |
> > @@ -110,6 +119,7 @@ struct CompareState {
> >
> >  QEMUBH *event_bh;
> >  enum colo_event event;
> > +QLIST_HEAD(, PassthroughEntry) passthroughlist;
> >
> >  QTAILQ_ENTRY(CompareState) next;
> >  };
> 
> 
> 
> --




RE: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp packet

2021-03-17 Thread Zhang, Chen
Sorry for the delay. Current COLO tree just merged this series,
I originally wanted to merge other COLO related patches(Lei or me) and submit 
it together to Jason.

Hi Jason, do you need me to send this series first or do you want to do it 
together?

Thanks
Chen

> -Original Message-
> From: Lukas Straub 
> Sent: Thursday, March 18, 2021 5:24 AM
> To: Zhang, Chen 
> Cc: qemu-devel ; Li Zhijian
> ; Jason Wang 
> Subject: Re: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp packet
> 
> Hi,
> This hasn't been merged yet.
> 
> Regards,
> Lukas Straub
> 
> On Mon, 16 Nov 2020 07:32:22 +
> "Zhang, Chen"  wrote:
> 
> > Queued this series to COLO tree.
> >
> > Thanks
> > Chen
> >
> > > -Original Message-
> > > From: Lukas Straub 
> > > Sent: Sunday, November 15, 2020 7:19 PM
> > > To: qemu-devel 
> > > Cc: Zhang, Chen ; Li Zhijian
> > > ; Jason Wang 
> > > Subject: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp
> > > packet
> > >
> > > Hello Everyone,
> > > This fixes a memory leak for non-tcp packets and optimizes the
> > > removal from the queue.
> > >
> > > Lukas Straub (2):
> > >   net/colo-compare.c: Fix memory leak for non-tcp packet
> > >   net/colo-compare.c: Optimize removal of secondary packet
> > >
> > >  net/colo-compare.c | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > --
> > > 2.20.1
> 
> 
> 
> --




Re: Serious doubts about Gitlab CI

2021-03-17 Thread Bin Meng
On Thu, Mar 18, 2021 at 4:32 AM Philippe Mathieu-Daudé  wrote:
>
> Hi,
>
> For some (unclear) reason I got my free tier Gitlab account renewed and
> lost the privilege for users opening account before the quota limit.
>
> I pushed a single branch to my namespace repo to trigger a pipeline.
> 1h later I was surprised to see the pipeline was stuck, having completed
> 99 jobs of 119. Looking closer there is a red comment on top of the
> pipeline:
>
>  philmd has exceeded its pipeline minutes quota. Unless you buy
>  additional pipeline minutes, no new jobs or pipelines in its projects
>  will run. [Buy more Pipelines minutes]
>
> So I exhausted my 400 monthly minutes credit.
>
> From this FAQ:
> https://about.gitlab.com/pricing/faq-consumption-cicd/#managing-your-cicd-minutes-usage
>
> Q. What happens if I hit the CI/CD Minutes allotted limit and forget to
> purchase additional CI/CD Minutes?
>
> A. You will not be able to run new jobs until you purchase additional
> CI/CD Minutes, or until the next month when you receive your monthly
> allotted CI/CD Minutes.
>
> Q. Will I be notified before I hit my limit on CI/CD Minutes?
>
> A. You will receive notification banners in-app when your group has less
> than 30%, 5% or exceeded your total allotted CI/CD minutes.
>
> I indeed received 3 warnings in 7 minutes.
>
> Now I'm having serious doubts about Gitlab usefulness for the QEMU
> community...
>
> Some screenshots FWIW:
>
> https://pasteboard.co/JT51wGR.png
> https://pasteboard.co/JT51Rqq.png

This snapshot shows that 2278 / 400 minutes (569%) were used. Strange?

> https://pasteboard.co/JT52fNL.png

I checked my gitlab settings, and it shows 0 / 400 minutes. However I
am pretty sure I have been using gitlab CI this month several times.

Regards,
Bin



Re: [PATCH v1 1/5] target/riscv: Convert the RISC-V exceptions to an enum

2021-03-17 Thread Bin Meng
On Thu, Mar 18, 2021 at 1:41 AM Alistair Francis
 wrote:
>
> Signed-off-by: Alistair Francis 
> ---
>  target/riscv/cpu_bits.h   | 44 ---
>  target/riscv/cpu.c|  2 +-
>  target/riscv/cpu_helper.c |  4 ++--
>  3 files changed, 26 insertions(+), 24 deletions(-)
>
> diff --git a/target/riscv/cpu_bits.h b/target/riscv/cpu_bits.h
> index caf4599207..8ae404c32a 100644
> --- a/target/riscv/cpu_bits.h
> +++ b/target/riscv/cpu_bits.h
> @@ -527,27 +527,29 @@
>  #define DEFAULT_RSTVEC  0x1000
>
>  /* Exception causes */
> -#define EXCP_NONE-1 /* sentinel value */
> -#define RISCV_EXCP_INST_ADDR_MIS 0x0
> -#define RISCV_EXCP_INST_ACCESS_FAULT 0x1
> -#define RISCV_EXCP_ILLEGAL_INST  0x2
> -#define RISCV_EXCP_BREAKPOINT0x3
> -#define RISCV_EXCP_LOAD_ADDR_MIS 0x4
> -#define RISCV_EXCP_LOAD_ACCESS_FAULT 0x5
> -#define RISCV_EXCP_STORE_AMO_ADDR_MIS0x6
> -#define RISCV_EXCP_STORE_AMO_ACCESS_FAULT0x7
> -#define RISCV_EXCP_U_ECALL   0x8
> -#define RISCV_EXCP_S_ECALL  0x9
> -#define RISCV_EXCP_VS_ECALL  0xa
> -#define RISCV_EXCP_M_ECALL   0xb
> -#define RISCV_EXCP_INST_PAGE_FAULT   0xc /* since: priv-1.10.0 */
> -#define RISCV_EXCP_LOAD_PAGE_FAULT   0xd /* since: priv-1.10.0 */
> -#define RISCV_EXCP_STORE_PAGE_FAULT  0xf /* since: priv-1.10.0 */
> -#define RISCV_EXCP_SEMIHOST  0x10
> -#define RISCV_EXCP_INST_GUEST_PAGE_FAULT 0x14
> -#define RISCV_EXCP_LOAD_GUEST_ACCESS_FAULT   0x15
> -#define RISCV_EXCP_VIRT_INSTRUCTION_FAULT0x16
> -#define RISCV_EXCP_STORE_GUEST_AMO_ACCESS_FAULT  0x17
> +typedef enum RiscVException {

nits: looking at other places in the RISC-V codes, I believe it's
better to name it "RISCVException"

> +RISCV_EXCP_NONE = -1, /* sentinel value */
> +RISCV_EXCP_INST_ADDR_MIS = 0x0,
> +RISCV_EXCP_INST_ACCESS_FAULT = 0x1,
> +RISCV_EXCP_ILLEGAL_INST = 0x2,
> +RISCV_EXCP_BREAKPOINT = 0x3,
> +RISCV_EXCP_LOAD_ADDR_MIS = 0x4,
> +RISCV_EXCP_LOAD_ACCESS_FAULT = 0x5,
> +RISCV_EXCP_STORE_AMO_ADDR_MIS = 0x6,
> +RISCV_EXCP_STORE_AMO_ACCESS_FAULT = 0x7,
> +RISCV_EXCP_U_ECALL = 0x8,
> +RISCV_EXCP_S_ECALL = 0x9,
> +RISCV_EXCP_VS_ECALL = 0xa,
> +RISCV_EXCP_M_ECALL = 0xb,
> +RISCV_EXCP_INST_PAGE_FAULT = 0xc, /* since: priv-1.10.0 */
> +RISCV_EXCP_LOAD_PAGE_FAULT = 0xd, /* since: priv-1.10.0 */
> +RISCV_EXCP_STORE_PAGE_FAULT = 0xf, /* since: priv-1.10.0 */
> +RISCV_EXCP_SEMIHOST = 0x10,
> +RISCV_EXCP_INST_GUEST_PAGE_FAULT = 0x14,
> +RISCV_EXCP_LOAD_GUEST_ACCESS_FAULT = 0x15,
> +RISCV_EXCP_VIRT_INSTRUCTION_FAULT = 0x16,
> +RISCV_EXCP_STORE_GUEST_AMO_ACCESS_FAULT = 0x17,
> +} RiscVException;
>
>  #define RISCV_EXCP_INT_FLAG0x8000
>  #define RISCV_EXCP_INT_MASK0x7fff
> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> index 2a990f6253..63584b4a20 100644
> --- a/target/riscv/cpu.c
> +++ b/target/riscv/cpu.c
> @@ -357,7 +357,7 @@ static void riscv_cpu_reset(DeviceState *dev)
>  env->mcause = 0;
>  env->pc = env->resetvec;
>  #endif
> -cs->exception_index = EXCP_NONE;
> +cs->exception_index = RISCV_EXCP_NONE;
>  env->load_res = -1;
>  set_default_nan_mode(1, &env->fp_status);
>  }
> diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
> index 83a6bcfad0..af702f65b1 100644
> --- a/target/riscv/cpu_helper.c
> +++ b/target/riscv/cpu_helper.c
> @@ -72,7 +72,7 @@ static int riscv_cpu_local_irq_pending(CPURISCVState *env)
>  if (irqs) {
>  return ctz64(irqs); /* since non-zero */
>  } else {
> -return EXCP_NONE; /* indicates no pending interrupt */
> +return RISCV_EXCP_NONE; /* indicates no pending interrupt */
>  }
>  }
>  #endif
> @@ -1017,5 +1017,5 @@ void riscv_cpu_do_interrupt(CPUState *cs)
>   */
>
>  #endif
> -cs->exception_index = EXCP_NONE; /* mark handled to qemu */
> +cs->exception_index = RISCV_EXCP_NONE; /* mark handled to qemu */
>  }
> --

Otherwise,
Reviewed-by: Bin Meng 



Re: [PATCH] hw/char/pl011: Fix clock migration failure

2021-03-17 Thread Gavin Shan

Hi Drew,

On 3/17/21 11:54 PM, Andrew Jones wrote:

On Wed, Mar 17, 2021 at 11:14:56AM +, Peter Maydell wrote:

On Wed, 17 Mar 2021 at 10:59, Gavin Shan  wrote:

On 3/17/21 9:40 PM, Peter Maydell wrote:

On Wed, 17 Mar 2021 at 10:37, Gavin Shan  wrote:

On 3/17/21 8:09 PM, Peter Maydell wrote:

On Wed, 17 Mar 2021 at 04:44, Gavin Shan  wrote:


static const VMStateDescription vmstate_pl011 = {
.name = "pl011",
.version_id = 2,
.minimum_version_id = 2,
+.post_load = pl011_post_load,
.fields = (VMStateField[]) {
VMSTATE_UINT32(readbuff, PL011State),
VMSTATE_UINT32(flags, PL011State),
@@ -355,10 +355,6 @@ static const VMStateDescription vmstate_pl011 = {
VMSTATE_INT32(read_trigger, PL011State),
VMSTATE_END_OF_LIST()
},
-.subsections = (const VMStateDescription * []) {
-&vmstate_pl011_clock,
-NULL
-}
};


Doesn't dropping the subsection break migration compat ?



It's why this patch needs to be backported to stable branches.
In that way, we won't have migration compatible issue.


No, migration has to work from the existing already
shipped 5.1, 5.2, etc releases to 6.0 (assuming you use
the correct "virt-5.2" &c versioned machine type.)



Commit aac63e0e6ea3 ("hw/char/pl011: add a clock input") is merged
to v5.2.0. The migration failure happens during migration from v6.0
to v5.1 with machine type as "virt-5.1", instead of migrating from
v5.1 to v6.0. One question is if we need support backwards migration?


Upstream doesn't care about backwards migration. AIUI
RedHat as a downstream care about the backwards-migration
case in some specific situations, but I don't know if that
would include this one.


Right, we do prefer to be able to support "ping-pong" migrations. For
example, if we start a virt-5.1 machine on a 5.1 build of QEMU, and then
migrate it to a 5.2 build of QEMU, we'd like to also be able to go back
to the 5.1 build.

I agree this patch is not the right approach. I think the right approach
is to introduce a compat property and make the "new" section dependent
on it. And then update the hw_compat_* arrays. Gavin, please take a look
at "Connecting subsections to properties" of docs/devel/migration.rst.



Agree and thanks for the pointer. I will post another patch to have
something in hw_compat_5_1 to address this particular issue.


I'm also curious what the state of mach-virt's machine types are for
migration. It'd be nice to exhaustively test both forward migration of
all machine types and ping-pong migrations of all machine types. We can
then consider each issue we find (the pessimist in me suggests we'll find
more than this pl011 issue) and how/if we want to resolve them.



Yeah, I will think about it and do the testing to see if there are more
issues. Also, it'd better to be integrated to existing testing framework
as you suggested.

Thanks,
Gavin




[PATCH] hw/arm/virt: Disable pl011 clock migration if needed

2021-03-17 Thread Gavin Shan
A clock is added by commit aac63e0e6ea3 ("hw/char/pl011: add a clock
input") since v5.2.0 which corresponds to virt-5.2 machine type. It
causes backwards migration failure from upstream to downstream (v5.1.0)
when the machine type is specified with virt-5.1.

This fixes the issue by following instructions from section "Connecting
subsections to properties" in docs/devel/migration.rst. With this applied,
the PL011 clock is migrated based on the machine type.

   virt-5.2 or newer:  migration
   virt-5.1 or older:  non-migration

Cc: qemu-sta...@nongnu.org # v5.2.0+
Fixes: aac63e0e6ea3 ("hw/char/pl011: add a clock input")
Suggested-by: Andrew Jones 
Signed-off-by: Gavin Shan 
---
 hw/char/pl011.c | 9 +
 hw/core/machine.c   | 1 +
 include/hw/char/pl011.h | 1 +
 3 files changed, 11 insertions(+)

diff --git a/hw/char/pl011.c b/hw/char/pl011.c
index c5621a195f..dc85527a5f 100644
--- a/hw/char/pl011.c
+++ b/hw/char/pl011.c
@@ -322,10 +322,18 @@ static const MemoryRegionOps pl011_ops = {
 .endianness = DEVICE_NATIVE_ENDIAN,
 };
 
+static bool pl011_clock_needed(void *opaque)
+{
+PL011State *s = PL011(opaque);
+
+return s->migrate_clk;
+}
+
 static const VMStateDescription vmstate_pl011_clock = {
 .name = "pl011/clock",
 .version_id = 1,
 .minimum_version_id = 1,
+.needed = pl011_clock_needed,
 .fields = (VMStateField[]) {
 VMSTATE_CLOCK(clk, PL011State),
 VMSTATE_END_OF_LIST()
@@ -363,6 +371,7 @@ static const VMStateDescription vmstate_pl011 = {
 
 static Property pl011_properties[] = {
 DEFINE_PROP_CHR("chardev", PL011State, chr),
+DEFINE_PROP_BOOL("migrate-clk", PL011State, migrate_clk, true),
 DEFINE_PROP_END_OF_LIST(),
 };
 
diff --git a/hw/core/machine.c b/hw/core/machine.c
index 257a664ea2..9935c6ddd5 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -52,6 +52,7 @@ GlobalProperty hw_compat_5_1[] = {
 { "virtio-scsi-device", "num_queues", "1"},
 { "nvme", "use-intel-id", "on"},
 { "pvpanic", "events", "1"}, /* PVPANIC_PANICKED */
+{ "pl011", "migrate-clk", "off" },
 };
 const size_t hw_compat_5_1_len = G_N_ELEMENTS(hw_compat_5_1);
 
diff --git a/include/hw/char/pl011.h b/include/hw/char/pl011.h
index 33e5e5317b..dc2c90eedc 100644
--- a/include/hw/char/pl011.h
+++ b/include/hw/char/pl011.h
@@ -50,6 +50,7 @@ struct PL011State {
 CharBackend chr;
 qemu_irq irq[6];
 Clock *clk;
+bool migrate_clk;
 const unsigned char *id;
 };
 
-- 
2.23.0




Re: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp packet

2021-03-17 Thread Jason Wang



在 2021/3/18 上午9:22, Zhang, Chen 写道:

Sorry for the delay. Current COLO tree just merged this series,
I originally wanted to merge other COLO related patches(Lei or me) and submit 
it together to Jason.

Hi Jason, do you need me to send this series first or do you want to do it 
together?



We're in soft freeze, so if you can collect all the patches before hard 
free, that would be better.


Thanks




Thanks
Chen


-Original Message-
From: Lukas Straub 
Sent: Thursday, March 18, 2021 5:24 AM
To: Zhang, Chen 
Cc: qemu-devel ; Li Zhijian
; Jason Wang 
Subject: Re: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp packet

Hi,
This hasn't been merged yet.

Regards,
Lukas Straub

On Mon, 16 Nov 2020 07:32:22 +
"Zhang, Chen"  wrote:


Queued this series to COLO tree.

Thanks
Chen


-Original Message-
From: Lukas Straub 
Sent: Sunday, November 15, 2020 7:19 PM
To: qemu-devel 
Cc: Zhang, Chen ; Li Zhijian
; Jason Wang 
Subject: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp
packet

Hello Everyone,
This fixes a memory leak for non-tcp packets and optimizes the
removal from the queue.

Lukas Straub (2):
   net/colo-compare.c: Fix memory leak for non-tcp packet
   net/colo-compare.c: Optimize removal of secondary packet

  net/colo-compare.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

--
2.20.1



--





How to create vhdx differencing disk using qemu-img

2021-03-17 Thread qi zhou
When I create vhdx differencing disk using qemu-img, It says
 qemu-img: xxx.vhd Backing file not supported for file format 'vhdx'

The command I used is
qemu-img create -f vhdx -b test.vhdx test-snapshot.vhdx

Here is my questions
1. Is vhdx format [full] supported by qemu ?
2. If not, is there any easy way to implement differencing disk of vhdx in 
qemu-img ?
3. Is there any other tools support vhdx on linux ?


[PATCH V3 0/7] Bypass specific network traffic in COLO

2021-03-17 Thread Zhang Chen
Due to some real user scenarios don't need to monitor all traffic.
And qemu net-filter also need function to more detailed flow control.  
This series give user ability to bypass kinds of COLO network stream.

For example, windows guest user want to enable windows remote desktop
to touch guest(UDP/TCP 3389), This case use UDP and TCP mixed, and the
tcp part payload always different caused by real desktop display
data(for guest time/ mouse display).

Another case is some real user application will actively transmit information
include guest time part, primary guest send data with time 10:01.000,
At the same time secondary guest send data with time 10:01.001,
it will always trigger COLO checkpoint(live migrate) to drop guest performance.

  V3:
- Add COLO passthrough list lock.
- Add usage demo and more comments.

  V2:
- Add the n-tuple support.
- Add some qapi definitions.
- Support multi colo-compare objects.
- Support setup each rules for each objects individually.
- Clean up COLO compare definition to .h file.
- Rebase HMP command for stable tree.
- Add redundant rules check.

Zhang Chen (7):
  qapi/net.json: Add IP_PROTOCOL definition
  qapi/net.json: Add L4_Connection definition
  qapi/net: Add new QMP command for COLO passthrough
  hmp-commands: Add new HMP command for COLO passthrough
  net/colo-compare: Move data structure and define to .h file.
  net/colo-compare: Add passthrough list to CompareState
  net/net.c: Add handler for COLO passthrough connection

 hmp-commands.hx   |  26 +++
 include/monitor/hmp.h |   2 +
 monitor/hmp-cmds.c|  34 +
 net/colo-compare.c| 135 --
 net/colo-compare.h| 117 ++
 net/net.c | 163 ++
 qapi/net.json |  96 +
 7 files changed, 467 insertions(+), 106 deletions(-)

-- 
2.25.1




[PATCH V3 3/7] qapi/net: Add new QMP command for COLO passthrough

2021-03-17 Thread Zhang Chen
Since the real user scenario does not need COLO to monitor all traffic.
Add colo-passthrough-add and colo-passthrough-del to maintain
a COLO network passthrough list.

QMP demo usage:
{'execute': 'colo-passthrough-add', 'arguments': {'protocol': 'tcp', 'id': 
'comp0', 'src_ip':'10.239.48.105', 'dst_ip':'10.239.48.128', 'src_port':1234, 
'dst_port':1235}}

Signed-off-by: Zhang Chen 
---
 net/net.c | 10 ++
 qapi/net.json | 40 
 2 files changed, 50 insertions(+)

diff --git a/net/net.c b/net/net.c
index e1035f21d1..037dcc5973 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1151,6 +1151,16 @@ void qmp_netdev_del(const char *id, Error **errp)
 qemu_del_net_client(nc);
 }
 
+void qmp_colo_passthrough_add(L4_Connection *conn, Error **errp)
+{
+/* Setup passthrough connection */
+}
+
+void qmp_colo_passthrough_del(L4_Connection *conn, Error **errp)
+{
+/* Delete passthrough connection */
+}
+
 static void netfilter_print_info(Monitor *mon, NetFilterState *nf)
 {
 char *str;
diff --git a/qapi/net.json b/qapi/net.json
index b4958447f2..e0c6e1d8f3 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -770,3 +770,43 @@
 { 'struct': 'L4_Connection',
   'data': { 'protocol': 'IP_PROTOCOL', '*id': 'str', '*src_ip': 'str', 
'*dst_ip': 'str',
 '*src_port': 'int', '*dst_port': 'int' } }
+
+##
+# @colo-passthrough-add:
+#
+# Add passthrough entry according to customer's needs in COLO-compare.
+#
+# Returns: Nothing on success
+#
+# Since: 6.0
+#
+# Example:
+#
+# -> { "execute": "colo-passthrough-add",
+#  "arguments": { "protocol": "tcp", "id": "object0", "src_ip": 
"192.168.1.1",
+#  "dst_ip": "192.168.1.2", "src_port": 1234, "dst_port": 4321 } }
+# <- { "return": {} }
+#
+##
+{ 'command': 'colo-passthrough-add', 'boxed': true,
+ 'data': 'L4_Connection' }
+
+##
+# @colo-passthrough-del:
+#
+# Delete passthrough entry according to customer's needs in COLO-compare.
+#
+# Returns: Nothing on success
+#
+# Since: 6.0
+#
+# Example:
+#
+# -> { "execute": "colo-passthrough-del",
+#  "arguments": { "protocol": "tcp", "id": "object0", "src_ip": 
"192.168.1.1",
+#  "dst_ip": "192.168.1.2", "src_port": 1234, "dst_port": 4321 } }
+# <- { "return": {} }
+#
+##
+{ 'command': 'colo-passthrough-del', 'boxed': true,
+ 'data': 'L4_Connection' }
-- 
2.25.1




[PATCH V3 5/7] net/colo-compare: Move data structure and define to .h file.

2021-03-17 Thread Zhang Chen
Make other modules can reuse COLO code.

Signed-off-by: Zhang Chen 
---
 net/colo-compare.c | 106 -
 net/colo-compare.h | 106 +
 2 files changed, 106 insertions(+), 106 deletions(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index 84db4978ac..a803f8b888 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -17,44 +17,24 @@
 #include "qemu/error-report.h"
 #include "trace.h"
 #include "qapi/error.h"
-#include "net/net.h"
 #include "net/eth.h"
 #include "qom/object_interfaces.h"
 #include "qemu/iov.h"
 #include "qom/object.h"
 #include "net/queue.h"
-#include "chardev/char-fe.h"
 #include "qemu/sockets.h"
-#include "colo.h"
-#include "sysemu/iothread.h"
 #include "net/colo-compare.h"
-#include "migration/colo.h"
-#include "migration/migration.h"
 #include "util.h"
 
 #include "block/aio-wait.h"
 #include "qemu/coroutine.h"
 
-#define TYPE_COLO_COMPARE "colo-compare"
-typedef struct CompareState CompareState;
-DECLARE_INSTANCE_CHECKER(CompareState, COLO_COMPARE,
- TYPE_COLO_COMPARE)
-
 static QTAILQ_HEAD(, CompareState) net_compares =
QTAILQ_HEAD_INITIALIZER(net_compares);
 
 static NotifierList colo_compare_notifiers =
 NOTIFIER_LIST_INITIALIZER(colo_compare_notifiers);
 
-#define COMPARE_READ_LEN_MAX NET_BUFSIZE
-#define MAX_QUEUE_SIZE 1024
-
-#define COLO_COMPARE_FREE_PRIMARY 0x01
-#define COLO_COMPARE_FREE_SECONDARY   0x02
-
-#define REGULAR_PACKET_CHECK_MS 1000
-#define DEFAULT_TIME_OUT_MS 3000
-
 /* #define DEBUG_COLO_PACKETS */
 
 static QemuMutex colo_compare_mutex;
@@ -64,92 +44,6 @@ static QemuCond event_complete_cond;
 static int event_unhandled_count;
 static uint32_t max_queue_size;
 
-/*
- *  + CompareState ++
- *  |   |
- *  +---+   +---+ +---+
- *  |   conn list   + - >  conn + --- >  conn + -- > ..
- *  +---+   +---+ +---+
- *  |   | |   | |  |
- *  +---+ +---v+  +---v++---v+ +---v+
- *|primary |  |secondary|primary | |secondary
- *|packet  |  |packet  +|packet  | |packet  +
- *++  ++++ ++
- *|   | |  |
- *+---v+  +---v++---v+ +---v+
- *|primary |  |secondary|primary | |secondary
- *|packet  |  |packet  +|packet  | |packet  +
- *++  ++++ ++
- *|   | |  |
- *+---v+  +---v++---v+ +---v+
- *|primary |  |secondary|primary | |secondary
- *|packet  |  |packet  +|packet  | |packet  +
- *++  ++++ ++
- */
-
-typedef struct SendCo {
-Coroutine *co;
-struct CompareState *s;
-CharBackend *chr;
-GQueue send_list;
-bool notify_remote_frame;
-bool done;
-int ret;
-} SendCo;
-
-typedef struct SendEntry {
-uint32_t size;
-uint32_t vnet_hdr_len;
-uint8_t *buf;
-} SendEntry;
-
-struct CompareState {
-Object parent;
-
-char *pri_indev;
-char *sec_indev;
-char *outdev;
-char *notify_dev;
-CharBackend chr_pri_in;
-CharBackend chr_sec_in;
-CharBackend chr_out;
-CharBackend chr_notify_dev;
-SocketReadState pri_rs;
-SocketReadState sec_rs;
-SocketReadState notify_rs;
-SendCo out_sendco;
-SendCo notify_sendco;
-bool vnet_hdr;
-uint64_t compare_timeout;
-uint32_t expired_scan_cycle;
-
-/*
- * Record the connection that through the NIC
- * Element type: Connection
- */
-GQueue conn_list;
-/* Record the connection without repetition */
-GHashTable *connection_track_table;
-
-IOThread *iothread;
-GMainContext *worker_context;
-QEMUTimer *packet_check_timer;
-
-QEMUBH *event_bh;
-enum colo_event event;
-
-QTAILQ_ENTRY(CompareState) next;
-};
-
-typedef struct CompareClass {
-ObjectClass parent_class;
-} CompareClass;
-
-enum {
-PRIMARY_IN = 0,
-SECONDARY_IN,
-};
-
 static const char *colo_mode[] = {
 [PRIMARY_IN] = "primary",
 [SECONDARY_IN] = "secondary",
diff --git a/net/colo-compare.h b/net/colo-compare.h
index 22ddd512e2..2a9dcac0a7 100644
--- a/net/colo-compare.h
+++ b/net/colo-compare.h
@@ -17,6 +17,112 @@
 #ifndef QEMU_COLO_COMPARE_H
 #define QEMU_COLO_COMPARE_H
 
+#include "net/net.h"
+#include "chardev/char-fe.h"
+#include "migration/colo.h"
+#include "migration/migration.h"
+#include "sysemu/iothread.h"
+#include "colo.h"
+
+#define TYPE_COLO_COMPARE "colo-compare"
+typedef struct CompareState CompareState;
+DEC

[PATCH V3 1/7] qapi/net.json: Add IP_PROTOCOL definition

2021-03-17 Thread Zhang Chen
Add IP_PROTOCOL as enum include TCP,UDP, ICMP... for other QMP commands.

Signed-off-by: Zhang Chen 
---
 qapi/net.json | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/qapi/net.json b/qapi/net.json
index c31748c87f..dc4c87dc7b 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -714,3 +714,33 @@
 ##
 { 'event': 'FAILOVER_NEGOTIATED',
   'data': {'device-id': 'str'} }
+
+##
+# @IP_PROTOCOL:
+#
+# Transport layer protocol.
+#
+# Just for IPv4.
+#
+# @tcp: Transmission Control Protocol.
+#
+# @udp: User Datagram Protocol.
+#
+# @dccp: Datagram Congestion Control Protocol.
+#
+# @sctp: Stream Control Transmission Protocol.
+#
+# @udplite: Lightweight User Datagram Protocol.
+#
+# @icmp: Internet Control Message Protocol.
+#
+# @igmp: Internet Group Management Protocol.
+#
+# @ipv6: IPv6 Encapsulation.
+#
+# TODO: Need to add more transport layer protocol.
+#
+# Since: 6.0
+##
+{ 'enum': 'IP_PROTOCOL', 'data': [ 'tcp', 'udp', 'dccp', 'sctp', 'udplite',
+'icmp', 'igmp', 'ipv6' ] }
-- 
2.25.1




[PATCH V3 2/7] qapi/net.json: Add L4_Connection definition

2021-03-17 Thread Zhang Chen
Add L4_Connection struct for other QMP commands.
Except protocol field is necessary, other fields are optional.

Signed-off-by: Zhang Chen 
---
 qapi/net.json | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/qapi/net.json b/qapi/net.json
index dc4c87dc7b..b4958447f2 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -744,3 +744,29 @@
 ##
 { 'enum': 'IP_PROTOCOL', 'data': [ 'tcp', 'udp', 'dccp', 'sctp', 'udplite',
 'icmp', 'igmp', 'ipv6' ] }
+
+##
+# @L4_Connection:
+#
+# Layer 4 network connection.
+#
+# Just for IPv4.
+#
+# @protocol: Transport layer protocol like TCP/UDP...
+#
+# @id: For specific module with Qemu object ID, If there is no such part,
+#  it means global rules.
+#
+# @src_ip: Source IP.
+#
+# @dst_ip: Destination IP.
+#
+# @src_port: Source port.
+#
+# @dst_port: Destination port.
+#
+# Since: 6.0
+##
+{ 'struct': 'L4_Connection',
+  'data': { 'protocol': 'IP_PROTOCOL', '*id': 'str', '*src_ip': 'str', 
'*dst_ip': 'str',
+'*src_port': 'int', '*dst_port': 'int' } }
-- 
2.25.1




[PATCH V3 7/7] net/net.c: Add handler for COLO passthrough connection

2021-03-17 Thread Zhang Chen
Use connection protocol,src port,dst port,src ip,dst ip as the key
to bypass certain network traffic in COLO compare.

Signed-off-by: Zhang Chen 
---
 net/net.c | 153 ++
 1 file changed, 153 insertions(+)

diff --git a/net/net.c b/net/net.c
index 037dcc5973..84065ec74e 100644
--- a/net/net.c
+++ b/net/net.c
@@ -55,6 +55,8 @@
 #include "sysemu/sysemu.h"
 #include "net/filter.h"
 #include "qapi/string-output-visitor.h"
+#include "net/colo-compare.h"
+#include "qom/object_interfaces.h"
 
 /* Net bridge is currently not supported for W32. */
 #if !defined(_WIN32)
@@ -1151,14 +1153,165 @@ void qmp_netdev_del(const char *id, Error **errp)
 qemu_del_net_client(nc);
 }
 
+static CompareState *colo_passthrough_check(L4_Connection *conn, Error **errp)
+{
+Object *container;
+Object *obj;
+CompareState *s;
+
+if (!conn->id) {
+error_setg(errp, QERR_INVALID_PARAMETER_VALUE, "id",
+   "Need input colo-compare object id");
+return NULL;
+}
+
+container = object_get_objects_root();
+obj = object_resolve_path_component(container, conn->id);
+if (!obj) {
+error_setg(errp, "colo-compare '%s' not found", conn->id);
+return NULL;
+}
+
+s = COLO_COMPARE(obj);
+
+if (conn->protocol == -1) {
+error_setg(errp, "COLO pass through get wrong protocol");
+return NULL;
+}
+
+if ((conn->src_ip && !qemu_isdigit(conn->src_ip[0])) ||
+(conn->dst_ip && !qemu_isdigit(conn->dst_ip[0]))) {
+error_setg(errp, "COLO pass through get wrong IP");
+return NULL;
+}
+
+if (conn->src_port > 65536 || conn->src_port < 0 ||
+conn->dst_port > 65536 || conn->dst_port < 0) {
+error_setg(errp, "COLO pass through get wrong port");
+return NULL;
+}
+
+return s;
+}
+
+static void compare_passthrough_add(CompareState *s,
+L4_Connection *conn,
+Error **errp)
+{
+PassthroughEntry *bypass = NULL, *next = NULL, *origin = NULL;
+
+bypass = g_new0(PassthroughEntry, 1);
+
+bypass->l4_protocol = conn->protocol;
+bypass->src_port = conn->src_port;
+bypass->dst_port = conn->dst_port;
+
+if (!inet_aton(conn->src_ip, &bypass->src_ip)) {
+bypass->src_ip.s_addr = 0;
+}
+
+if (!inet_aton(conn->dst_ip, &bypass->dst_ip)) {
+bypass->dst_ip.s_addr = 0;
+}
+
+qemu_mutex_lock(&s->passthroughlist_mutex);
+if (!QLIST_EMPTY(&s->passthroughlist)) {
+QLIST_FOREACH_SAFE(origin, &s->passthroughlist, node, next) {
+if ((bypass->l4_protocol == origin->l4_protocol) &&
+(bypass->src_port == origin->src_port) &&
+(bypass->src_ip.s_addr == origin->src_ip.s_addr) &&
+(bypass->dst_ip.s_addr == origin->dst_ip.s_addr)) {
+error_setg(errp, "The pass through connection already exists");
+g_free(bypass);
+qemu_mutex_unlock(&s->passthroughlist_mutex);
+return;
+}
+}
+}
+
+QLIST_INSERT_HEAD(&s->passthroughlist, bypass, node);
+qemu_mutex_unlock(&s->passthroughlist_mutex);
+}
+
+static void compare_passthrough_del(CompareState *s,
+L4_Connection *conn,
+Error **errp)
+{
+PassthroughEntry *bypass = NULL, *next = NULL, *origin = NULL;
+
+bypass = g_new0(PassthroughEntry, 1);
+
+bypass->l4_protocol = conn->protocol;
+bypass->src_port = conn->src_port;
+bypass->dst_port = conn->dst_port;
+
+if (!inet_aton(conn->src_ip, &bypass->src_ip)) {
+bypass->src_ip.s_addr = 0;
+}
+
+if (!inet_aton(conn->dst_ip, &bypass->dst_ip)) {
+bypass->dst_ip.s_addr = 0;
+}
+
+qemu_mutex_lock(&s->passthroughlist_mutex);
+if (!QLIST_EMPTY(&s->passthroughlist)) {
+QLIST_FOREACH_SAFE(origin, &s->passthroughlist, node, next) {
+if ((bypass->l4_protocol == origin->l4_protocol) &&
+(bypass->src_port == origin->src_port) &&
+(bypass->src_ip.s_addr == origin->src_ip.s_addr) &&
+(bypass->dst_ip.s_addr == origin->dst_ip.s_addr)) {
+QLIST_REMOVE(origin, node);
+g_free(origin);
+g_free(bypass);
+qemu_mutex_unlock(&s->passthroughlist_mutex);
+return;
+}
+}
+error_setg(errp, "The pass through list can't find the connection");
+} else {
+error_setg(errp, "The pass through connection list is empty");
+}
+
+g_free(bypass);
+qemu_mutex_unlock(&s->passthroughlist_mutex);
+}
+
 void qmp_colo_passthrough_add(L4_Connection *conn, Error **errp)
 {
 /* Setup passthrough connection */
+CompareState *s;
+Error *err = NULL;
+
+s = colo_passthrough_check(conn, &err);
+if (err) {
+error

Re: [RFC v2 05/13] vhost: Route guest->host notification through shadow virtqueue

2021-03-17 Thread Jason Wang



在 2021/3/18 上午12:47, Eugenio Perez Martin 写道:

On Wed, Mar 17, 2021 at 3:05 AM Jason Wang  wrote:


在 2021/3/16 下午6:31, Eugenio Perez Martin 写道:

On Tue, Mar 16, 2021 at 8:18 AM Jason Wang  wrote:

在 2021/3/16 上午3:48, Eugenio Pérez 写道:

Shadow virtqueue notifications forwarding is disabled when vhost_dev
stops, so code flow follows usual cleanup.

Signed-off-by: Eugenio Pérez 
---
hw/virtio/vhost-shadow-virtqueue.h |   7 ++
include/hw/virtio/vhost.h  |   4 +
hw/virtio/vhost-shadow-virtqueue.c | 113 ++-
hw/virtio/vhost.c  | 143 -
4 files changed, 265 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/vhost-shadow-virtqueue.h 
b/hw/virtio/vhost-shadow-virtqueue.h
index 6cc18d6acb..c891c6510d 100644
--- a/hw/virtio/vhost-shadow-virtqueue.h
+++ b/hw/virtio/vhost-shadow-virtqueue.h
@@ -17,6 +17,13 @@

typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;

+bool vhost_shadow_vq_start(struct vhost_dev *dev,
+   unsigned idx,
+   VhostShadowVirtqueue *svq);
+void vhost_shadow_vq_stop(struct vhost_dev *dev,
+  unsigned idx,
+  VhostShadowVirtqueue *svq);
+
VhostShadowVirtqueue *vhost_shadow_vq_new(struct vhost_dev *dev, int idx);

void vhost_shadow_vq_free(VhostShadowVirtqueue *vq);
diff --git a/include/hw/virtio/vhost.h b/include/hw/virtio/vhost.h
index ac963bf23d..7ffdf9aea0 100644
--- a/include/hw/virtio/vhost.h
+++ b/include/hw/virtio/vhost.h
@@ -55,6 +55,8 @@ struct vhost_iommu {
QLIST_ENTRY(vhost_iommu) iommu_next;
};

+typedef struct VhostShadowVirtqueue VhostShadowVirtqueue;
+
typedef struct VhostDevConfigOps {
/* Vhost device config space changed callback
 */
@@ -83,7 +85,9 @@ struct vhost_dev {
uint64_t backend_cap;
bool started;
bool log_enabled;
+bool shadow_vqs_enabled;
uint64_t log_size;
+VhostShadowVirtqueue **shadow_vqs;

Any reason that you don't embed the shadow virtqueue into
vhost_virtqueue structure?


Not really, it could be relatively big and I would prefer SVQ
members/methods to remain hidden from any other part that includes
vhost.h. But it could be changed, for sure.


(Note that there's a masked_notifier in struct vhost_virtqueue).


They are used differently: in SVQ the masked notifier is a pointer,
and if it's NULL the SVQ code knows that device is not masked. The
vhost_virtqueue is the real owner.


Yes, but it's an example for embedding auxciliary data structures in the
vhost_virtqueue.



It could be replaced by a boolean in SVQ or something like that, I
experimented with a tri-state too (UNMASKED, MASKED, MASKED_NOTIFIED)
and let vhost.c code to manage all the transitions. But I find clearer
the pointer use, since it's the more natural for the
vhost_virtqueue_mask, vhost_virtqueue_pending existing functions.

This masking/unmasking is the part I dislike the most from this
series, so I'm very open to alternatives.


See below. I think we don't even need to care about that.



Error *migration_blocker;
const VhostOps *vhost_ops;
void *opaque;
diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
b/hw/virtio/vhost-shadow-virtqueue.c
index 4512e5b058..3e43399e9c 100644
--- a/hw/virtio/vhost-shadow-virtqueue.c
+++ b/hw/virtio/vhost-shadow-virtqueue.c
@@ -8,9 +8,12 @@
 */

#include "hw/virtio/vhost-shadow-virtqueue.h"
+#include "hw/virtio/vhost.h"
+
+#include "standard-headers/linux/vhost_types.h"

#include "qemu/error-report.h"
-#include "qemu/event_notifier.h"
+#include "qemu/main-loop.h"

/* Shadow virtqueue to relay notifications */
typedef struct VhostShadowVirtqueue {
@@ -18,14 +21,121 @@ typedef struct VhostShadowVirtqueue {
EventNotifier kick_notifier;
/* Shadow call notifier, sent to vhost */
EventNotifier call_notifier;
+
+/*
+ * Borrowed virtqueue's guest to host notifier.
+ * To borrow it in this event notifier allows to register on the event
+ * loop and access the associated shadow virtqueue easily. If we use the
+ * VirtQueue, we don't have an easy way to retrieve it.

So this is something that worries me. It looks like a layer violation
that makes the codes harder to work correctly.


I don't follow you here.

The vhost code already depends on virtqueue in the same sense:
virtio_queue_get_host_notifier is called on vhost_virtqueue_start. So
if this behavior ever changes it is unlikely for vhost to keep working
without changes. vhost_virtqueue has a kick/call int where I think it
should be stored actually, but they are never used as far as I see.

Previous RFC did rely on vhost_dev_disable_notifiers. From its documentation:
/* Stop processing guest IO notifications in vhost.
   * Start processing them in qemu.
   ...
But it was easier for this mode to miss a notification, since they
create a new host_notifier in vir

[PATCH V3 4/7] hmp-commands: Add new HMP command for COLO passthrough

2021-03-17 Thread Zhang Chen
Add hmp_colo_passthrough_add and hmp_colo_passthrough_del make user
can maintain COLO network passthrough list in human monitor.

Signed-off-by: Zhang Chen 
---
 hmp-commands.hx   | 26 ++
 include/monitor/hmp.h |  2 ++
 monitor/hmp-cmds.c| 34 ++
 3 files changed, 62 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index 73e0832ea1..c71521303c 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1341,6 +1341,32 @@ SRST
   Remove host network device.
 ERST
 
+{
+.name   = "colo_passthrough_add",
+.args_type  = 
"protocol:s,id:s?,src_ip:s?,dst_ip:s?,src_port:i?,dst_port:i?",
+.params = "protocol [id] [src_ip] [dst_ip] [src_port] [dst_port]",
+.help   = "Add network stream to colo passthrough list",
+.cmd= hmp_colo_passthrough_add,
+},
+
+SRST
+``colo_passthrough_add``
+  Add network stream to colo passthrough list.
+ERST
+
+{
+.name   = "colo_passthrough_del",
+.args_type  = 
"protocol:s,id:s?,src_ip:s?,dst_ip:s?,src_port:i?,dst_port:i?",
+.params = "protocol [id] [src_ip] [dst_ip] [src_port] [dst_port]",
+.help   = "Delete network stream from colo passthrough list",
+.cmd= hmp_colo_passthrough_del,
+},
+
+SRST
+``colo_passthrough_del``
+  Delete network stream from colo passthrough list.
+ERST
+
 {
 .name   = "object_add",
 .args_type  = "object:O",
diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
index ed2913fd18..3c4943b09f 100644
--- a/include/monitor/hmp.h
+++ b/include/monitor/hmp.h
@@ -81,6 +81,8 @@ void hmp_device_del(Monitor *mon, const QDict *qdict);
 void hmp_dump_guest_memory(Monitor *mon, const QDict *qdict);
 void hmp_netdev_add(Monitor *mon, const QDict *qdict);
 void hmp_netdev_del(Monitor *mon, const QDict *qdict);
+void hmp_colo_passthrough_add(Monitor *mon, const QDict *qdict);
+void hmp_colo_passthrough_del(Monitor *mon, const QDict *qdict);
 void hmp_getfd(Monitor *mon, const QDict *qdict);
 void hmp_closefd(Monitor *mon, const QDict *qdict);
 void hmp_sendkey(Monitor *mon, const QDict *qdict);
diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
index fd4d77e246..de675d16e7 100644
--- a/monitor/hmp-cmds.c
+++ b/monitor/hmp-cmds.c
@@ -1660,6 +1660,40 @@ void hmp_netdev_del(Monitor *mon, const QDict *qdict)
 hmp_handle_error(mon, err);
 }
 
+void hmp_colo_passthrough_add(Monitor *mon, const QDict *qdict)
+{
+const char *prot = qdict_get_str(qdict, "protocol");
+L4_Connection *l4_conn = g_new0(L4_Connection, 1);
+Error *err = NULL;
+
+l4_conn->id = g_strdup(qdict_get_try_str(qdict, "id"));
+l4_conn->protocol = qapi_enum_parse(&IP_PROTOCOL_lookup, prot, -1, &err);
+l4_conn->src_ip = g_strdup(qdict_get_try_str(qdict, "src_ip"));
+l4_conn->dst_ip = g_strdup(qdict_get_try_str(qdict, "dst_ip"));
+l4_conn->src_port = qdict_get_try_int(qdict, "src_port", 0);
+l4_conn->dst_port = qdict_get_try_int(qdict, "dst_port", 0);
+
+qmp_colo_passthrough_add(l4_conn, &err);
+hmp_handle_error(mon, err);
+}
+
+void hmp_colo_passthrough_del(Monitor *mon, const QDict *qdict)
+{
+const char *prot = qdict_get_str(qdict, "protocol");
+L4_Connection *l4_conn = g_new0(L4_Connection, 1);
+Error *err = NULL;
+
+l4_conn->id = g_strdup(qdict_get_try_str(qdict, "id"));
+l4_conn->protocol = qapi_enum_parse(&IP_PROTOCOL_lookup, prot, -1, &err);
+l4_conn->src_ip = g_strdup(qdict_get_try_str(qdict, "src_ip"));
+l4_conn->dst_ip = g_strdup(qdict_get_try_str(qdict, "dst_ip"));
+l4_conn->src_port = qdict_get_try_int(qdict, "src_port", 0);
+l4_conn->dst_port = qdict_get_try_int(qdict, "dst_port", 0);
+
+qmp_colo_passthrough_del(l4_conn, &err);
+hmp_handle_error(mon, err);
+}
+
 void hmp_object_add(Monitor *mon, const QDict *qdict)
 {
 Error *err = NULL;
-- 
2.25.1




[PATCH V3 6/7] net/colo-compare: Add passthrough list to CompareState

2021-03-17 Thread Zhang Chen
Add passthrough list for each CompareState.

Signed-off-by: Zhang Chen 
---
 net/colo-compare.c | 29 +
 net/colo-compare.h | 11 +++
 2 files changed, 40 insertions(+)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index a803f8b888..40af8cd501 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -141,6 +141,7 @@ static int packet_enqueue(CompareState *s, int mode, 
Connection **con)
 ConnectionKey key;
 Packet *pkt = NULL;
 Connection *conn;
+PassthroughEntry *bypass, *next;
 int ret;
 
 if (mode == PRIMARY_IN) {
@@ -160,6 +161,32 @@ static int packet_enqueue(CompareState *s, int mode, 
Connection **con)
 }
 fill_connection_key(pkt, &key);
 
+/* Check COLO passthrough connenction */
+qemu_mutex_lock(&s->passthroughlist_mutex);
+if (!QLIST_EMPTY(&s->passthroughlist)) {
+QLIST_FOREACH_SAFE(bypass, &s->passthroughlist, node, next) {
+if (((key.ip_proto == IPPROTO_TCP) && (bypass->l4_protocol == 0)) 
||
+((key.ip_proto == IPPROTO_UDP) && (bypass->l4_protocol == 1))) 
{
+if (bypass->src_port == 0 || bypass->src_port == key.dst_port) 
{
+if (bypass->src_ip.s_addr == 0 ||
+bypass->src_ip.s_addr == key.src.s_addr) {
+if (bypass->dst_port == 0 ||
+bypass->dst_port == key.src_port) {
+if (bypass->dst_ip.s_addr == 0 ||
+bypass->dst_ip.s_addr == key.dst.s_addr) {
+packet_destroy(pkt, NULL);
+pkt = NULL;
+qemu_mutex_unlock(&s->passthroughlist_mutex);
+return -1;
+}
+}
+}
+}
+}
+}
+}
+qemu_mutex_unlock(&s->passthroughlist_mutex);
+
 conn = connection_get(s->connection_track_table,
   &key,
   &s->conn_list);
@@ -1224,6 +1251,7 @@ static void colo_compare_complete(UserCreatable *uc, 
Error **errp)
 }
 
 g_queue_init(&s->conn_list);
+QLIST_INIT(&s->passthroughlist);
 
 s->connection_track_table = g_hash_table_new_full(connection_key_hash,
   connection_key_equal,
@@ -1236,6 +1264,7 @@ static void colo_compare_complete(UserCreatable *uc, 
Error **errp)
 if (!colo_compare_active) {
 qemu_mutex_init(&event_mtx);
 qemu_cond_init(&event_complete_cond);
+qemu_mutex_init(&s->passthroughlist_mutex);
 colo_compare_active = true;
 }
 QTAILQ_INSERT_TAIL(&net_compares, s, next);
diff --git a/net/colo-compare.h b/net/colo-compare.h
index 2a9dcac0a7..2259abcd63 100644
--- a/net/colo-compare.h
+++ b/net/colo-compare.h
@@ -54,6 +54,15 @@ typedef struct SendEntry {
 uint8_t *buf;
 } SendEntry;
 
+typedef struct PassthroughEntry {
+int l4_protocol;
+int src_port;
+int dst_port;
+struct in_addr src_ip;
+struct in_addr dst_ip;
+QLIST_ENTRY(PassthroughEntry) node;
+} PassthroughEntry;
+
 /*
  *  + CompareState ++
  *  |   |
@@ -110,6 +119,8 @@ struct CompareState {
 
 QEMUBH *event_bh;
 enum colo_event event;
+QLIST_HEAD(, PassthroughEntry) passthroughlist;
+QemuMutex passthroughlist_mutex;
 
 QTAILQ_ENTRY(CompareState) next;
 };
-- 
2.25.1




Re: [RFC v2 11/13] vhost: Shadow virtqueue buffers forwarding

2021-03-17 Thread Jason Wang



在 2021/3/17 下午10:38, Eugenio Perez Martin 写道:

On Wed, Mar 17, 2021 at 3:51 AM Jason Wang  wrote:


在 2021/3/17 上午12:05, Eugenio Perez Martin 写道:

On Tue, Mar 16, 2021 at 9:15 AM Jason Wang  wrote:

在 2021/3/16 上午3:48, Eugenio Pérez 写道:

Initial version of shadow virtqueue that actually forward buffers.

It reuses the VirtQueue code for the device part. The driver part is
based on Linux's virtio_ring driver, but with stripped functionality
and optimizations so it's easier to review.

These will be added in later commits.

Signed-off-by: Eugenio Pérez 
---
hw/virtio/vhost-shadow-virtqueue.c | 212 +++--
hw/virtio/vhost.c  | 113 ++-
2 files changed, 312 insertions(+), 13 deletions(-)

diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
b/hw/virtio/vhost-shadow-virtqueue.c
index 1460d1d5d1..68ed0f2740 100644
--- a/hw/virtio/vhost-shadow-virtqueue.c
+++ b/hw/virtio/vhost-shadow-virtqueue.c
@@ -9,6 +9,7 @@

#include "hw/virtio/vhost-shadow-virtqueue.h"
#include "hw/virtio/vhost.h"
+#include "hw/virtio/virtio-access.h"

#include "standard-headers/linux/vhost_types.h"

@@ -55,11 +56,96 @@ typedef struct VhostShadowVirtqueue {
/* Virtio device */
VirtIODevice *vdev;

+/* Map for returning guest's descriptors */
+VirtQueueElement **ring_id_maps;
+
+/* Next head to expose to device */
+uint16_t avail_idx_shadow;
+
+/* Next free descriptor */
+uint16_t free_head;
+
+/* Last seen used idx */
+uint16_t shadow_used_idx;
+
+/* Next head to consume from device */
+uint16_t used_idx;
+
/* Descriptors copied from guest */
vring_desc_t descs[];
} VhostShadowVirtqueue;

-/* Forward guest notifications */
+static void vhost_vring_write_descs(VhostShadowVirtqueue *svq,
+const struct iovec *iovec,
+size_t num, bool more_descs, bool write)
+{
+uint16_t i = svq->free_head, last = svq->free_head;
+unsigned n;
+uint16_t flags = write ? virtio_tswap16(svq->vdev, VRING_DESC_F_WRITE) : 0;
+vring_desc_t *descs = svq->vring.desc;
+
+if (num == 0) {
+return;
+}
+
+for (n = 0; n < num; n++) {
+if (more_descs || (n + 1 < num)) {
+descs[i].flags = flags | virtio_tswap16(svq->vdev,
+VRING_DESC_F_NEXT);
+} else {
+descs[i].flags = flags;
+}
+descs[i].addr = virtio_tswap64(svq->vdev, (hwaddr)iovec[n].iov_base);

So unsing virtio_tswap() is probably not correct since we're talking
with vhost backends which has its own endiness.


I was trying to expose the buffer with the same endianness as the
driver originally offered, so if guest->qemu requires a bswap, I think
it will always require a bswap again to expose to the device again.


So assumes vhost-vDPA always provide a non-transitional device[1].

Then if Qemu present a transitional device, we need to do the endian
conversion when necessary, if Qemu present a non-transitional device, we
don't need to do that, guest driver will do that for us.

But it looks to me the virtio_tswap() can't be used for this since it:

static inline bool virtio_access_is_big_endian(VirtIODevice *vdev)
{
#if defined(LEGACY_VIRTIO_IS_BIENDIAN)
  return virtio_is_big_endian(vdev);
#elif defined(TARGET_WORDS_BIGENDIAN)
  if (virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
  /* Devices conforming to VIRTIO 1.0 or later are always LE. */
  return false;
  }
  return true;
#else
  return false;
#endif
}

So if we present a legacy device on top of a non-transitiaonl vDPA
device. The VIRITIO_F_VERSION_1 check is wrong.



For vhost-vDPA, we can assume that it's a 1.0 device.

Isn't it needed if the host is big endian?


[1]

So non-transitional device always assume little endian.

For vhost-vDPA, we don't want to present transitional device which may
end up with a lot of burdens.

I suspect the legacy driver plust vhost vDPA already break, so I plan to
mandate VERSION_1 for all vDPA devices.


Right. I think it's the best then.

However, then we will need a similar method to always expose
address/length as little endian, isn't it?



Yes.





+descs[i].len = virtio_tswap32(svq->vdev, iovec[n].iov_len);
+
+last = i;
+i = virtio_tswap16(svq->vdev, descs[i].next);
+}
+
+svq->free_head = virtio_tswap16(svq->vdev, descs[last].next);
+}
+
+static unsigned vhost_shadow_vq_add_split(VhostShadowVirtqueue *svq,
+  VirtQueueElement *elem)
+{
+int head;
+unsigned avail_idx;
+vring_avail_t *avail = svq->vring.avail;
+
+head = svq->free_head;
+
+/* We need some descriptors here */
+assert(elem->out_num || elem->in_num);
+
+vhost_vring_write_descs(svq, elem->out_sg, elem->out_num,
+elem->in_num > 0, false);
+   

RE: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp packet

2021-03-17 Thread Zhang, Chen



> -Original Message-
> From: Jason Wang 
> Sent: Thursday, March 18, 2021 10:41 AM
> To: Zhang, Chen ; Lukas Straub
> 
> Cc: qemu-devel ; Li Zhijian
> 
> Subject: Re: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp packet
> 
> 
> 在 2021/3/18 上午9:22, Zhang, Chen 写道:
> > Sorry for the delay. Current COLO tree just merged this series, I
> > originally wanted to merge other COLO related patches(Lei or me) and
> submit it together to Jason.
> >
> > Hi Jason, do you need me to send this series first or do you want to do it
> together?
> 
> 
> We're in soft freeze, so if you can collect all the patches before hard free,
> that would be better.
> 

OK, I will send this series first.

Thanks
Chen

> Thanks
> 
> 
> >
> > Thanks
> > Chen
> >
> >> -Original Message-
> >> From: Lukas Straub 
> >> Sent: Thursday, March 18, 2021 5:24 AM
> >> To: Zhang, Chen 
> >> Cc: qemu-devel ; Li Zhijian
> >> ; Jason Wang 
> >> Subject: Re: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp
> >> packet
> >>
> >> Hi,
> >> This hasn't been merged yet.
> >>
> >> Regards,
> >> Lukas Straub
> >>
> >> On Mon, 16 Nov 2020 07:32:22 +
> >> "Zhang, Chen"  wrote:
> >>
> >>> Queued this series to COLO tree.
> >>>
> >>> Thanks
> >>> Chen
> >>>
>  -Original Message-
>  From: Lukas Straub 
>  Sent: Sunday, November 15, 2020 7:19 PM
>  To: qemu-devel 
>  Cc: Zhang, Chen ; Li Zhijian
>  ; Jason Wang 
>  Subject: [PATCH 0/2] colo-compare: Fix memory leak for non-tcp
>  packet
> 
>  Hello Everyone,
>  This fixes a memory leak for non-tcp packets and optimizes the
>  removal from the queue.
> 
>  Lukas Straub (2):
> net/colo-compare.c: Fix memory leak for non-tcp packet
> net/colo-compare.c: Optimize removal of secondary packet
> 
>    net/colo-compare.c | 3 ++-
>    1 file changed, 2 insertions(+), 1 deletion(-)
> 
>  --
>  2.20.1
> >>
> >>
> >> --




[PATCH v2] net/macos: implement vmnet-based netdev

2021-03-17 Thread Akihiko Odaki
From: Phillip Tennen 

This patch implements a new netdev device, reachable via -netdev
vmnet-macos, that’s backed by macOS’s vmnet framework.

The vmnet framework provides native bridging support, and its usage in
this patch is intended as a replacement for attempts to use a tap device
via the tuntaposx kernel extension. Notably, the tap/tuntaposx approach
never would have worked in the first place, as QEMU interacts with the
tap device via poll(), and macOS does not support polling device files.

vmnet requires either a special entitlement, granted via a provisioning
profile, or root access. Otherwise attempts to create the virtual
interface will fail with a “generic error” status code. QEMU may not
currently be signed with an entitlement granted in a provisioning
profile, as this would necessitate pre-signed binary build distribution,
rather than source-code distribution. As such, using this netdev
currently requires that qemu be run with root access. I’ve opened a
feedback report with Apple to allow the use of the relevant entitlement
with this use case:
https://openradar.appspot.com/radar?id=5007417364447232

vmnet offers three operating modes, all of which are supported by this
patch via the “mode=host|shared|bridge” option:

* "Host" mode: Allows the vmnet interface to communicate with other
* vmnet
interfaces that are in host mode and also with the native host.
* "Shared" mode: Allows traffic originating from the vmnet interface to
reach the Internet through a NAT. The vmnet interface can also
communicate with the native host.
* "Bridged" mode: Bridges the vmnet interface with a physical network
interface.

Each of these modes also provide some extra configuration that’s
supported by this patch:

* "Bridged" mode: The user may specify the physical interface to bridge
with. Defaults to en0.
* "Host" mode / "Shared" mode: The user may specify the DHCP range and
subnet. Allocated by vmnet if not provided.

vmnet also offers some extra configuration options that are not
supported by this patch:

* Enable isolation from other VMs using vmnet
* Port forwarding rules
* Enabling TCP segmentation offload
* Only applicable in "shared" mode: specifying the NAT IPv6 prefix
* Only available in "host" mode: specifying the IP address for the VM
within an isolated network

Note that this patch requires macOS 10.15 as a minimum, as this is when
bridging support was implemented in vmnet.framework.

Rebased to commit 571d413b5da6bc6f1c2aaca8484717642255ddb0 by Akihiko
Odaki.

Signed-off-by: Phillip Tennen 
Signed-off-by: Akihiko Odaki 
---
 meson.build   |   3 +
 net/clients.h |   5 +
 net/meson.build   |   1 +
 net/net.c |   3 +
 net/vmnet-macos.c | 446 ++
 qapi/net.json | 120 -
 qemu-options.hx   |   9 +
 7 files changed, 585 insertions(+), 2 deletions(-)
 create mode 100644 net/vmnet-macos.c

diff --git a/meson.build b/meson.build
index 8b51b51c973..fb0cebce753 100644
--- a/meson.build
+++ b/meson.build
@@ -178,6 +178,7 @@ socket = []
 version_res = []
 coref = []
 iokit = []
+vmnet = not_found
 emulator_link_args = []
 hvf = not_found
 if targetos == 'windows'
@@ -191,6 +192,7 @@ if targetos == 'windows'
 elif targetos == 'darwin'
   coref = dependency('appleframeworks', modules: 'CoreFoundation')
   iokit = dependency('appleframeworks', modules: 'IOKit')
+  vmnet = dependency('appleframeworks', modules: 'vmnet')
 elif targetos == 'sunos'
   socket = [cc.find_library('socket'),
 cc.find_library('nsl'),
@@ -1147,6 +1149,7 @@ config_host_data.set('CONFIG_FUSE', fuse.found())
 config_host_data.set('CONFIG_FUSE_LSEEK', fuse_lseek.found())
 config_host_data.set('CONFIG_X11', x11.found())
 config_host_data.set('CONFIG_CFI', get_option('cfi'))
+config_host_data.set('CONFIG_VMNET', vmnet.found())
 config_host_data.set('QEMU_VERSION', '"@0@"'.format(meson.project_version()))
 config_host_data.set('QEMU_VERSION_MAJOR', 
meson.project_version().split('.')[0])
 config_host_data.set('QEMU_VERSION_MINOR', 
meson.project_version().split('.')[1])
diff --git a/net/clients.h b/net/clients.h
index 92f9b59aedc..2c2af67f82a 100644
--- a/net/clients.h
+++ b/net/clients.h
@@ -63,4 +63,9 @@ int net_init_vhost_user(const Netdev *netdev, const char 
*name,
 
 int net_init_vhost_vdpa(const Netdev *netdev, const char *name,
 NetClientState *peer, Error **errp);
+
+#ifdef CONFIG_VMNET
+int net_init_vmnet_macos(const Netdev *netdev, const char *name,
+NetClientState *peer, Error **errp);
+#endif
 #endif /* QEMU_NET_CLIENTS_H */
diff --git a/net/meson.build b/net/meson.build
index 1076b0a7ab4..ba6a5b7fa0b 100644
--- a/net/meson.build
+++ b/net/meson.build
@@ -37,5 +37,6 @@ endif
 softmmu_ss.add(when: 'CONFIG_POSIX', if_true: files(tap_posix))
 softmmu_ss.add(when: 'CONFIG_WIN32', if_true: files('tap-win32.c'))
 softmmu_ss.add(when: 'CONFIG_VHOST_NET_VDPA', if_true: files('vhost-vdpa.c'))
+softmmu_ss.add(when: 

RE: [PATCH v8 17/35] Hexagon (target/hexagon/fma_emu.[ch]) utility functions

2021-03-17 Thread Taylor Simpson


> -Original Message-
> From: Richard Henderson 
> Sent: Sunday, February 14, 2021 5:15 PM
> To: Taylor Simpson ; qemu-devel@nongnu.org
> Cc: phi...@redhat.com; alex.ben...@linaro.org; laur...@vivier.eu;
> a...@rev.ng; Brian Cain 
> Subject: Re: [PATCH v8 17/35] Hexagon (target/hexagon/fma_emu.[ch])
> utility functions
>
> On 2/7/21 9:46 PM, Taylor Simpson wrote:
>
> Redundant with softfloat.  Is the default nan really -1?  I suppose then that
> hexagon does not distinguish QNaN from SNaN?
>
> You'll want to patch fpu/softfloat-specialize.c.inc for both of these choices:
> no_signaling_nans and parts_default_nan.

Yes, the default is really -1.  We do distinguish SNaN - when a SNaN is fed to 
an arithmetic operation, it raises the invalid flag and a QNaN is returned.

So, it looks like I'll need to patch parts_default_nan and parts_silence_nan as 
well as set default_nan_mode to 1.


> This is duplicating code from include/fpu/softfloat-macros.h, except for the
> wrapping to Int128.  That said, I don't think you should actually need this,
> or, frankly, the vast majority of the rest of your fp code.

OK, I will look into this.


Thanks,
Taylor


RE: [PATCH v8 16/35] Hexagon (target/hexagon/conv_emu.[ch]) utility functions

2021-03-17 Thread Taylor Simpson


> -Original Message-
> From: Richard Henderson 
> Sent: Sunday, February 14, 2021 2:57 PM
> To: Taylor Simpson ; qemu-devel@nongnu.org
> Cc: phi...@redhat.com; alex.ben...@linaro.org; laur...@vivier.eu;
> a...@rev.ng; Brian Cain 
> Subject: Re: [PATCH v8 16/35] Hexagon (target/hexagon/conv_emu.[ch])
> utility functions
>
> On 2/7/21 9:46 PM, Taylor Simpson wrote:
> > +uint64_t conv_sf_to_8u(float32 in, float_status *fp_status);
> > +uint32_t conv_sf_to_4u(float32 in, float_status *fp_status);
> > +int64_t conv_sf_to_8s(float32 in, float_status *fp_status);
> > +int32_t conv_sf_to_4s(float32 in, float_status *fp_status);
> > +
> > +uint64_t conv_df_to_8u(float64 in, float_status *fp_status);
> > +uint32_t conv_df_to_4u(float64 in, float_status *fp_status);
> > +int64_t conv_df_to_8s(float64 in, float_status *fp_status);
> > +int32_t conv_df_to_4s(float64 in, float_status *fp_status);
>
> You need to either use the normal float conversion routines, or document
> what the differences are.

There are some differences in floating point flags raised, so I could write 
something like this:
if (float32_is_infinity(RsV)) {
float_raise(float_flag_invalid, &env->fp_status);
if (float32_is_neg(RsV)) {
RddV = 0ULL;
} else {
RddV = ~0ULL;
}
} else if (float32_is_any_nan(RsV)) {
float_raise(float_flag_invalid, &env->fp_status);
RddV = ~0ULL;
} else if (float32_is_zero(RsV)) {
RddV = 0;
} else if (float32_is_neg(RsV)) {
float_raise(float_flag_invalid, &env->fp_status);
RddV = 0;
} else {
RddV = float32_to_uint64_round_to_zero(RsV, &env->fp_status);
}

Does that work?


Thanks,
Taylor


RE: [PATCH v8 15/35] Hexagon (target/hexagon/arch.[ch]) utility functions

2021-03-17 Thread Taylor Simpson


> -Original Message-
> From: Richard Henderson 
> Sent: Sunday, February 14, 2021 2:13 PM
> To: Taylor Simpson ; qemu-devel@nongnu.org
> Cc: phi...@redhat.com; alex.ben...@linaro.org; laur...@vivier.eu;
> a...@rev.ng; Brian Cain 
> Subject: Re: [PATCH v8 15/35] Hexagon (target/hexagon/arch.[ch]) utility
> functions
>
> On 2/7/21 9:46 PM, Taylor Simpson wrote:
> > +uint32_t carry_from_add64(uint64_t a, uint64_t b, uint32_t c)
> > +{
> > +uint64_t tmpa, tmpb, tmpc;
> > +tmpa = fGETUWORD(0, a);
> > +tmpb = fGETUWORD(0, b);
> > +tmpc = tmpa + tmpb + c;
> > +tmpa = fGETUWORD(1, a);
> > +tmpb = fGETUWORD(1, b);
> > +tmpc = tmpa + tmpb + fGETUWORD(1, tmpc);
> > +tmpc = fGETUWORD(1, tmpc);
> > +return tmpc;
> > +}
>
> I presume this is intended to compute carry-out from 64-bit addition with
> carry-in?
>
> uint64_t r = a + b;
> return c ? r <= a : r < a;

Actually, I can remove this because the instructions that use it have TCG 
overrides (i.e., there isn't a helper that references it).


>
> > +static const int softfloat_roundingmodes[] = {
>
> FloatRoundMode

OK

> > +static float32 float32_mul_pow2(float32 a, uint32_t p, float_status
> *fp_status)
> > +{
> > +float32 b = make_float32((SF_BIAS + p) << SF_MANTBITS);
> > +return float32_mul(a, b, fp_status);
> > +}
>
> This is float32_scalbn.

OK


Thanks,
Taylor


Re: [PATCH v2] net/macos: implement vmnet-based netdev

2021-03-17 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/20210318035427.13436-1-akihiko.od...@gmail.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Type: series
Message-id: 20210318035427.13436-1-akihiko.od...@gmail.com
Subject: [PATCH v2] net/macos: implement vmnet-based netdev

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag] patchew/20210318035427.13436-1-akihiko.od...@gmail.com -> 
patchew/20210318035427.13436-1-akihiko.od...@gmail.com
Switched to a new branch 'test'
c3e0507 net/macos: implement vmnet-based netdev

=== OUTPUT BEGIN ===
Use of uninitialized value $acpi_testexpected in string eq at 
./scripts/checkpatch.pl line 1529.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#144: 
new file mode 100644

ERROR: externs should be avoided in .c files
#178: FILE: net/vmnet-macos.c:30:
+int net_init_vmnet_macos(const Netdev *netdev, const char *name,

WARNING: architecture specific defines should be avoided
#203: FILE: net/vmnet-macos.c:55:
+#if __MAC_OS_X_VERSION_MAX_ALLOWED >= 11

ERROR: spaces required around that '^' (ctx:ExV)
#287: FILE: net/vmnet-macos.c:139:
+^bool(size_t index, xpc_object_t  _Nonnull value) {
 ^

ERROR: spaces required around that '^' (ctx:ExV)
#300: FILE: net/vmnet-macos.c:152:
+^bool(size_t index, xpc_object_t  _Nonnull value) {
 ^

WARNING: line over 80 characters
#385: FILE: net/vmnet-macos.c:237:
+xpc_object_t iface_desc = 
_construct_vmnet_interface_description(vmnet_opts);

ERROR: spaces required around that '^' (ctx:ExV)
#419: FILE: net/vmnet-macos.c:271:
+^(vmnet_return_t status, xpc_object_t  _Nullable interface_param) {
 ^

ERROR: spaces required around that '^' (ctx:ExV)
#500: FILE: net/vmnet-macos.c:352:
+^(interface_event_t event_mask, xpc_object_t  _Nonnull event) {
 ^

WARNING: Block comments use a leading /* on a separate line
#538: FILE: net/vmnet-macos.c:390:
+/* Dispatch this block to a global queue instead of the main queue,

ERROR: spaces required around that '^' (ctx:ExV)
#545: FILE: net/vmnet-macos.c:397:
+   ^{
^

total: 6 errors, 4 warnings, 653 lines checked

Commit c3e0507f4c95 (net/macos: implement vmnet-based netdev) has style 
problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20210318035427.13436-1-akihiko.od...@gmail.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

[PULL 0/2] 2021-03-18 COLO proxy patches

2021-03-17 Thread Zhang Chen
Hi Jason, please merge this series to net queue.

Lukas Straub (2):
  net/colo-compare.c: Fix memory leak for non-tcp packet
  net/colo-compare.c: Optimize removal of secondary packet

 net/colo-compare.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.25.1




[PULL 1/2] net/colo-compare.c: Fix memory leak for non-tcp packet

2021-03-17 Thread Zhang Chen
From: Lukas Straub 

Additional to removing the packet from the secondary queue,
we also need to free it.

Signed-off-by: Lukas Straub 
Signed-off-by: Zhang Chen 
Reviewed-by: Zhang Chen 
---
 net/colo-compare.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index 84db4978ac..2e819ffedb 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -690,6 +690,7 @@ static void colo_compare_packet(CompareState *s, Connection 
*conn,
 
 if (result) {
 colo_release_primary_pkt(s, pkt);
+packet_destroy(result->data, NULL);
 g_queue_remove(&conn->secondary_list, result->data);
 } else {
 /*
-- 
2.25.1




[PULL 2/2] net/colo-compare.c: Optimize removal of secondary packet

2021-03-17 Thread Zhang Chen
From: Lukas Straub 

g_queue_remove needs to look up the list entry first, but we
already have it as result and can remove it directly with
g_queue_delete_link.

Signed-off-by: Lukas Straub 
Signed-off-by: Zhang Chen 
Reviewed-by: Zhang Chen 
---
 net/colo-compare.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/colo-compare.c b/net/colo-compare.c
index 2e819ffedb..9d1ad99941 100644
--- a/net/colo-compare.c
+++ b/net/colo-compare.c
@@ -691,7 +691,7 @@ static void colo_compare_packet(CompareState *s, Connection 
*conn,
 if (result) {
 colo_release_primary_pkt(s, pkt);
 packet_destroy(result->data, NULL);
-g_queue_remove(&conn->secondary_list, result->data);
+g_queue_delete_link(&conn->secondary_list, result);
 } else {
 /*
  * If one packet arrive late, the secondary_list or
-- 
2.25.1




Re: [PATCH 2/2] utils: Work around mingw strto*l bug with 0x

2021-03-17 Thread Thomas Huth

On 17/03/2021 15.33, Eric Blake wrote:

Mingw recognizes that "0x" has value 0 without setting errno, but
fails to advance endptr to the trailing garbage 'x'.  This in turn
showed up in our recent testsuite additions for qemu_strtosz (commit
1657ba44b4 utils: Enhance testsuite for do_strtosz()); adjust our
remaining tests to show that we now work around this windows bug.

This patch intentionally fails check-syntax for use of strtol.

Signed-off-by: Eric Blake 
---
  tests/unit/test-cutils.c | 54 
  util/cutils.c| 29 +++--
  2 files changed, 75 insertions(+), 8 deletions(-)


Reviewed-by: Thomas Huth 




Re: [PATCH] docs/devel/testing.rst: Fix referencies to unit tests

2021-03-17 Thread Thomas Huth

On 17/03/2021 20.48, Wainer dos Santos Moschetta wrote:

With the recent move of the unit tests to tests/unit directory some
instructions under the "Unit tests" section became imprecise, which
are fixed by this change.

Related-to: da668aa15b99 (tests: Move unit tests into a separate directory)
Signed-off-by: Wainer dos Santos Moschetta 
---
  docs/devel/testing.rst | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/devel/testing.rst b/docs/devel/testing.rst
index 1434a50cc4..1da4c4e4c4 100644
--- a/docs/devel/testing.rst
+++ b/docs/devel/testing.rst
@@ -34,17 +34,17 @@ If you are writing new code in QEMU, consider adding a unit 
test, especially
  for utility modules that are relatively stateless or have few dependencies. To
  add a new unit test:
  
-1. Create a new source file. For example, ``tests/foo-test.c``.

+1. Create a new source file. For example, ``tests/unit/foo-test.c``.
  
  2. Write the test. Normally you would include the header file which exports

 the module API, then verify the interface behaves as expected from your
 test. The test code should be organized with the glib testing framework.
 Copying and modifying an existing test is usually a good idea.
  
-3. Add the test to ``tests/meson.build``. The unit tests are listed in a

+3. Add the test to ``tests/unit/meson.build``. The unit tests are listed in a
 dictionary called ``tests``.  The values are any additional sources and
 dependencies to be linked with the test.  For a simple test whose source
-   is in ``tests/foo-test.c``, it is enough to add an entry like::
+   is in ``tests/unit/foo-test.c``, it is enough to add an entry like::
  
   {

 ...



Reviewed-by: Thomas Huth 




Re: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log

2021-03-17 Thread Kunkun Jiang

kindly ping,
Any comments and reviews are welcome.😁

Thanks,
Kunkun Jiang

On 2021/3/10 17:41, Kunkun Jiang wrote:

Hi all,

In the past, we clear dirty log immediately after sync dirty log to
userspace. This may cause redundant dirty handling if userspace
handles dirty log iteratively:

After vfio clears dirty log, new dirty log starts to generate. These
new dirty log will be reported to userspace even if they are generated
before userspace handles the same dirty page.

Since a new dirty log tracking method for vfio based on iommu hwdbm[1]
has been introduced in the kernel and added a new capability named
VFIO_DIRTY_LOG_MANUAL_CLEAR, we can eliminate some redundant dirty
handling by supporting it.

This series include patches as below:
Patch 1:
- updated the linux-headers/linux/vfio.h from kernel side

Patch 2:
- introduced 'struct VFIODMARange' to describe a range of the given DMA
   mapping and with respect to a VFIO_IOMMU_MAP_DMA operation

Patch 3:
- implemented the operation to manual clear vfio dirty log, which can
   eliminate some redundant dirty handling

Thanks,
Kunkun Jiang

[1] 
https://lore.kernel.org/linux-iommu/20210310090614.26668-1-zhukeqi...@huawei.com/T/#mb168c9738ecd3d8794e2da14f970545d5820f863

Zenghui Yu (3):
   linux-headers: update against 5.12-rc2 and "vfio log clear" series
   vfio: Maintain DMA mapping range for the container
   vfio/migration: Support VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP

  hw/vfio/common.c  | 207 --
  include/hw/vfio/vfio-common.h |  10 ++
  linux-headers/linux/vfio.h|  55 -
  3 files changed, 264 insertions(+), 8 deletions(-)






RE: [RFC 0/1] Use dmabufs for display updates instead of pixman

2021-03-17 Thread Zhang, Tina



> -Original Message-
> From: Qemu-devel 
> On Behalf Of Gerd Hoffmann
> Sent: Tuesday, March 2, 2021 8:04 PM
> To: Kasireddy, Vivek 
> Cc: Daniel Vetter ; Kim, Dongwon
> ; qemu-devel@nongnu.org; Marc-André Lureau
> 
> Subject: Re: [RFC 0/1] Use dmabufs for display updates instead of pixman
> 
> On Tue, Mar 02, 2021 at 12:03:57AM -0800, Vivek Kasireddy wrote:
> > This is still a WIP/RFC patch that attempts to use dmabufs for display
> > updates with the help of Udmabuf driver instead of pixman. This patch
> > is posted to the ML to elicit feedback and start a discussion whether
> > something like this would be useful or not for mainly non-Virgl
> > rendered BOs and also potentially in other cases.
> 
> Yes, it surely makes sense to go into that direction.
> The patch as-is doesn't, it breaks the guest/host interface.
> That's ok-ish for a quick proof-of-concept, but clearly not merge-able.

Hi,
According to 
https://lore.kernel.org/dri-devel/20210212110140.gdpu7kapnr7ov...@sirius.home.kraxel.org/
 proposal, we made some progress on making a 'virtio-gpu (display) + 
pass-through GPU' prototype. We leverage the kmsro framework provided by mesa 
to let the virtio-gpu display work with a passed-through GPU in headless mode. 
And the MR is here: 
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9592

Although our work is different from this on-going discussion which is about 
enabling a general way to share buffers between guest and host, we'd like to 
leverage this patch. So, is there any plan to refine this patch? E.g. move the 
uuid blob support into another patch, as the implementation of the proposal 
doesn't require guest user space to share buffers with host side, and also 
maybe add the dma-buf support for cursor plane. Thanks.

BR,
Tina

> 
> > TODO:
> > - Use Blob resources for getting meta-data such as modifier, format, etc.
> 
> That is pretty much mandatory.  Without blob resources there is no concept of
> resources shared between host and guest in virtio-gpu, all data is explicitly
> copied with transfer commands.
> 
> Which implies quite a bit of work because we don't have blob resource support
> in qemu yet.
> 
> > - Test with Virgil rendered BOs to see if this can be used in that case..
> 
> That also opens up the question how to go forward with virtio-gpu in general.
> The object hierarchy we have right now (skipping pci + vga variants for
> simplicity):
> 
>   TYPE_VIRTIO_GPU_BASE (abstract base)
>-> TYPE_VIRTIO_GPU (in-qemu implementation)
>-> TYPE_VHOST_USER_GPU (vhost-user implementation)
> 
> When compiled with opengl + virgl TYPE_VIRTIO_GPU has a virgl=on/off
> property.  Having a single device is not ideal for modular builds.
> because the hw-display-virtio-gpu.so module has a dependency on ui-opengl.so
> so that is needed (due to symbol references) even for the virgl=off case.  
> Also
> the code is a bit of a #ifdef mess.
> 
> I think we should split TYPE_VIRTIO_GPU into two devices.  Remove
> virgl+opengl support from TYPE_VIRTIO_GPU.  Add a new
> TYPE_VIRTIO_GPU_VIRGL, with either TYPE_VIRTIO_GPU or
> TYPE_VIRTIO_GPU_BASE as parent (not sure which is easier), have all
> opengl/virgl support code there.
> 
> I think when using opengl it makes sense to also require virgl, so we can use 
> the
> virglrenderer library to manage blob resources (even when the actual rendering
> isn't done with virgl).  Also reduces the complexity and test matrix.
> 
> Maybe it even makes sense to deprecate in-qemu virgl support and focus
> exclusively on the vhost-user implementation, so we don't have to duplicate 
> all
> work for both implementations.
> 
> > Considerations/Challenges:
> > - One of the main concerns with using dmabufs is how to synchronize
> > access to them and this use-case is no different. If the Guest is
> > running Weston, then it could use a maximum of 4 color buffers but
> > uses only 2 by default and flips between them if it is not sharing the
> > FBs with other plugins while running with the drm backend. In this
> > case, how do we make sure that Weston and Qemu UI are not using the same
> buffer at any given time?
> 
> There is graphic_hw_gl_block + graphic_hw_gl_flushed for syncronization.
> Right now this is only wired up in spice, and it is rather simple (just 
> stalls virgl
> rendering instead of providing per-buffer syncronization).
> 
> > - If we have Xorg running in the Guest, then it gets even more
> > interesting as Xorg in some cases does frontbuffer rendering (uses
> DRM_IOCTL_MODE_DIRTYFB).
> 
> Well, if the guest does frontbuffer rendering we can't do much about it and 
> have
> to live with rendering glitches I guess.
> 
> take care,
>   Gerd
> 




RE: [RFC PATCH 0/3] vfio/migration: Support manual clear vfio dirty log

2021-03-17 Thread Tian, Kevin
> From: Kunkun Jiang
> Sent: Wednesday, March 10, 2021 5:41 PM
> 
> Hi all,
> 
> In the past, we clear dirty log immediately after sync dirty log to
> userspace. This may cause redundant dirty handling if userspace
> handles dirty log iteratively:
> 
> After vfio clears dirty log, new dirty log starts to generate. These
> new dirty log will be reported to userspace even if they are generated
> before userspace handles the same dirty page.
> 
> Since a new dirty log tracking method for vfio based on iommu hwdbm[1]
> has been introduced in the kernel and added a new capability named
> VFIO_DIRTY_LOG_MANUAL_CLEAR, we can eliminate some redundant dirty
> handling by supporting it.

Is there any performance data showing the benefit of this new method?

> 
> This series include patches as below:
> Patch 1:
> - updated the linux-headers/linux/vfio.h from kernel side
> 
> Patch 2:
> - introduced 'struct VFIODMARange' to describe a range of the given DMA
>   mapping and with respect to a VFIO_IOMMU_MAP_DMA operation
> 
> Patch 3:
> - implemented the operation to manual clear vfio dirty log, which can
>   eliminate some redundant dirty handling
> 
> Thanks,
> Kunkun Jiang
> 
> [1] https://lore.kernel.org/linux-iommu/20210310090614.26668-1-
> zhukeqi...@huawei.com/T/#mb168c9738ecd3d8794e2da14f970545d5820f
> 863
> 
> Zenghui Yu (3):
>   linux-headers: update against 5.12-rc2 and "vfio log clear" series
>   vfio: Maintain DMA mapping range for the container
>   vfio/migration: Support VFIO_IOMMU_DIRTY_PAGES_FLAG_CLEAR_BITMAP
> 
>  hw/vfio/common.c  | 207 --
>  include/hw/vfio/vfio-common.h |  10 ++
>  linux-headers/linux/vfio.h|  55 -
>  3 files changed, 264 insertions(+), 8 deletions(-)
> 
> --
> 2.23.0
> 




RE: Microsoft and Intel NVDIMM ACPI _DSM interfaces status?

2021-03-17 Thread Dexuan Cui
> From: Laszlo Ersek 
> Sent: Wednesday, March 17, 2021 3:45 PM
> > The specs for the Intel interface are available here:
> > ...
> > This is the interface that QEMU emulates. It has been reported that
> > Windows 2016 Server and 2019 Server guests do not recognize QEMU's
> > emulated NVDIMM devices using the Microsoft driver.

I'm not sure why this happens -- sorry, I have no Windows knowledge.
 
> > Should QEMU emulate both of them to make running Windows guests easy?

I'm not sure about the background here, but since it looks like QEMU is already
able to emulate the Intel NVDIMM, I suppose it should be quick to add the
emulation of the Hyper-V NVDIMM. I think they're pretty similar, and the
_DSM interface supported by Hyper-V NVDIMM is simple.
 
> In my (uneducated) opinion: yes. Microsoft standarized their Region
> Format Interface, with their _DSM UUID and all; and right now, that spec
> seems to be the *only* officially approved format in the RFIC registry.
> So it's plausible to me that, unlike the Linux kernel, Microsoft's
> driver doesn't support the -- technically unapproved, nonstandard --
> Intel Region Format Interface.
> 
> Dexuan, please correct me if I'm wrong.
> 
> Thanks,
> Laszlo

Hi Laszlo, I'm not 100% sure, but I guess your may be correct.

BTW, earlier in 2019, we made the below patches (which are in the mainline):

2019-02-28libnvdimm/btt: Fix LBA masking during 'free list' population
2019-02-12acpi/nfit: Require opt-in for read-only label configurations
2019-02-02libnvdimm/dimm: Add a no-BLK quirk based on NVDIMM family
2019-01-29nfit: Add Hyper-V NVDIMM DSM command set to white list
2019-01-29nfit: acpi_nfit_ctl(): Check out_obj->type in the right place

The patches improve the interoperability between Windows VM and 
Linux VM, e.g. the same Hyper-V NVDIMM device can work this way:
the Windows VM creates an NTFS partition based on the device, and
creates a text file in the partition, and later we shut down the Windows VM
and assign the device to Linux VM, and Linux VM is able to read the text file.

Before the patches, IIRC, Linux VM could only use the Hyper-V NVIDMM
device in label-less mode.

Let me share some old 2019 notes about Hyper-V NVDIMM, in case the
info may be helpful to you: 

"
In Linux VM, IMO the label-less mode is preferred for Hyper-V NVDIMM,
because Hyper-V does not support _LSW (I'm not sure about the latest
status), so Dan made the patch "acpi/nfit: Require opt-in for read-only
label configurations" to not use the Hyper-V label info, by default.
In label-less mode, when creating a namespace, Linux can set it to
one of the 4 namespace modes: fsdax, devdax, sector, and raw (these
namespace modes are Linux-specific and can not be recognized
by Windows.). 

With the "nfit.force_labels" bootup-time kernel parameter, Linux can
be forced to be in label mode, and then if Hyper-V initializes the 4KB
BTT Info Block(s) with the standard EFI_BTT_ABSTRACTION_GUID
(which is defined in UEFI 2.7 spec), we're supposed to support the
"interoperability" between Windows VM and Linux VM.

Note: label-less mode is incompatible with label mode. A namespace
created in one mode can't be recognized when Linux runs in the other
mode. In label mode, so far, only 2 namespace modes (raw and sector)
can be supported by the Hyper-V NVDIMM, because Hyper-V doesn't
support _LSW, yet. If Hyper-V sets the EFI_BTT_ABSTRACTION_GUID,
the namespace is "BTT-capable" and can be in sector namespace
mode, otherwise it's in raw namespace mode.

After a Windows VM initializes a BTT-capable namespace in a Hyper-V
NVDIMM device by creating a NTFS file system in the namespace, we
can re-assign the Hyper-V NVDIMM device to Linux VM, and in label
mode Linux VM is supposed to be able to read and write the files in
the NTFS file system.
"

Thanks,
-- Dexuan



Re: [RFC PATCH v2 4/5] Add migration support for KVM guest with MTE

2021-03-17 Thread Haibo Xu
On Thu, 18 Mar 2021 at 04:11, Dr. David Alan Gilbert
 wrote:
>
> * Haibo Xu (haibo...@linaro.org) wrote:
> > To make it easier to keep the page tags sync with
> > the page data, tags for one page are appended to
> > the data during ram save iteration.
> >
> > This patch only add the pre-copy migration support.
> > Post-copy and compress as well as zero page saving
> > are not supported yet.
> >
> > Signed-off-by: Haibo Xu 
>
> My guess is that this doesn't work with a lot of other options; e.g.
> postcopy and probably compression and a bunch of other things.
> Postcopy I can see you'll need some interesting kernel changes for -
> you'd need to be able to atomically place a  page with it's tag data.
>
> You probably need to add stuff to migrate_caps_check  to disable
> features that you don't support.
>

Hi David,

Thanks so much for the comments!

You are right, this RFC patch only supports pre-copy mode, no
postcopy, no compression.
As a RFC, here just want to finalize the tag migration process, that is:
1. let the tag go with the page data(the current choice) which may be
a little complex to put
them into the current migration process.
2. migrate them separately which is easy to implement with the current
migration(treat the tags
as device status), but it would be hard to keep the page data and
tag to sync with each other.
3. Any other ways?

Once the tag migration process is finalized, a new formal patch series
with postcopy as well as
compression should be reworked.

What's more, you mentioned that "some interesting kernel changes are
needed to atomically
place a  page with it's tag data". You mean a single kernel API to
store page data and tag in
the migration load process?

Regards,
Haibo

> > ---
> >  include/hw/arm/virt.h|  2 +
> >  include/migration/misc.h |  1 +
> >  migration/ram.c  | 86 +++-
> >  3 files changed, 88 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h
> > index 921416f918..8b28cde8bf 100644
> > --- a/include/hw/arm/virt.h
> > +++ b/include/hw/arm/virt.h
> > @@ -166,6 +166,8 @@ struct VirtMachineState {
> >  PCIBus *bus;
> >  char *oem_id;
> >  char *oem_table_id;
> > +/* migrate memory tags */
> > +NotifierWithReturn precopy_notifier;
> >  };
> >
> >  #define VIRT_ECAM_ID(high) (high ? VIRT_HIGH_PCIE_ECAM : VIRT_PCIE_ECAM)
> > diff --git a/include/migration/misc.h b/include/migration/misc.h
> > index bccc1b6b44..005133f471 100644
> > --- a/include/migration/misc.h
> > +++ b/include/migration/misc.h
> > @@ -38,6 +38,7 @@ void precopy_add_notifier(NotifierWithReturn *n);
> >  void precopy_remove_notifier(NotifierWithReturn *n);
> >  int precopy_notify(PrecopyNotifyReason reason, Error **errp);
> >  void precopy_enable_free_page_optimization(void);
> > +void precopy_enable_metadata_migration(void);
> >
> >  void ram_mig_init(void);
> >  void qemu_guest_free_page_hint(void *addr, size_t len);
> > diff --git a/migration/ram.c b/migration/ram.c
> > index 72143da0ac..e67b798c3b 100644
> > --- a/migration/ram.c
> > +++ b/migration/ram.c
> > @@ -53,10 +53,12 @@
> >  #include "block.h"
> >  #include "sysemu/sysemu.h"
> >  #include "sysemu/cpu-throttle.h"
> > +#include "sysemu/kvm.h"
> >  #include "savevm.h"
> >  #include "qemu/iov.h"
> >  #include "multifd.h"
> >  #include "sysemu/runstate.h"
> > +#include "kvm_arm.h"
> >
> >  #if defined(__linux__)
> >  #include "qemu/userfaultfd.h"
> > @@ -80,6 +82,9 @@
> >  #define RAM_SAVE_FLAG_XBZRLE   0x40
> >  /* 0x80 is reserved in migration.h start with 0x100 next */
> >  #define RAM_SAVE_FLAG_COMPRESS_PAGE0x100
> > +#define RAM_SAVE_FLAG_MTE  0x200
>
> I think that's using the last free bit in the flags field, which is a
> bit painful.
>

Yes, only 0x80(reserved) and 0x200 are available.

> > +#define MTE_GRANULE_SIZE   (16)
> >
> >  static inline bool is_zero_range(uint8_t *p, uint64_t size)
> >  {
> > @@ -317,6 +322,8 @@ struct RAMState {
> >  bool ram_bulk_stage;
> >  /* The free page optimization is enabled */
> >  bool fpo_enabled;
> > +/* The RAM meta data(e.t memory tag) is enabled */
> > +bool metadata_enabled;
> >  /* How many times we have dirty too many pages */
> >  int dirty_rate_high_cnt;
> >  /* these variables are used for bitmap sync */
> > @@ -394,6 +401,15 @@ void precopy_enable_free_page_optimization(void)
> >  ram_state->fpo_enabled = true;
> >  }
> >
> > +void precopy_enable_metadata_migration(void)
> > +{
> > +if (!ram_state) {
> > +return;
> > +}
> > +
> > +ram_state->metadata_enabled = true;
> > +}
> > +
> >  uint64_t ram_bytes_remaining(void)
> >  {
> >  return ram_state ? (ram_state->migration_dirty_pages * 
> > TARGET_PAGE_SIZE) :
> > @@ -1134,6 +1150,61 @@ static bool control_save_page(RAMState *rs, RAMBlock 
> > *block, ram_addr_t offset,
> >  return true;
> >  }
> >
> > +static int save_normal_page_mte_tags(QEMUFile *f

[PATCH v2] piix: fix regression during unplug in Xen HVM domUs

2021-03-17 Thread Olaf Hering
Commit ee358e919e385fdc79d59d0d47b4a81e349cd5c9 causes a regression in
Xen HVM domUs which run xenlinux based kernels.

If the domU has an USB device assigned, for example with
"usbdevice=['tablet']" in domU.cfg, the late unplug of devices will
kill the emulated USB host. As a result the khubd thread hangs, and as
a result the entire boot process.

For some reason this does not affect pvops based kernels. This is
most likely caused by the fact that unplugging happens very early
during boot.

Signed-off-by: Olaf Hering 
---
 hw/ide/piix.c| 5 +
 include/hw/ide/pci.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index b9860e35a5..7f1998bf04 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -109,6 +109,9 @@ static void piix_ide_reset(DeviceState *dev)
 uint8_t *pci_conf = pd->config;
 int i;
 
+if (d->xen_unplug_done == true) {
+return;
+}
 for (i = 0; i < 2; i++) {
 ide_bus_reset(&d->bus[i]);
 }
@@ -151,6 +154,7 @@ static void pci_piix_ide_realize(PCIDevice *dev, Error 
**errp)
 PCIIDEState *d = PCI_IDE(dev);
 uint8_t *pci_conf = dev->config;
 
+d->xen_unplug_done = false;
 pci_conf[PCI_CLASS_PROG] = 0x80; // legacy ATA mode
 
 bmdma_setup_bar(d);
@@ -170,6 +174,7 @@ int pci_piix3_xen_ide_unplug(DeviceState *dev, bool aux)
 BlockBackend *blk;
 
 pci_ide = PCI_IDE(dev);
+pci_ide->xen_unplug_done = true;
 
 for (i = aux ? 1 : 0; i < 4; i++) {
 idebus = &pci_ide->bus[i / 2];
diff --git a/include/hw/ide/pci.h b/include/hw/ide/pci.h
index d8384e1c42..9e71cfec3b 100644
--- a/include/hw/ide/pci.h
+++ b/include/hw/ide/pci.h
@@ -50,6 +50,7 @@ struct PCIIDEState {
 IDEBus bus[2];
 BMDMAState bmdma[2];
 uint32_t secondary; /* used only for cmd646 */
+bool xen_unplug_done;
 MemoryRegion bmdma_bar;
 MemoryRegion cmd_bar[2];
 MemoryRegion data_bar[2];



  1   2   3   4   5   >