From 76f67bac79f6d915c7760d46c2be58731def8f03 Mon Sep 17 00:00:00 2001 From: Jessica Clarke Date: Sat, 20 Mar 2021 17:12:21 +0000 Subject: [PATCH 01/12] meson: Propagate gnutls dependency to migration Commit 3eacf70bb5a83e4775ad8003cbca63a40f70c8c2 neglected to fix this for softmmu configs, which pull in migration's use of gnutls. This fixes the following compilation failure on Arm-based Macs: In file included from migration/multifd.c:23: In file included from migration/tls.h:25: In file included from include/io/channel-tls.h:26: In file included from include/crypto/tlssession.h:24: include/crypto/tlscreds.h:28:10: fatal error: 'gnutls/gnutls.h' file not found #include ^~~~~~~~~~~~~~~~~ 1 error generated. (as well as for channel.c and tls.c) Signed-off-by: Jessica Clarke Reviewed-by: Juan Quintela Message-Id: <20210320171221.37437-1-jrtc27@jrtc27.com> Signed-off-by: Paolo Bonzini --- migration/meson.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/migration/meson.build b/migration/meson.build index 9645f44005..6fa2f8745d 100644 --- a/migration/meson.build +++ b/migration/meson.build @@ -24,7 +24,7 @@ softmmu_ss.add(files( 'savevm.c', 'socket.c', 'tls.c', -)) +), gnutls) softmmu_ss.add(when: ['CONFIG_RDMA', rdma], if_true: files('rdma.c')) softmmu_ss.add(when: 'CONFIG_LIVE_BLOCK_MIGRATION', if_true: files('block.c')) From 10b8eb94c0902b58d83df84a9eeae709a3480e82 Mon Sep 17 00:00:00 2001 From: Richard Henderson Date: Wed, 24 Mar 2021 10:46:50 -0600 Subject: [PATCH 02/12] target/i386: Verify memory operand for lcall and ljmp These two opcodes only allow a memory operand. Lacking the check for a register operand, we used the A0 temp without initialization, which led to a tcg abort. Buglink: https://bugs.launchpad.net/qemu/+bug/1921138 Signed-off-by: Richard Henderson Message-Id: <20210324164650.128608-1-richard.henderson@linaro.org> Signed-off-by: Paolo Bonzini --- target/i386/tcg/translate.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c index af1faf9342..880bc45561 100644 --- a/target/i386/tcg/translate.c +++ b/target/i386/tcg/translate.c @@ -5061,6 +5061,9 @@ static target_ulong disas_insn(DisasContext *s, CPUState *cpu) gen_jr(s, s->T0); break; case 3: /* lcall Ev */ + if (mod == 3) { + goto illegal_op; + } gen_op_ld_v(s, ot, s->T1, s->A0); gen_add_A0_im(s, 1 << ot); gen_op_ld_v(s, MO_16, s->T0, s->A0); @@ -5088,6 +5091,9 @@ static target_ulong disas_insn(DisasContext *s, CPUState *cpu) gen_jr(s, s->T0); break; case 5: /* ljmp Ev */ + if (mod == 3) { + goto illegal_op; + } gen_op_ld_v(s, ot, s->T1, s->A0); gen_add_A0_im(s, 1 << ot); gen_op_ld_v(s, MO_16, s->T0, s->A0); From a061a71e0d8f259fbb241485f6601bd02c7d086a Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Fri, 26 Mar 2021 04:48:39 -0400 Subject: [PATCH 03/12] qapi: qom: do not use target-specific conditionals ObjectType and ObjectOptions are defined in a target-independent file, therefore they do not have access to target-specific configuration symbols such as CONFIG_PSERIES or CONFIG_SEV. For this reason, pef-guest and sev-guest are currently omitted when compiling the generated QAPI files. In addition, this causes ObjectType to have different definitions depending on the file that is including qapi-types-qom.h (currently this is not causing any issues, but it is wrong). Define the two enum entries and the SevGuestProperties type unconditionally to avoid the issue. We do not expect to have many target-dependent user-creatable classes, so it is not particularly problematic. Reported-by: Tom Lendacky Signed-off-by: Paolo Bonzini --- qapi/qom.json | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/qapi/qom.json b/qapi/qom.json index 2056edc072..db5ac419b1 100644 --- a/qapi/qom.json +++ b/qapi/qom.json @@ -733,8 +733,7 @@ '*policy': 'uint32', '*handle': 'uint32', '*cbitpos': 'uint32', - 'reduced-phys-bits': 'uint32' }, - 'if': 'defined(CONFIG_SEV)' } + 'reduced-phys-bits': 'uint32' } } ## # @ObjectType: @@ -768,14 +767,14 @@ { 'name': 'memory-backend-memfd', 'if': 'defined(CONFIG_LINUX)' }, 'memory-backend-ram', - {'name': 'pef-guest', 'if': 'defined(CONFIG_PSERIES)' }, + 'pef-guest', 'pr-manager-helper', 'rng-builtin', 'rng-egd', 'rng-random', 'secret', 'secret_keyring', - {'name': 'sev-guest', 'if': 'defined(CONFIG_SEV)' }, + 'sev-guest', 's390-pv-guest', 'throttle-group', 'tls-creds-anon', @@ -831,8 +830,7 @@ 'rng-random': 'RngRandomProperties', 'secret': 'SecretProperties', 'secret_keyring': 'SecretKeyringProperties', - 'sev-guest': { 'type': 'SevGuestProperties', - 'if': 'defined(CONFIG_SEV)' }, + 'sev-guest': 'SevGuestProperties', 'throttle-group': 'ThrottleGroupProperties', 'tls-creds-anon': 'TlsCredsAnonProperties', 'tls-creds-psk': 'TlsCredsPskProperties', From 7cebff0d0374d2ffd94f3bffe6ea922bb9091563 Mon Sep 17 00:00:00 2001 From: Pavel Dovgalyuk Date: Mon, 29 Mar 2021 10:59:25 +0300 Subject: [PATCH 04/12] replay: fix recursive checkpoints Record/replay uses checkpoints to synchronize the execution of the threads and timers. Hardware events such as BH are processed at the checkpoints too. Event processing can cause refreshing the virtual timers and calling the icount-related functions, that also use checkpoints. This patch prevents recursive processing of such checkpoints, because they have their own records in the log and should be processed later. Signed-off-by: Pavel Dovgalyuk Message-Id: <161700476500.1140362.10108444973730452257.stgit@pasha-ThinkPad-X280> Signed-off-by: Paolo Bonzini --- replay/replay.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/replay/replay.c b/replay/replay.c index c806fec69a..6df2abc18c 100644 --- a/replay/replay.c +++ b/replay/replay.c @@ -180,12 +180,13 @@ bool replay_checkpoint(ReplayCheckpoint checkpoint) } if (in_checkpoint) { - /* If we are already in checkpoint, then there is no need - for additional synchronization. + /* Recursion occurs when HW event modifies timers. - Timer modification may invoke the checkpoint and - proceed to recursion. */ - return true; + Prevent performing icount warp in this case and + wait for another invocation of the checkpoint. + */ + g_assert(replay_mode == REPLAY_MODE_PLAY); + return false; } in_checkpoint = true; From cb4d9e38bd2a9077716d2e41778cd0bb155ae119 Mon Sep 17 00:00:00 2001 From: Thomas Huth Date: Sun, 28 Mar 2021 07:47:58 +0200 Subject: [PATCH 05/12] Revert "qom: use qemu_printf to print help for user-creatable objects" This reverts commit 6d9abb6de9cc53a508823db0283061824f2f98a2. The real code change had already been added by Kevin's commit da0a932bbf ("hmp: QAPIfy object_add") and commit 6d9abb6d just added a duplicated include statement as a left-over of a rebase. Signed-off-by: Thomas Huth Message-Id: <20210328054758.2351461-1-thuth@redhat.com> Signed-off-by: Paolo Bonzini --- qom/object_interfaces.c | 1 - 1 file changed, 1 deletion(-) diff --git a/qom/object_interfaces.c b/qom/object_interfaces.c index c3324b0f86..b17aa57de1 100644 --- a/qom/object_interfaces.c +++ b/qom/object_interfaces.c @@ -17,7 +17,6 @@ #include "qemu/qemu-print.h" #include "qapi/opts-visitor.h" #include "qemu/config-file.h" -#include "qemu/qemu-print.h" bool user_creatable_complete(UserCreatable *uc, Error **errp) { From fe852ac2b3725055bb210270e3aca5a0ed4b6217 Mon Sep 17 00:00:00 2001 From: Pavel Dovgalyuk Date: Mon, 29 Mar 2021 13:22:30 +0300 Subject: [PATCH 06/12] icount: get rid of static variable This patch moves static last_delta variable into timers_state structure to allow correct vmstate operations with icount shift=auto enabled. Signed-off-by: Pavel Dovgalyuk Message-Id: <161701335066.1180180.7104085247702343395.stgit@pasha-ThinkPad-X280> Signed-off-by: Paolo Bonzini --- softmmu/cpu-timers.c | 5 +++-- softmmu/icount.c | 9 +++------ softmmu/timers-state.h | 2 ++ 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/softmmu/cpu-timers.c b/softmmu/cpu-timers.c index cd38595245..34ddfa02f1 100644 --- a/softmmu/cpu-timers.c +++ b/softmmu/cpu-timers.c @@ -188,11 +188,12 @@ static const VMStateDescription icount_vmstate_adjust_timers = { static const VMStateDescription icount_vmstate_shift = { .name = "timer/icount/shift", - .version_id = 1, - .minimum_version_id = 1, + .version_id = 2, + .minimum_version_id = 2, .needed = icount_shift_state_needed, .fields = (VMStateField[]) { VMSTATE_INT16(icount_time_shift, TimersState), + VMSTATE_INT64(last_delta, TimersState), VMSTATE_END_OF_LIST() } }; diff --git a/softmmu/icount.c b/softmmu/icount.c index dbcd8c3594..21341a4ce4 100644 --- a/softmmu/icount.c +++ b/softmmu/icount.c @@ -176,9 +176,6 @@ static void icount_adjust(void) int64_t cur_icount; int64_t delta; - /* Protected by TimersState mutex. */ - static int64_t last_delta; - /* If the VM is not running, then do nothing. */ if (!runstate_is_running()) { return; @@ -193,20 +190,20 @@ static void icount_adjust(void) delta = cur_icount - cur_time; /* FIXME: This is a very crude algorithm, somewhat prone to oscillation. */ if (delta > 0 - && last_delta + ICOUNT_WOBBLE < delta * 2 + && timers_state.last_delta + ICOUNT_WOBBLE < delta * 2 && timers_state.icount_time_shift > 0) { /* The guest is getting too far ahead. Slow time down. */ qatomic_set(&timers_state.icount_time_shift, timers_state.icount_time_shift - 1); } if (delta < 0 - && last_delta - ICOUNT_WOBBLE > delta * 2 + && timers_state.last_delta - ICOUNT_WOBBLE > delta * 2 && timers_state.icount_time_shift < MAX_ICOUNT_SHIFT) { /* The guest is getting too far behind. Speed time up. */ qatomic_set(&timers_state.icount_time_shift, timers_state.icount_time_shift + 1); } - last_delta = delta; + timers_state.last_delta = delta; qatomic_set_i64(&timers_state.qemu_icount_bias, cur_icount - (timers_state.qemu_icount << timers_state.icount_time_shift)); diff --git a/softmmu/timers-state.h b/softmmu/timers-state.h index db4e60f18f..8c262ce139 100644 --- a/softmmu/timers-state.h +++ b/softmmu/timers-state.h @@ -43,6 +43,8 @@ typedef struct TimersState { /* Conversion factor from emulated instructions to virtual clock ticks. */ int16_t icount_time_shift; + /* Icount delta used for shift auto adjust. */ + int64_t last_delta; /* Compensate for varying guest execution speed. */ int64_t qemu_icount_bias; From 46967b1a43dead33fa0c4afecd91b456693d1c4f Mon Sep 17 00:00:00 2001 From: Pavel Dovgalyuk Date: Thu, 1 Apr 2021 11:19:51 +0300 Subject: [PATCH 07/12] replay: notify CPU on event This patch enables vCPU notification to wake it up when new async event comes in replay mode. The motivation of this patch is the following. Consider recorded block async event. It is saved into the log with one of the checkpoints. This checkpoint may be passed in vCPU loop. In replay mode when this async event is read from the log, and block thread task is not finished yet, vCPU thread goes to sleep. That is why this patch adds waking up the vCPU to process this finished event. Signed-off-by: Pavel Dovgalyuk Message-Id: <161726519158.1476949.7614181684462079836.stgit@pasha-ThinkPad-X280> Signed-off-by: Paolo Bonzini --- replay/replay-events.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/replay/replay-events.c b/replay/replay-events.c index a1c6bb934e..15983dd250 100644 --- a/replay/replay-events.c +++ b/replay/replay-events.c @@ -15,6 +15,7 @@ #include "replay-internal.h" #include "block/aio.h" #include "ui/input.h" +#include "hw/core/cpu.h" typedef struct Event { ReplayAsyncEventKind event_kind; @@ -126,6 +127,7 @@ void replay_add_event(ReplayAsyncEventKind event_kind, g_assert(replay_mutex_locked()); QTAILQ_INSERT_TAIL(&events_list, event, events); + qemu_cpu_kick(first_cpu); } void replay_bh_schedule_event(QEMUBH *bh) From b9e40bac9c7a9f7301e190aa597e84f95657b5b7 Mon Sep 17 00:00:00 2001 From: Pavel Dovgalyuk Date: Mon, 29 Mar 2021 10:42:41 +0300 Subject: [PATCH 08/12] target/openrisc: fix icount handling for timer instructions This patch adds icount handling to mfspr/mtspr instructions that may deal with hardware timers. Signed-off-by: Pavel Dovgalyuk Message-Id: <161700376169.1135890.8707223959310729949.stgit@pasha-ThinkPad-X280> Signed-off-by: Paolo Bonzini Acked-by: Stafford Horne --- target/openrisc/translate.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/target/openrisc/translate.c b/target/openrisc/translate.c index c6dce879f1..a9c81f8bd5 100644 --- a/target/openrisc/translate.c +++ b/target/openrisc/translate.c @@ -884,6 +884,18 @@ static bool trans_l_mfspr(DisasContext *dc, arg_l_mfspr *a) gen_illegal_exception(dc); } else { TCGv spr = tcg_temp_new(); + + if (tb_cflags(dc->base.tb) & CF_USE_ICOUNT) { + gen_io_start(); + if (dc->delayed_branch) { + tcg_gen_mov_tl(cpu_pc, jmp_pc); + tcg_gen_discard_tl(jmp_pc); + } else { + tcg_gen_movi_tl(cpu_pc, dc->base.pc_next + 4); + } + dc->base.is_jmp = DISAS_EXIT; + } + tcg_gen_ori_tl(spr, cpu_R(dc, a->a), a->k); gen_helper_mfspr(cpu_R(dc, a->d), cpu_env, cpu_R(dc, a->d), spr); tcg_temp_free(spr); @@ -898,6 +910,9 @@ static bool trans_l_mtspr(DisasContext *dc, arg_l_mtspr *a) } else { TCGv spr; + if (tb_cflags(dc->base.tb) & CF_USE_ICOUNT) { + gen_io_start(); + } /* For SR, we will need to exit the TB to recognize the new * exception state. For NPC, in theory this counts as a branch * (although the SPR only exists for use by an ICE). Save all From c7328271cf31a01a72234be4b913c1d5c12bf824 Mon Sep 17 00:00:00 2001 From: Miroslav Rezanina Date: Wed, 31 Mar 2021 10:18:45 +0200 Subject: [PATCH 09/12] configure: Do not use default_feature for EXESUF Commit "c87ea11631 configure: add --without-default-features" use default_feature to set default values for configure option. This value is used for EXESUF too. However, EXESUF is not option to be tested, it is just append to any binary name so using --without-default-features set EXESUF to "n"o and all binaries using it has form no (e.g. qemu-imgno). This is not expected behavior as disabling features should not cause generating different binary names. Reverting back to setting EXESUF to empty value unless needed otherwise. Signed-off-by: Miroslav Rezanina Message-Id: <20210331081845.105089-1-mrezanin@redhat.com> Signed-off-by: Paolo Bonzini --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index 535e6a9269..8275df1506 100755 --- a/configure +++ b/configure @@ -365,7 +365,7 @@ tcg_interpreter="false" bigendian="no" mingw32="no" gcov="no" -EXESUF="$default_feature" +EXESUF="" HOST_DSOSUF=".so" modules="no" module_upgrades="no" From a5158a963e7f1bd8d43de54a6471941faf9f5b4e Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Tue, 9 Mar 2021 16:15:30 +0100 Subject: [PATCH 10/12] hexagon: do not specify executables as inputs gen_semantics is an executable, not an input. Meson 0.57 special cases the first argument and @INPUT@ is not expanded there. Fix that by not including it in the input, only in the command. Signed-off-by: Paolo Bonzini --- target/hexagon/meson.build | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/target/hexagon/meson.build b/target/hexagon/meson.build index 15318a6fa7..5dd68907b1 100644 --- a/target/hexagon/meson.build +++ b/target/hexagon/meson.build @@ -33,8 +33,7 @@ gen_semantics = executable( semantics_generated = custom_target( 'semantics_generated.pyinc', output: 'semantics_generated.pyinc', - input: gen_semantics, - command: ['@INPUT@', '@OUTPUT@'], + command: [gen_semantics, '@OUTPUT@'], ) hexagon_ss.add(semantics_generated) @@ -154,8 +153,7 @@ gen_dectree_import = executable( iset_py = custom_target( 'iset.py', output: 'iset.py', - input: gen_dectree_import, - command: ['@INPUT@', '@OUTPUT@'], + command: [gen_dectree_import, '@OUTPUT@'], ) hexagon_ss.add(iset_py) From 2008b34a5926701caf6e7a78ee7b92975455f351 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Tue, 9 Mar 2021 16:15:30 +0100 Subject: [PATCH 11/12] hexagon: do not specify Python scripts as inputs Python scripts are not inputs, and putting them in @INPUT@. This puts requirements on the command line format, keeping all inputs close to the name of the script. Avoid that by not including the script in the command and not in the inputs. Also wrap "PYTHONPATH" usage with "env", since setting the environment this way is not valid under Windows. Signed-off-by: Paolo Bonzini --- target/hexagon/meson.build | 30 ++++++++++-------------------- 1 file changed, 10 insertions(+), 20 deletions(-) diff --git a/target/hexagon/meson.build b/target/hexagon/meson.build index 5dd68907b1..bb0b4fb621 100644 --- a/target/hexagon/meson.build +++ b/target/hexagon/meson.build @@ -53,90 +53,81 @@ hexagon_ss.add(semantics_generated) shortcode_generated = custom_target( 'shortcode_generated.h.inc', output: 'shortcode_generated.h.inc', - input: 'gen_shortcode.py', depends: [semantics_generated], depend_files: [hex_common_py, attribs_def], - command: [python, '@INPUT@', semantics_generated, attribs_def, '@OUTPUT@'], + command: [python, files('gen_shortcode.py'), semantics_generated, attribs_def, '@OUTPUT@'], ) hexagon_ss.add(shortcode_generated) helper_protos_generated = custom_target( 'helper_protos_generated.h.inc', output: 'helper_protos_generated.h.inc', - input: 'gen_helper_protos.py', depends: [semantics_generated], depend_files: [hex_common_py, attribs_def, gen_tcg_h], - command: [python, '@INPUT@', semantics_generated, attribs_def, gen_tcg_h, '@OUTPUT@'], + command: [python, files('gen_helper_protos.py'), semantics_generated, attribs_def, gen_tcg_h, '@OUTPUT@'], ) hexagon_ss.add(helper_protos_generated) tcg_funcs_generated = custom_target( 'tcg_funcs_generated.c.inc', output: 'tcg_funcs_generated.c.inc', - input: 'gen_tcg_funcs.py', depends: [semantics_generated], depend_files: [hex_common_py, attribs_def, gen_tcg_h], - command: [python, '@INPUT@', semantics_generated, attribs_def, gen_tcg_h, '@OUTPUT@'], + command: [python, files('gen_tcg_funcs.py'), semantics_generated, attribs_def, gen_tcg_h, '@OUTPUT@'], ) hexagon_ss.add(tcg_funcs_generated) tcg_func_table_generated = custom_target( 'tcg_func_table_generated.c.inc', output: 'tcg_func_table_generated.c.inc', - input: 'gen_tcg_func_table.py', depends: [semantics_generated], depend_files: [hex_common_py, attribs_def], - command: [python, '@INPUT@', semantics_generated, attribs_def, '@OUTPUT@'], + command: [python, files('gen_tcg_func_table.py'), semantics_generated, attribs_def, '@OUTPUT@'], ) hexagon_ss.add(tcg_func_table_generated) helper_funcs_generated = custom_target( 'helper_funcs_generated.c.inc', output: 'helper_funcs_generated.c.inc', - input: 'gen_helper_funcs.py', depends: [semantics_generated], depend_files: [hex_common_py, attribs_def, gen_tcg_h], - command: [python, '@INPUT@', semantics_generated, attribs_def, gen_tcg_h, '@OUTPUT@'], + command: [python, files('gen_helper_funcs.py'), semantics_generated, attribs_def, gen_tcg_h, '@OUTPUT@'], ) hexagon_ss.add(helper_funcs_generated) printinsn_generated = custom_target( 'printinsn_generated.h.inc', output: 'printinsn_generated.h.inc', - input: 'gen_printinsn.py', depends: [semantics_generated], depend_files: [hex_common_py, attribs_def], - command: [python, '@INPUT@', semantics_generated, attribs_def, '@OUTPUT@'], + command: [python, files('gen_printinsn.py'), semantics_generated, attribs_def, '@OUTPUT@'], ) hexagon_ss.add(printinsn_generated) op_regs_generated = custom_target( 'op_regs_generated.h.inc', output: 'op_regs_generated.h.inc', - input: 'gen_op_regs.py', depends: [semantics_generated], depend_files: [hex_common_py, attribs_def], - command: [python, '@INPUT@', semantics_generated, attribs_def, '@OUTPUT@'], + command: [python, files('gen_op_regs.py'), semantics_generated, attribs_def, '@OUTPUT@'], ) hexagon_ss.add(op_regs_generated) op_attribs_generated = custom_target( 'op_attribs_generated.h.inc', output: 'op_attribs_generated.h.inc', - input: 'gen_op_attribs.py', depends: [semantics_generated], depend_files: [hex_common_py, attribs_def], - command: [python, '@INPUT@', semantics_generated, attribs_def, '@OUTPUT@'], + command: [python, files('gen_op_attribs.py'), semantics_generated, attribs_def, '@OUTPUT@'], ) hexagon_ss.add(op_attribs_generated) opcodes_def_generated = custom_target( 'opcodes_def_generated.h.inc', output: 'opcodes_def_generated.h.inc', - input: 'gen_opcodes_def.py', depends: [semantics_generated], depend_files: [hex_common_py, attribs_def], - command: [python, '@INPUT@', semantics_generated, attribs_def, '@OUTPUT@'], + command: [python, files('gen_opcodes_def.py'), semantics_generated, attribs_def, '@OUTPUT@'], ) hexagon_ss.add(opcodes_def_generated) @@ -164,9 +155,8 @@ hexagon_ss.add(iset_py) dectree_generated = custom_target( 'dectree_generated.h.inc', output: 'dectree_generated.h.inc', - input: 'dectree.py', depends: [iset_py], - command: ['PYTHONPATH=' + meson.current_build_dir(), '@INPUT@', '@OUTPUT@'], + command: ['env', 'PYTHONPATH=' + meson.current_build_dir(), files('dectree.py'), '@OUTPUT@'], ) hexagon_ss.add(dectree_generated) From c81cfb89bc440466c1f128b64a8fbca256477b60 Mon Sep 17 00:00:00 2001 From: Paolo Bonzini Date: Wed, 31 Mar 2021 16:35:27 +0200 Subject: [PATCH 12/12] docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In an ideal world, we would all get along together very well, always be polite and never end up in huge conflicts. And even if there are conflicts, we would always handle each other fair and respectfully. Unfortunately, this is not an ideal world and sometimes people forget how to interact with each other in a professional and respectful way. Fortunately, this seldom happens in the QEMU community, but for such rare cases it is preferrable to have a basic code of conduct document available to show to people who are misbehaving. In case that does not help yet, we should also have a conflict resolution policy ready that can be applied in the worst case. The Code of Conduct document tries to be short and to the point while trying to remain friendly and welcoming; it is based on the Fedora Code of Conduct[1] with extra detail added based on the Contributor Covenant 1.3.0[2]. Other proposals included the Contributor Covenant 1.3.0 itself or the Django Code of Conduct[3] (which is also a derivative of Fedora's) but, in any case, there was agreement on keeping the conflict resolution policy separate from the CoC itself. An important point is whether to apply the code of conduct to violations that occur outside public spaces. The text herein restricts that to individuals acting as a representative or a member of the project or its community. This is intermediate between the Contributor Covenant (which only mentions representatives of the community, for example using an official project e-mail address or posting via an official social media account), and the Django Code of Conduct, which says that violations of this code outside these spaces "may" be considered but otherwise applies no limit. The conflict resolution policy is based on the Drupal Conflict Resolution Policy[4] and its derivative, the Mozilla Consequence Ladder[5]. [1] https://www.fedoraproject.com/code-of-conduct/ [2] https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/ [3] https://www.djangoproject.com/conduct/ [4] https://www.drupal.org/conflict-resolution [5] https://github.com/mozilla/diversity/blob/master/code-of-conduct-enforcement/consequence-ladder.md Co-developed-by: Thomas Huth Reviewed-by: David Edmondson Reviewed-by: Alex Bennée Reviewed-by: Thomas Huth Signed-off-by: Paolo Bonzini --- docs/devel/code-of-conduct.rst | 60 ++++++++++++++++++++++ docs/devel/conflict-resolution.rst | 80 ++++++++++++++++++++++++++++++ docs/devel/index.rst | 2 + 3 files changed, 142 insertions(+) create mode 100644 docs/devel/code-of-conduct.rst create mode 100644 docs/devel/conflict-resolution.rst diff --git a/docs/devel/code-of-conduct.rst b/docs/devel/code-of-conduct.rst new file mode 100644 index 0000000000..277b5250d1 --- /dev/null +++ b/docs/devel/code-of-conduct.rst @@ -0,0 +1,60 @@ +Code of Conduct +=============== + +The QEMU community is made up of a mixture of professionals and +volunteers from all over the world. Diversity is one of our strengths, +but it can also lead to communication issues and unhappiness. +To that end, we have a few ground rules that we ask people to adhere to. + +* Be welcoming. We are committed to making participation in this project + a harassment-free experience for everyone, regardless of level of + experience, gender, gender identity and expression, sexual orientation, + disability, personal appearance, body size, race, ethnicity, age, religion, + or nationality. + +* Be respectful. Not all of us will agree all the time. Disagreements, both + social and technical, happen all the time and the QEMU community is no + exception. When we disagree, we try to understand why. It is important that + we resolve disagreements and differing views constructively. Members of the + QEMU community should be respectful when dealing with other contributors as + well as with people outside the QEMU community and with users of QEMU. + +Harassment and other exclusionary behavior are not acceptable. A community +where people feel uncomfortable or threatened is neither welcoming nor +respectful. Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery + +* Personal attacks + +* Trolling or insulting/derogatory comments + +* Public or private harassment + +* Publishing other's private information, such as physical or electronic + addresses, without explicit permission + +This isn't an exhaustive list of things that you can't do. Rather, take +it in the spirit in which it's intended: a guide to make it easier to +be excellent to each other. + +This code of conduct applies to all spaces managed by the QEMU project. +This includes IRC, the mailing lists, the issue tracker, community +events, and any other forums created by the project team which the +community uses for communication. This code of conduct also applies +outside these spaces, when an individual acts as a representative or a +member of the project or its community. + +By adopting this code of conduct, project maintainers commit themselves +to fairly and consistently applying these principles to every aspect of +managing this project. If you believe someone is violating the code of +conduct, please read the :ref:`conflict-resolution` document for +information about how to proceed. + +Sources +------- + +This document is based on the `Fedora Code of Conduct +`__ and the +`Contributor Covenant version 1.3.0 +`__. diff --git a/docs/devel/conflict-resolution.rst b/docs/devel/conflict-resolution.rst new file mode 100644 index 0000000000..bb25f61865 --- /dev/null +++ b/docs/devel/conflict-resolution.rst @@ -0,0 +1,80 @@ +.. _conflict-resolution: + +Conflict Resolution Policy +========================== + +Conflicts in the community can take many forms, from someone having a +bad day and using harsh and hurtful language on the mailing list to more +serious code of conduct violations (including sexist/racist statements +or threats of violence), and everything in between. + +For the vast majority of issues, we aim to empower individuals to first +resolve conflicts themselves, asking for help when needed, and only +after that fails to escalate further. This approach gives people more +control over the outcome of their dispute. + +How we resolve conflicts +------------------------ + +If you are experiencing conflict, please consider first addressing the +perceived conflict directly with other involved parties, preferably through +a real-time medium such as IRC. You could also try to get a third-party (e.g. +a mutual friend, and/or someone with background on the issue, but not +involved in the conflict) to intercede or mediate. + +If this fails or if you do not feel comfortable proceeding this way, or +if the problem requires immediate escalation, report the issue to the QEMU +leadership committee by sending an email to qemu@sfconservancy.org, providing +references to the misconduct. +For very urgent topics, you can also inform one or more members through IRC. +The up-to-date list of members is `available on the QEMU wiki +`__. + +Your report will be treated confidentially by the leadership committee and +not be published without your agreement. The QEMU leadership committee will +then do its best to review the incident in a timely manner, and will either +seek further information, or will make a determination on next steps. + +Remedies +-------- + +Escalating an issue to the QEMU leadership committee may result in actions +impacting one or more involved parties. In the event the leadership +committee has to intervene, here are some of the ways they might respond: + +1. Take no action. For example, if the leadership committee determines + the complaint has not been substantiated or is being made in bad faith, + or if it is deemed to be outside its purview. + +2. A private reprimand, explaining the consequences of continued behavior, + to one or more involved individuals. + +3. A private reprimand and request for a private or public apology + +4. A public reprimand and request for a public apology + +5. A public reprimand plus a mandatory cooling off period. The cooling + off period may require, for example, one or more of the following: + abstaining from maintainer duties; not interacting with people involved, + including unsolicited interaction with those enforcing the guidelines + and interaction on social media; being denied participation to in-person + events. The cooling off period is voluntary but may escalate to a + temporary ban in order to enforce it. + +6. A temporary or permanent ban from some or all current and future QEMU + spaces (mailing lists, IRC, wiki, etc.), possibly including in-person + events. + +In the event of severe harassment, the leadership committee may advise that +the matter be escalated to the relevant local law enforcement agency. It +is however not the role of the leadership committee to initiate contact +with law enforcement on behalf of any of the community members involved +in an incident. + +Sources +------- + +This document was developed based on the `Drupal Conflict Resolution +Policy and Process `__ +and the `Mozilla Consequence Ladder +`__ diff --git a/docs/devel/index.rst b/docs/devel/index.rst index 7c424ea6d7..416261505f 100644 --- a/docs/devel/index.rst +++ b/docs/devel/index.rst @@ -14,6 +14,8 @@ Contents: :maxdepth: 2 :includehidden: + code-of-conduct + conflict-resolution build-system style kconfig