[PULL 00/12] Misc patches for QEMU 6.0-rc2

[PULL 00/12] Misc patches for QEMU 6.0-rc2

[Paolo Bonzini]

The following changes since commit 6ee55e1d10c25c2f6bf5ce2084ad2327e17affa5:

  Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.0-20210331' into staging (2021-03-31 13:14:18 +0100)

are available in the Git repository at:

  https://gitlab.com/bonzini/qemu.git tags/for-upstream

for you to fetch changes up to 7dd6acc82fa6fbc2ff99f173635ac6be0c72b1eb:

  docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document (2021-04-01 10:37:20 +0200)

----------------------------------------------------------------
* Bugfixes
* Code of conduct and conflict resolution policy

----------------------------------------------------------------
Jessica Clarke (1):
      meson: Propagate gnutls dependency to migration

Miroslav Rezanina (1):
      configure: Do not use default_feature for EXESUF

Paolo Bonzini (4):
      qapi: qom: do not use target-specific conditionals
      hexagon: do not specify executables as inputs
      hexagon: do not specify Python scripts as inputs
      docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document

Pavel Dovgalyuk (4):
      replay: fix recursive checkpoints
      icount: get rid of static variable
      replay: notify CPU on event
      target/openrisc: fix icount handling for timer instructions

Richard Henderson (1):
      target/i386: Verify memory operand for lcall and ljmp

Thomas Huth (1):
      Revert "qom: use qemu_printf to print help for user-creatable objects"

 configure                          |  2 +-
 docs/devel/code-of-conduct.rst     | 60 ++++++++++++++++++++++++++++
 docs/devel/conflict-resolution.rst | 80 ++++++++++++++++++++++++++++++++++++++
 docs/devel/index.rst               |  2 +
 migration/meson.build              |  2 +-
 qapi/qom.json                      | 10 ++---
 qom/object_interfaces.c            |  1 -
 replay/replay-events.c             |  2 +
 replay/replay.c                    | 11 +++---
 softmmu/cpu-timers.c               |  5 ++-
 softmmu/icount.c                   |  9 ++---
 softmmu/timers-state.h             |  2 +
 target/hexagon/meson.build         | 36 ++++++-----------
 target/i386/tcg/translate.c        |  6 +++
 target/openrisc/translate.c        | 15 +++++++
 15 files changed, 197 insertions(+), 46 deletions(-)
 create mode 100644 docs/devel/code-of-conduct.rst
 create mode 100644 docs/devel/conflict-resolution.rst
-- 
2.30.1

[PULL 01/12] meson: Propagate gnutls dependency to migration

[Paolo Bonzini]

From: Jessica Clarke <jrtc27@jrtc27.com>

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 <gnutls/gnutls.h>
           ^~~~~~~~~~~~~~~~~
  1 error generated.

(as well as for channel.c and tls.c)

Signed-off-by: Jessica Clarke <jrtc27@jrtc27.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Message-Id: <20210320171221.37437-1-jrtc27@jrtc27.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 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'))
-- 
2.30.1

[PULL 02/12] target/i386: Verify memory operand for lcall and ljmp

[Paolo Bonzini]

From: Richard Henderson <richard.henderson@linaro.org>

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 <richard.henderson@linaro.org>
Message-Id: <20210324164650.128608-1-richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 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);
-- 
2.30.1

[PULL 03/12] qapi: qom: do not use target-specific conditionals

[Paolo Bonzini]

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 <thomas.lendacky@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 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',
-- 
2.30.1

[PULL 04/12] replay: fix recursive checkpoints

[Paolo Bonzini]

From: Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>

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 <Pavel.Dovgalyuk@ispras.ru>
Message-Id: <161700476500.1140362.10108444973730452257.stgit@pasha-ThinkPad-X280>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 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;
 
-- 
2.30.1

[PULL 05/12] Revert "qom: use qemu_printf to print help for user-creatable objects"

[Paolo Bonzini]

From: Thomas Huth <thuth@redhat.com>

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 <thuth@redhat.com>
Message-Id: <20210328054758.2351461-1-thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 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)
 {
-- 
2.30.1

[PULL 06/12] icount: get rid of static variable

[Paolo Bonzini]

From: Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>

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 <Pavel.Dovgalyuk@ispras.ru>
Message-Id: <161701335066.1180180.7104085247702343395.stgit@pasha-ThinkPad-X280>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 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;
-- 
2.30.1

[PULL 07/12] replay: notify CPU on event

[Paolo Bonzini]

From: Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>

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 <Pavel.Dovgalyuk@ispras.ru>
Message-Id: <161726519158.1476949.7614181684462079836.stgit@pasha-ThinkPad-X280>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 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)
-- 
2.30.1

[PULL 08/12] target/openrisc: fix icount handling for timer instructions

[Paolo Bonzini]

From: Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>

This patch adds icount handling to mfspr/mtspr instructions
that may deal with hardware timers.

Signed-off-by: Pavel Dovgalyuk <pavel.dovgalyuk@ispras.ru>
Message-Id: <161700376169.1135890.8707223959310729949.stgit@pasha-ThinkPad-X280>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Stafford Horne <shorne@gmail.com>
---
 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
-- 
2.30.1

[PULL 09/12] configure: Do not use default_feature for EXESUF

[Paolo Bonzini]

From: Miroslav Rezanina <mrezanin@redhat.com>

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 <name>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 <mrezanin@redhat.com>
Message-Id: <20210331081845.105089-1-mrezanin@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 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"
-- 
2.30.1

[PULL 10/12] hexagon: do not specify executables as inputs

[Paolo Bonzini]

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 <pbonzini@redhat.com>
---
 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)
 
-- 
2.30.1

[PULL 11/12] hexagon: do not specify Python scripts as inputs

[Paolo Bonzini]

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 <pbonzini@redhat.com>
---
 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)
 
-- 
2.30.1

[PULL 12/12] docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document

[Paolo Bonzini]

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 <thuth@redhat.com>
Reviewed-by: David Edmondson <david.edmondson@oracle.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 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..eac75ea6d9
--- /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
+<https://fedoraproject.org/code-of-conduct>`__ and the
+`Contributor Covenant version 1.3.0
+<https://www.contributor-covenant.org/version/1/3/0/code-of-conduct/>`__.
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
+<https://wiki.qemu.org/Conservancy>`__.
+
+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 <https://www.drupal.org/conflict-resolution>`__
+and the `Mozilla Consequence Ladder
+<https://github.com/mozilla/diversity/blob/master/code-of-conduct-enforcement/consequence-ladder.md>`__
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
-- 
2.30.1

Re: [PULL 00/12] Misc patches for QEMU 6.0-rc2

[Peter Maydell]

On Thu, 1 Apr 2021 at 12:25, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
> The following changes since commit 6ee55e1d10c25c2f6bf5ce2084ad2327e17affa5:
>
>   Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.0-20210331' into staging (2021-03-31 13:14:18 +0100)
>
> are available in the Git repository at:
>
>   https://gitlab.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to 7dd6acc82fa6fbc2ff99f173635ac6be0c72b1eb:
>
>   docs: Add a QEMU Code of Conduct and Conflict Resolution Policy document (2021-04-01 10:37:20 +0200)
>
> ----------------------------------------------------------------
> * Bugfixes
> * Code of conduct and conflict resolution policy
>



Applied, thanks.

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

-- PMM