date:20200228

On 2/25/20 4:15 AM, Laurent Vivier wrote:
>hppa)
>  mttcg="yes"
> +TARGET_SYSTBL_ABI=common,64

We only support hppa32.   We don't even emulate a 64-bit cpu.

Of course... I wasn't even aware that linux had any support for a 64-bit
userland for hppa, which was one of the reasons why I hadn't bothered doing the
cpu -- no easy way to test.

r~

Re: [PATCH v3 02/21] linux-user, alpha: add syscall table generation support

On 2/25/20 4:15 AM, Laurent Vivier wrote:
> Copy syscall.tbl and syscallhdr.sh from linux/arch/alpha/kernel/syscalls v5.5
> Update syscallhdr.sh to generate QEMU syscall_nr.h
> 
> Signed-off-by: Laurent Vivier 
> ---
>  configure  |   3 +-
>  linux-user/Makefile.objs   |   2 +
>  linux-user/alpha/Makefile.objs |   5 +
>  linux-user/alpha/syscall.tbl   | 479 
>  linux-user/alpha/syscall_nr.h  | 492 -
>  linux-user/alpha/syscallhdr.sh |  32 +++
>  6 files changed, 520 insertions(+), 493 deletions(-)
>  create mode 100644 linux-user/alpha/Makefile.objs
>  create mode 100644 linux-user/alpha/syscall.tbl
>  delete mode 100644 linux-user/alpha/syscall_nr.h
>  create mode 100644 linux-user/alpha/syscallhdr.sh


Reviewed-by: Richard Henderson 

> +++ b/linux-user/alpha/syscallhdr.sh
> @@ -0,0 +1,32 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0
> +
> +in="$1"
> +out="$2"
> +my_abis=`echo "($3)" | tr ',' '|'`
> +prefix="$4"
> +offset="$5"
> +
> +fileguard=LINUX_USER_ALPHA_`basename "$out" | sed \
> +-e 'y/abcdefghijklmnopqrstuvwxyz/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' \
> +-e 's/[^A-Z0-9_]/_/g' -e 's/__/_/g'`
> +grep -E "^[0-9A-Fa-fXx]+[[:space:]]+${my_abis}" "$in" | sort -n | (
> +printf "#ifndef %s\n" "${fileguard}"
> +printf "#define %s\n" "${fileguard}"
> +printf "\n"
> +
> +nxt=0
> +while read nr abi name entry ; do
> +if [ -z "$offset" ]; then
> +printf "#define TARGET_NR_%s%s\t%s\n" \
> +"${prefix}" "${name}" "${nr}"
> +else
> +printf "#define TARGET_NR_%s%s\t(%s + %s)\n" \
> +"${prefix}" "${name}" "${offset}" "${nr}"
> +fi
> +nxt=$((nr+1))
> +done
> +
> +printf "\n"
> +printf "#endif /* %s */" "${fileguard}"
> +) > "$out"
> 

Not an objection per-se, but why does every target need its own copy of this
script?  There appears to be only the fileguard that differs between these.

Could we have a common script for the common cases?


r~

Re: [PATCH v3 01/21] linux-user: introduce parameters to generate syscall_nr.h

On 2/25/20 4:15 AM, Laurent Vivier wrote:
> This will be used when we'll import syscall.tbl from the kernel
> 
> Add a script to remove all the dependencies to syscall_nr.h
> that point to source directory and not to the build directory.
> The list of arch will be update while the generated files are added.
> 
> Signed-off-by: Laurent Vivier 
> ---
>  Makefile.target |  3 ++-
>  configure   | 14 ++
>  2 files changed, 16 insertions(+), 1 deletion(-)

Reviewed-by: Richard Henderson 


r~

Re: [PATCH v3 2/2] util: add util function buffer_zero_avx512()

2020-02-28 Thread Robert Hoo

On Fri, 2020-02-28 at 18:09 -0800, Richard Henderson wrote:
> On 2/27/20 6:24 PM, Robert Hoo wrote:
> >  if ((bv & 6) == 6 && (b & bit_AVX2)) {
> >  cache |= CACHE_AVX2;
> >  }
> > +if ((bv & 6) == 6 && (b & bit_AVX512F)) {
> > +cache |= CACHE_AVX512F;
> > +}
> 
> Oh, one more thing I missed -- we have to ensure that the 512-bit
> registers are
> enabled.  I believe the minimum is bits 6 and 7 enabled (ZMM_Hi256,
> Hi16_ZMM),
> since we don't know that the compiler won't allocate registers from
> zmm16-31.
> 
> So: (bv & 0xc6) == 0xc6.
> 
> You'd be right that some comments would be helpful on these
> lines.  :-P
> 
Oh, right, thank you very much for remind.

SDM's recommended detection on AVX512F support procedure is
1. Detect CPUID.1:ECX.OSXSAVE[bit 27] = 1 (XGETBV enabled for
application use).
2. Execute XGETBV and verify that XCR0[7:5] = 111b (OPMASK state, upper
256-bit of ZMM0-ZMM15 and ZMM16-ZMM31 state are enabled by OS) and that
XCR0[2:1] = 11b (XMM state and YMM state are enabled by OS).
3. Detect CPUID.0x7.0:EBX.AVX512F[bit 16] = 1.

I'm going to send v4 to address this.

> With that,
> Reviewed-by: Richard Henderson 
> 
> 
> r~

[PULL 4/8] tcg/arm: Expand epilogue inline

From: Richard Henderson 

It is, after all, just two instructions.

Profiling on a cortex-a15, using -d nochain to increase the number
of exit_tb that are executed, shows a minor improvement of 0.5%.

Signed-off-by: Richard Henderson 
---
 tcg/arm/tcg-target.inc.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
index e1aa740ba4..6aa7757aac 100644
--- a/tcg/arm/tcg-target.inc.c
+++ b/tcg/arm/tcg-target.inc.c
@@ -1745,7 +1745,6 @@ static void tcg_out_qemu_st(TCGContext *s, const TCGArg 
*args, bool is64)
 #endif
 }
 
-static tcg_insn_unit *tb_ret_addr;
 static void tcg_out_epilogue(TCGContext *s);
 
 static inline void tcg_out_op(TCGContext *s, TCGOpcode opc,
@@ -1756,14 +1755,8 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 
 switch (opc) {
 case INDEX_op_exit_tb:
-/* Reuse the zeroing that exists for goto_ptr.  */
-a0 = args[0];
-if (a0 == 0) {
-tcg_out_goto(s, COND_AL, s->code_gen_epilogue);
-} else {
-tcg_out_movi32(s, COND_AL, TCG_REG_R0, args[0]);
-tcg_out_goto(s, COND_AL, tb_ret_addr);
-}
+tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R0, args[0]);
+tcg_out_epilogue(s);
 break;
 case INDEX_op_goto_tb:
 {
@@ -2309,7 +2302,6 @@ static void tcg_target_qemu_prologue(TCGContext *s)
  */
 s->code_gen_epilogue = s->code_ptr;
 tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R0, 0);
-tb_ret_addr = s->code_ptr;
 tcg_out_epilogue(s);
 }
 
-- 
2.20.1

[PULL 5/8] accel/tcg: use units.h for defining code gen buffer sizes

From: Alex Bennée 

It's easier to read.

Signed-off-by: Alex Bennée 
Reviewed-by: Niek Linnenbank 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Message-Id: <20200228192415.19867-2-alex.ben...@linaro.org>
Signed-off-by: Richard Henderson 
---
 accel/tcg/translate-all.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index a08ab11f65..238b0e575b 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -18,6 +18,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include "qemu-common.h"
 
 #define NO_CPU_IO_DEFS
@@ -901,33 +902,33 @@ static void page_lock_pair(PageDesc **ret_p1, 
tb_page_addr_t phys1,
 
 /* Minimum size of the code gen buffer.  This number is randomly chosen,
but not so small that we can't have a fair number of TB's live.  */
-#define MIN_CODE_GEN_BUFFER_SIZE (1024u * 1024)
+#define MIN_CODE_GEN_BUFFER_SIZE (1 * MiB)
 
 /* Maximum size of the code gen buffer we'd like to use.  Unless otherwise
indicated, this is constrained by the range of direct branches on the
host cpu, as used by the TCG implementation of goto_tb.  */
 #if defined(__x86_64__)
-# define MAX_CODE_GEN_BUFFER_SIZE  (2ul * 1024 * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (2 * GiB)
 #elif defined(__sparc__)
-# define MAX_CODE_GEN_BUFFER_SIZE  (2ul * 1024 * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (2 * GiB)
 #elif defined(__powerpc64__)
-# define MAX_CODE_GEN_BUFFER_SIZE  (2ul * 1024 * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (2 * GiB)
 #elif defined(__powerpc__)
-# define MAX_CODE_GEN_BUFFER_SIZE  (32u * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (32 * MiB)
 #elif defined(__aarch64__)
-# define MAX_CODE_GEN_BUFFER_SIZE  (2ul * 1024 * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (2 * GiB)
 #elif defined(__s390x__)
   /* We have a +- 4GB range on the branches; leave some slop.  */
-# define MAX_CODE_GEN_BUFFER_SIZE  (3ul * 1024 * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (3 * GiB)
 #elif defined(__mips__)
   /* We have a 256MB branch region, but leave room to make sure the
  main executable is also within that region.  */
-# define MAX_CODE_GEN_BUFFER_SIZE  (128ul * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (128 * MiB)
 #else
 # define MAX_CODE_GEN_BUFFER_SIZE  ((size_t)-1)
 #endif
 
-#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32u * 1024 * 1024)
+#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB)
 
 #define DEFAULT_CODE_GEN_BUFFER_SIZE \
   (DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \
-- 
2.20.1

[PULL 2/8] compiler.h: Don't use compile-time assert when __NO_INLINE__ is defined

From: Zenghui Yu 

Our robot reported the following compile-time warning while compiling
Qemu with -fno-inline cflags:

In function 'load_memop',
inlined from 'load_helper' at /qemu/accel/tcg/cputlb.c:1578:20,
inlined from 'full_ldub_mmu' at /qemu/accel/tcg/cputlb.c:1624:12:
/qemu/accel/tcg/cputlb.c:1502:9: error: call to 'qemu_build_not_reached' 
declared with attribute error: code path is reachable
 qemu_build_not_reached();
 ^~~~
[...]

It looks like a false-positive because only (MO_UB ^ MO_BSWAP) will
hit the default case in load_memop() while need_swap (size > 1) has
already ensured that MO_UB is not involved.

So the thing is that compilers get confused by the -fno-inline and
just can't accurately evaluate memop_size(op) at compile time, and
then the qemu_build_not_reached() is wrongly triggered by (MO_UB ^
MO_BSWAP).  Let's carefully don't use the compile-time assert when
no functions will be inlined into their callers.

Reported-by: Euler Robot 
Suggested-by: Richard Henderson 
Signed-off-by: Zenghui Yu 
Message-Id: <20200205141545.180-1-yuzeng...@huawei.com>
Signed-off-by: Richard Henderson 
---
 include/qemu/compiler.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index 85c02c16d3..c76281f354 100644
--- a/include/qemu/compiler.h
+++ b/include/qemu/compiler.h
@@ -236,7 +236,7 @@
  * supports QEMU_ERROR, this will be reported at compile time; otherwise
  * this will be reported at link time due to the missing symbol.
  */
-#ifdef __OPTIMIZE__
+#if defined(__OPTIMIZE__) && !defined(__NO_INLINE__)
 extern void QEMU_NORETURN QEMU_ERROR("code path is reachable")
 qemu_build_not_reached(void);
 #else
-- 
2.20.1

[PULL 6/8] accel/tcg: remove link between guest ram and TCG cache size

From: Alex Bennée 

Basing the TB cache size on the ram_size was always a little heuristic
and was broken by a1b18df9a4 which caused ram_size not to be fully
realised at the time we initialise the TCG translation cache.

The current DEFAULT_CODE_GEN_BUFFER_SIZE may still be a little small
but follow-up patches will address that.

Fixes: a1b18df9a4
Cc: Igor Mammedov 
Signed-off-by: Alex Bennée 
Reviewed-by: Richard Henderson 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Niek Linnenbank 
Message-Id: <20200228192415.19867-3-alex.ben...@linaro.org>
Signed-off-by: Richard Henderson 
---
 accel/tcg/translate-all.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index 238b0e575b..5b66af783b 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -938,15 +938,7 @@ static inline size_t size_code_gen_buffer(size_t tb_size)
 {
 /* Size the buffer.  */
 if (tb_size == 0) {
-#ifdef USE_STATIC_CODE_GEN_BUFFER
 tb_size = DEFAULT_CODE_GEN_BUFFER_SIZE;
-#else
-/* ??? Needs adjustments.  */
-/* ??? If we relax the requirement that CONFIG_USER_ONLY use the
-   static buffer, we could size this on RESERVED_VA, on the text
-   segment size of the executable, or continue to use the default.  */
-tb_size = (unsigned long)(ram_size / 4);
-#endif
 }
 if (tb_size < MIN_CODE_GEN_BUFFER_SIZE) {
 tb_size = MIN_CODE_GEN_BUFFER_SIZE;
-- 
2.20.1

[PULL 7/8] accel/tcg: only USE_STATIC_CODE_GEN_BUFFER on 32 bit hosts

From: Alex Bennée 

There is no particular reason to use a static codegen buffer on 64 bit
hosts as we have address space to burn. Allow the common CONFIG_USER
case to use the mmap'ed buffers like SoftMMU.

Signed-off-by: Alex Bennée 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Niek Linnenbank 
Message-Id: <20200228192415.19867-4-alex.ben...@linaro.org>
Signed-off-by: Richard Henderson 
---
 accel/tcg/translate-all.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index 5b66af783b..4ce5d1b393 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -892,11 +892,12 @@ static void page_lock_pair(PageDesc **ret_p1, 
tb_page_addr_t phys1,
 }
 }
 
-#if defined(CONFIG_USER_ONLY)
-/* Currently it is not recommended to allocate big chunks of data in
-   user mode. It will change when a dedicated libc will be used.  */
-/* ??? 64-bit hosts ought to have no problem mmaping data outside the
-   region in which the guest needs to run.  Revisit this.  */
+#if defined(CONFIG_USER_ONLY) && TCG_TARGET_REG_BITS == 32
+/*
+ * For user mode on smaller 32 bit systems we may run into trouble
+ * allocating big chunks of data in the right place. On these systems
+ * we utilise a static code generation buffer directly in the binary.
+ */
 #define USE_STATIC_CODE_GEN_BUFFER
 #endif
 
-- 
2.20.1

[PULL 8/8] accel/tcg: increase default code gen buffer size for 64 bit

From: Alex Bennée 

While 32mb is certainly usable a full system boot ends up flushing the
codegen buffer nearly 100 times. Increase the default on 64 bit hosts
to take advantage of all that spare memory. After this change I can
boot my tests system without any TB flushes.

As we usually run more CONFIG_USER binaries at a time in typical usage
we aren't quite as profligate for user-mode code generation usage. We
also bring the static code gen defies to the same place to keep all
the reasoning in the comments together.

Signed-off-by: Alex Bennée 
Tested-by: Niek Linnenbank 
Reviewed-by: Niek Linnenbank 
Message-Id: <20200228192415.19867-5-alex.ben...@linaro.org>
Signed-off-by: Richard Henderson 
---
 accel/tcg/translate-all.c | 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index 4ce5d1b393..78914154bf 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -892,15 +892,6 @@ static void page_lock_pair(PageDesc **ret_p1, 
tb_page_addr_t phys1,
 }
 }
 
-#if defined(CONFIG_USER_ONLY) && TCG_TARGET_REG_BITS == 32
-/*
- * For user mode on smaller 32 bit systems we may run into trouble
- * allocating big chunks of data in the right place. On these systems
- * we utilise a static code generation buffer directly in the binary.
- */
-#define USE_STATIC_CODE_GEN_BUFFER
-#endif
-
 /* Minimum size of the code gen buffer.  This number is randomly chosen,
but not so small that we can't have a fair number of TB's live.  */
 #define MIN_CODE_GEN_BUFFER_SIZE (1 * MiB)
@@ -929,7 +920,33 @@ static void page_lock_pair(PageDesc **ret_p1, 
tb_page_addr_t phys1,
 # define MAX_CODE_GEN_BUFFER_SIZE  ((size_t)-1)
 #endif
 
+#if TCG_TARGET_REG_BITS == 32
 #define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB)
+#ifdef CONFIG_USER_ONLY
+/*
+ * For user mode on smaller 32 bit systems we may run into trouble
+ * allocating big chunks of data in the right place. On these systems
+ * we utilise a static code generation buffer directly in the binary.
+ */
+#define USE_STATIC_CODE_GEN_BUFFER
+#endif
+#else /* TCG_TARGET_REG_BITS == 64 */
+#ifdef CONFIG_USER_ONLY
+/*
+ * As user-mode emulation typically means running multiple instances
+ * of the translator don't go too nuts with our default code gen
+ * buffer lest we make things too hard for the OS.
+ */
+#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (128 * MiB)
+#else
+/*
+ * We expect most system emulation to run one or two guests per host.
+ * Users running large scale system emulation may want to tweak their
+ * runtime setup via the tb-size control on the command line.
+ */
+#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (1 * GiB)
+#endif
+#endif
 
 #define DEFAULT_CODE_GEN_BUFFER_SIZE \
   (DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \
-- 
2.20.1

[PULL 3/8] tcg/arm: Split out tcg_out_epilogue

From: Richard Henderson 

We will shortly use this function from tcg_out_op as well.

Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Richard Henderson 
---
 tcg/arm/tcg-target.inc.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/tcg/arm/tcg-target.inc.c b/tcg/arm/tcg-target.inc.c
index fffb6611e2..e1aa740ba4 100644
--- a/tcg/arm/tcg-target.inc.c
+++ b/tcg/arm/tcg-target.inc.c
@@ -1746,6 +1746,7 @@ static void tcg_out_qemu_st(TCGContext *s, const TCGArg 
*args, bool is64)
 }
 
 static tcg_insn_unit *tb_ret_addr;
+static void tcg_out_epilogue(TCGContext *s);
 
 static inline void tcg_out_op(TCGContext *s, TCGOpcode opc,
 const TCGArg *args, const int *const_args)
@@ -2284,19 +2285,17 @@ static void tcg_out_nop_fill(tcg_insn_unit *p, int 
count)
   + TCG_TARGET_STACK_ALIGN - 1) \
  & -TCG_TARGET_STACK_ALIGN)
 
+#define STACK_ADDEND  (FRAME_SIZE - PUSH_SIZE)
+
 static void tcg_target_qemu_prologue(TCGContext *s)
 {
-int stack_addend;
-
 /* Calling convention requires us to save r4-r11 and lr.  */
 /* stmdb sp!, { r4 - r11, lr } */
 tcg_out32(s, (COND_AL << 28) | 0x092d4ff0);
 
 /* Reserve callee argument and tcg temp space.  */
-stack_addend = FRAME_SIZE - PUSH_SIZE;
-
 tcg_out_dat_rI(s, COND_AL, ARITH_SUB, TCG_REG_CALL_STACK,
-   TCG_REG_CALL_STACK, stack_addend, 1);
+   TCG_REG_CALL_STACK, STACK_ADDEND, 1);
 tcg_set_frame(s, TCG_REG_CALL_STACK, TCG_STATIC_CALL_ARGS_SIZE,
   CPU_TEMP_BUF_NLONGS * sizeof(long));
 
@@ -2310,11 +2309,15 @@ static void tcg_target_qemu_prologue(TCGContext *s)
  */
 s->code_gen_epilogue = s->code_ptr;
 tcg_out_movi(s, TCG_TYPE_PTR, TCG_REG_R0, 0);
-
-/* TB epilogue */
 tb_ret_addr = s->code_ptr;
+tcg_out_epilogue(s);
+}
+
+static void tcg_out_epilogue(TCGContext *s)
+{
+/* Release local stack frame.  */
 tcg_out_dat_rI(s, COND_AL, ARITH_ADD, TCG_REG_CALL_STACK,
-   TCG_REG_CALL_STACK, stack_addend, 1);
+   TCG_REG_CALL_STACK, STACK_ADDEND, 1);
 
 /* ldmia sp!, { r4 - r11, pc } */
 tcg_out32(s, (COND_AL << 28) | 0x08bd8ff0);
-- 
2.20.1

[PULL 1/8] accel/tcg: fix race in cpu_exec_step_atomic (bug 1863025)

From: Alex Bennée 

The bug describes a race whereby cpu_exec_step_atomic can acquire a TB
which is invalidated by a tb_flush before we execute it. This doesn't
affect the other cpu_exec modes as a tb_flush by it's nature can only
occur on a quiescent system. The race was described as:

  B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code
  B3. tcg_tb_alloc obtains a new TB

  C3. TB obtained with tb_lookup__cpu_state or tb_gen_code
  (same TB as B2)

  A3. start_exclusive critical section entered
  A4. do_tb_flush is called, TB memory freed/re-allocated
  A5. end_exclusive exits critical section

  B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code
  B3. tcg_tb_alloc reallocates TB from B2

  C4. start_exclusive critical section entered
  C5. cpu_tb_exec executes the TB code that was free in A4

The simplest fix is to widen the exclusive period to include the TB
lookup. As a result we can drop the complication of checking we are in
the exclusive region before we end it.

Cc: Yifan 
Buglink: https://bugs.launchpad.net/qemu/+bug/1863025
Reviewed-by: Paolo Bonzini 
Reviewed-by: Richard Henderson 
Signed-off-by: Alex Bennée 
Message-Id: <20200214144952.15502-1-alex.ben...@linaro.org>
Signed-off-by: Richard Henderson 
---
 accel/tcg/cpu-exec.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/accel/tcg/cpu-exec.c b/accel/tcg/cpu-exec.c
index 2560c90eec..d95c4848a4 100644
--- a/accel/tcg/cpu-exec.c
+++ b/accel/tcg/cpu-exec.c
@@ -240,6 +240,8 @@ void cpu_exec_step_atomic(CPUState *cpu)
 uint32_t cf_mask = cflags & CF_HASH_MASK;
 
 if (sigsetjmp(cpu->jmp_env, 0) == 0) {
+start_exclusive();
+
 tb = tb_lookup__cpu_state(cpu, , _base, , cf_mask);
 if (tb == NULL) {
 mmap_lock();
@@ -247,8 +249,6 @@ void cpu_exec_step_atomic(CPUState *cpu)
 mmap_unlock();
 }
 
-start_exclusive();
-
 /* Since we got here, we know that parallel_cpus must be true.  */
 parallel_cpus = false;
 cc->cpu_exec_enter(cpu);
@@ -271,14 +271,15 @@ void cpu_exec_step_atomic(CPUState *cpu)
 qemu_plugin_disable_mem_helpers(cpu);
 }
 
-if (cpu_in_exclusive_context(cpu)) {
-/* We might longjump out of either the codegen or the
- * execution, so must make sure we only end the exclusive
- * region if we started it.
- */
-parallel_cpus = true;
-end_exclusive();
-}
+
+/*
+ * As we start the exclusive region before codegen we must still
+ * be in the region if we longjump out of either the codegen or
+ * the execution.
+ */
+g_assert(cpu_in_exclusive_context(cpu));
+parallel_cpus = true;
+end_exclusive();
 }
 
 struct tb_desc {
-- 
2.20.1

[PULL 0/8] tcg patch queue

The following changes since commit e0175b71638cf4398903c0d25f93fe62e0606389:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200228' 
into staging (2020-02-28 16:39:27 +)

are available in the Git repository at:

  https://github.com/rth7680/qemu.git tags/pull-tcg-20200228

for you to fetch changes up to 600e17b261555c56a048781b8dd5ba3985650013:

  accel/tcg: increase default code gen buffer size for 64 bit (2020-02-28 
17:43:31 -0800)


Fix race in cpu_exec_step_atomic.
Work around compile failure with -fno-inine.
Expand tcg/arm epilogue inline.
Adjustments to the default code gen buffer size.


Alex Bennée (5):
  accel/tcg: fix race in cpu_exec_step_atomic (bug 1863025)
  accel/tcg: use units.h for defining code gen buffer sizes
  accel/tcg: remove link between guest ram and TCG cache size
  accel/tcg: only USE_STATIC_CODE_GEN_BUFFER on 32 bit hosts
  accel/tcg: increase default code gen buffer size for 64 bit

Richard Henderson (2):
  tcg/arm: Split out tcg_out_epilogue
  tcg/arm: Expand epilogue inline

Zenghui Yu (1):
  compiler.h: Don't use compile-time assert when __NO_INLINE__ is defined

 include/qemu/compiler.h   |  2 +-
 accel/tcg/cpu-exec.c  | 21 
 accel/tcg/translate-all.c | 61 ---
 tcg/arm/tcg-target.inc.c  | 29 ++
 4 files changed, 60 insertions(+), 53 deletions(-)

RE: [PATCH v2 02/13] block/iscsi:Remove redundant statement in iscsi_open()

2020-02-28 Thread Chenqun (kuhn)

>-Original Message-
>From: Kevin Wolf [mailto:kw...@redhat.com]
>Sent: Friday, February 28, 2020 6:55 PM
>To: Chenqun (kuhn) 
>Cc: qemu-devel@nongnu.org; qemu-triv...@nongnu.org;
>peter.mayd...@linaro.org; Zhanghailiang ;
>Euler Robot ; Ronnie Sahlberg
>; Paolo Bonzini ; Peter
>Lieven ; Max Reitz 
>Subject: Re: [PATCH v2 02/13] block/iscsi:Remove redundant statement in
>iscsi_open()
>
>Am 28.02.2020 um 08:30 hat Chenqun (kuhn) geschrieben:
>> >-Original Message-
>> >From: Kevin Wolf [mailto:kw...@redhat.com]
>> >Sent: Thursday, February 27, 2020 6:31 PM
>> >To: Chenqun (kuhn) 
>> >Cc: qemu-devel@nongnu.org; qemu-triv...@nongnu.org;
>> >peter.mayd...@linaro.org; Zhanghailiang
>> >; Euler Robot
>> >; Ronnie Sahlberg
>;
>> >Paolo Bonzini ; Peter Lieven ; Max
>> >Reitz 
>> >Subject: Re: [PATCH v2 02/13] block/iscsi:Remove redundant statement
>> >in
>> >iscsi_open()
>> >
>> >Am 27.02.2020 um 02:49 hat Chenqun (kuhn) geschrieben:
>> >> >-Original Message-
>> >> >From: Kevin Wolf [mailto:kw...@redhat.com]
>> >> >Sent: Wednesday, February 26, 2020 5:55 PM
>> >> >To: Chenqun (kuhn) 
>> >> >Cc: qemu-devel@nongnu.org; qemu-triv...@nongnu.org;
>> >> >peter.mayd...@linaro.org; Zhanghailiang
>> >> >; Euler Robot
>> >> >; Ronnie Sahlberg
>> >;
>> >> >Paolo Bonzini ; Peter Lieven ;
>> >> >Max Reitz 
>> >> >Subject: Re: [PATCH v2 02/13] block/iscsi:Remove redundant
>> >> >statement in
>> >> >iscsi_open()
>> >> >
>> >> >Am 26.02.2020 um 09:46 hat kuhn.chen...@huawei.com geschrieben:
>> >> >> From: Chen Qun 
>> >> >>
>> >> >> Clang static code analyzer show warning:
>> >> >>   block/iscsi.c:1920:9: warning: Value stored to 'flags' is never read
>> >> >> flags &= ~BDRV_O_RDWR;
>> >> >> ^
>> >> >>
>> >> >> Reported-by: Euler Robot 
>> >> >> Signed-off-by: Chen Qun 
>> >> >
>> >> >Hmm, I'm not so sure about this one because if we remove the line,
>> >> >flags will be inconsistent with bs->open_flags. It feels like
>> >> >setting a trap for anyone who wants to add code using flags in the
>future.
>> >> Hi Kevin,
>> >> I find it exists since 8f3bf50d34037266.   :  )
>> >
>> >Yes, it has existed from the start with auto-read-only.
>> >
>> >> It's not a big deal,  just upset clang static code analyzer.
>> >> As you said, it could be a trap for the future.
>> >
>> >What's interesting is that we do have one user of the flags later in
>> >the function, but it uses bs->open_flags instead:
>> >
>> >ret = iscsi_allocmap_init(iscsilun, bs->open_flags);
>> >
>> >Maybe this should be using flags? (The value of the bits we're
>> >interested in is the same, but when flags is passed as a parameter, I
>> >would expect it to be
>> >used.)
>> >
>> Hi Kevin,
>> I have a question: are 'flags' exactly the same as 'bs-> open_flags'?
>> In the function bdrv_open_common() at block.c file,  the existence of
>statement( open_flags = bdrv_open_flags(bs, bs->open_flags); ) makes them
>a little different.
>> Will this place affect them inconsistently ?
>
>Not exactly the same, that's why I said "value of the bits we're interested in 
>is
>the same". bdrv_open_flags() basically just filters out things that are handled
>by the generic block layer and none of the block driver's business.
>
>To be precise, iscsi_allocmap_init() only checks BDRV_O_NOCACHE, which is
>the same in both.
>
>> Is it safer if we assign bs-> open_flags to flags?
>
>This would add back the flags that we consciously filtered out before, so I
>would say no.
>
Well, I see, thank you very much for your detailed explanation!

Thanks.

Re: [PATCH v3 2/2] util: add util function buffer_zero_avx512()

On 2/27/20 6:24 PM, Robert Hoo wrote:
>  if ((bv & 6) == 6 && (b & bit_AVX2)) {
>  cache |= CACHE_AVX2;
>  }
> +if ((bv & 6) == 6 && (b & bit_AVX512F)) {
> +cache |= CACHE_AVX512F;
> +}

Oh, one more thing I missed -- we have to ensure that the 512-bit registers are
enabled.  I believe the minimum is bits 6 and 7 enabled (ZMM_Hi256, Hi16_ZMM),
since we don't know that the compiler won't allocate registers from zmm16-31.

So: (bv & 0xc6) == 0xc6.

You'd be right that some comments would be helpful on these lines.  :-P

With that,
Reviewed-by: Richard Henderson 

r~

Re: [PATCH v3 1/2] configure: add configure option avx512f_opt

On 2/27/20 6:24 PM, Robert Hoo wrote:
> If it is enabled, config-host.mak will have CONFIG_AVX512F_OPT defined.
> 
> AVX512F instruction set is available since Intel Skylake, and can be enabled 
> in
> compiling with -mavx512f.
> More info:
> https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
> 
> Signed-off-by: Robert Hoo 
> ---
>  configure | 41 +
>  1 file changed, 41 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [PATCH] linux-user: Add an argument QEMU_MMAP_BASE to set custom mmap base address in qemu user mode

2020-02-28 Thread Lirong Yuan

On Fri, Feb 21, 2020 at 5:09 PM Lirong Yuan  wrote:
>
> This change allows us to set custom base address for guest programs. It is 
> needed to allow qemu to work with Thread Sanitizer (TSan), which has specific 
> boundary definitions for memory mappings on different platforms:
> https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/tsan/rtl/tsan_platform.h
>
> Signed-off-by: Lirong Yuan 
> ---
>  linux-user/main.c | 12 
>  linux-user/mmap.c |  3 ++-
>  linux-user/qemu.h |  5 +
>  3 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index fba833aac9..c01af6bfee 100644
> --- a/linux-user/main.c
> +++ b/linux-user/main.c
> @@ -336,6 +336,16 @@ static void handle_arg_guest_base(const char *arg)
>  have_guest_base = 1;
>  }
>
> +static void handle_arg_mmap_base(const char *arg)
> +{
> +int err = qemu_strtoul(arg, NULL, 0, _base);
> +if (err) {
> +fprintf(stderr, "Invalid mmap_base: %s, err: %d\n", arg, err);
> +exit(EXIT_FAILURE);
> +}
> +mmap_next_start = mmap_base;
> +}
> +
>  static void handle_arg_reserved_va(const char *arg)
>  {
>  char *p;
> @@ -440,6 +450,8 @@ static const struct qemu_argument arg_table[] = {
>   "uname",  "set qemu uname release string to 'uname'"},
>  {"B",  "QEMU_GUEST_BASE",  true,  handle_arg_guest_base,
>   "address","set guest_base address to 'address'"},
> +{"mmap_base",  "QEMU_MMAP_BASE",   true,  handle_arg_mmap_base,
> + "",   "begin allocating guest pages at this host address"},
>  {"R",  "QEMU_RESERVED_VA", true,  handle_arg_reserved_va,
>   "size",   "reserve 'size' bytes for guest virtual address space"},
>  {"d",  "QEMU_LOG", true,  handle_arg_log,
> diff --git a/linux-user/mmap.c b/linux-user/mmap.c
> index 8685f02e7e..3f35543acf 100644
> --- a/linux-user/mmap.c
> +++ b/linux-user/mmap.c
> @@ -189,6 +189,7 @@ static int mmap_frag(abi_ulong real_start,
>  # define TASK_UNMAPPED_BASE  0x4000
>  #endif
>  abi_ulong mmap_next_start = TASK_UNMAPPED_BASE;
> +abi_ulong mmap_base = TASK_UNMAPPED_BASE;
>
>  unsigned long last_brk;
>
> @@ -299,7 +300,7 @@ abi_ulong mmap_find_vma(abi_ulong start, abi_ulong size, 
> abi_ulong align)
>
>  if ((addr & (align - 1)) == 0) {
>  /* Success.  */
> -if (start == mmap_next_start && addr >= TASK_UNMAPPED_BASE) {
> +if (start == mmap_next_start && addr >= mmap_base) {
>  mmap_next_start = addr + size;
>  }
>  return addr;
> diff --git a/linux-user/qemu.h b/linux-user/qemu.h
> index 560a68090e..83c00cfea2 100644
> --- a/linux-user/qemu.h
> +++ b/linux-user/qemu.h
> @@ -161,6 +161,11 @@ void task_settid(TaskState *);
>  void stop_all_tasks(void);
>  extern const char *qemu_uname_release;
>  extern unsigned long mmap_min_addr;
> +/*
> + * mmap_base is minimum address to use when allocating guest pages. All guest
> + * pages will be allocated at this (guest) address or higher addresses.
> + */
> +extern abi_ulong mmap_base;
>
>  /* ??? See if we can avoid exposing so much of the loader internals.  */
>
> --
> 2.25.0.265.gbab2e86ba0-goog
>

Friendly ping~

Link to the page for the patch on patchwork:
http://patchwork.ozlabs.org/patch/1242370/

Re: [PATCH] linux-user: Add AT_EXECFN and AT_EXECFD auxval

2020-02-28 Thread Lirong Yuan

On Fri, Feb 21, 2020 at 12:29 PM Lirong Yuan  wrote:
>
> This change adds the support for AT_EXECFN and AT_EXECFD auxval.
>
> Signed-off-by: Lirong Yuan 
> ---
>  linux-user/elfload.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/linux-user/elfload.c b/linux-user/elfload.c
> index f3080a1635..7e0f3042f1 100644
> --- a/linux-user/elfload.c
> +++ b/linux-user/elfload.c
> @@ -1568,7 +1568,7 @@ struct exec
>   ~(abi_ulong)(TARGET_ELF_EXEC_PAGESIZE-1))
>  #define TARGET_ELF_PAGEOFFSET(_v) ((_v) & (TARGET_ELF_EXEC_PAGESIZE-1))
>
> -#define DLINFO_ITEMS 15
> +#define DLINFO_ITEMS 17
>
>  static inline void memcpy_fromfs(void * to, const void * from, unsigned long 
> n)
>  {
> @@ -1888,11 +1888,14 @@ static abi_ulong loader_build_fdpic_loadmap(struct 
> image_info *info, abi_ulong s
>  return sp;
>  }
>
> -static abi_ulong create_elf_tables(abi_ulong p, int argc, int envc,
> +static abi_ulong create_elf_tables(struct linux_binprm *bprm,
> struct elfhdr *exec,
> struct image_info *info,
> struct image_info *interp_info)
>  {
> +abi_ulong p = bprm->p;
> +int argc = bprm->argc;
> +int envc = bprm->envc;
>  abi_ulong sp;
>  abi_ulong u_argc, u_argv, u_envp, u_auxv;
>  int size;
> @@ -2032,6 +2035,8 @@ static abi_ulong create_elf_tables(abi_ulong p, int 
> argc, int envc,
>  NEW_AUX_ENT(AT_CLKTCK, (abi_ulong) sysconf(_SC_CLK_TCK));
>  NEW_AUX_ENT(AT_RANDOM, (abi_ulong) u_rand_bytes);
>  NEW_AUX_ENT(AT_SECURE, (abi_ulong) qemu_getauxval(AT_SECURE));
> +NEW_AUX_ENT(AT_EXECFN, info->file_string);
> +NEW_AUX_ENT(AT_EXECFD, bprm->fd);
>
>  #ifdef ELF_HWCAP2
>  NEW_AUX_ENT(AT_HWCAP2, (abi_ulong) ELF_HWCAP2);
> @@ -2870,8 +2875,8 @@ int load_elf_binary(struct linux_binprm *bprm, struct 
> image_info *info)
>  #endif
>  }
>
> -bprm->p = create_elf_tables(bprm->p, bprm->argc, bprm->envc, _ex,
> -info, (elf_interpreter ? _info : 
> NULL));
> +bprm->p = create_elf_tables(bprm, _ex, info,
> +(elf_interpreter ? _info : NULL));
>  info->start_stack = bprm->p;
>
>  /* If we have an interpreter, set that as the program's entry point.
> --
> 2.25.0.265.gbab2e86ba0-goog
>

Friendly ping~

Link to the page for the patch on patchwork:
http://patchwork.ozlabs.org/patch/1242331/

Re: [PATCH v2 0/4] Clean-up codegen cache size

On 2/28/20 11:24 AM, Alex Bennée wrote:
> Hi,
> 
> A few tweaks to the final commit so we are a little less greedy for
> translation buffer, especially for the CONFIG_USER case. Otherwise
> I've applied the review tags.
> 
> Alex Bennée (4):
>   accel/tcg: use units.h for defining code gen buffer sizes
>   accel/tcg: remove link between guest ram and TCG cache size
>   accel/tcg: only USE_STATIC_CODE_GEN_BUFFER on 32 bit hosts
>   accel/tcg: increase default code gen buffer size for 64 bit
> 
>  accel/tcg/translate-all.c | 61 +++
>  1 file changed, 36 insertions(+), 25 deletions(-)

Applied to tcg-next.


r~

[PATCH v5 11/12] target/arm: Honor the HCR_EL2.TTLB bit

This bit traps EL1 access to tlb maintenance insns.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 85 +
 1 file changed, 55 insertions(+), 30 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 40faa70cb7..2f148e0dc2 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -563,6 +563,16 @@ static CPAccessResult access_tacr(CPUARMState *env, const 
ARMCPRegInfo *ri,
 return CP_ACCESS_OK;
 }
 
+/* Check for traps from EL1 due to HCR_EL2.TTLB. */
+static CPAccessResult access_ttlb(CPUARMState *env, const ARMCPRegInfo *ri,
+  bool isread)
+{
+if (arm_current_el(env) == 1 && (arm_hcr_el2_eff(env) & HCR_TTLB)) {
+return CP_ACCESS_TRAP_EL2;
+}
+return CP_ACCESS_OK;
+}
+
 static void dacr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t 
value)
 {
 ARMCPU *cpu = env_archcpu(env);
@@ -2285,41 +2295,53 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
   .type = ARM_CP_NO_RAW, .access = PL1_R, .readfn = isr_read },
 /* 32 bit ITLB invalidates */
 { .name = "ITLBIALL", .cp = 15, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 0,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbiall_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbiall_write },
 { .name = "ITLBIMVA", .cp = 15, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 1,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbimva_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbimva_write },
 { .name = "ITLBIASID", .cp = 15, .opc1 = 0, .crn = 8, .crm = 5, .opc2 = 2,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbiasid_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbiasid_write },
 /* 32 bit DTLB invalidates */
 { .name = "DTLBIALL", .cp = 15, .opc1 = 0, .crn = 8, .crm = 6, .opc2 = 0,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbiall_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbiall_write },
 { .name = "DTLBIMVA", .cp = 15, .opc1 = 0, .crn = 8, .crm = 6, .opc2 = 1,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbimva_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbimva_write },
 { .name = "DTLBIASID", .cp = 15, .opc1 = 0, .crn = 8, .crm = 6, .opc2 = 2,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbiasid_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbiasid_write },
 /* 32 bit TLB invalidates */
 { .name = "TLBIALL", .cp = 15, .opc1 = 0, .crn = 8, .crm = 7, .opc2 = 0,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbiall_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbiall_write },
 { .name = "TLBIMVA", .cp = 15, .opc1 = 0, .crn = 8, .crm = 7, .opc2 = 1,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbimva_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbimva_write },
 { .name = "TLBIASID", .cp = 15, .opc1 = 0, .crn = 8, .crm = 7, .opc2 = 2,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbiasid_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbiasid_write },
 { .name = "TLBIMVAA", .cp = 15, .opc1 = 0, .crn = 8, .crm = 7, .opc2 = 3,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbimvaa_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbimvaa_write },
 REGINFO_SENTINEL
 };
 
 static const ARMCPRegInfo v7mp_cp_reginfo[] = {
 /* 32 bit TLB invalidates, Inner Shareable */
 { .name = "TLBIALLIS", .cp = 15, .opc1 = 0, .crn = 8, .crm = 3, .opc2 = 0,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbiall_is_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbiall_is_write },
 { .name = "TLBIMVAIS", .cp = 15, .opc1 = 0, .crn = 8, .crm = 3, .opc2 = 1,
-  .type = ARM_CP_NO_RAW, .access = PL1_W, .writefn = tlbimva_is_write },
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
+  .writefn = tlbimva_is_write },
 { .name = "TLBIASIDIS", .cp = 15, .opc1 = 0, .crn = 8, .crm = 3, .opc2 = 2,
-  .type = ARM_CP_NO_RAW, .access = PL1_W,
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
   .writefn = tlbiasid_is_write },
 { .name = "TLBIMVAAIS", .cp = 15, .opc1 = 0, .crn = 8, .crm = 3, .opc2 = 3,
-  .type = ARM_CP_NO_RAW, .access = PL1_W,
+  .type = ARM_CP_NO_RAW, .access = PL1_W, .accessfn = access_ttlb,
   .writefn = tlbimvaa_is_write },
 REGINFO_SENTINEL
 };
@@

[PATCH v5 12/12] tests/tcg/aarch64: Add newline in pauth-1 printf

Make the output just a bit prettier when running by hand.

Cc: Alex Bennée 
Signed-off-by: Richard Henderson 
---
 tests/tcg/aarch64/pauth-1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/tcg/aarch64/pauth-1.c b/tests/tcg/aarch64/pauth-1.c
index ea0984ea82..d3878cbeb6 100644
--- a/tests/tcg/aarch64/pauth-1.c
+++ b/tests/tcg/aarch64/pauth-1.c
@@ -29,7 +29,7 @@ int main()
 }
 
 perc = (float) count / (float) (TESTS * 2);
-printf("Ptr Check: %0.2f%%", perc * 100.0);
+printf("Ptr Check: %0.2f%%\n", perc * 100.0);
 assert(perc > 0.95);
 return 0;
 }
-- 
2.20.1

[PATCH v5 08/12] target/arm: Honor the HCR_EL2.TACR bit

This bit traps EL1 access to the auxiliary control registers.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index ddef3d7dc3..2c06ac8d02 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -553,6 +553,16 @@ static CPAccessResult access_tsw(CPUARMState *env, const 
ARMCPRegInfo *ri,
 return CP_ACCESS_OK;
 }
 
+/* Check for traps from EL1 due to HCR_EL2.TACR.  */
+static CPAccessResult access_tacr(CPUARMState *env, const ARMCPRegInfo *ri,
+  bool isread)
+{
+if (arm_current_el(env) == 1 && (arm_hcr_el2_eff(env) & HCR_TACR)) {
+return CP_ACCESS_TRAP_EL2;
+}
+return CP_ACCESS_OK;
+}
+
 static void dacr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t 
value)
 {
 ARMCPU *cpu = env_archcpu(env);
@@ -6961,8 +6971,8 @@ static const ARMCPRegInfo ats1cp_reginfo[] = {
 static const ARMCPRegInfo actlr2_hactlr2_reginfo[] = {
 { .name = "ACTLR2", .state = ARM_CP_STATE_AA32,
   .cp = 15, .opc1 = 0, .crn = 1, .crm = 0, .opc2 = 3,
-  .access = PL1_RW, .type = ARM_CP_CONST,
-  .resetvalue = 0 },
+  .access = PL1_RW, .accessfn = access_tacr,
+  .type = ARM_CP_CONST, .resetvalue = 0 },
 { .name = "HACTLR2", .state = ARM_CP_STATE_AA32,
   .cp = 15, .opc1 = 4, .crn = 1, .crm = 0, .opc2 = 3,
   .access = PL2_RW, .type = ARM_CP_CONST,
@@ -7718,8 +7728,8 @@ void register_cp_regs_for_features(ARMCPU *cpu)
 ARMCPRegInfo auxcr_reginfo[] = {
 { .name = "ACTLR_EL1", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 0, .crn = 1, .crm = 0, .opc2 = 1,
-  .access = PL1_RW, .type = ARM_CP_CONST,
-  .resetvalue = cpu->reset_auxcr },
+  .access = PL1_RW, .accessfn = access_tacr,
+  .type = ARM_CP_CONST, .resetvalue = cpu->reset_auxcr },
 { .name = "ACTLR_EL2", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 4, .crn = 1, .crm = 0, .opc2 = 1,
   .access = PL2_RW, .type = ARM_CP_CONST,
-- 
2.20.1

[PATCH v5 07/12] target/arm: Honor the HCR_EL2.TSW bit

These bits trap EL1 access to set/way cache maintenance insns.

Buglink: https://bugs.launchpad.net/bugs/1863685
Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 1f371b0391..ddef3d7dc3 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -543,6 +543,16 @@ static CPAccessResult access_tvm_trvm(CPUARMState *env, 
const ARMCPRegInfo *ri,
 return CP_ACCESS_OK;
 }
 
+/* Check for traps from EL1 due to HCR_EL2.TSW.  */
+static CPAccessResult access_tsw(CPUARMState *env, const ARMCPRegInfo *ri,
+ bool isread)
+{
+if (arm_current_el(env) == 1 && (arm_hcr_el2_eff(env) & HCR_TSW)) {
+return CP_ACCESS_TRAP_EL2;
+}
+return CP_ACCESS_OK;
+}
+
 static void dacr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t 
value)
 {
 ARMCPU *cpu = env_archcpu(env);
@@ -4704,14 +4714,14 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
   .access = PL1_W, .type = ARM_CP_NOP },
 { .name = "DC_ISW", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 6, .opc2 = 2,
-  .access = PL1_W, .type = ARM_CP_NOP },
+  .access = PL1_W, .accessfn = access_tsw, .type = ARM_CP_NOP },
 { .name = "DC_CVAC", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 3, .crn = 7, .crm = 10, .opc2 = 1,
   .access = PL0_W, .type = ARM_CP_NOP,
   .accessfn = aa64_cacheop_access },
 { .name = "DC_CSW", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 10, .opc2 = 2,
-  .access = PL1_W, .type = ARM_CP_NOP },
+  .access = PL1_W, .accessfn = access_tsw, .type = ARM_CP_NOP },
 { .name = "DC_CVAU", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 3, .crn = 7, .crm = 11, .opc2 = 1,
   .access = PL0_W, .type = ARM_CP_NOP,
@@ -4722,7 +4732,7 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
   .accessfn = aa64_cacheop_access },
 { .name = "DC_CISW", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 14, .opc2 = 2,
-  .access = PL1_W, .type = ARM_CP_NOP },
+  .access = PL1_W, .accessfn = access_tsw, .type = ARM_CP_NOP },
 /* TLBI operations */
 { .name = "TLBI_VMALLE1IS", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 8, .crm = 3, .opc2 = 0,
@@ -4903,17 +4913,17 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
 { .name = "DCIMVAC", .cp = 15, .opc1 = 0, .crn = 7, .crm = 6, .opc2 = 1,
   .type = ARM_CP_NOP, .access = PL1_W },
 { .name = "DCISW", .cp = 15, .opc1 = 0, .crn = 7, .crm = 6, .opc2 = 2,
-  .type = ARM_CP_NOP, .access = PL1_W },
+  .type = ARM_CP_NOP, .access = PL1_W, .accessfn = access_tsw },
 { .name = "DCCMVAC", .cp = 15, .opc1 = 0, .crn = 7, .crm = 10, .opc2 = 1,
   .type = ARM_CP_NOP, .access = PL1_W },
 { .name = "DCCSW", .cp = 15, .opc1 = 0, .crn = 7, .crm = 10, .opc2 = 2,
-  .type = ARM_CP_NOP, .access = PL1_W },
+  .type = ARM_CP_NOP, .access = PL1_W, .accessfn = access_tsw },
 { .name = "DCCMVAU", .cp = 15, .opc1 = 0, .crn = 7, .crm = 11, .opc2 = 1,
   .type = ARM_CP_NOP, .access = PL1_W },
 { .name = "DCCIMVAC", .cp = 15, .opc1 = 0, .crn = 7, .crm = 14, .opc2 = 1,
   .type = ARM_CP_NOP, .access = PL1_W },
 { .name = "DCCISW", .cp = 15, .opc1 = 0, .crn = 7, .crm = 14, .opc2 = 2,
-  .type = ARM_CP_NOP, .access = PL1_W },
+  .type = ARM_CP_NOP, .access = PL1_W, .accessfn = access_tsw },
 /* MMU Domain access control / MPU write buffer control */
 { .name = "DACR", .cp = 15, .opc1 = 0, .crn = 3, .crm = 0, .opc2 = 0,
   .access = PL1_RW, .accessfn = access_tvm_trvm, .resetvalue = 0,
-- 
2.20.1

[PATCH v5 09/12] target/arm: Honor the HCR_EL2.TPCP bit

This bit traps EL1 access to cache maintenance insns that operate
to the point of coherency or persistence.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v3: Fix el0 fallthru (pmm).
---
 target/arm/helper.c | 39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 2c06ac8d02..e87a76c6f5 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -4314,6 +4314,28 @@ static CPAccessResult aa64_cacheop_access(CPUARMState 
*env,
 return CP_ACCESS_OK;
 }
 
+static CPAccessResult aa64_cacheop_poc_access(CPUARMState *env,
+  const ARMCPRegInfo *ri,
+  bool isread)
+{
+/* Cache invalidate/clean to Point of Coherency or Persistence...  */
+switch (arm_current_el(env)) {
+case 0:
+/* ... EL0 must UNDEF unless SCTLR_EL1.UCI is set.  */
+if (!(arm_sctlr(env, 0) & SCTLR_UCI)) {
+return CP_ACCESS_TRAP;
+}
+/* fall through */
+case 1:
+/* ... EL1 must trap to EL2 if HCR_EL2.TPCP is set.  */
+if (arm_hcr_el2_eff(env) & HCR_TPCP) {
+return CP_ACCESS_TRAP_EL2;
+}
+break;
+}
+return CP_ACCESS_OK;
+}
+
 /* See: D4.7.2 TLB maintenance requirements and the TLB maintenance 
instructions
  * Page D4-1736 (DDI0487A.b)
  */
@@ -4721,14 +4743,15 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
   .accessfn = aa64_cacheop_access },
 { .name = "DC_IVAC", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 6, .opc2 = 1,
-  .access = PL1_W, .type = ARM_CP_NOP },
+  .access = PL1_W, .accessfn = aa64_cacheop_poc_access,
+  .type = ARM_CP_NOP },
 { .name = "DC_ISW", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 6, .opc2 = 2,
   .access = PL1_W, .accessfn = access_tsw, .type = ARM_CP_NOP },
 { .name = "DC_CVAC", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 3, .crn = 7, .crm = 10, .opc2 = 1,
   .access = PL0_W, .type = ARM_CP_NOP,
-  .accessfn = aa64_cacheop_access },
+  .accessfn = aa64_cacheop_poc_access },
 { .name = "DC_CSW", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 10, .opc2 = 2,
   .access = PL1_W, .accessfn = access_tsw, .type = ARM_CP_NOP },
@@ -4739,7 +4762,7 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
 { .name = "DC_CIVAC", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 3, .crn = 7, .crm = 14, .opc2 = 1,
   .access = PL0_W, .type = ARM_CP_NOP,
-  .accessfn = aa64_cacheop_access },
+  .accessfn = aa64_cacheop_poc_access },
 { .name = "DC_CISW", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 14, .opc2 = 2,
   .access = PL1_W, .accessfn = access_tsw, .type = ARM_CP_NOP },
@@ -4921,17 +4944,17 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
 { .name = "BPIMVA", .cp = 15, .opc1 = 0, .crn = 7, .crm = 5, .opc2 = 7,
   .type = ARM_CP_NOP, .access = PL1_W },
 { .name = "DCIMVAC", .cp = 15, .opc1 = 0, .crn = 7, .crm = 6, .opc2 = 1,
-  .type = ARM_CP_NOP, .access = PL1_W },
+  .type = ARM_CP_NOP, .access = PL1_W, .accessfn = aa64_cacheop_poc_access 
},
 { .name = "DCISW", .cp = 15, .opc1 = 0, .crn = 7, .crm = 6, .opc2 = 2,
   .type = ARM_CP_NOP, .access = PL1_W, .accessfn = access_tsw },
 { .name = "DCCMVAC", .cp = 15, .opc1 = 0, .crn = 7, .crm = 10, .opc2 = 1,
-  .type = ARM_CP_NOP, .access = PL1_W },
+  .type = ARM_CP_NOP, .access = PL1_W, .accessfn = aa64_cacheop_poc_access 
},
 { .name = "DCCSW", .cp = 15, .opc1 = 0, .crn = 7, .crm = 10, .opc2 = 2,
   .type = ARM_CP_NOP, .access = PL1_W, .accessfn = access_tsw },
 { .name = "DCCMVAU", .cp = 15, .opc1 = 0, .crn = 7, .crm = 11, .opc2 = 1,
   .type = ARM_CP_NOP, .access = PL1_W },
 { .name = "DCCIMVAC", .cp = 15, .opc1 = 0, .crn = 7, .crm = 14, .opc2 = 1,
-  .type = ARM_CP_NOP, .access = PL1_W },
+  .type = ARM_CP_NOP, .access = PL1_W, .accessfn = aa64_cacheop_poc_access 
},
 { .name = "DCCISW", .cp = 15, .opc1 = 0, .crn = 7, .crm = 14, .opc2 = 2,
   .type = ARM_CP_NOP, .access = PL1_W, .accessfn = access_tsw },
 /* MMU Domain access control / MPU write buffer control */
@@ -6750,7 +6773,7 @@ static const ARMCPRegInfo dcpop_reg[] = {
 { .name = "DC_CVAP", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 3, .crn = 7, .crm = 12, .opc2 = 1,
   .access = PL0_W, .type = ARM_CP_NO_RAW | ARM_CP_SUPPRESS_TB_END,
-  .accessfn = aa64_cacheop_access, .writefn = dccvap_writefn },
+  .accessfn = aa64_cacheop_poc_access, .writefn = dccvap_writefn },
 REGINFO_SENTINEL
 };
 
@@ -6758,7 +6781,7 @@ static const ARMCPRegInfo dcpodp_reg[] = {
 { .name = "DC_CVADP", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 3, .crn = 7, .crm = 13, .opc2 = 1,
   .access = PL0_W,

[PATCH v5 03/12] target/arm: Disable has_el2 and has_el3 for user-only

In arm_cpu_reset, we configure many system registers so that user-only
behaves as it should with a minimum of ifdefs.  However, we do not set
all of the system registers as required for a cpu with EL2 and EL3.

Disabling EL2 and EL3 mean that we will not look at those registers,
which means that we don't have to worry about configuring them.

Signed-off-by: Richard Henderson 
---
 target/arm/cpu.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index e6016e33ce..33c28fe868 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1103,11 +1103,13 @@ static Property arm_cpu_reset_hivecs_property =
 static Property arm_cpu_rvbar_property =
 DEFINE_PROP_UINT64("rvbar", ARMCPU, rvbar, 0);
 
+#ifndef CONFIG_USER_ONLY
 static Property arm_cpu_has_el2_property =
 DEFINE_PROP_BOOL("has_el2", ARMCPU, has_el2, true);
 
 static Property arm_cpu_has_el3_property =
 DEFINE_PROP_BOOL("has_el3", ARMCPU, has_el3, true);
+#endif
 
 static Property arm_cpu_cfgend_property =
 DEFINE_PROP_BOOL("cfgend", ARMCPU, cfgend, false);
@@ -1222,25 +1224,25 @@ void arm_cpu_post_init(Object *obj)
 qdev_property_add_static(DEVICE(obj), _cpu_rvbar_property);
 }
 
+#ifndef CONFIG_USER_ONLY
 if (arm_feature(>env, ARM_FEATURE_EL3)) {
 /* Add the has_el3 state CPU property only if EL3 is allowed.  This 
will
  * prevent "has_el3" from existing on CPUs which cannot support EL3.
  */
 qdev_property_add_static(DEVICE(obj), _cpu_has_el3_property);
 
-#ifndef CONFIG_USER_ONLY
 object_property_add_link(obj, "secure-memory",
  TYPE_MEMORY_REGION,
  (Object **)>secure_memory,
  qdev_prop_allow_set_link_before_realize,
  OBJ_PROP_LINK_STRONG,
  _abort);
-#endif
 }
 
 if (arm_feature(>env, ARM_FEATURE_EL2)) {
 qdev_property_add_static(DEVICE(obj), _cpu_has_el2_property);
 }
+#endif
 
 if (arm_feature(>env, ARM_FEATURE_PMU)) {
 cpu->has_pmu = true;
-- 
2.20.1

[PATCH v5 10/12] target/arm: Honor the HCR_EL2.TPU bit

This bit traps EL1 access to cache maintenance insns that operate
to the point of unification.  There are no longer any references to
plain aa64_cacheop_access, so remove it.

Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v3: Fix el0 fallthru (pmm).
---
 target/arm/helper.c | 53 +++--
 1 file changed, 32 insertions(+), 21 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index e87a76c6f5..40faa70cb7 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -4301,19 +4301,6 @@ static const ARMCPRegInfo uao_reginfo = {
 .readfn = aa64_uao_read, .writefn = aa64_uao_write
 };
 
-static CPAccessResult aa64_cacheop_access(CPUARMState *env,
-  const ARMCPRegInfo *ri,
-  bool isread)
-{
-/* Cache invalidate/clean: NOP, but EL0 must UNDEF unless
- * SCTLR_EL1.UCI is set.
- */
-if (arm_current_el(env) == 0 && !(arm_sctlr(env, 0) & SCTLR_UCI)) {
-return CP_ACCESS_TRAP;
-}
-return CP_ACCESS_OK;
-}
-
 static CPAccessResult aa64_cacheop_poc_access(CPUARMState *env,
   const ARMCPRegInfo *ri,
   bool isread)
@@ -4336,6 +4323,28 @@ static CPAccessResult 
aa64_cacheop_poc_access(CPUARMState *env,
 return CP_ACCESS_OK;
 }
 
+static CPAccessResult aa64_cacheop_pou_access(CPUARMState *env,
+  const ARMCPRegInfo *ri,
+  bool isread)
+{
+/* Cache invalidate/clean to Point of Unification... */
+switch (arm_current_el(env)) {
+case 0:
+/* ... EL0 must UNDEF unless SCTLR_EL1.UCI is set.  */
+if (!(arm_sctlr(env, 0) & SCTLR_UCI)) {
+return CP_ACCESS_TRAP;
+}
+/* fall through */
+case 1:
+/* ... EL1 must trap to EL2 if HCR_EL2.TPU is set.  */
+if (arm_hcr_el2_eff(env) & HCR_TPU) {
+return CP_ACCESS_TRAP_EL2;
+}
+break;
+}
+return CP_ACCESS_OK;
+}
+
 /* See: D4.7.2 TLB maintenance requirements and the TLB maintenance 
instructions
  * Page D4-1736 (DDI0487A.b)
  */
@@ -4733,14 +4742,16 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
 /* Cache ops: all NOPs since we don't emulate caches */
 { .name = "IC_IALLUIS", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 1, .opc2 = 0,
-  .access = PL1_W, .type = ARM_CP_NOP },
+  .access = PL1_W, .type = ARM_CP_NOP,
+  .accessfn = aa64_cacheop_pou_access },
 { .name = "IC_IALLU", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 5, .opc2 = 0,
-  .access = PL1_W, .type = ARM_CP_NOP },
+  .access = PL1_W, .type = ARM_CP_NOP,
+  .accessfn = aa64_cacheop_pou_access },
 { .name = "IC_IVAU", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 3, .crn = 7, .crm = 5, .opc2 = 1,
   .access = PL0_W, .type = ARM_CP_NOP,
-  .accessfn = aa64_cacheop_access },
+  .accessfn = aa64_cacheop_pou_access },
 { .name = "DC_IVAC", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 0, .crn = 7, .crm = 6, .opc2 = 1,
   .access = PL1_W, .accessfn = aa64_cacheop_poc_access,
@@ -4758,7 +4769,7 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
 { .name = "DC_CVAU", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 3, .crn = 7, .crm = 11, .opc2 = 1,
   .access = PL0_W, .type = ARM_CP_NOP,
-  .accessfn = aa64_cacheop_access },
+  .accessfn = aa64_cacheop_pou_access },
 { .name = "DC_CIVAC", .state = ARM_CP_STATE_AA64,
   .opc0 = 1, .opc1 = 3, .crn = 7, .crm = 14, .opc2 = 1,
   .access = PL0_W, .type = ARM_CP_NOP,
@@ -4932,13 +4943,13 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
   .writefn = tlbiipas2_is_write },
 /* 32 bit cache operations */
 { .name = "ICIALLUIS", .cp = 15, .opc1 = 0, .crn = 7, .crm = 1, .opc2 = 0,
-  .type = ARM_CP_NOP, .access = PL1_W },
+  .type = ARM_CP_NOP, .access = PL1_W, .accessfn = aa64_cacheop_pou_access 
},
 { .name = "BPIALLUIS", .cp = 15, .opc1 = 0, .crn = 7, .crm = 1, .opc2 = 6,
   .type = ARM_CP_NOP, .access = PL1_W },
 { .name = "ICIALLU", .cp = 15, .opc1 = 0, .crn = 7, .crm = 5, .opc2 = 0,
-  .type = ARM_CP_NOP, .access = PL1_W },
+  .type = ARM_CP_NOP, .access = PL1_W, .accessfn = aa64_cacheop_pou_access 
},
 { .name = "ICIMVAU", .cp = 15, .opc1 = 0, .crn = 7, .crm = 5, .opc2 = 1,
-  .type = ARM_CP_NOP, .access = PL1_W },
+  .type = ARM_CP_NOP, .access = PL1_W, .accessfn = aa64_cacheop_pou_access 
},
 { .name = "BPIALL", .cp = 15, .opc1 = 0, .crn = 7, .crm = 5, .opc2 = 6,
   .type = ARM_CP_NOP, .access = PL1_W },
 { .name = "BPIMVA", .cp = 15, .opc1 = 0, .crn = 7, .crm = 5, .opc2 = 7,
@@ -4952,7 +4963,7 @@ static const ARMCPRegInfo v8_cp_reginfo[] = {
 { .name = "DCCSW", .cp = 15, .opc1 =

[PATCH v5 06/12] target/arm: Honor the HCR_EL2.{TVM,TRVM} bits

These bits trap EL1 access to various virtual memory controls.

Buglink: https://bugs.launchpad.net/bugs/1855072
Reviewed-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
v2: Include TTBCR.
v3: Include not_v8_cp_reginfo, lpae_cp_reginfo, CONTEXTIDR_S;
exclude not_v7_cp_reginfo (pmm).
---
 target/arm/helper.c | 82 ++---
 1 file changed, 55 insertions(+), 27 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index ef3f02d194..1f371b0391 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -530,6 +530,19 @@ static CPAccessResult access_tpm(CPUARMState *env, const 
ARMCPRegInfo *ri,
 return CP_ACCESS_OK;
 }
 
+/* Check for traps from EL1 due to HCR_EL2.TVM and HCR_EL2.TRVM.  */
+static CPAccessResult access_tvm_trvm(CPUARMState *env, const ARMCPRegInfo *ri,
+  bool isread)
+{
+if (arm_current_el(env) == 1) {
+uint64_t trap = isread ? HCR_TRVM : HCR_TVM;
+if (arm_hcr_el2_eff(env) & trap) {
+return CP_ACCESS_TRAP_EL2;
+}
+}
+return CP_ACCESS_OK;
+}
+
 static void dacr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t 
value)
 {
 ARMCPU *cpu = env_archcpu(env);
@@ -785,12 +798,14 @@ static const ARMCPRegInfo cp_reginfo[] = {
  */
 { .name = "CONTEXTIDR_EL1", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 0, .crn = 13, .crm = 0, .opc2 = 1,
-  .access = PL1_RW, .secure = ARM_CP_SECSTATE_NS,
+  .access = PL1_RW, .accessfn = access_tvm_trvm,
+  .secure = ARM_CP_SECSTATE_NS,
   .fieldoffset = offsetof(CPUARMState, cp15.contextidr_el[1]),
   .resetvalue = 0, .writefn = contextidr_write, .raw_writefn = raw_write, 
},
 { .name = "CONTEXTIDR_S", .state = ARM_CP_STATE_AA32,
   .cp = 15, .opc1 = 0, .crn = 13, .crm = 0, .opc2 = 1,
-  .access = PL1_RW, .secure = ARM_CP_SECSTATE_S,
+  .access = PL1_RW, .accessfn = access_tvm_trvm,
+  .secure = ARM_CP_SECSTATE_S,
   .fieldoffset = offsetof(CPUARMState, cp15.contextidr_s),
   .resetvalue = 0, .writefn = contextidr_write, .raw_writefn = raw_write, 
},
 REGINFO_SENTINEL
@@ -803,7 +818,7 @@ static const ARMCPRegInfo not_v8_cp_reginfo[] = {
 /* MMU Domain access control / MPU write buffer control */
 { .name = "DACR",
   .cp = 15, .opc1 = CP_ANY, .crn = 3, .crm = CP_ANY, .opc2 = CP_ANY,
-  .access = PL1_RW, .resetvalue = 0,
+  .access = PL1_RW, .accessfn = access_tvm_trvm, .resetvalue = 0,
   .writefn = dacr_write, .raw_writefn = raw_write,
   .bank_fieldoffsets = { offsetoflow32(CPUARMState, cp15.dacr_s),
  offsetoflow32(CPUARMState, cp15.dacr_ns) } },
@@ -996,7 +1011,7 @@ static const ARMCPRegInfo v6_cp_reginfo[] = {
 { .name = "DMB", .cp = 15, .crn = 7, .crm = 10, .opc1 = 0, .opc2 = 5,
   .access = PL0_W, .type = ARM_CP_NOP },
 { .name = "IFAR", .cp = 15, .crn = 6, .crm = 0, .opc1 = 0, .opc2 = 2,
-  .access = PL1_RW,
+  .access = PL1_RW, .accessfn = access_tvm_trvm,
   .bank_fieldoffsets = { offsetof(CPUARMState, cp15.ifar_s),
  offsetof(CPUARMState, cp15.ifar_ns) },
   .resetvalue = 0, },
@@ -2208,16 +2223,19 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
  */
 { .name = "AFSR0_EL1", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 0, .crn = 5, .crm = 1, .opc2 = 0,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+  .access = PL1_RW, .accessfn = access_tvm_trvm,
+  .type = ARM_CP_CONST, .resetvalue = 0 },
 { .name = "AFSR1_EL1", .state = ARM_CP_STATE_BOTH,
   .opc0 = 3, .opc1 = 0, .crn = 5, .crm = 1, .opc2 = 1,
-  .access = PL1_RW, .type = ARM_CP_CONST, .resetvalue = 0 },
+  .access = PL1_RW, .accessfn = access_tvm_trvm,
+  .type = ARM_CP_CONST, .resetvalue = 0 },
 /* MAIR can just read-as-written because we don't implement caches
  * and so don't need to care about memory attributes.
  */
 { .name = "MAIR_EL1", .state = ARM_CP_STATE_AA64,
   .opc0 = 3, .opc1 = 0, .crn = 10, .crm = 2, .opc2 = 0,
-  .access = PL1_RW, .fieldoffset = offsetof(CPUARMState, cp15.mair_el[1]),
+  .access = PL1_RW, .accessfn = access_tvm_trvm,
+  .fieldoffset = offsetof(CPUARMState, cp15.mair_el[1]),
   .resetvalue = 0 },
 { .name = "MAIR_EL3", .state = ARM_CP_STATE_AA64,
   .opc0 = 3, .opc1 = 6, .crn = 10, .crm = 2, .opc2 = 0,
@@ -2231,12 +2249,14 @@ static const ARMCPRegInfo v7_cp_reginfo[] = {
   * handled in the field definitions.
   */
 { .name = "MAIR0", .state = ARM_CP_STATE_AA32,
-  .cp = 15, .opc1 = 0, .crn = 10, .crm = 2, .opc2 = 0, .access = PL1_RW,
+  .cp = 15, .opc1 = 0, .crn = 10, .crm = 2, .opc2 = 0,
+  .access = PL1_RW, .accessfn = access_tvm_trvm,
   .bank_fieldoffsets = { offsetof(CPUARMState, cp15.mair0_s),
  offsetof(CPUARMState, cp15.mair0_ns) },
   .resetfn =

[PATCH v5 01/12] target/arm: Improve masking of HCR/HCR2 RES0 bits

Don't merely start with v8.0, handle v7VE as well.  Ensure that writes
from aarch32 mode do not change bits in the other half of the register.
Protect reads of aa64 id registers with ARM_FEATURE_AARCH64.

Suggested-by: Peter Maydell 
Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 38 +-
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 6be9ffa09e..e68e16b85b 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -5086,11 +5086,15 @@ static const ARMCPRegInfo el3_no_el2_v8_cp_reginfo[] = {
 REGINFO_SENTINEL
 };
 
-static void hcr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value)
+static void do_hcr_write(CPUARMState *env, uint64_t value, uint64_t valid_mask)
 {
 ARMCPU *cpu = env_archcpu(env);
-/* Begin with bits defined in base ARMv8.0.  */
-uint64_t valid_mask = MAKE_64BIT_MASK(0, 34);
+
+if (arm_feature(env, ARM_FEATURE_V8)) {
+valid_mask |= MAKE_64BIT_MASK(0, 34);  /* ARMv8.0 */
+} else {
+valid_mask |= MAKE_64BIT_MASK(0, 28);  /* ARMv7VE */
+}
 
 if (arm_feature(env, ARM_FEATURE_EL3)) {
 valid_mask &= ~HCR_HCD;
@@ -5104,14 +5108,17 @@ static void hcr_write(CPUARMState *env, const 
ARMCPRegInfo *ri, uint64_t value)
  */
 valid_mask &= ~HCR_TSC;
 }
-if (cpu_isar_feature(aa64_vh, cpu)) {
-valid_mask |= HCR_E2H;
-}
-if (cpu_isar_feature(aa64_lor, cpu)) {
-valid_mask |= HCR_TLOR;
-}
-if (cpu_isar_feature(aa64_pauth, cpu)) {
-valid_mask |= HCR_API | HCR_APK;
+
+if (arm_feature(env, ARM_FEATURE_AARCH64)) {
+if (cpu_isar_feature(aa64_vh, cpu)) {
+valid_mask |= HCR_E2H;
+}
+if (cpu_isar_feature(aa64_lor, cpu)) {
+valid_mask |= HCR_TLOR;
+}
+if (cpu_isar_feature(aa64_pauth, cpu)) {
+valid_mask |= HCR_API | HCR_APK;
+}
 }
 
 /* Clear RES0 bits.  */
@@ -5143,12 +5150,17 @@ static void hcr_write(CPUARMState *env, const 
ARMCPRegInfo *ri, uint64_t value)
 arm_cpu_update_vfiq(cpu);
 }
 
+static void hcr_write(CPUARMState *env, const ARMCPRegInfo *ri, uint64_t value)
+{
+do_hcr_write(env, value, 0);
+}
+
 static void hcr_writehigh(CPUARMState *env, const ARMCPRegInfo *ri,
   uint64_t value)
 {
 /* Handle HCR2 write, i.e. write to high half of HCR_EL2 */
 value = deposit64(env->cp15.hcr_el2, 32, 32, value);
-hcr_write(env, NULL, value);
+do_hcr_write(env, value, MAKE_64BIT_MASK(0, 32));
 }
 
 static void hcr_writelow(CPUARMState *env, const ARMCPRegInfo *ri,
@@ -5156,7 +5168,7 @@ static void hcr_writelow(CPUARMState *env, const 
ARMCPRegInfo *ri,
 {
 /* Handle HCR write, i.e. write to low half of HCR_EL2 */
 value = deposit64(env->cp15.hcr_el2, 0, 32, value);
-hcr_write(env, NULL, value);
+do_hcr_write(env, value, MAKE_64BIT_MASK(32, 32));
 }
 
 /*
-- 
2.20.1

[PATCH v5 05/12] target/arm: Improve masking in arm_hcr_el2_eff

Update the {TGE,E2H} == '11' masking to ARMv8.6.
If EL2 is configured for aarch32, disable all of
the bits that are RES0 in aarch32 mode.

Signed-off-by: Richard Henderson 
---
 target/arm/helper.c | 31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index e68e16b85b..ef3f02d194 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -5196,14 +5196,37 @@ uint64_t arm_hcr_el2_eff(CPUARMState *env)
  * Since the v8.4 language applies to the entire register, and
  * appears to be backward compatible, use that.
  */
-ret = 0;
-} else if (ret & HCR_TGE) {
-/* These bits are up-to-date as of ARMv8.4.  */
+return 0;
+}
+
+/*
+ * For a cpu that supports both aarch64 and aarch32, we can set bits
+ * in HCR_EL2 (e.g. via EL3) that are RES0 when we enter EL2 as aa32.
+ * Ignore all of the bits in HCR+HCR2 that are not valid for aarch32.
+ */
+if (!arm_el_is_aa64(env, 2)) {
+uint64_t aa32_valid;
+
+/*
+ * These bits are up-to-date as of ARMv8.6.
+ * For HCR, it's easiest to list just the 2 bits that are invalid.
+ * For HCR2, list those that are valid.
+ */
+aa32_valid = MAKE_64BIT_MASK(0, 32) & ~(HCR_RW | HCR_TDZ);
+aa32_valid |= (HCR_CD | HCR_ID | HCR_TERR | HCR_TEA | HCR_MIOCNCE |
+   HCR_TID4 | HCR_TICAB | HCR_TOCU | HCR_TTLBIS);
+ret &= aa32_valid;
+}
+
+if (ret & HCR_TGE) {
+/* These bits are up-to-date as of ARMv8.6.  */
 if (ret & HCR_E2H) {
 ret &= ~(HCR_VM | HCR_FMO | HCR_IMO | HCR_AMO |
  HCR_BSU_MASK | HCR_DC | HCR_TWI | HCR_TWE |
  HCR_TID0 | HCR_TID2 | HCR_TPCP | HCR_TPU |
- HCR_TDZ | HCR_CD | HCR_ID | HCR_MIOCNCE);
+ HCR_TDZ | HCR_CD | HCR_ID | HCR_MIOCNCE |
+ HCR_TID4 | HCR_TICAB | HCR_TOCU | HCR_ENSCXT |
+ HCR_TTLBIS | HCR_TTLBOS | HCR_TID5);
 } else {
 ret |= HCR_FMO | HCR_IMO | HCR_AMO;
 }
-- 
2.20.1

[PATCH v5 00/12] target/arm: Honor more HCR_EL2 traps

Changes for v5:
  * Patch 1 was broken for aa32.  Not just the masking vs the "other"
32-bit register that Peter noticed, but more explicitly in that
"ri" was dereferenced as NULL -- hcr_write{high,low} did not pass
along the structure.  Oops.

Break out a new helper that is passed a starting mask, which is
used to preserve bits from the "other" 32-bit register.

Check the aa64 isar registers only if aarch64 is enabled.

  * Add HCR bits from armv8.6.
  * Remove EL2 & EL3 from user-only.

  * Mask hcr_el2 bits that are res0 in aa32.
This didn't work at first because we weren't configuring SCR_RW
for user-only, so aarch64-linux-user thought EL2 was aa32, which
disabled pauth.  Rather than find other corner cases like this,
I think it makes more sense for user-only to only contend with EL1.

Patches 1-5, 12 require review.


r~


Richard Henderson (12):
  target/arm: Improve masking of HCR/HCR2 RES0 bits
  target/arm: Add HCR_EL2 bit definitions from ARMv8.6
  target/arm: Disable has_el2 and has_el3 for user-only
  target/arm: Remove EL2 and EL3 setup from user-only
  target/arm: Improve masking in arm_hcr_el2_eff
  target/arm: Honor the HCR_EL2.{TVM,TRVM} bits
  target/arm: Honor the HCR_EL2.TSW bit
  target/arm: Honor the HCR_EL2.TACR bit
  target/arm: Honor the HCR_EL2.TPCP bit
  target/arm: Honor the HCR_EL2.TPU bit
  target/arm: Honor the HCR_EL2.TTLB bit
  tests/tcg/aarch64: Add newline in pauth-1 printf

 target/arm/cpu.h|   7 +
 target/arm/cpu.c|  12 +-
 target/arm/helper.c | 358 +---
 tests/tcg/aarch64/pauth-1.c |   2 +-
 4 files changed, 262 insertions(+), 117 deletions(-)

-- 
2.20.1

[PATCH v5 04/12] target/arm: Remove EL2 and EL3 setup from user-only

We have disabled EL2 and EL3 for user-only, which means that these
registers "don't exist" and should not be set.

Signed-off-by: Richard Henderson 
---
 target/arm/cpu.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 33c28fe868..af541431e6 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -191,19 +191,13 @@ static void arm_cpu_reset(CPUState *s)
 /* Enable all PAC keys.  */
 env->cp15.sctlr_el[1] |= (SCTLR_EnIA | SCTLR_EnIB |
   SCTLR_EnDA | SCTLR_EnDB);
-/* Enable all PAC instructions */
-env->cp15.hcr_el2 |= HCR_API;
-env->cp15.scr_el3 |= SCR_API;
 /* and to the FP/Neon instructions */
 env->cp15.cpacr_el1 = deposit64(env->cp15.cpacr_el1, 20, 2, 3);
 /* and to the SVE instructions */
 env->cp15.cpacr_el1 = deposit64(env->cp15.cpacr_el1, 16, 2, 3);
-env->cp15.cptr_el[3] |= CPTR_EZ;
 /* with maximum vector length */
 env->vfp.zcr_el[1] = cpu_isar_feature(aa64_sve, cpu) ?
  cpu->sve_max_vq - 1 : 0;
-env->vfp.zcr_el[2] = env->vfp.zcr_el[1];
-env->vfp.zcr_el[3] = env->vfp.zcr_el[1];
 /*
  * Enable TBI0 and TBI1.  While the real kernel only enables TBI0,
  * turning on both here will produce smaller code and otherwise
-- 
2.20.1

[PATCH v5 02/12] target/arm: Add HCR_EL2 bit definitions from ARMv8.6

Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 0b84742b66..0ae07a72e4 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1410,6 +1410,7 @@ static inline void xpsr_write(CPUARMState *env, uint32_t 
val, uint32_t mask)
 #define HCR_TERR  (1ULL << 36)
 #define HCR_TEA   (1ULL << 37)
 #define HCR_MIOCNCE   (1ULL << 38)
+/* RES0 bit 39 */
 #define HCR_APK   (1ULL << 40)
 #define HCR_API   (1ULL << 41)
 #define HCR_NV(1ULL << 42)
@@ -1418,13 +1419,19 @@ static inline void xpsr_write(CPUARMState *env, 
uint32_t val, uint32_t mask)
 #define HCR_NV2   (1ULL << 45)
 #define HCR_FWB   (1ULL << 46)
 #define HCR_FIEN  (1ULL << 47)
+/* RES0 bit 48 */
 #define HCR_TID4  (1ULL << 49)
 #define HCR_TICAB (1ULL << 50)
+#define HCR_AMVOFFEN  (1ULL << 51)
 #define HCR_TOCU  (1ULL << 52)
+#define HCR_ENSCXT(1ULL << 53)
 #define HCR_TTLBIS(1ULL << 54)
 #define HCR_TTLBOS(1ULL << 55)
 #define HCR_ATA   (1ULL << 56)
 #define HCR_DCT   (1ULL << 57)
+#define HCR_TID5  (1ULL << 58)
+#define HCR_TWEDEN(1ULL << 59)
+#define HCR_TWEDELMAKE_64BIT_MASK(60, 4)
 
 #define SCR_NS(1U << 0)
 #define SCR_IRQ   (1U << 1)
-- 
2.20.1

[Bug 1759522] Re: windows qemu-img create vpc/vhdx error

2020-02-28 Thread maro

I also discovered just a few days ago the problem that sparse VHD/VHDX
image files are not being accepted by Windows.

It appears that qemu-img on Windows always tries to create images as
sparse files. Only in some cases (e.g. when operating on a NTFS file
system) will the file actually be a sparse file.

Being a sparse file seems to be no issue when using these file with QEMU
itself. Most file formats that qemu-img is able to create will be
unknown to Windows own tools, but the one exception are VHD/VHDX files.

As long as a file carries the sparse attribute it will be "un-
acceptable" to the Windows tools (e.g. diskpart/diskmgmt). As a crude
work-around I've noticed that a copy of such a file will have "lost" the
sparse attribute, and therefore can be mounted. Likewise any copy of a
file created on a different system will not be a sparse file (and hence
the issue does not arise).

I'm attaching a log file (with a few comments) of some steps that
demonstrate the problem, and how I worked around it. The test was done
with qemu-img v4.1.0, but I'm fairly certain that this issue has been
present since "forever" (and a quick re-test with v4.2.0 confirmed that
it has not "gone away").

So, a simple work-around exists, but I see myself unable to suggest a
patch. I guess the patch should be specific to prevent the creation of
sparse VHD/VHDX files on Windows. But from the superficial reading I did
I could not work out whether the image format information would be
available in 'raw_co_create()' (of: 'block/file-win32.c').

** Attachment added: "sparse-VHD_issue.log"

https://bugs.launchpad.net/qemu/+bug/1759522/+attachment/5332081/+files/sparse-VHD_issue.log

--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1759522

Title:
windows qemu-img create vpc/vhdx error

Status in QEMU:
New

Bug description:
On windows, using qemu-img (version 2.11.90) to create vpc/vhdx
virtual disk tends to fail. Here's the way to reproduce:

1. Install qemu-w64-setup-20180321.exe

2. Use `qemu-img create -f vhdx -o subformat=fixed disk.vhdx 512M` to create
a vhdx:
Formatting 'disk.vhdx', fmt=vhdx size=536870912 log_size=1048576
block_size=0 subformat=fixed

3. Execute `qemu-img info disk.vhdx` gives the result, (note the `disk size`
is incorrect):
image: disk.vhdx
file format: vhdx
virtual size: 512M (536870912 bytes)
disk size: 1.4M
cluster_size: 8388608

4. On Windows 10 (V1709), double click disk.vhdx gives an error:
Make sure the file is in an NTFS volume and isn't in a compressed folder
or volume.

Using Disk Management -> Action -> Attach VHD gives an error:
The requested operation could not be completed due to a virtual disk
system limitation. Virtual hard disk files must be uncompressed and uneccrypted
and must not be sparse.

Comparison with Windows 10 created VHDX:

1. Using Disk Management -> Action -> Create VHD:
File name: win.vhdx
Virtual hard disk size: 512MB
Virtual hard disk format: VHDX
Virtual hard disk type: Fixed size

2. Detach VHDX

3. Execute `qemu-img info win.vhdx` gives the result:
image: win.vhdx
file format: vhdx
virtual size: 512M (536870912 bytes)
disk size: 516M
cluster_size: 33554432

Comparison with qemu-img under Ubuntu:

2. qemu-img create -f vhdx -o subformat=fixed lin.vhdx 512M
Formatting 'lin.vhdx', fmt=vhdx size=536870912 log_size=1048576
block_size=0 subformat=fixed

3. qemu-img info lin.vhdx
image: lin.vhdx
file format: vhdx
virtual size: 512M (536870912 bytes)
disk size: 520M
cluster_size: 8388608

4. Load lin.vhdx under Windows 10 is ok

The same thing happens on `vpc` format with or without
`oformat=fixed`, it seems that windows version of qemu-img has some
incorrect operation? My guess is that windows version of qemu-img
doesn't handle the description field of vpc/vhdx, which leads to an
incorrect `disk size` field.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1759522/+subscriptions

Re: [PATCH] hw/smbios: add options for type 4 max_speed and current_speed

2020-02-28 Thread Heyi Guo


Hi Igor,

On 2020/2/28 17:39, Igor Mammedov wrote:

On Thu, 27 Feb 2020 17:12:21 +0800
Heyi Guo  wrote:


On 2020/2/25 17:24, Philippe Mathieu-Daudé wrote:

On 2/25/20 8:50 AM, Heyi Guo wrote:

Common VM users sometimes care about CPU speed, so we add two new
options to allow VM vendors to present CPU speed to their users.
Normally these information can be fetched from host smbios.

Strictly speaking, the "max speed" and "current speed" in type 4
are not really for the max speed and current speed of processor, for
"max speed" identifies a capability of the system, and "current speed"
identifies the processor's speed at boot (see smbios spec), but some
applications do not tell the differences.

Signed-off-by: Heyi Guo 

---
Cc: "Michael S. Tsirkin" 
Cc: Igor Mammedov 
---
   hw/smbios/smbios.c | 22 +++---
   qemu-options.hx    |  3 ++-
   2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/hw/smbios/smbios.c b/hw/smbios/smbios.c
index ffd98727ee..1d5439643d 100644
--- a/hw/smbios/smbios.c
+++ b/hw/smbios/smbios.c
@@ -94,6 +94,8 @@ static struct {
     static struct {
   const char *sock_pfx, *manufacturer, *version, *serial, *asset,
*part;
+    uint32_t max_speed;
+    uint32_t current_speed;
   } type4;
     static struct {
@@ -272,6 +274,14 @@ static const QemuOptDesc
qemu_smbios_type4_opts[] = {
   .name = "version",
   .type = QEMU_OPT_STRING,
   .help = "version number",
+    },{
+    .name = "max_speed",

I'd suggest to use - instead of _ in option name


Thanks for your comments. However I can see other options like 
"sock_pfx" and "loc_pfx" also use "_" in option names. Should we keep 
consistent with the context?


Thanks,

Heyi





+    .type = QEMU_OPT_NUMBER,
+    .help = "max speed in MHz",
+    },{
+    .name = "current_speed",

ditto


+    .type = QEMU_OPT_NUMBER,
+    .help = "speed at system boot in MHz",
   },{
   .name = "serial",
   .type = QEMU_OPT_STRING,
@@ -586,9 +596,8 @@ static void
smbios_build_type_4_table(MachineState *ms, unsigned instance)
   SMBIOS_TABLE_SET_STR(4, processor_version_str, type4.version);
   t->voltage = 0;
   t->external_clock = cpu_to_le16(0); /* Unknown */
-    /* SVVP requires max_speed and current_speed to not be unknown. */
-    t->max_speed = cpu_to_le16(2000); /* 2000 MHz */
-    t->current_speed = cpu_to_le16(2000); /* 2000 MHz */
+    t->max_speed = cpu_to_le16(type4.max_speed);
+    t->current_speed = cpu_to_le16(type4.current_speed);
   t->status = 0x41; /* Socket populated, CPU enabled */
   t->processor_upgrade = 0x01; /* Other */
   t->l1_cache_handle = cpu_to_le16(0x); /* N/A */
@@ -1129,6 +1138,13 @@ void smbios_entry_add(QemuOpts *opts, Error
**errp)
   save_opt(, opts, "serial");
   save_opt(, opts, "asset");
   save_opt(, opts, "part");
+    /*
+ * SVVP requires max_speed and current_speed to not be
unknown, and
+ * we set the default value to 2000MHz as we did before.
+ */
+    type4.max_speed = qemu_opt_get_number(opts, "max_speed",
2000);
+    type4.current_speed = qemu_opt_get_number(opts,
"current_speed",
+  2000);

Maybe check speeds are <= UINT16_MAX else set errp?

OK; I can do that in the v2. But I would wait for the maintainers to
provide more comments :)

Thanks,

Heyi

  

   return;
   case 11:
   qemu_opts_validate(opts, qemu_smbios_type11_opts, );
diff --git a/qemu-options.hx b/qemu-options.hx
index ac315c1ac4..bc9ef0fda8 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -2233,6 +2233,7 @@ DEF("smbios", HAS_ARG, QEMU_OPTION_smbios,
   "    specify SMBIOS type 3 fields\n"
   "-smbios
type=4[,sock_pfx=str][,manufacturer=str][,version=str][,serial=str]\n"
   "  [,asset=str][,part=str]\n"
+    "  [,max_speed=%d][,current_speed=%d]\n"
   "    specify SMBIOS type 4 fields\n"
   "-smbios
type=17[,loc_pfx=str][,bank=str][,manufacturer=str][,serial=str]\n"
   "   [,asset=str][,part=str][,speed=%d]\n"
@@ -2255,7 +2256,7 @@ Specify SMBIOS type 2 fields
   @item -smbios
type=3[,manufacturer=@var{str}][,version=@var{str}][,serial=@var{str}][,asset=@var{str}][,sku=@var{str}]
   Specify SMBIOS type 3 fields
   -@item -smbios
type=4[,sock_pfx=@var{str}][,manufacturer=@var{str}][,version=@var{str}][,serial=@var{str}][,asset=@var{str}][,part=@var{str}]
+@item -smbios
type=4[,sock_pfx=@var{str}][,manufacturer=@var{str}][,version=@var{str}][,serial=@var{str}][,asset=@var{str}][,part=@var{str}][,max_speed=@var{%d}][,current_speed=@var{%d}]
   Specify SMBIOS type 4 fields
     @item -smbios
type=17[,loc_pfx=@var{str}][,bank=@var{str}][,manufacturer=@var{str}][,serial=@var{str}][,asset=@var{str}][,part=@var{str}][,speed=@var{%d}]
  


.


.

Re: [PATCH v2 0/2] hw/arm/xilinx_zynq: Fix USB port instantiation

2020-02-28 Thread Guenter Roeck

On Fri, Feb 28, 2020 at 12:44:19PM -0600, Edgar E. Iglesias wrote:
> Sorry Peter, I missed the email.
> 
> Reviewed-by: Edgar E. Iglesias 
> 

Thanks a lot everyone!

Guenter

> Best regards,
> Edgar
> 
> 
> On Fri, 28 Feb. 2020, 10:00 Peter Maydell,  wrote:
> 
> > On Thu, 20 Feb 2020 at 15:05, Peter Maydell 
> > wrote:
> > >
> > > On Sat, 15 Feb 2020 at 12:23, Guenter Roeck  wrote:
> > > >
> > > > USB ports on Xilinx Zync must be instantiated as TYPE_CHIPIDEA to work.
> > > > Linux expects and checks various chipidea registers, which do not exist
> > > > with the basic ehci emulation. This patch series fixes the problem.
> > > >
> > > > The first patch in the series fixes the actual problem.
> > > >
> > > > The second patch removes the now obsolete explicit Xilinx
> > > > support from the EHCI code.
> > > >
> > > > v2: Introduced summary
> > > >
> > > > 
> > > > Guenter Roeck (2):
> > > >   hw/arm/xilinx_zynq: Fix USB port instantiation
> > > >   hw/usb/hcd-ehci-sysbus: Remove obsolete xlnx,ps7-usb class
> > >
> > > Xilinx folks -- could you provide a reviewed-by or acked-by
> > > for this series, please?
> >
> > No? Oh, well, applied to target-arm.next anyway.
> >
> > thanks
> > -- PMM
> >

Re: [PATCH v4 1/7] target/arm: Improve masking of HCR RES0 bits

On 2/28/20 11:03 AM, Peter Maydell wrote:
> It occurs to me that we should check what the required
> semantics are for the opposite half of the register
> if the guest writes to one half of it via hcr_writehigh()
> or hcr_writelow() -- is the un-accessed half supposed
> to stay exactly as it is, or is it ok for the
> RES0-for-aarch32 bits to get squashed in the process?
> That would seem at least a bit odd even if it's valid,
> so maybe better to do aarch32 RES0 masking in
> hcr_writehigh() and hcr_writelow()?

Hmm.  You're thinking of a situation in which

 1) EL3 invokes EL2 with aa64 which sets HCR_EL2,
 2) EL3 invokes EL2 in aa32 which sets HCR which
as a side-effect clears some of the bits in HCR2
 3) EL3 invokes EL2 with aa64 again and HCR_EL2
incorrectly has some high bits clear.

I can't find any language that explicitly says, but "architecturally mapped"
means that the bits backing the storage must be the same.  So while it isn't
legal for aa32 to set HCR2 bit 8 (HCR_EL2.APK), I imagine that it would still
read as written.

So I think you're correct that we shouldn't alter the half B when writing to
half A.

Perhaps I should do some masking for aa32 in arm_hcr_el2_eff.

r~

RE: Emulating Solaris 10 on SPARC64 sun4u

2020-02-28 Thread BALATON Zoltan


On Wed, 19 Feb 2020, BALATON Zoltan wrote:

On Wed, 19 Feb 2020, BALATON Zoltan wrote:
faster or doing something differently? Does someone know what interrupts 
are generated on real hardware in DMA mode so we can compare that to what 
we see with QEMU?


The document Programming Interface for Bus Master IDE Controller, Revision 
1.0 (5/16/94) has some info on this. AFAIU it says that after DMA operation 
is completed an IRQ should be raised. On page 5, section 3.1. Data 
Synchronization it says:


"Another way to view this requirement is that the first read to the 
controller Status register in response to the IDE device interrupt must 
return with the Interrupt bit set and with the guarantee that all buffered 
data has been written to memory."


Not sure if this is relevant but how is it handled in QEMU? Is the right 
interrupt bit set after DMA transfer is done? If so is it the one that's 
checked by the OS driver?


I think I now understand the problem with via-ide at least and the 
following is true for that case. I'm not sure about the CMD646 but it may 
be similar as these seem to be similar designs or maybe even related 
somehow. The problem in my case stems from that the device has two modes 
documented: legacy where it uses standard ISA ioports and INT14 and 15 for 
the two channels and native mode in which it uses PCI BARs for io address 
and an IRQ configurable via PCI_INTERRUPT_LINE (config reg 9). It seems 
the IRQ in native mode is still not a PCI INT line but an ISA IRQ, however 
it can be selected by config reg and it's a single interrupt instead of 
two for separate channels (Linux prints these during boot so that's a good 
way to check which mode it thinks it's using). That's so far is complex 
enough to not be easy to emulate in QEMU as we can set up legacy ISA ports 
with ide_init_ioport() but there's no way then to switch it off so via-ide 
either implemented legacy or native mode but can't correctly switch 
between those. This may not be a problem most of the time for Linux at 
least which tries to check which mode the controller is in and use that so 
it would work with whatever is there as long as the regs match what's 
emulated so we can just emulate one mode and still work.


But all of the above is further complicated by that on some (most?) boards 
there's also a "non 100% native mode" in which the io addresses are taken 
from the PCI BARs but still using hardcoded INT14 and 15, ignoring the 
setting in PCI_INTERRUPT_LINE. So guest drivers may assume this without 
checking regs and not care about what's set in PCI_INTERRUPT_LINE just 
expect interrupts on INT14 and 15. If the emulation raises PCI INT or some 
other isa interrupt it won't work, even if config regs correctly describe 
the difference following the docs but guest drivers don't care about the 
chip spec only the implementation on the board they meant to run on. 
Unfortunately different guests use different heuristics and workarounds 
(even Linux does so on different archs) so it's not easy to make an 
emulation that works with all. The pegasos2 firmware for example sets 
via-ide in native mode and assigns interrupt 9 but on real hardware this 
reg seems to be hardcoded to 14 and Linux uses this to detect if it needs 
to use the half-native mode but sets the mode reg to legacy to note this 
despite then using PCI BARs (so we can't hardcode mode reg to always 
native without breaking this but have to force int reg and emulate half 
native mode to work with other guests). Linux would also work with 100% 
native mode with IRQ9 but Amiga like OSes don't seem to care and just use 
hardcoded half-native mode regardless of config regs and expect interrupt 
on IRQ14 and 15. I could make a patch to work with all these on pegasos2 
but the via-ide is also used on a mips board where the corresponding Linux 
version also applies its own (different) workarounds corresponding to the 
quirks of that board and ends up either trying to use legacy mode (which 
is not emulated as io is only on PCI BARs) or trying to use 100% native 
mode which does not work with half-native interrupts. I think I'll need to 
add a special property to the device to set it to half-native for pegasos2 
and leave it 100% native for mips, otherwise there may not be a 
combination which works with all these firmwares and guests on both 
machines. (We still can avoid having to implement native mode as well but 
I can imagine if some PC guests were involved we may need that too but on 
these ppc and mips boards and also in your case I think native and 
half-native modes should be enough as that's all guests use.)


The CMD646 case might be similar and that's also used on a hppa board so 
you may need to check with that too if you make changes. To check this 
theory you might try forcing ide interrupts to be IRQ14 and 15 via 
something like:


qemu_set_irq(isa_get_irq(NULL, (channel ? 15 : 14)), level);

instead of using PCI interrupt or configured ISA

Re: [PATCH v3 3/4] target/i386: Add new property note to versioned CPU models

On Wed, Feb 12, 2020 at 04:13:27PM +0800, Tao Xu wrote:
> Add additional information for -cpu help to indicate the changes in this
> version of CPU model.
> 
> Suggested-by: Eduardo Habkost 
> Signed-off-by: Tao Xu 

Queued, thanks!

-- 
Eduardo

Re: [PATCH v3 4/4] target/i386: Add notes for versioned CPU models

On Wed, Feb 12, 2020 at 04:13:28PM +0800, Tao Xu wrote:
> Add which features are added or removed in this version. Remove the
> changed model-id in versioned CPU models, to keep the model name
> unchanged at /proc/cpuinfo inside the VM.
> 
> Signed-off-by: Tao Xu 
> ---
> 
> Changes in v2:
> - correct the note of Cascadelake v3 (Xiaoyao)
> ---
>  target/i386/cpu.c | 54 ++-
>  1 file changed, 25 insertions(+), 29 deletions(-)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 81a039beb6..739ef4ce91 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -2278,10 +2278,9 @@ static X86CPUDefinition builtin_x86_defs[] = {
>  {
>  .version = 2,
>  .alias = "Nehalem-IBRS",
> +.note = "IBRS",
>  .props = (PropValue[]) {
>  { "spec-ctrl", "on" },
> -{ "model-id",
> -  "Intel Core i7 9xx (Nehalem Core i7, IBRS update)" },
>  { /* end of list */ }

Changing model-id is guest-visible, so we can't do this.  The
same applies to the other models where model-id is being removed.

I suggest using the .note property only on the CPU model versions
that don't have custom model-id set yet, or when existing
information on model-id is incomplete.

For future CPU model versions, we can start using only .note and
stop changing model-id.

-- 
Eduardo

Re: [PATCH v3 1/4] target/i386: Add Denverton-v2 (no MPX) CPU model

On Wed, Feb 12, 2020 at 04:13:25PM +0800, Tao Xu wrote:
> Because MPX is being removed from the linux kernel, remove MPX feature
> from Denverton.
> 
> Signed-off-by: Tao Xu 

Queued, thanks!

-- 
Eduardo

Re: [PATCH v3 2/4] target/i386: Remove monitor from some CPU models

On Wed, Feb 12, 2020 at 04:13:26PM +0800, Tao Xu wrote:
> Add new version of Snowridge, Denverton, Opteron_G3, EPYC, and Dhyana
> CPU model to remove MONITOR/MWAIT feature.
> 
> After QEMU/KVM use "-overcommit cpu-pm=on" to expose MONITOR/MWAIT
> (commit id 6f131f13e68d648a8e4f083c667ab1acd88ce4cd), the MONITOR/MWAIT
> feature in these CPU model is unused.
> 
> Signed-off-by: Tao Xu 

What exactly is the problem you are trying to fix?

No CPU model will ever have monitor=on set by default with KVM,
because kvm_default_props has a monitor=off element.

> ---
>  target/i386/cpu.c | 38 ++
>  1 file changed, 38 insertions(+)
> 
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 848c992cd3..6905e4eabd 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -3731,6 +3731,14 @@ static X86CPUDefinition builtin_x86_defs[] = {
>  { /* end of list */ },
>  },
>  },
> +{
> +.version = 3,
> +.props = (PropValue[]) {
> +/* mpx was already removed by -v2 above */
> +{ "monitor", "off" },
> +{ /* end of list */ },
> +},
> +},
>  { /* end of list */ },
>  },
>  },
> @@ -3842,6 +3850,17 @@ static X86CPUDefinition builtin_x86_defs[] = {
>  CPUID_EXT3_ABM | CPUID_EXT3_SVM | CPUID_EXT3_LAHF_LM,
>  .xlevel = 0x8008,
>  .model_id = "AMD Opteron 23xx (Gen 3 Class Opteron)",
> +.versions = (X86CPUVersionDefinition[]) {
> +{ .version = 1 },
> +{
> +.version = 2,
> +.props = (PropValue[]) {
> +{ "monitor", "off" },
> +{ /* end of list */ },
> +},
> +},
> +{ /* end of list */ },
> +},
>  },
>  {
>  .name = "Opteron_G4",
> @@ -3966,6 +3985,14 @@ static X86CPUDefinition builtin_x86_defs[] = {
>  { /* end of list */ }
>  }
>  },
> +{
> +.version = 3,
> +.props = (PropValue[]) {
> +/* ibpb was already enabled by -v2 above */
> +{ "monitor", "off" },
> +{ /* end of list */ },
> +},
> +},
>  { /* end of list */ }
>  }
>  },
> @@ -4018,6 +4045,17 @@ static X86CPUDefinition builtin_x86_defs[] = {
>  .xlevel = 0x801E,
>  .model_id = "Hygon Dhyana Processor",
>  .cache_info = _cache_info,
> +.versions = (X86CPUVersionDefinition[]) {
> +{ .version = 1 },
> +{
> +.version = 2,
> +.props = (PropValue[]) {
> +{ "monitor", "off" },
> +{ /* end of list */ },
> +},
> +},
> +{ /* end of list */ },
> +},
>  },
>  };
>  
> -- 
> 2.20.1
> 
> 

-- 
Eduardo

Re: [PATCH v3 00/33] Convert qemu-doc to rST

2020-02-28 Thread Stefan Weil

Am 28.02.20 um 19:36 schrieb Peter Maydell:

> Hi Stefan -- I meant to cc you on these but forgot, relating to the
> "qemu.nsi needs updating to know that it should install
> Sphinx documentation these days" part...
>
> On Fri, 28 Feb 2020 at 15:36, Peter Maydell  wrote:
[...]
>> A couple of notes:
>>  * I haven't actually been in a position to test the cocoa.m
>>update of the HTML filename
>>  * qemu.nsi (the Windows installer config file) thinks that
>>qemu-doc.html is the only doc file it needs to know about,
>>which is clearly wrong. However I don't have any idea about
>>the Windows installer to be able to update or test it...

Maybe it is sufficient to update qemu.nsi after that series was merged.

Do you think that all documentation should be part of the Windows
installer, although it is also available online? Too much documentation
can be confusing, because it makes it more difficult to find the right
entry.

Kind regards

Stefan

[PULL 3/4] hw: Make MachineClass::is_default a boolean type

From: Philippe Mathieu-Daudé 

There's no good reason for it to be type int, change it to bool.

Suggested-by: Richard Henderson 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20200207161948.15972-3-phi...@redhat.com>
Reviewed-by: Marc-André Lureau 
Reviewed-by: Laurent Vivier 
Signed-off-by: Eduardo Habkost 
---
 hw/alpha/dp264.c |  2 +-
 hw/cris/axis_dev88.c |  2 +-
 hw/hppa/machine.c|  2 +-
 hw/i386/pc_piix.c| 10 +-
 hw/lm32/lm32_boards.c|  2 +-
 hw/m68k/mcf5208.c|  2 +-
 hw/microblaze/petalogix_s3adsp1800_mmu.c |  2 +-
 hw/mips/mips_malta.c |  2 +-
 hw/moxie/moxiesim.c  |  2 +-
 hw/nios2/10m50_devboard.c|  2 +-
 hw/openrisc/openrisc_sim.c   |  2 +-
 hw/ppc/mac_oldworld.c|  2 +-
 hw/ppc/spapr.c   |  2 +-
 hw/riscv/spike.c |  2 +-
 hw/s390x/s390-virtio-ccw.c   |  2 +-
 hw/sh4/shix.c|  2 +-
 hw/sparc/sun4m.c |  2 +-
 hw/sparc64/sun4u.c   |  2 +-
 hw/unicore32/puv3.c  |  2 +-
 include/hw/boards.h  |  4 +++-
 20 files changed, 26 insertions(+), 24 deletions(-)

diff --git a/hw/alpha/dp264.c b/hw/alpha/dp264.c
index 8d71a30617..d28f57199f 100644
--- a/hw/alpha/dp264.c
+++ b/hw/alpha/dp264.c
@@ -181,7 +181,7 @@ static void clipper_machine_init(MachineClass *mc)
 mc->init = clipper_init;
 mc->block_default_type = IF_IDE;
 mc->max_cpus = 4;
-mc->is_default = 1;
+mc->is_default = true;
 mc->default_cpu_type = ALPHA_CPU_TYPE_NAME("ev67");
 mc->default_ram_id = "ram";
 }
diff --git a/hw/cris/axis_dev88.c b/hw/cris/axis_dev88.c
index cf6790fd6f..75e5c993b5 100644
--- a/hw/cris/axis_dev88.c
+++ b/hw/cris/axis_dev88.c
@@ -344,7 +344,7 @@ static void axisdev88_machine_init(MachineClass *mc)
 {
 mc->desc = "AXIS devboard 88";
 mc->init = axisdev88_init;
-mc->is_default = 1;
+mc->is_default = true;
 mc->default_cpu_type = CRIS_CPU_TYPE_NAME("crisv32");
 mc->default_ram_id = "axisdev88.ram";
 }
diff --git a/hw/hppa/machine.c b/hw/hppa/machine.c
index 67181e75ba..bf18767e24 100644
--- a/hw/hppa/machine.c
+++ b/hw/hppa/machine.c
@@ -290,7 +290,7 @@ static void machine_hppa_machine_init(MachineClass *mc)
 mc->block_default_type = IF_SCSI;
 mc->max_cpus = HPPA_MAX_CPUS;
 mc->default_cpus = 1;
-mc->is_default = 1;
+mc->is_default = true;
 mc->default_ram_size = 512 * MiB;
 mc->default_boot_order = "cd";
 mc->default_ram_id = "ram";
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index fa12203079..9088db8fb6 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -423,7 +423,7 @@ static void pc_i440fx_5_0_machine_options(MachineClass *m)
 PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_i440fx_machine_options(m);
 m->alias = "pc";
-m->is_default = 1;
+m->is_default = true;
 pcmc->default_cpu_version = 1;
 }
 
@@ -434,7 +434,7 @@ static void pc_i440fx_4_2_machine_options(MachineClass *m)
 {
 pc_i440fx_5_0_machine_options(m);
 m->alias = NULL;
-m->is_default = 0;
+m->is_default = false;
 compat_props_add(m->compat_props, hw_compat_4_2, hw_compat_4_2_len);
 compat_props_add(m->compat_props, pc_compat_4_2, pc_compat_4_2_len);
 }
@@ -446,7 +446,7 @@ static void pc_i440fx_4_1_machine_options(MachineClass *m)
 {
 pc_i440fx_4_2_machine_options(m);
 m->alias = NULL;
-m->is_default = 0;
+m->is_default = false;
 compat_props_add(m->compat_props, hw_compat_4_1, hw_compat_4_1_len);
 compat_props_add(m->compat_props, pc_compat_4_1, pc_compat_4_1_len);
 }
@@ -459,7 +459,7 @@ static void pc_i440fx_4_0_machine_options(MachineClass *m)
 PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 pc_i440fx_4_1_machine_options(m);
 m->alias = NULL;
-m->is_default = 0;
+m->is_default = false;
 pcmc->default_cpu_version = CPU_VERSION_LEGACY;
 compat_props_add(m->compat_props, hw_compat_4_0, hw_compat_4_0_len);
 compat_props_add(m->compat_props, pc_compat_4_0, pc_compat_4_0_len);
@@ -473,7 +473,7 @@ static void pc_i440fx_3_1_machine_options(MachineClass *m)
 PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
 
 pc_i440fx_4_0_machine_options(m);
-m->is_default = 0;
+m->is_default = false;
 pcmc->do_not_add_smb_acpi = true;
 m->smbus_no_migration_support = true;
 m->alias = NULL;
diff --git a/hw/lm32/lm32_boards.c b/hw/lm32/lm32_boards.c
index 747a175b55..b842f74344 100644
--- a/hw/lm32/lm32_boards.c
+++ b/hw/lm32/lm32_boards.c
@@ -295,7 +295,7 @@ static void lm32_evr_class_init(ObjectClass *oc, void *data)
 
 mc->desc = "LatticeMico32 EVR32 eval system";
 mc->init = lm32_evr_init;
-mc->is_default = 1;
+

[PULL 2/4] hw: Do not initialize MachineClass::is_default to 0

From: Philippe Mathieu-Daudé 

The MachineClass is already zeroed on creation.

Note: The code setting is_default=0 in hw/i386/pc_piix.c is
  different (related to compat options). When adding a
  new versioned machine, we want it to be the new default,
  so we have to mark the previous one as not default.

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20200207161948.15972-2-phi...@redhat.com>
Reviewed-by: Laurent Vivier 
Signed-off-by: Eduardo Habkost 
---
 hw/lm32/lm32_boards.c   | 1 -
 hw/lm32/milkymist.c | 1 -
 hw/m68k/q800.c  | 1 -
 hw/microblaze/petalogix_ml605_mmu.c | 1 -
 hw/tricore/tricore_testboard.c  | 1 -
 5 files changed, 5 deletions(-)

diff --git a/hw/lm32/lm32_boards.c b/hw/lm32/lm32_boards.c
index 4e0a98c117..747a175b55 100644
--- a/hw/lm32/lm32_boards.c
+++ b/hw/lm32/lm32_boards.c
@@ -313,7 +313,6 @@ static void lm32_uclinux_class_init(ObjectClass *oc, void 
*data)
 
 mc->desc = "lm32 platform for uClinux and u-boot by Theobroma Systems";
 mc->init = lm32_uclinux_init;
-mc->is_default = 0;
 mc->default_cpu_type = LM32_CPU_TYPE_NAME("lm32-full");
 mc->default_ram_size = 64 * MiB;
 mc->default_ram_id = "lm32_uclinux.sdram";
diff --git a/hw/lm32/milkymist.c b/hw/lm32/milkymist.c
index 5c72266e58..85913bb68b 100644
--- a/hw/lm32/milkymist.c
+++ b/hw/lm32/milkymist.c
@@ -219,7 +219,6 @@ static void milkymist_machine_init(MachineClass *mc)
 {
 mc->desc = "Milkymist One";
 mc->init = milkymist_init;
-mc->is_default = 0;
 mc->default_cpu_type = LM32_CPU_TYPE_NAME("lm32-full");
 mc->default_ram_size = 128 * MiB;
 mc->default_ram_id = "milkymist.sdram";
diff --git a/hw/m68k/q800.c b/hw/m68k/q800.c
index a4c4bc14cb..c5699f6f3e 100644
--- a/hw/m68k/q800.c
+++ b/hw/m68k/q800.c
@@ -438,7 +438,6 @@ static void q800_machine_class_init(ObjectClass *oc, void 
*data)
 mc->init = q800_init;
 mc->default_cpu_type = M68K_CPU_TYPE_NAME("m68040");
 mc->max_cpus = 1;
-mc->is_default = 0;
 mc->block_default_type = IF_SCSI;
 mc->default_ram_id = "m68k_mac.ram";
 }
diff --git a/hw/microblaze/petalogix_ml605_mmu.c 
b/hw/microblaze/petalogix_ml605_mmu.c
index 09486bc8bf..0a2640c40b 100644
--- a/hw/microblaze/petalogix_ml605_mmu.c
+++ b/hw/microblaze/petalogix_ml605_mmu.c
@@ -216,7 +216,6 @@ static void petalogix_ml605_machine_init(MachineClass *mc)
 {
 mc->desc = "PetaLogix linux refdesign for xilinx ml605 little endian";
 mc->init = petalogix_ml605_init;
-mc->is_default = 0;
 }
 
 DEFINE_MACHINE("petalogix-ml605", petalogix_ml605_machine_init)
diff --git a/hw/tricore/tricore_testboard.c b/hw/tricore/tricore_testboard.c
index 20c9ccb3ce..8ec2b5bddd 100644
--- a/hw/tricore/tricore_testboard.c
+++ b/hw/tricore/tricore_testboard.c
@@ -105,7 +105,6 @@ static void ttb_machine_init(MachineClass *mc)
 {
 mc->desc = "a minimal TriCore board";
 mc->init = tricoreboard_init;
-mc->is_default = 0;
 mc->default_cpu_type = TRICORE_CPU_TYPE_NAME("tc1796");
 }
 
-- 
2.24.1

[PULL 0/4] Machine queue, 2020-02-28

The following changes since commit e0175b71638cf4398903c0d25f93fe62e0606389:

  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20200228' 
into staging (2020-02-28 16:39:27 +)

are available in the Git repository at:

  git://github.com/ehabkost/qemu.git tags/machine-next-pull-request

for you to fetch changes up to 6db1857ec9960c63024f4ce6329d947f727bad39:

  vl: Abort if multiple machines are registered as default (2020-02-28 14:57:19 
-0500)


Machine queue, 2020-02-28

Cleanups:
* Fix NMI() macro (Philippe Mathieu-Daudé)
* Make MachineClass::is_default boolean, refuse multiple
  default machines (Philippe Mathieu-Daudé)



Philippe Mathieu-Daudé (4):
  hw/nmi: Fix the NMI() macro, based on INTERFACE_CHECK()
  hw: Do not initialize MachineClass::is_default to 0
  hw: Make MachineClass::is_default a boolean type
  vl: Abort if multiple machines are registered as default

 hw/alpha/dp264.c |  2 +-
 hw/cris/axis_dev88.c |  2 +-
 hw/hppa/machine.c|  2 +-
 hw/i386/pc_piix.c| 10 +-
 hw/lm32/lm32_boards.c|  3 +--
 hw/lm32/milkymist.c  |  1 -
 hw/m68k/mcf5208.c|  2 +-
 hw/m68k/q800.c   |  1 -
 hw/microblaze/petalogix_ml605_mmu.c  |  1 -
 hw/microblaze/petalogix_s3adsp1800_mmu.c |  2 +-
 hw/mips/mips_malta.c |  2 +-
 hw/moxie/moxiesim.c  |  2 +-
 hw/nios2/10m50_devboard.c|  2 +-
 hw/openrisc/openrisc_sim.c   |  2 +-
 hw/ppc/mac_oldworld.c|  2 +-
 hw/ppc/spapr.c   |  2 +-
 hw/riscv/spike.c |  2 +-
 hw/s390x/s390-virtio-ccw.c   |  2 +-
 hw/sh4/shix.c|  2 +-
 hw/sparc/sun4m.c |  2 +-
 hw/sparc64/sun4u.c   |  2 +-
 hw/tricore/tricore_testboard.c   |  1 -
 hw/unicore32/puv3.c  |  2 +-
 include/hw/boards.h  |  4 +++-
 include/hw/nmi.h |  2 +-
 softmmu/vl.c |  6 --
 26 files changed, 31 insertions(+), 32 deletions(-)

-- 
2.24.1

[PULL 1/4] hw/nmi: Fix the NMI() macro, based on INTERFACE_CHECK()

From: Philippe Mathieu-Daudé 

There is no declaration of the 'NMI' type. INTERFACE_CHECK()
returns an abstract type (see commit aa1b35b975d8). The abstract
type corresponding to the TYPE_NMI interface is 'NMIState'.

Fixes: 9cb805fd267
Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20191207094823.20707-1-phi...@redhat.com>
Reviewed-by: Gavin Shan 
Signed-off-by: Eduardo Habkost 
---
 include/hw/nmi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/hw/nmi.h b/include/hw/nmi.h
index a1e128724e..fe37ce3ad8 100644
--- a/include/hw/nmi.h
+++ b/include/hw/nmi.h
@@ -31,7 +31,7 @@
 #define NMI_GET_CLASS(obj) \
 OBJECT_GET_CLASS(NMIClass, (obj), TYPE_NMI)
 #define NMI(obj) \
- INTERFACE_CHECK(NMI, (obj), TYPE_NMI)
+ INTERFACE_CHECK(NMIState, (obj), TYPE_NMI)
 
 typedef struct NMIState NMIState;
 
-- 
2.24.1

[PULL 4/4] vl: Abort if multiple machines are registered as default

From: Philippe Mathieu-Daudé 

It would be confusing to have multiple default machines.
Abort if this ever occurs.

Signed-off-by: Philippe Mathieu-Daudé 
Message-Id: <20200207161948.15972-4-phi...@redhat.com>
Reviewed-by: Marc-André Lureau 
Signed-off-by: Eduardo Habkost 
Reviewed-by: Laurent Vivier 
Tested-by: Laurent Vivier 
---
 softmmu/vl.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/softmmu/vl.c b/softmmu/vl.c
index 705ee6f841..5549f4b619 100644
--- a/softmmu/vl.c
+++ b/softmmu/vl.c
@@ -1163,16 +1163,18 @@ static MachineClass *find_machine(const char *name, 
GSList *machines)
 static MachineClass *find_default_machine(GSList *machines)
 {
 GSList *el;
+MachineClass *default_machineclass = NULL;
 
 for (el = machines; el; el = el->next) {
 MachineClass *mc = el->data;
 
 if (mc->is_default) {
-return mc;
+assert(default_machineclass == NULL && "Multiple default 
machines");
+default_machineclass = mc;
 }
 }
 
-return NULL;
+return default_machineclass;
 }
 
 static int machine_help_func(QemuOpts *opts, MachineState *machine)
-- 
2.24.1

RE: [EXTERNAL] Re: PATCH] WHPX: TSC get and set should be dependent on VM state

2020-02-28 Thread Sunil Muthuswamy

> -Original Message-
> From: Paolo Bonzini 
> Sent: Friday, February 28, 2020 2:45 AM
> To: Sunil Muthuswamy ; Richard Henderson 
> ; Eduardo Habkost
> 
> Cc: qemu-devel@nongnu.org; Stefan Weil 
> Subject: [EXTERNAL] Re: PATCH] WHPX: TSC get and set should be dependent on 
> VM state
> 
> On 26/02/20 21:54, Sunil Muthuswamy wrote:
> > Currently, TSC is set as part of the VM runtime state. Setting TSC at
> > runtime is heavy and additionally can have side effects on the guest,
> > which are not very resilient to variances in the TSC. This patch uses
> > the VM state to determine whether to set TSC or not. Some minor
> > enhancements for getting TSC values as well that considers the VM state.
> >
> > Additionally, while setting the TSC, the partition is suspended to
> > reduce the variance in the TSC value across vCPUs.
> >
> > Signed-off-by: Sunil Muthuswamy 
> 
> Looks good.  Do you want me to queue this until you can have your GPG
> key signed?  (And also, I can help you sign it of course).
> 

Yes, please. Thanks.

I haven't used GPG keys before. What would I be using it for?
 
> Thanks,
> 
> > ---
> >  include/sysemu/whpx.h  |   7 +++
> >  target/i386/whp-dispatch.h |   9 
> >  target/i386/whpx-all.c | 103 +
> >  3 files changed, 110 insertions(+), 9 deletions(-)
> >
> > diff --git a/include/sysemu/whpx.h b/include/sysemu/whpx.h
> > index 4794e8effe..a84b49e749 100644
> > --- a/include/sysemu/whpx.h
> > +++ b/include/sysemu/whpx.h
> > @@ -35,4 +35,11 @@ int whpx_enabled(void);
> >
> >  #endif /* CONFIG_WHPX */
> >
> > +/* state subset only touched by the VCPU itself during runtime */
> > +#define WHPX_SET_RUNTIME_STATE   1
> > +/* state subset modified during VCPU reset */
> > +#define WHPX_SET_RESET_STATE 2
> > +/* full state set, modified during initialization or on vmload */
> > +#define WHPX_SET_FULL_STATE  3
> > +
> >  #endif /* QEMU_WHPX_H */
> > diff --git a/target/i386/whp-dispatch.h b/target/i386/whp-dispatch.h
> > index 87d049ceab..e4695c349f 100644
> > --- a/target/i386/whp-dispatch.h
> > +++ b/target/i386/whp-dispatch.h
> > @@ -23,6 +23,12 @@
> >X(HRESULT, WHvGetVirtualProcessorRegisters, (WHV_PARTITION_HANDLE 
> > Partition, UINT32 VpIndex, const
> WHV_REGISTER_NAME* RegisterNames, UINT32 RegisterCount, WHV_REGISTER_VALUE* 
> RegisterValues)) \
> >X(HRESULT, WHvSetVirtualProcessorRegisters, (WHV_PARTITION_HANDLE 
> > Partition, UINT32 VpIndex, const
> WHV_REGISTER_NAME* RegisterNames, UINT32 RegisterCount, const 
> WHV_REGISTER_VALUE* RegisterValues)) \
> >
> > +/*
> > + * These are supplemental functions that may not be present
> > + * on all versions and are not critical for basic functionality.
> > + */
> > +#define LIST_WINHVPLATFORM_FUNCTIONS_SUPPLEMENTAL(X) \
> > +  X(HRESULT, WHvSuspendPartitionTime, (WHV_PARTITION_HANDLE Partition)) \
> >
> >  #define LIST_WINHVEMULATION_FUNCTIONS(X) \
> >X(HRESULT, WHvEmulatorCreateEmulator, (const WHV_EMULATOR_CALLBACKS* 
> > Callbacks, WHV_EMULATOR_HANDLE*
> Emulator)) \
> > @@ -40,10 +46,12 @@
> >  /* Define function typedef */
> >  LIST_WINHVPLATFORM_FUNCTIONS(WHP_DEFINE_TYPE)
> >  LIST_WINHVEMULATION_FUNCTIONS(WHP_DEFINE_TYPE)
> > +LIST_WINHVPLATFORM_FUNCTIONS_SUPPLEMENTAL(WHP_DEFINE_TYPE)
> >
> >  struct WHPDispatch {
> >  LIST_WINHVPLATFORM_FUNCTIONS(WHP_DECLARE_MEMBER)
> >  LIST_WINHVEMULATION_FUNCTIONS(WHP_DECLARE_MEMBER)
> > +LIST_WINHVPLATFORM_FUNCTIONS_SUPPLEMENTAL(WHP_DECLARE_MEMBER)
> >  };
> >
> >  extern struct WHPDispatch whp_dispatch;
> > @@ -53,6 +61,7 @@ bool init_whp_dispatch(void);
> >  typedef enum WHPFunctionList {
> >  WINHV_PLATFORM_FNS_DEFAULT,
> >  WINHV_EMULATION_FNS_DEFAULT,
> > +WINHV_PLATFORM_FNS_SUPPLEMENTAL
> >  } WHPFunctionList;
> >
> >  #endif /* WHP_DISPATCH_H */
> > diff --git a/target/i386/whpx-all.c b/target/i386/whpx-all.c
> > index 35601b8176..6a885c0fb3 100644
> > --- a/target/i386/whpx-all.c
> > +++ b/target/i386/whpx-all.c
> > @@ -114,7 +114,6 @@ static const WHV_REGISTER_NAME whpx_register_names[] = {
> >  WHvX64RegisterXmmControlStatus,
> >
> >  /* X64 MSRs */
> > -WHvX64RegisterTsc,
> >  WHvX64RegisterEfer,
> >  #ifdef TARGET_X86_64
> >  WHvX64RegisterKernelGsBase,
> > @@ -215,7 +214,44 @@ static SegmentCache whpx_seg_h2q(const 
> > WHV_X64_SEGMENT_REGISTER *hs)
> >  return qs;
> >  }
> >
> > -static void whpx_set_registers(CPUState *cpu)
> > +static int whpx_set_tsc(CPUState *cpu)
> > +{
> > +struct CPUX86State *env = (CPUArchState *)(cpu->env_ptr);
> > +WHV_REGISTER_NAME tsc_reg = WHvX64RegisterTsc;
> > +WHV_REGISTER_VALUE tsc_val;
> > +HRESULT hr;
> > +struct whpx_state *whpx = _global;
> > +
> > +/*
> > + * Suspend the partition prior to setting the TSC to reduce the 
> > variance
> > + * in TSC across vCPUs. When the first vCPU runs post suspend, the
> > + * partition is automatically resumed.
> > + */
> > +if

Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()

On Fri, Feb 28, 2020 at 09:16:28PM +0100, David Hildenbrand wrote:
> 

[...]

> >> @@ -631,7 +658,7 @@ int qemu_vfio_dma_map(QEMUVFIOState *s, void *host, 
> >> size_t size,
> >> qemu_vfio_remove_mapping(s, mapping);
> >> goto out;
> >> }
> >> -s->low_water_mark += size;
> >> +s->low_water_mark += max_size;
> > 
> > I think it's fine to only increase the low water mark here, however
> > imo it would be better to also cache the max size in IOVAMapping too,
> > then in resize() we double check new_size <= max_size?  It also makes
> > IOVAMapping more self contained.
> > 
> 
> I‘ll have a look how much additional code that will imply - if it‘s simple, 
> I‘ll do it.

AFAICT it'll be as simple as introducing IOVAMapping.max_size, then
pass max_size into qemu_vfio_add_mapping().  Thanks,

-- 
Peter Xu

Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()




> Am 28.02.2020 um 21:49 schrieb Peter Xu :
> 
> On Fri, Feb 28, 2020 at 03:19:45PM -0500, David Hildenbrand wrote:
>> 
>> 
 Am 28.02.2020 um 20:55 schrieb Peter Xu :
>>> 
>>> On Thu, Feb 27, 2020 at 11:12:02AM +0100, David Hildenbrand wrote:
 +static void qemu_vfio_dma_map_resize(QEMUVFIOState *s, void *host,
 + size_t old_size, size_t new_size)
 +{
 +IOVAMapping *m;
 +int index = 0;
 +
 +qemu_mutex_lock(>lock);
 +m = qemu_vfio_find_mapping(s, host, );
 +if (!m) {
 +return;
 +}
 +assert(m->size == old_size);
 +
 +/* Note: Not atomic - we need a new ioctl for that. */
 +qemu_vfio_undo_mapping(s, m->iova, m->size);
 +qemu_vfio_do_mapping(s, host, m->iova, new_size);
>>> 
>>> Another way to ask my previous question 1 (in the other reply): Can we
>>> simply map/unmap the extra, while keep the shared untouched?
>> 
>> As far as I understand the kernel implementation, unfortunately no. You 
>> might be able to grow (by mapping the delta), but shrinking is not possible 
>> AFAIR. And I *think* with many resizes, there could be an issue if I 
>> remember correctly.
> 
> Ah right (and I think the same thing will happen to vfio-pci during
> memory_region_set_size()).  Then please double confirm that virtio-mem
> is disabled for both vfio-helper users and vfio-pci.  Also, would you

Yes, will double check, should have taken care of both.

> mind comment above the unmap+map with more information?  E.g.:
> 

Sure, will add - thanks!

>  For now, we must unmap the whole mapped range first and remap with
>  the new size.  The reason is that VFIO_IOMMU_UNMAP_DMA might fail
>  with partial unmap of previous mappings, so even we can add extra
>  new mappings to extend the old range, however we still won't able to
>  always success on shrinking memories.  The side effect is that it's
>  never safe to do resizing during VM execution.
> 
> Or something better.  With an enriched comment, I think it's fine:
> 
> Reviewed-by: Peter Xu 
> 

Thanks Peter! Have a nice weekend!

Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()

On Fri, Feb 28, 2020 at 03:19:45PM -0500, David Hildenbrand wrote:
> 
> 
> > Am 28.02.2020 um 20:55 schrieb Peter Xu :
> > 
> > On Thu, Feb 27, 2020 at 11:12:02AM +0100, David Hildenbrand wrote:
> >> +static void qemu_vfio_dma_map_resize(QEMUVFIOState *s, void *host,
> >> + size_t old_size, size_t new_size)
> >> +{
> >> +IOVAMapping *m;
> >> +int index = 0;
> >> +
> >> +qemu_mutex_lock(>lock);
> >> +m = qemu_vfio_find_mapping(s, host, );
> >> +if (!m) {
> >> +return;
> >> +}
> >> +assert(m->size == old_size);
> >> +
> >> +/* Note: Not atomic - we need a new ioctl for that. */
> >> +qemu_vfio_undo_mapping(s, m->iova, m->size);
> >> +qemu_vfio_do_mapping(s, host, m->iova, new_size);
> > 
> > Another way to ask my previous question 1 (in the other reply): Can we
> > simply map/unmap the extra, while keep the shared untouched?
> 
> As far as I understand the kernel implementation, unfortunately no. You might 
> be able to grow (by mapping the delta), but shrinking is not possible AFAIR. 
> And I *think* with many resizes, there could be an issue if I remember 
> correctly.

Ah right (and I think the same thing will happen to vfio-pci during
memory_region_set_size()).  Then please double confirm that virtio-mem
is disabled for both vfio-helper users and vfio-pci.  Also, would you
mind comment above the unmap+map with more information?  E.g.:

  For now, we must unmap the whole mapped range first and remap with
  the new size.  The reason is that VFIO_IOMMU_UNMAP_DMA might fail
  with partial unmap of previous mappings, so even we can add extra
  new mappings to extend the old range, however we still won't able to
  always success on shrinking memories.  The side effect is that it's
  never safe to do resizing during VM execution.

Or something better.  With an enriched comment, I think it's fine:

Reviewed-by: Peter Xu 

Thanks,

-- 
Peter Xu

Re: [PATCH v3 15/15] exec: Ram blocks with resizeable anonymous allocations under POSIX

On Thu, Feb 27, 2020 at 11:12:05AM +0100, David Hildenbrand wrote:

[...]

> +static void ram_block_alloc_ram(RAMBlock *rb)
> +{
> +const bool shared = qemu_ram_is_shared(rb);
> +
> +/*
> + * If we can, try to allocate actually resizeable ram. Will also fail
> + * if qemu_anon_ram_alloc_resizeable() is not implemented.
> + */
> +if (phys_mem_alloc == qemu_anon_ram_alloc &&
> +qemu_ram_is_resizeable(rb) &&
> +ram_block_notifiers_support_resize()) {
> +rb->host = qemu_anon_ram_alloc_resizeable(rb->used_length,
> +  rb->max_length,
> +  >mr->align, shared);
> +if (rb->host) {
> +rb->flags |= RAM_RESIZEABLE_ALLOC;

A trivial nit: If it should only be set automatically by the memory
code, shall we mark it our somewhere just in case someone passed this
in flag explicitly (which, iiuc, is a misuse)?  Maybe:

  assert(!(rb->flags | RAM_RESIZEABLE_ALLOC));

At the entry of this function?  Other than that it looks sane to me:

Reviewed-by: Peter Xu 

> +return;
> +}
> +}
> +rb->host = phys_mem_alloc(rb->max_length, >mr->align, shared);
> +}

Thanks,

-- 
Peter Xu

Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()



> Am 28.02.2020 um 20:55 schrieb Peter Xu :
> 
> On Thu, Feb 27, 2020 at 11:12:02AM +0100, David Hildenbrand wrote:
>> +static void qemu_vfio_dma_map_resize(QEMUVFIOState *s, void *host,
>> + size_t old_size, size_t new_size)
>> +{
>> +IOVAMapping *m;
>> +int index = 0;
>> +
>> +qemu_mutex_lock(>lock);
>> +m = qemu_vfio_find_mapping(s, host, );
>> +if (!m) {
>> +return;
>> +}
>> +assert(m->size == old_size);
>> +
>> +/* Note: Not atomic - we need a new ioctl for that. */
>> +qemu_vfio_undo_mapping(s, m->iova, m->size);
>> +qemu_vfio_do_mapping(s, host, m->iova, new_size);
> 
> Another way to ask my previous question 1 (in the other reply): Can we
> simply map/unmap the extra, while keep the shared untouched?

As far as I understand the kernel implementation, unfortunately no. You might 
be able to grow (by mapping the delta), but shrinking is not possible AFAIR. 
And I *think* with many resizes, there could be an issue if I remember 
correctly.

Thanks!

> 
> Thanks,
> 
>> +
>> +m->size = new_size;
>> +assert(qemu_vfio_verify_mappings(s));
>> +
>> +qemu_mutex_unlock(>lock);
>> +}
> 
> -- 
> Peter Xu
>

Re: [PATCH v2 4/4] accel/tcg: increase default code gen buffer size for 64 bit

2020-02-28 Thread Niek Linnenbank

On Fri, Feb 28, 2020 at 8:24 PM Alex Bennée  wrote:

> While 32mb is certainly usable a full system boot ends up flushing the
> codegen buffer nearly 100 times. Increase the default on 64 bit hosts
> to take advantage of all that spare memory. After this change I can
> boot my tests system without any TB flushes.
>
> As we usually run more CONFIG_USER binaries at a time in typical usage
> we aren't quite as profligate for user-mode code generation usage. We
> also bring the static code gen defies to the same place to keep all
> the reasoning in the comments together.
>
> Signed-off-by: Alex Bennée 
> Tested-by: Niek Linnenbank 
>
Reviewed-by: Niek Linnenbank 


>
> ---
> v2
>   - 2gb->1gb for system emulation
>   - split user and system emulation buffer sizes
> ---
>  accel/tcg/translate-all.c | 35 ++-
>  1 file changed, 26 insertions(+), 9 deletions(-)
>
> diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
> index 4ce5d1b3931..78914154bfc 100644
> --- a/accel/tcg/translate-all.c
> +++ b/accel/tcg/translate-all.c
> @@ -892,15 +892,6 @@ static void page_lock_pair(PageDesc **ret_p1,
> tb_page_addr_t phys1,
>  }
>  }
>
> -#if defined(CONFIG_USER_ONLY) && TCG_TARGET_REG_BITS == 32
> -/*
> - * For user mode on smaller 32 bit systems we may run into trouble
> - * allocating big chunks of data in the right place. On these systems
> - * we utilise a static code generation buffer directly in the binary.
> - */
> -#define USE_STATIC_CODE_GEN_BUFFER
> -#endif
> -
>  /* Minimum size of the code gen buffer.  This number is randomly chosen,
> but not so small that we can't have a fair number of TB's live.  */
>  #define MIN_CODE_GEN_BUFFER_SIZE (1 * MiB)
> @@ -929,7 +920,33 @@ static void page_lock_pair(PageDesc **ret_p1,
> tb_page_addr_t phys1,
>  # define MAX_CODE_GEN_BUFFER_SIZE  ((size_t)-1)
>  #endif
>
> +#if TCG_TARGET_REG_BITS == 32
>  #define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB)
> +#ifdef CONFIG_USER_ONLY
> +/*
> + * For user mode on smaller 32 bit systems we may run into trouble
> + * allocating big chunks of data in the right place. On these systems
> + * we utilise a static code generation buffer directly in the binary.
> + */
> +#define USE_STATIC_CODE_GEN_BUFFER
> +#endif
> +#else /* TCG_TARGET_REG_BITS == 64 */
> +#ifdef CONFIG_USER_ONLY
> +/*
> + * As user-mode emulation typically means running multiple instances
> + * of the translator don't go too nuts with our default code gen
> + * buffer lest we make things too hard for the OS.
> + */
> +#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (128 * MiB)
> +#else
> +/*
> + * We expect most system emulation to run one or two guests per host.
> + * Users running large scale system emulation may want to tweak their
> + * runtime setup via the tb-size control on the command line.
> + */
> +#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (1 * GiB)
> +#endif
> +#endif
>
>  #define DEFAULT_CODE_GEN_BUFFER_SIZE \
>(DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \
> --
> 2.20.1
>
>

-- 
Niek Linnenbank

Re: [PATCH v2 2/4] accel/tcg: remove link between guest ram and TCG cache size

2020-02-28 Thread Niek Linnenbank

On Fri, Feb 28, 2020 at 8:24 PM Alex Bennée  wrote:

> Basing the TB cache size on the ram_size was always a little heuristic
> and was broken by a1b18df9a4 which caused ram_size not to be fully
> realised at the time we initialise the TCG translation cache.
>
> The current DEFAULT_CODE_GEN_BUFFER_SIZE may still be a little small
> but follow-up patches will address that.
>
> Fixes: a1b18df9a4
> Signed-off-by: Alex Bennée 
> Reviewed-by: Richard Henderson 
> Tested-by: Philippe Mathieu-Daudé 
>
Reviewed-by: Niek Linnenbank 

Cc: Niek Linnenbank 
> Cc: Igor Mammedov 
> ---
>  accel/tcg/translate-all.c | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
> index 238b0e575bf..5b66af783b5 100644
> --- a/accel/tcg/translate-all.c
> +++ b/accel/tcg/translate-all.c
> @@ -938,15 +938,7 @@ static inline size_t size_code_gen_buffer(size_t
> tb_size)
>  {
>  /* Size the buffer.  */
>  if (tb_size == 0) {
> -#ifdef USE_STATIC_CODE_GEN_BUFFER
>  tb_size = DEFAULT_CODE_GEN_BUFFER_SIZE;
> -#else
> -/* ??? Needs adjustments.  */
> -/* ??? If we relax the requirement that CONFIG_USER_ONLY use the
> -   static buffer, we could size this on RESERVED_VA, on the text
> -   segment size of the executable, or continue to use the
> default.  */
> -tb_size = (unsigned long)(ram_size / 4);
> -#endif
>  }
>  if (tb_size < MIN_CODE_GEN_BUFFER_SIZE) {
>  tb_size = MIN_CODE_GEN_BUFFER_SIZE;
> --
> 2.20.1
>
>

-- 
Niek Linnenbank

Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()




> Am 28.02.2020 um 20:43 schrieb Peter Xu :
> 
> On Thu, Feb 27, 2020 at 11:12:02AM +0100, David Hildenbrand wrote:
>> Let's implement ram_block_resized(), allowing resizeable mappings.
>> 
>> For resizeable mappings, we reserve $max_size IOVA address space, but only
>> map $size of it. When resizing, unmap the old part and remap the new
>> part. We'll need a new ioctl to do this atomically (e.g., to resize
>> while the guest is running - not allowed for now).
> 
> Curious: I think it's true for now because resizing only happens
> during reboot or destination VM during migration (but before
> switching).  However is that guaranteed too in the future?
> 

E.g., virtio-mem will run mutual exclusive with vfio until vfio won‘t pin all 
guest memory anymore blindly (iow, is compatible with memory overcommit and 
discarding of ram blocks).

> [...]
> 
>> @@ -631,7 +658,7 @@ int qemu_vfio_dma_map(QEMUVFIOState *s, void *host, 
>> size_t size,
>> qemu_vfio_remove_mapping(s, mapping);
>> goto out;
>> }
>> -s->low_water_mark += size;
>> +s->low_water_mark += max_size;
> 
> I think it's fine to only increase the low water mark here, however
> imo it would be better to also cache the max size in IOVAMapping too,
> then in resize() we double check new_size <= max_size?  It also makes
> IOVAMapping more self contained.
> 

I‘ll have a look how much additional code that will imply - if it‘s simple, 
I‘ll do it.

Thanks!

> Thanks,
> 
> -- 
> Peter Xu
>

Re: [PATCH v3 14/15] numa: Introduce ram_block_notifiers_support_resize()

On Thu, Feb 27, 2020 at 11:12:04AM +0100, David Hildenbrand wrote:
> We want to actually use resizeable allocations in resizeable ram blocks
> (IOW, make everything between used_length and max_length inaccessible) -
> however, not all ram block notifiers can support that.
> 
> Introduce a way to detect if any registered notifier does not
> support resizes - ram_block_notifiers_support_resize() - which we can later
> use to fallback to legacy handling if a registered notifier (esp., SEV and
> HAX) does not support actual resizes.
> 
> Cc: Richard Henderson 
> Cc: Paolo Bonzini 
> Cc: "Dr. David Alan Gilbert" 
> Cc: Eduardo Habkost 
> Cc: Marcel Apfelbaum 
> Cc: "Michael S. Tsirkin" 
> Cc: Igor Mammedov 
> Signed-off-by: David Hildenbrand 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v3 13/15] util: oslib: Resizeable anonymous allocations under POSIX

On Thu, Feb 27, 2020 at 11:12:03AM +0100, David Hildenbrand wrote:
> Introduce qemu_anon_ram_alloc_resizeable() and qemu_anon_ram_resize().
> Implement them under POSIX and make them return NULL under WIN32.
> 
> Under POSIX, we make use of resizeable mmaps. An implementation under
> WIN32 is theoretically possible AFAIK and can be added later.
> 
> In qemu_anon_ram_free(), rename the size parameter to max_size, to make
> it clearer that we have to use the maximum size when freeing resizeable
> anonymous allocations.
> 
> Cc: Richard Henderson 
> Cc: Paolo Bonzini 
> Cc: "Dr. David Alan Gilbert" 
> Cc: Eduardo Habkost 
> Cc: Marcel Apfelbaum 
> Cc: Stefan Weil 
> Cc: Igor Mammedov 
> Signed-off-by: David Hildenbrand 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()

On Thu, Feb 27, 2020 at 11:12:02AM +0100, David Hildenbrand wrote:
> +static void qemu_vfio_dma_map_resize(QEMUVFIOState *s, void *host,
> + size_t old_size, size_t new_size)
> +{
> +IOVAMapping *m;
> +int index = 0;
> +
> +qemu_mutex_lock(>lock);
> +m = qemu_vfio_find_mapping(s, host, );
> +if (!m) {
> +return;
> +}
> +assert(m->size == old_size);
> +
> +/* Note: Not atomic - we need a new ioctl for that. */
> +qemu_vfio_undo_mapping(s, m->iova, m->size);
> +qemu_vfio_do_mapping(s, host, m->iova, new_size);

Another way to ask my previous question 1 (in the other reply): Can we
simply map/unmap the extra, while keep the shared untouched?

Thanks,

> +
> +m->size = new_size;
> +assert(qemu_vfio_verify_mappings(s));
> +
> +qemu_mutex_unlock(>lock);
> +}

-- 
Peter Xu

Re: [PATCH v3 11/15] util/mmap-alloc: Implement resizeable mmaps

On Thu, Feb 27, 2020 at 11:12:01AM +0100, David Hildenbrand wrote:
> Implement resizeable mmaps. For now, the actual resizing is not wired up.
> Introduce qemu_ram_mmap_resizeable() and qemu_ram_mmap_resize(). Make
> qemu_ram_mmap() a wrapper of qemu_ram_mmap_resizeable().
> 
> Cc: Richard Henderson 
> Cc: Igor Kotrasinski 
> Cc: Murilo Opsfelder Araujo 
> Cc: "Michael S. Tsirkin" 
> Cc: Greg Kurz 
> Cc: Eduardo Habkost 
> Cc: "Dr. David Alan Gilbert" 
> Cc: Igor Mammedov 
> Signed-off-by: David Hildenbrand 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v3 07/15] util/mmap-alloc: Factor out calculation of the pagesize for the guard page

On Thu, Feb 27, 2020 at 11:11:57AM +0100, David Hildenbrand wrote:
> Let's factor out calculating the size of the guard page and rename the
> variable to make it clearer that this pagesize only applies to the
> guard page.
> 
> Cc: "Michael S. Tsirkin" 
> Cc: Murilo Opsfelder Araujo 
> Cc: Greg Kurz 
> Cc: Eduardo Habkost 
> Cc: "Dr. David Alan Gilbert" 
> Cc: Igor Mammedov 
> Signed-off-by: David Hildenbrand 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v3 12/15] util: vfio-helpers: Implement ram_block_resized()

On Thu, Feb 27, 2020 at 11:12:02AM +0100, David Hildenbrand wrote:
> Let's implement ram_block_resized(), allowing resizeable mappings.
> 
> For resizeable mappings, we reserve $max_size IOVA address space, but only
> map $size of it. When resizing, unmap the old part and remap the new
> part. We'll need a new ioctl to do this atomically (e.g., to resize
> while the guest is running - not allowed for now).

Curious: I think it's true for now because resizing only happens
during reboot or destination VM during migration (but before
switching).  However is that guaranteed too in the future?

[...]

> @@ -631,7 +658,7 @@ int qemu_vfio_dma_map(QEMUVFIOState *s, void *host, 
> size_t size,
>  qemu_vfio_remove_mapping(s, mapping);
>  goto out;
>  }
> -s->low_water_mark += size;
> +s->low_water_mark += max_size;

I think it's fine to only increase the low water mark here, however
imo it would be better to also cache the max size in IOVAMapping too,
then in resize() we double check new_size <= max_size?  It also makes
IOVAMapping more self contained.

Thanks,

-- 
Peter Xu

[PATCH v2 4/4] accel/tcg: increase default code gen buffer size for 64 bit

While 32mb is certainly usable a full system boot ends up flushing the
codegen buffer nearly 100 times. Increase the default on 64 bit hosts
to take advantage of all that spare memory. After this change I can
boot my tests system without any TB flushes.

As we usually run more CONFIG_USER binaries at a time in typical usage
we aren't quite as profligate for user-mode code generation usage. We
also bring the static code gen defies to the same place to keep all
the reasoning in the comments together.

Signed-off-by: Alex Bennée 
Tested-by: Niek Linnenbank 

---
v2
  - 2gb->1gb for system emulation
  - split user and system emulation buffer sizes
---
 accel/tcg/translate-all.c | 35 ++-
 1 file changed, 26 insertions(+), 9 deletions(-)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index 4ce5d1b3931..78914154bfc 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -892,15 +892,6 @@ static void page_lock_pair(PageDesc **ret_p1, 
tb_page_addr_t phys1,
 }
 }
 
-#if defined(CONFIG_USER_ONLY) && TCG_TARGET_REG_BITS == 32
-/*
- * For user mode on smaller 32 bit systems we may run into trouble
- * allocating big chunks of data in the right place. On these systems
- * we utilise a static code generation buffer directly in the binary.
- */
-#define USE_STATIC_CODE_GEN_BUFFER
-#endif
-
 /* Minimum size of the code gen buffer.  This number is randomly chosen,
but not so small that we can't have a fair number of TB's live.  */
 #define MIN_CODE_GEN_BUFFER_SIZE (1 * MiB)
@@ -929,7 +920,33 @@ static void page_lock_pair(PageDesc **ret_p1, 
tb_page_addr_t phys1,
 # define MAX_CODE_GEN_BUFFER_SIZE  ((size_t)-1)
 #endif
 
+#if TCG_TARGET_REG_BITS == 32
 #define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB)
+#ifdef CONFIG_USER_ONLY
+/*
+ * For user mode on smaller 32 bit systems we may run into trouble
+ * allocating big chunks of data in the right place. On these systems
+ * we utilise a static code generation buffer directly in the binary.
+ */
+#define USE_STATIC_CODE_GEN_BUFFER
+#endif
+#else /* TCG_TARGET_REG_BITS == 64 */
+#ifdef CONFIG_USER_ONLY
+/*
+ * As user-mode emulation typically means running multiple instances
+ * of the translator don't go too nuts with our default code gen
+ * buffer lest we make things too hard for the OS.
+ */
+#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (128 * MiB)
+#else
+/*
+ * We expect most system emulation to run one or two guests per host.
+ * Users running large scale system emulation may want to tweak their
+ * runtime setup via the tb-size control on the command line.
+ */
+#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (1 * GiB)
+#endif
+#endif
 
 #define DEFAULT_CODE_GEN_BUFFER_SIZE \
   (DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \
-- 
2.20.1

[PATCH v2 2/4] accel/tcg: remove link between guest ram and TCG cache size

Basing the TB cache size on the ram_size was always a little heuristic
and was broken by a1b18df9a4 which caused ram_size not to be fully
realised at the time we initialise the TCG translation cache.

The current DEFAULT_CODE_GEN_BUFFER_SIZE may still be a little small
but follow-up patches will address that.

Fixes: a1b18df9a4
Signed-off-by: Alex Bennée 
Reviewed-by: Richard Henderson 
Tested-by: Philippe Mathieu-Daudé 
Cc: Niek Linnenbank 
Cc: Igor Mammedov 
---
 accel/tcg/translate-all.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index 238b0e575bf..5b66af783b5 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -938,15 +938,7 @@ static inline size_t size_code_gen_buffer(size_t tb_size)
 {
 /* Size the buffer.  */
 if (tb_size == 0) {
-#ifdef USE_STATIC_CODE_GEN_BUFFER
 tb_size = DEFAULT_CODE_GEN_BUFFER_SIZE;
-#else
-/* ??? Needs adjustments.  */
-/* ??? If we relax the requirement that CONFIG_USER_ONLY use the
-   static buffer, we could size this on RESERVED_VA, on the text
-   segment size of the executable, or continue to use the default.  */
-tb_size = (unsigned long)(ram_size / 4);
-#endif
 }
 if (tb_size < MIN_CODE_GEN_BUFFER_SIZE) {
 tb_size = MIN_CODE_GEN_BUFFER_SIZE;
-- 
2.20.1

[PATCH v2 1/4] accel/tcg: use units.h for defining code gen buffer sizes

It's easier to read.

Signed-off-by: Alex Bennée 
Reviewed-by: Niek Linnenbank 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
---
 accel/tcg/translate-all.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index a08ab11f657..238b0e575bf 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -18,6 +18,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include "qemu-common.h"
 
 #define NO_CPU_IO_DEFS
@@ -901,33 +902,33 @@ static void page_lock_pair(PageDesc **ret_p1, 
tb_page_addr_t phys1,
 
 /* Minimum size of the code gen buffer.  This number is randomly chosen,
but not so small that we can't have a fair number of TB's live.  */
-#define MIN_CODE_GEN_BUFFER_SIZE (1024u * 1024)
+#define MIN_CODE_GEN_BUFFER_SIZE (1 * MiB)
 
 /* Maximum size of the code gen buffer we'd like to use.  Unless otherwise
indicated, this is constrained by the range of direct branches on the
host cpu, as used by the TCG implementation of goto_tb.  */
 #if defined(__x86_64__)
-# define MAX_CODE_GEN_BUFFER_SIZE  (2ul * 1024 * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (2 * GiB)
 #elif defined(__sparc__)
-# define MAX_CODE_GEN_BUFFER_SIZE  (2ul * 1024 * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (2 * GiB)
 #elif defined(__powerpc64__)
-# define MAX_CODE_GEN_BUFFER_SIZE  (2ul * 1024 * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (2 * GiB)
 #elif defined(__powerpc__)
-# define MAX_CODE_GEN_BUFFER_SIZE  (32u * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (32 * MiB)
 #elif defined(__aarch64__)
-# define MAX_CODE_GEN_BUFFER_SIZE  (2ul * 1024 * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (2 * GiB)
 #elif defined(__s390x__)
   /* We have a +- 4GB range on the branches; leave some slop.  */
-# define MAX_CODE_GEN_BUFFER_SIZE  (3ul * 1024 * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (3 * GiB)
 #elif defined(__mips__)
   /* We have a 256MB branch region, but leave room to make sure the
  main executable is also within that region.  */
-# define MAX_CODE_GEN_BUFFER_SIZE  (128ul * 1024 * 1024)
+# define MAX_CODE_GEN_BUFFER_SIZE  (128 * MiB)
 #else
 # define MAX_CODE_GEN_BUFFER_SIZE  ((size_t)-1)
 #endif
 
-#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32u * 1024 * 1024)
+#define DEFAULT_CODE_GEN_BUFFER_SIZE_1 (32 * MiB)
 
 #define DEFAULT_CODE_GEN_BUFFER_SIZE \
   (DEFAULT_CODE_GEN_BUFFER_SIZE_1 < MAX_CODE_GEN_BUFFER_SIZE \
-- 
2.20.1

[PATCH v2 3/4] accel/tcg: only USE_STATIC_CODE_GEN_BUFFER on 32 bit hosts

There is no particular reason to use a static codegen buffer on 64 bit
hosts as we have address space to burn. Allow the common CONFIG_USER
case to use the mmap'ed buffers like SoftMMU.

Signed-off-by: Alex Bennée 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Tested-by: Philippe Mathieu-Daudé 
Reviewed-by: Niek Linnenbank 
---
 accel/tcg/translate-all.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index 5b66af783b5..4ce5d1b3931 100644
--- a/accel/tcg/translate-all.c
+++ b/accel/tcg/translate-all.c
@@ -892,11 +892,12 @@ static void page_lock_pair(PageDesc **ret_p1, 
tb_page_addr_t phys1,
 }
 }
 
-#if defined(CONFIG_USER_ONLY)
-/* Currently it is not recommended to allocate big chunks of data in
-   user mode. It will change when a dedicated libc will be used.  */
-/* ??? 64-bit hosts ought to have no problem mmaping data outside the
-   region in which the guest needs to run.  Revisit this.  */
+#if defined(CONFIG_USER_ONLY) && TCG_TARGET_REG_BITS == 32
+/*
+ * For user mode on smaller 32 bit systems we may run into trouble
+ * allocating big chunks of data in the right place. On these systems
+ * we utilise a static code generation buffer directly in the binary.
+ */
 #define USE_STATIC_CODE_GEN_BUFFER
 #endif
 
-- 
2.20.1

[PATCH v2 0/4] Clean-up codegen cache size

Hi,

A few tweaks to the final commit so we are a little less greedy for
translation buffer, especially for the CONFIG_USER case. Otherwise
I've applied the review tags.

Alex Bennée (4):
  accel/tcg: use units.h for defining code gen buffer sizes
  accel/tcg: remove link between guest ram and TCG cache size
  accel/tcg: only USE_STATIC_CODE_GEN_BUFFER on 32 bit hosts
  accel/tcg: increase default code gen buffer size for 64 bit

 accel/tcg/translate-all.c | 61 +++
 1 file changed, 36 insertions(+), 25 deletions(-)

-- 
2.20.1

Re: [PATCH v1 4/4] accel/tcg: increase default code gen buffer size for 64 bit



Igor Mammedov  writes:

> On Thu, 27 Feb 2020 20:07:24 +0100
> Niek Linnenbank  wrote:
>
>> Hi Richard,
>> 
>> On Thu, Feb 27, 2020 at 1:57 PM Richard Henderson <
>> richard.hender...@linaro.org> wrote:  
>> 
>> > On 2/27/20 4:31 AM, Alex Bennée wrote:  
>> > >> It does not make sense for a linux-user chroot, running make -jN, on  
>> > just about  
>> > >> any host.  For linux-user, I could be happy with a modest increase, but 
>> > >>  
>> > not all  
>> > >> the way out to 2GiB.
>> > >>
>> > >> Discuss.  
>> > >
>> > > Does it matter that much? Surely for small programs the kernel just
>> > > never pages in the used portions of the mmap?  
>> >
>> > That's why I used the example of a build under the chroot, because the
>> > compiler
>> > is not a small program.
>> >
>> > Consider when the memory *is* used, and N * 2GB implies lots of paging,
>> > where
>> > the previous N * 32MB did not.
>> >
>> > I agree that a lower default value probably is safer until we have more  
>> proof that a larger value does not give any issues.
>> 
>> 
>> > I'm saying that we should consider a setting more like 128MB or so, since
>> > the
>> > value cannot be changed from the command-line, or through the environment.
>> >  
>> 
>> Proposal: can we then introduce a new command line parameter for this?
>> Maybe in a new patch?
>
> linux-user currently uses 32Mb static buffer so it probably fine to
> leave it as is or bump it to 128Mb regardless of the 32/64bit host.
>
> for system emulation, we already have tb-size option to set user
> specified buffer size.
>
> Issue is with system emulation is that it sizes buffer to 1/4 of
> ram_size and dependency on ram_size is what we are trying to get
> rid of. If we consider unit/acceptance tests as main target/user,
> then they mostly use default ram_size value which varies mostly
> from 16Mb to 1Gb depending on the board. So used buffer size is
> in 4-256Mb range.
> Considering that current CI runs fine with max 256Mb buffer,
> it might make sense to use it as new heuristic which would not
> regress our test infrastructure and might improve performance
> for boards where smaller default buffer was used.

I've dropped it from 2gb to 1gb for system emulation. For the acceptance
tests I doubt we'll even fill the buffer but the mmap memory should
overcommit fine.

>
>
>> Since the size of the code generation buffer appears to have an impact on
>> performance,
>> in my opinion it would make sense to make it configurable by the user.
>> 
>> Regards,
>> 
>> 
>> >
>> >
>> > r~
>> >
>> >  
>> 


-- 
Alex Bennée

Re: [PATCH v4 1/7] target/arm: Improve masking of HCR RES0 bits

On Fri, 28 Feb 2020 at 18:55, Richard Henderson
 wrote:
>
> On 2/28/20 9:34 AM, Peter Maydell wrote:
> > You could refine the valid mask as the & of the bits which we
> > do want to exist in aarch32, rather than &~ of the reserved bits:
> >
> >  valid_mask &= TTLBIS | TOCU | TICAB | ...
> >
> > ?
>
> Yes, that's a good idea.

It occurs to me that we should check what the required
semantics are for the opposite half of the register
if the guest writes to one half of it via hcr_writehigh()
or hcr_writelow() -- is the un-accessed half supposed
to stay exactly as it is, or is it ok for the
RES0-for-aarch32 bits to get squashed in the process?
That would seem at least a bit odd even if it's valid,
so maybe better to do aarch32 RES0 masking in
hcr_writehigh() and hcr_writelow()?

thanks
-- PMM

Re: [PATCH v4 1/7] target/arm: Improve masking of HCR RES0 bits

On 2/28/20 9:34 AM, Peter Maydell wrote:
> One of us is miscounting, and I don't *think* it's me...
> 
> bits 63..0:  ff80ff8c9000
> bits 63..32: ff80ff8c
> bits 64..48: ff80
> 
> bit 48 looks like it's 0 to me.

Oops, yes, it's me.

> You could refine the valid mask as the & of the bits which we
> do want to exist in aarch32, rather than &~ of the reserved bits:
> 
>  valid_mask &= TTLBIS | TOCU | TICAB | ...
> 
> ?

Yes, that's a good idea.


r~

Re: [PATCH v4 5/5] target/riscv: add vector amo operations

On 2/28/20 1:19 AM, LIU Zhiwei wrote:
>>> +#define GEN_VEXT_AMO_NOATOMIC_OP(NAME, ETYPE, MTYPE, H, DO_OP, SUF)  \
>>> +static void vext_##NAME##_noatomic_op(void *vs3, target_ulong addr,  \
>>> +    uint32_t wd, uint32_t idx, CPURISCVState *env, uintptr_t retaddr)\
>>> +{    \
>>> +    ETYPE ret;   \
>>> +    target_ulong tmp;    \
>>> +    int mmu_idx = cpu_mmu_index(env, false); \
>>> +    tmp = cpu_ld##SUF##_mmuidx_ra(env, addr, mmu_idx, retaddr);  \
>>> +    ret = DO_OP((ETYPE)(MTYPE)tmp, *((ETYPE *)vs3 + H(idx)));    \
>>> +    cpu_st##SUF##_mmuidx_ra(env, addr, ret, mmu_idx, retaddr);   \
>>> +    if (wd) {    \
>>> +    *((ETYPE *)vs3 + H(idx)) = (target_long)(MTYPE)tmp;  \
>> The target_long cast is wrong; should be ETYPE.
> "If the AMO memory element width is less than SEW, the value returned from 
> memory
>  is sign-extended to fill SEW"
> 
> So just use (target_long) to sign-extended. As you see, instructions like
> 
> vamominud
> 
> have the uint64_t as ETYPE.  And it can't sign-extend the value from memory by
> (ETYPE)(MTYPE)tmp.

Casting to target_long doesn't help -- it becomes signed at a variable size,
possibly larger than MTYPE.

In addition, I think you're performing the operation at the wrong length.  The
text of the ISA document could be clearer, but

  # If SEW > 32 bits, the value returned from memory
  # is sign-extended to fill SEW.

You are performing the operation in ETYPE, but it should be done in MTYPE and
only afterward extended to ETYPE.

For minu/maxu, you're right that you need an unsigned for the operation.  But
then you need a signed type of the same width for the extension.

One possibility is to *always* make MTYPE a signed type, but for the two cases
that require an unsigned type, provide it.  E.g.

#define GEN_VEXT_AMO_NOATOMIC_OP(NAME, ESZ, MSZ, H, DO_OP, SUF)
static void vext_##NAME##_noatomic_op(void *vs3,
target_ulong addr, uint32_t wd, uint32_t idx,
CPURISCVState *env, uintptr_t retaddr)
{
typedef int##ESZ##_t ETYPE;
typedef int##MSZ##_t MTYPE;
typedef uint##MSZ##_t UMTYPE;
ETYPE *pe3 = (ETYPE *)vs3 + H(idx);
MTYPE a = *pe3, b = cpu_ld##SUF##_data(env, addr);
a = DO_OP(a, b);
cpu_st##SUF##_data(env, addr, a);
if (wd) {
*pe3 = a;
}
}

/* Signed min/max */
#define DO_MAX(N, M)  ((N) >= (M) ? (N) : (M))
#define DO_MIN(N, M)  ((N) >= (M) ? (M) : (N))

/* Unsigned min/max */
#define DO_MAXU(N, M) DO_MAX((UMTYPE)N, (UMTYPE)M)
#define DO_MINU(N, M) DO_MIN((UMTYPE)N, (UMTYPE)M)

GEN_VEXT_AMO_NOATOMIC_OP(vamomaxuw_v_d, 64, 32, H8, DO_MAXU, l)
GEN_VEXT_AMO_NOATOMIC_OP(vamomaxud_v_d, 64, 64, H8, DO_MAXU, q)


>> The missing aligned address check is the only remaining exception that the
>> helper_atomic_* functions would raise, since you have properly checked for
>> read+write.  So it might be possible to get away with using the helpers, but 
>> I
>> don't like it.
> Do you mean write my own helpers to implement atomic operations?
> 
> What's the meaning of " but I don't like it. "?

I don't like re-using helpers in an incorrect way.

>> But I do think it would be better to write your own helpers for the atomic
>> paths.  They need not check quite so much, since we have already done the
>> validation above.  You pretty much only need to use tlb_vaddr_to_host.
>>
>> If that gets too ugly, we can talk about rearranging
>> accel/tcg/atomic_template.h so that it could be reused.
> Good idea.  Perhaps use tlb_vaddr_to_host instead of atomic_mmu_lookup
> to define another macro like GEN_ATOMIC_HELPER?
>> Alternately, we could simply *always* use the non-atomic helpers, and raise
>> exit_atomic if PARALLEL.
> Yes, it's the simplest way.
> However I prefer try to define something like GEN_ATOMIC_HELPER in
> vector_helper.c.

I'll think about this some more.
In the short-term, I think non-atomic is the best we can do.


r~

Re: [PATCH v5 49/50] multi-process: add the concept description to docs/devel/qemu-multiprocess

2020-02-28 Thread Elena Ufimtseva

On Thu, Feb 27, 2020 at 05:11:40PM +, Stefan Hajnoczi wrote:
> On Mon, Feb 24, 2020 at 03:55:40PM -0500, Jagannathan Raman wrote:
> > From: John G Johnson 
> > 
> > Signed-off-by: John G Johnson 
> > Signed-off-by: Elena Ufimtseva 
> > Signed-off-by: Jagannathan Raman 
> > ---
> >  docs/devel/index.rst |1 +
> >  docs/devel/qemu-multiprocess.rst | 1102 
> > ++
> >  2 files changed, 1103 insertions(+)
> >  create mode 100644 docs/devel/qemu-multiprocess.rst
> > 
> > diff --git a/docs/devel/index.rst b/docs/devel/index.rst
> > index 4dc2ca8..1a95871 100644
> > --- a/docs/devel/index.rst
> > +++ b/docs/devel/index.rst
> > @@ -25,3 +25,4 @@ Contents:
> > tcg-plugins
> > bitops
> > reset
> > +   multi-process
> > diff --git a/docs/devel/qemu-multiprocess.rst 
> > b/docs/devel/qemu-multiprocess.rst
> > new file mode 100644
> > index 000..477e246
> > --- /dev/null
> > +++ b/docs/devel/qemu-multiprocess.rst
> > @@ -0,0 +1,1102 @@
> > +Disaggregating QEMU
> 
> Please revise this document and the patch series to use consistent
> terminology.  At least "qemu-multiprocess.rst", "--enable-mpqemu", and
> "disaggregated QEMU" are used to describe this feature (there are
> probably more, I have only looked at 2 patches so far).
> 
> It's confusing for someone who stumbles across one of these terms and
> then has to figure out that we're talking about the same thing when
> encountering other terms later on.
> 
> Please use a single name and use it consistently.
>


Thanks Stefan, will work on this. 
> > +===
> > +
> > +QEMU is often used as the hypervisor for virtual machines running in the
> > +Oracle cloud. Since one of the advantages of cloud computing is the
> > +ability to run many VMs from different tenants in the same cloud
> > +infrastructure, a guest that compromised its hypervisor could
> > +potentially use the hypervisor's access privileges to access data it is
> > +not authorized for.
> > +
> > +QEMU can be susceptible to security attack because it is a large,
> 
> s/attack/attacks/
> 
> > +monolithic program that provides many features to the VMs it services.
> > +Many of these feature can be configured out of QEMU, but even a reduced
> 
> s/feature/features/

Re: [PATCH v2 0/2] hw/arm/xilinx_zynq: Fix USB port instantiation

2020-02-28 Thread Edgar E. Iglesias

Sorry Peter, I missed the email.

Reviewed-by: Edgar E. Iglesias 

Best regards,
Edgar


On Fri, 28 Feb. 2020, 10:00 Peter Maydell,  wrote:

> On Thu, 20 Feb 2020 at 15:05, Peter Maydell 
> wrote:
> >
> > On Sat, 15 Feb 2020 at 12:23, Guenter Roeck  wrote:
> > >
> > > USB ports on Xilinx Zync must be instantiated as TYPE_CHIPIDEA to work.
> > > Linux expects and checks various chipidea registers, which do not exist
> > > with the basic ehci emulation. This patch series fixes the problem.
> > >
> > > The first patch in the series fixes the actual problem.
> > >
> > > The second patch removes the now obsolete explicit Xilinx
> > > support from the EHCI code.
> > >
> > > v2: Introduced summary
> > >
> > > 
> > > Guenter Roeck (2):
> > >   hw/arm/xilinx_zynq: Fix USB port instantiation
> > >   hw/usb/hcd-ehci-sysbus: Remove obsolete xlnx,ps7-usb class
> >
> > Xilinx folks -- could you provide a reviewed-by or acked-by
> > for this series, please?
>
> No? Oh, well, applied to target-arm.next anyway.
>
> thanks
> -- PMM
>

Re: [PATCH v5 50/50] multi-process: add configure and usage information

2020-02-28 Thread Elena Ufimtseva

On Thu, Feb 27, 2020 at 04:58:04PM +, Stefan Hajnoczi wrote:
> On Mon, Feb 24, 2020 at 03:55:41PM -0500, Jagannathan Raman wrote:
> > From: Elena Ufimtseva 
> > 
> > Signed-off-by: Elena Ufimtseva 
> > Signed-off-by: Jagannathan Raman 
> > Signed-off-by: John G Johnson 
> > ---
> >  docs/qemu-multiprocess.txt | 86 
> > ++
> >  1 file changed, 86 insertions(+)
> >  create mode 100644 docs/qemu-multiprocess.txt
> > 
> > diff --git a/docs/qemu-multiprocess.txt b/docs/qemu-multiprocess.txt
> > new file mode 100644
> > index 000..f156177
> > --- /dev/null
> > +++ b/docs/qemu-multiprocess.txt
> > @@ -0,0 +1,86 @@
> > +Multi-process QEMU
> > +==
> > +
> > +This document describes how to configure and use multi-process qemu.
> > +For the design document refer to docs/devel/qemu-multiprocess.
> > +
> > +1) Configuration
> > +
> > +
> > +To enable support for multi-process add --enable-mpqemu
> > +to the list of options for the "configure" script.
> > +
> > +
> > +2) Usage
> > +
> > +
> > +To start qemu with devices intended to run in a separate emulation
> > +process without libvirtd support, the following should be used on QEMU
> > +command line. As of now, we only support the emulation of lsi53c895a
> > +in a separate process
> > +
> > +* Since parts of the RAM are shared between QEMU & remote process, a
> > +  memory-backend-file is required to facilitate this, as follows:
> > +
> > +  -object memory-backend-file,id=mem,mem-path=/dev/shm/,size=4096M,share=on
> 
> memory-backend-memfd is more convenient.  It doesn't require a mem-path
> and share=on is the default.
>

Will change this. 
> > +
> > +* The devices to be emulated in the separate process are defined as
> > +  before with addition of "rid" suboption that serves as a remote group
> > +  identificator.
> > +
> > +  -device ,rid="remote process id"
> > +
> > +  For example, for non multi-process qemu:
> > +-device lsi53c895a,id=scsi0 device
> > +-device scsi-hd,drive=drive0,bus=scsi0.0,scsi-id=0
> > +-drive id=drive0,file=data-disk.img
> > +
> > +  and for multi-process qemu and no libvirt
> > +  support (i.e. QEMU forks child processes):
> > +-device lsi53c895a,id=scsi0,rid=0
> > +-device scsi-hd,drive=drive0,bus=scsi0.0,scsi-id=0,rid=0
> 
> This approach is invasive:
>  * lsi53c895a should not need to be modified with a new rid= option.
>  * QEMU should not know about the scsi-hd device or drive0.  Only the
>device emulation process needs to know about scsi-hd.
> 
> In order to cleanly separate QEMU and the device emulation process
> syntax like this is needed:
> 
>   -object remote-device,id=rid0,...
>   -device remote-pci-device,id=scsi0,remote-device=rid0
> 
> The "remote-device" object could be part of remote-pci-device, but
> keeping it separate may be useful in the future in order to support
> things like reconnection.
> 
> The generic "remote-pci-device" device handles any remote PCI device,
> not just the LSI SCSI controller.
> 
> Do you agree with this approach?
> 

We discussed these changes and they seem to be along the lines with
the future work on vfio over socket approach we will be working on later.

Could we for this experimental version have the changes you propose here
with one modification - instead of having generic remote-pci-device imply that 
that is LSI
device? And while we work towards vfio over socket this will become any remote
PCI device?

> > +* The command-line options for the remote process are added to the 
> > "command"
> > +  suboption of the newly added "-remote" option. 
> > +
> > +   -remote [socket],rid=0,exec="...",command="..."
> 
> QEMU has been using the -object TYPE syntax instead of adding new -TYPE
> command-line options.  This gives you object_add hotplug for free, for
> example.  I suggest using -object remote-device,id=,exec=,command=,
> instead of -remote.
> 

We will add these changes.
> > +
> > +  The drives to be emulated by the remote process are specified as part of
> > +  this command sub-option. The device to be used to connect to the monitor
> > +  is also specified as part of this suboption.
> > +
> > +  For example, the following option adds a drive and monitor to the remote
> > +  process:
> > +  -remote rid=0,exec="qemu-scsi-dev",command="-drive 
> > id=drive0,,file=data-disk.img -monitor unix:/home/qmp-sock,,server,,nowait"
> > +
> > +  Note: There's an issue with this "command" sub-option which we are in the
> > +  process of fixing. To work around this issue, it requires additional
> > +  "comma" characters as illustrated above, and in the example below.
> 
> command= (which could be called args= for clarity) will be difficult to
> use not just because of comma escaping but also because of double-quote
> escaping.  How do you pass a command-line argument that contains spaces?

Yes, this is not great. And spaces are the problem at the moment.
I am looking if the -object has

Re: [PATCH v3 00/33] Convert qemu-doc to rST

Hi Stefan -- I meant to cc you on these but forgot, relating to the
"qemu.nsi needs updating to know that it should install
Sphinx documentation these days" part...

On Fri, 28 Feb 2020 at 15:36, Peter Maydell  wrote:
>
> Hi; this series does a complete conversion of qemu-doc from
> Texinfo to rST, including the hxtool-generated parts and
> creation of the qemu.1 manpage from rST.
>
> It's marked v3 because it's a development of the v2 that
> Paolo sent out earlier this week.
>
> Changes from v2:
>  * I made the various review-comment fixes I suggested in
>replies to Paolo's series
>  * rebased on current master
>  * new patches at the end of the series which do the conversion
>of the .hx file doc fragments to rST
>(I did part of this semi-by-hand and then qemu-options.hx
>entirely automatically)
>  * new patches which generate the qemu.1 manpage with Sphinx
>  * new patches which remove the old qemu-doc makefile runes
>and other references to it
>  * new patches which delete the old texinfo sources, etc
>
> The only thing left still using Texinfo after this is the
> docs autogenerated from the QAPI doc-comments, which are
> their own standalone html and manpages so not affected by this.
>
> A couple of notes:
>  * I haven't actually been in a position to test the cocoa.m
>update of the HTML filename
>  * qemu.nsi (the Windows installer config file) thinks that
>qemu-doc.html is the only doc file it needs to know about,
>which is clearly wrong. However I don't have any idea about
>the Windows installer to be able to update or test it...
>
> The conversion is a little rough around the edges in a few
> place (mostly I have noted in commit messages when this is
> the case) but I would like to argue for (assuming we're happy
> with the series broadly) taking it into master and then refining
> it in-place. Having it out-of-tree for long is an invitation
> to conflicts and to accidentally losing docs updates if they
> hit master as changes to the texi or hx files before this
> series goes in.
>
> You can find a prerendered set of docs at
> https://people.linaro.org/~peter.maydell/qdoc-no-texi/
> (the interesting part is the system emulation user's guide,
> mostly), and a copy of the new manpage at
> https://people.linaro.org/~peter.maydell/qemu.1
> (download and examine with 'man -l path/to/qemu.1').
>
> thanks
> -- PMM

[Bug 1865188] Re: Switching from the monitor to the emulated machine with a French keyboard (AZERTY)

2020-02-28 Thread Laurent Vivier

In an xterm to switch to/from QEMU monitor use "Ctrl-A c"

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1865188

Title:
  Switching from the monitor to the emulated machine with a French
  keyboard (AZERTY)

Status in QEMU:
  New

Bug description:
  Hi,
  I run qemu in an xterm terminal, with TERM=vt100. My keyboard is french 
AZERTY.

  sudo ./qemu-system-hppa -monitor /dev/pts/2 -k fr  -boot d -drive
  if=scsi,bus=0,index=5,file=../../hpux_11iv1.img,format=raw -serial
  mon:stdio -D qemu1.log -nographic -m 512 -d nochain -cdrom
  ../../distri/11iv1/'HP-
  UX_11iv1_B.11.11_TCOE_September_2005_1of4_Core_OS
  _Install_B6821-10046.iso' -net nic,model=tulip  -net tap

  When I want to use the monitor (to change cdrom during the hp-ux
  installation process), the characters I type are misinterpreted. For
  example, I enter "2" at hp-ux prompt, I see : "412691;82;22".
  Impossible to switch from monitor to hp-ux with Ctrl+Alt+1 and
  Ctrl+Alt+2.

  I tried with Debian and Fedora host, TERM=xterm and TERM=vt100, qemu options 
-alt-grab and -ctrl-grab, -monitor in the same terminal or an other terminal 
than hp-ux. Nothing works.
  Best regards.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1865188/+subscriptions

Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback

On 28.02.20 17:49, Shameerali Kolothum Thodi wrote:
> 
> 
>> -Original Message-
>> From: David Hildenbrand [mailto:da...@redhat.com]
>> Sent: 13 February 2020 17:09
>> To: Shameerali Kolothum Thodi ;
>> Igor Mammedov 
>> Cc: peter.mayd...@linaro.org; xiaoguangrong.e...@gmail.com;
>> m...@redhat.com; shannon.zha...@gmail.com; qemu-devel@nongnu.org;
>> xuwei (O) ; Linuxarm ;
>> eric.au...@redhat.com; qemu-...@nongnu.org; ler...@redhat.com;
>> dgilb...@redhat.com; Juan Jose Quintela Carreira 
>> Subject: Re: [PATCH v2 1/7] exec: Fix for qemu_ram_resize() callback
> 
> [...]
> 
 Thanks for that. I had a go with the below patch and it indeed fixes the 
 issue
 of callback not being called on resize. But the migration fails with the 
 below
 error,

 For x86
 -
 qemu-system-x86_64: Unknown combination of migration flags: 0x14
 qemu-system-x86_64: error while loading state for instance 0x0 of device
>> 'ram'
 qemu-system-x86_64: load of migration failed: Invalid argument

 For arm64
 --
 qemu-system-aarch64: Received an unexpected compressed page
 qemu-system-aarch64: error while loading state for instance 0x0 of device
>> 'ram'
 qemu-system-aarch64: load of migration failed: Invalid argument

 I haven’t debugged this further but looks like there is a corruption
>> happening.
 Please let me know if you have any clue.
>>>
>>> The issue is
>>>
>>> qemu_put_be64(f, ram_bytes_total_common(true) |
>> RAM_SAVE_FLAG_MEM_SIZE)
>>>
>>> The total ram size we store must be page aligned, otherwise it will be
>>> detected as flags. Hm ... maybe we can round it up ...
>>>
>>
>> I'm afraid we can't otherwise we will run into issues in
>> ram_load_precopy(). Hm ...
> 
> Sorry, took a while to get back on this. Yes, round up indeed breaks in
> ram_load_precopy() . I had the below on top of your patch and that 
> seems to do the job (sanity tested on arm/virt).
> 
> Please take a look and let me know if you see any issues with this approach.
> 
> Thanks,
> Shameer
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 2acc4b85ca..7447f0cefa 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -1782,7 +1782,7 @@ static uint64_t ram_bytes_total_migration(void)
>  RCU_READ_LOCK_GUARD();
>  
>  RAMBLOCK_FOREACH_MIGRATABLE(block) {
> -total += ramblock_ram_bytes_migration(block);
> +total += block->used_length;
>  }
>  return total;
>  }
> @@ -3479,7 +3479,7 @@ static int ram_load_precopy(QEMUFile *f)
>  ret = -EINVAL;
>  }
>  
> -total_ram_bytes -= length;
> +total_ram_bytes -= block->used_length;
>  }
>  break;
> 
> 
> 

What you mean is the following:


commit 702f4325086c3a8d6083787f8bc8503f7523bac8 (HEAD -> master)
Author: David Hildenbrand 
Date:   Wed Feb 12 19:16:34 2020 +0100

tmp

Signed-off-by: David Hildenbrand 

diff --git a/exec.c b/exec.c
index 67e520d18e..cec643b914 100644
--- a/exec.c
+++ b/exec.c
@@ -2125,11 +2125,21 @@ static int memory_try_enable_merging(void *addr, size_t 
len)
  */
 int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp)
 {
+const ram_addr_t unaligned_size = newsize;
+
 assert(block);
 
 newsize = HOST_PAGE_ALIGN(newsize);
 
 if (block->used_length == newsize) {
+/*
+ * We don't have to resize the ram block (which only knows aligned
+ * sizes), however, we have to notify if the unaligned size changed.
+ */
+if (block->resized && unaligned_size != memory_region_size(block->mr)) 
{
+block->resized(block->idstr, unaligned_size, block->host);
+memory_region_set_size(block->mr, unaligned_size);
+}
 return 0;
 }
 
@@ -2153,9 +2163,9 @@ int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, 
Error **errp)
 block->used_length = newsize;
 cpu_physical_memory_set_dirty_range(block->offset, block->used_length,
 DIRTY_CLIENTS_ALL);
-memory_region_set_size(block->mr, newsize);
+memory_region_set_size(block->mr, unaligned_size);
 if (block->resized) {
-block->resized(block->idstr, newsize, block->host);
+block->resized(block->idstr, unaligned_size, block->host);
 }
 return 0;
 }
diff --git a/migration/ram.c b/migration/ram.c
index d2208b5534..249d3edede 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -3412,7 +3412,15 @@ static int ram_save_setup(QEMUFile *f, void *opaque)
 RAMBLOCK_FOREACH_MIGRATABLE(block) {
 qemu_put_byte(f, strlen(block->idstr));
 qemu_put_buffer(f, (uint8_t *)block->idstr, strlen(block->idstr));
-qemu_put_be64(f, block->used_length);
+/*
+ * When resizing on the target, we need the unaligned size,
+ * otherwise we lose the unaligned sise during migration.
+

Re: [PULL 00/33] target-arm queue

On Fri, 28 Feb 2020 at 16:38, Peter Maydell  wrote:
>
> Another arm pullreq; nothing particularly exciting here.
>
> -- PMM
>
>
> The following changes since commit e27d5b488ef08408691bfed61f34ee2858136287:
>
>   Merge remote-tracking branch 
> 'remotes/juanquintela/tags/pull-migration-pull-request' into staging 
> (2020-02-28 14:02:31 +)
>
> are available in the Git repository at:
>
>   https://git.linaro.org/people/pmaydell/qemu-arm.git 
> tags/pull-target-arm-20200228
>
> for you to fetch changes up to 1904f9b5f1d94fe12fe021db6b504c87d684f6db:
>
>   hw/intc/arm_gic_kvm: Don't assume kernel can provide a GICv2 (2020-02-28 
> 16:14:57 +)
>
> 
> target-arm queue:
>  * hw/arm: Use TYPE_PL011 to create serial port
>  * target/arm: Set ID_MMFR4.HPDS for aarch64_max_initfn
>  * hw/arm/integratorcp: Map the audio codec controller
>  * GICv2: Correctly implement the limited number of priority bits
>  * target/arm: refactoring of VFP related feature checks and decode
>  * xilinx_zynq: Fix USB port instantiation
>  * acceptance tests for n800, n810, integratorcp
>  * Implement v8.3-RCPC, v8.4-RCPC, v8.3-CCIDX
>  * arm_gic_kvm: Don't assume kernel can provide a GICv2
>(provide better error message for user error)


Applied, thanks.

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

-- PMM

Re: [PATCH v5 48/50] multi-process: Validate incoming commands from Proxy

2020-02-28 Thread Elena Ufimtseva

On Thu, Feb 27, 2020 at 05:18:30PM +, Stefan Hajnoczi wrote:
> On Mon, Feb 24, 2020 at 03:55:39PM -0500, Jagannathan Raman wrote:
> > From: Elena Ufimtseva 
> > 
> > Validate the incoming commands to confirm that they would not cause any
> > errors in the remote process.
> > 
> > Signed-off-by: Elena Ufimtseva 
> > Signed-off-by: Jagannathan Raman 
> > Signed-off-by: John G Johnson 
> > ---
> >  hw/proxy/qemu-proxy.c|  6 +++-
> >  include/io/mpqemu-link.h |  2 ++
> >  io/mpqemu-link.c | 75 
> > +++-
> >  remote/remote-main.c |  4 +++
> >  4 files changed, 85 insertions(+), 2 deletions(-)
> 
> Please squash this into the patch(es) that introduced the code.
> 
> Reviewers want to see a logical sequence of patches.  Introducing
> unsafe code in an earlier patch and adding checks in a later patch makes
> it impossible to review the patches in sequence (reviewers would waste
> time pointing out bugs that end up getting fixed later).
>

Thanks Stefan, will merge that with appropriate patches.
 
> > diff --git a/remote/remote-main.c b/remote/remote-main.c
> > index 20d160e..c4aa3e0 100644
> > --- a/remote/remote-main.c
> > +++ b/remote/remote-main.c
> > @@ -435,6 +435,10 @@ static void process_msg(GIOCondition cond, 
> > MPQemuChannel *chan)
> >  if (msg->id > MAX_REMOTE_DEVICES) {
> >  error_setg(, "id of the device is larger than max number of "\
> >   "devices per remote process.");
> > +}
> 
> Was goto finalize_loop accidentally dropped?
Yes, thank you.

Elena

Re: [PATCH v4 00/10] vTPM for aarch64

2020-02-28 Thread Stefan Berger


On 2/28/20 9:49 AM, Auger Eric wrote:

Hi Stefan,
On 2/28/20 3:37 PM, Stefan Berger wrote:

On 2/27/20 3:07 AM, Auger Eric wrote:

Hi Stefan,
On 2/26/20 11:44 PM, Stefan Berger wrote:

On 2/26/20 3:59 PM, Eric Auger wrote:

This series adds the capability to instantiate an MMIO TPM TIS
in ARM virt. It is candidate to qemu 5.0.

I queued it now here:
https://github.com/stefanberger/qemu-tpm/commits/tpm-next

I will send the PR within a few days. Thanks!

Thank you. I will just ping Peter to make sure he has no comments on

[PATCH v4 06/10] hw/arm/virt: vTPM support


The little dent is now an arm boot failure:


https://travis-ci.org/stefanberger/qemu-tpm/jobs/655573347?utm_medium=notification_source=email

is this really related to the sysbus TPM-TIS addition? I have the
impression cubieboard acceptance tests (ARM 32b) are failing. I touched
ARM virt machine.


I hadn't seen this one here before:

https://travis-ci.org/qemu/qemu/jobs/656327906


We're good.


   Stefan





Thanks

Eric



Have a look at the raw log.


    Stefan

Re: [PATCH v4 1/7] target/arm: Improve masking of HCR RES0 bits

On Fri, 28 Feb 2020 at 16:57, Richard Henderson
 wrote:
>
> On 2/28/20 8:22 AM, Peter Maydell wrote:
> >> +if (ri->state == ARM_CP_STATE_AA32) {
> >> +/*
> >> + * Writes from aarch32 mode have more RES0 bits.
> >> + * This includes TDZ, RW, E2H, and more.
> >> + */
> >> +valid_mask &= ~0xff80ff8c9000ull;
> >> +}
> >
> > Isn't bit HCR2 bit 16 (aka bit 32+16==48 here) also RES0 from AArch32 ?
>
> Yes, and it's set in the above.

One of us is miscounting, and I don't *think* it's me...

bits 63..0:  ff80ff8c9000
bits 63..32: ff80ff8c
bits 64..48: ff80

bit 48 looks like it's 0 to me.

> > I'm not really a fan of the hex-number here either, given we
> > have HCR_* constants.
>
> While plenty of those bits have names, many don't.  Shall I simply name all of
> the ones that have names, and that differ from the aa64 masking?

You could refine the valid mask as the & of the bits which we
do want to exist in aarch32, rather than &~ of the reserved bits:

 valid_mask &= TTLBIS | TOCU | TICAB | ...

?

thanks
-- PMM

[Bug 1865188] [NEW] Switching from the monitor to the emulated machine with a French keyboard (AZERTY)

2020-02-28 Thread Thierry Briot

Public bug reported:

Hi,
I run qemu in an xterm terminal, with TERM=vt100. My keyboard is french AZERTY.

sudo ./qemu-system-hppa -monitor /dev/pts/2 -k fr  -boot d -drive
if=scsi,bus=0,index=5,file=../../hpux_11iv1.img,format=raw -serial
mon:stdio -D qemu1.log -nographic -m 512 -d nochain -cdrom
../../distri/11iv1/'HP-UX_11iv1_B.11.11_TCOE_September_2005_1of4_Core_OS
_Install_B6821-10046.iso' -net nic,model=tulip  -net tap

When I want to use the monitor (to change cdrom during the hp-ux
installation process), the characters I type are misinterpreted. For
example, I enter "2" at hp-ux prompt, I see : "412691;82;22". Impossible
to switch from monitor to hp-ux with Ctrl+Alt+1 and Ctrl+Alt+2.

I tried with Debian and Fedora host, TERM=xterm and TERM=vt100, qemu options 
-alt-grab and -ctrl-grab, -monitor in the same terminal or an other terminal 
than hp-ux. Nothing works.
Best regards.

** Affects: qemu
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1865188

Title:
  Switching from the monitor to the emulated machine with a French
  keyboard (AZERTY)

Status in QEMU:
  New

Bug description:
  Hi,
  I run qemu in an xterm terminal, with TERM=vt100. My keyboard is french 
AZERTY.

  sudo ./qemu-system-hppa -monitor /dev/pts/2 -k fr  -boot d -drive
  if=scsi,bus=0,index=5,file=../../hpux_11iv1.img,format=raw -serial
  mon:stdio -D qemu1.log -nographic -m 512 -d nochain -cdrom
  ../../distri/11iv1/'HP-
  UX_11iv1_B.11.11_TCOE_September_2005_1of4_Core_OS
  _Install_B6821-10046.iso' -net nic,model=tulip  -net tap

  When I want to use the monitor (to change cdrom during the hp-ux
  installation process), the characters I type are misinterpreted. For
  example, I enter "2" at hp-ux prompt, I see : "412691;82;22".
  Impossible to switch from monitor to hp-ux with Ctrl+Alt+1 and
  Ctrl+Alt+2.

  I tried with Debian and Fedora host, TERM=xterm and TERM=vt100, qemu options 
-alt-grab and -ctrl-grab, -monitor in the same terminal or an other terminal 
than hp-ux. Nothing works.
  Best regards.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1865188/+subscriptions

Re: [PATCH v2 2/6] util: Replace fprintf(stderr, "*\n" with error_report()

2020-02-28 Thread Markus Armbruster

Philippe Mathieu-Daudé  writes:

> On 2/28/20 10:50 AM, Philippe Mathieu-Daudé wrote:
[...]
>> Thanks for your review. I'll drop the changes in util/oslib-win32.c
>> for for now, and add a note in my TODO for after the 5.0 release.
>
> Well if I follow this line, I'v to drop the changes in util/osdep.c too.
> Maybe we can keep fprintf() for now and improve the error message, and
> do the fprintf -> error_report cleanup later?

I recommend to convert from fprintf() to error_report() & friends and
improve the message all in one go.

Separating different kinds of changes makes sense when some kinds are
mechanical and the resulting mechanical patches are large.  These
patches aren't large.

But it's really up to you.  I'm not going to veto an improvement only
because further improvement is called for.

Re: [PATCH v4 1/7] target/arm: Improve masking of HCR RES0 bits

On 2/28/20 8:22 AM, Peter Maydell wrote:
>> +if (ri->state == ARM_CP_STATE_AA32) {
>> +/*
>> + * Writes from aarch32 mode have more RES0 bits.
>> + * This includes TDZ, RW, E2H, and more.
>> + */
>> +valid_mask &= ~0xff80ff8c9000ull;
>> +}
> 
> Isn't bit HCR2 bit 16 (aka bit 32+16==48 here) also RES0 from AArch32 ?

Yes, and it's set in the above.

> I'm not really a fan of the hex-number here either, given we
> have HCR_* constants.

While plenty of those bits have names, many don't.  Shall I simply name all of
the ones that have names, and that differ from the aa64 masking?


r~

[RFC PATCH v2 67/67] Hexagon HVX build infrastructure

Signed-off-by: Taylor Simpson 
---
 target/hexagon/Makefile.objs | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/target/hexagon/Makefile.objs b/target/hexagon/Makefile.objs
index be0d08f..d18b41f 100644
--- a/target/hexagon/Makefile.objs
+++ b/target/hexagon/Makefile.objs
@@ -28,7 +28,9 @@ obj-y += \
 printinsn.o \
 arch.o \
 fma_emu.o \
-conv_emu.o
+conv_emu.o \
+mmvec/decode_ext_mmvec.o \
+mmvec/system_ext_mmvec.o
 
 #
 #  Step 1
@@ -47,10 +49,14 @@ IDEF_FILES = \
 $(SRC_PATH)/target/hexagon/imported/mpy.idef \
 $(SRC_PATH)/target/hexagon/imported/shift.idef \
 $(SRC_PATH)/target/hexagon/imported/subinsns.idef \
-$(SRC_PATH)/target/hexagon/imported/system.idef
+$(SRC_PATH)/target/hexagon/imported/system.idef \
+$(SRC_PATH)/target/hexagon/imported/allext.idef \
+$(SRC_PATH)/target/hexagon/imported/mmvec/ext.idef
 DEF_FILES = \
 $(SRC_PATH)/target/hexagon/imported/allidefs.def \
-$(SRC_PATH)/target/hexagon/imported/macros.def
+$(SRC_PATH)/target/hexagon/imported/macros.def \
+$(SRC_PATH)/target/hexagon/imported/allext_macros.def \
+$(SRC_PATH)/target/hexagon/imported/mmvec/macros.def
 
 $(GEN_SEMANTICS): $(GEN_SEMANTICS_SRC) $(IDEF_FILES) $(DEF_FILES)
$(CC) $(CFLAGS) $(GEN_SEMANTICS_SRC) -o $(GEN_SEMANTICS)
-- 
2.7.4

[RFC PATCH v2 52/67] Hexagon Linux user emulation

Implementation of Linux user emulation for RISC-V
Some common files modified in addition to new files in linux-user/hexagon

Signed-off-by: Taylor Simpson 
---
 linux-user/hexagon/sockbits.h   |  18 ++
 linux-user/hexagon/syscall_nr.h | 346 
 linux-user/hexagon/target_cpu.h |  44 +
 linux-user/hexagon/target_elf.h |  38 
 linux-user/hexagon/target_fcntl.h   |  18 ++
 linux-user/hexagon/target_signal.h  |  34 
 linux-user/hexagon/target_structs.h |  46 +
 linux-user/hexagon/target_syscall.h |  32 
 linux-user/hexagon/termbits.h   |  18 ++
 linux-user/syscall_defs.h   |  33 
 linux-user/elfload.c|  16 ++
 linux-user/hexagon/cpu_loop.c   | 173 ++
 linux-user/hexagon/signal.c | 276 
 linux-user/syscall.c|   2 +
 14 files changed, 1094 insertions(+)
 create mode 100644 linux-user/hexagon/sockbits.h
 create mode 100644 linux-user/hexagon/syscall_nr.h
 create mode 100644 linux-user/hexagon/target_cpu.h
 create mode 100644 linux-user/hexagon/target_elf.h
 create mode 100644 linux-user/hexagon/target_fcntl.h
 create mode 100644 linux-user/hexagon/target_signal.h
 create mode 100644 linux-user/hexagon/target_structs.h
 create mode 100644 linux-user/hexagon/target_syscall.h
 create mode 100644 linux-user/hexagon/termbits.h
 create mode 100644 linux-user/hexagon/cpu_loop.c
 create mode 100644 linux-user/hexagon/signal.c

diff --git a/linux-user/hexagon/sockbits.h b/linux-user/hexagon/sockbits.h
new file mode 100644
index 000..a6e8966
--- /dev/null
+++ b/linux-user/hexagon/sockbits.h
@@ -0,0 +1,18 @@
+/*
+ *  Copyright(c) 2019-2020 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 "../generic/sockbits.h"
diff --git a/linux-user/hexagon/syscall_nr.h b/linux-user/hexagon/syscall_nr.h
new file mode 100644
index 000..9ea38cc
--- /dev/null
+++ b/linux-user/hexagon/syscall_nr.h
@@ -0,0 +1,346 @@
+/*
+ *  Copyright(c) 2019-2020 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 .
+ */
+
+/*
+ * Syscall numbers
+ */
+
+#define  TARGET_NR_io_setup 0
+#define  TARGET_NR_io_destroy 1
+#define  TARGET_NR_io_submit 2
+#define  TARGET_NR_io_cancel 3
+#define  TARGET_NR_io_getevents 4
+#define  TARGET_NR_setxattr 5
+#define  TARGET_NR_lsetxattr 6
+#define  TARGET_NR_fsetxattr 7
+#define  TARGET_NR_getxattr 8
+#define  TARGET_NR_lgetxattr 9
+#define  TARGET_NR_fgetxattr 10
+#define  TARGET_NR_listxattr 11
+#define  TARGET_NR_llistxattr 12
+#define  TARGET_NR_flistxattr 13
+#define  TARGET_NR_removexattr 14
+#define  TARGET_NR_lremovexattr 15
+#define  TARGET_NR_fremovexattr 16
+#define  TARGET_NR_getcwd 17
+#define  TARGET_NR_lookup_dcookie 18
+#define  TARGET_NR_eventfd2 19
+#define  TARGET_NR_epoll_create1 20
+#define  TARGET_NR_epoll_ctl 21
+#define  TARGET_NR_epoll_pwait 22
+#define  TARGET_NR_dup 23
+#define  TARGET_NR_dup3 24
+#define  TARGET_NR3264_fcntl 25
+#define  TARGET_NR_inotify_init1 26
+#define  TARGET_NR_inotify_add_watch 27
+#define  TARGET_NR_inotify_rm_watch 28
+#define  TARGET_NR_ioctl 29
+#define  TARGET_NR_ioprio_set 30
+#define  TARGET_NR_ioprio_get 31
+#define  TARGET_NR_flock 32
+#define  TARGET_NR_mknodat 33
+#define  TARGET_NR_mkdirat 34
+#define  TARGET_NR_unlinkat 35
+#define  TARGET_NR_symlinkat 36
+#define  TARGET_NR_linkat 37
+#define  TARGET_NR_renameat 38
+#define  TARGET_NR_umount2 39
+#define  TARGET_NR_mount 40
+#define  TARGET_NR_pivot_root 41
+#define  TARGET_NR_nfsservctl 42
+#define  TARGET_NR3264_statfs 43
+#define  TARGET_NR_statfs TARGET_NR3264_statfs
+#define

[RFC PATCH v2 26/67] Hexagon generator phase 2 - op_regs_generated.h

Lists the register and immediate operands for each instruction

Signed-off-by: Taylor Simpson 
---
 target/hexagon/do_qemu.py | 86 +++
 1 file changed, 86 insertions(+)

diff --git a/target/hexagon/do_qemu.py b/target/hexagon/do_qemu.py
index 499f0e0..0c7643a 100755
--- a/target/hexagon/do_qemu.py
+++ b/target/hexagon/do_qemu.py
@@ -806,3 +806,89 @@ realf.write(f.getvalue())
 realf.close()
 f.close()
 
+##
+## Generate the op_regs_generated.h file
+## Lists the register and immediate operands for each instruction
+##
+def calculate_regid_reg(tag):
+def letter_inc(x): return chr(ord(x)+1)
+ordered_implregs = [ 'SP','FP','LR' ]
+srcdst_lett = 'X'
+src_lett = 'S'
+dst_lett = 'D'
+retstr = ""
+mapdict = {}
+for reg in ordered_implregs:
+reg_rd = 0
+reg_wr = 0
+if ('A_IMPLICIT_READS_'+reg) in attribdict[tag]: reg_rd = 1
+if ('A_IMPLICIT_WRITES_'+reg) in attribdict[tag]: reg_wr = 1
+if reg_rd and reg_wr:
+retstr += srcdst_lett
+mapdict[srcdst_lett] = reg
+srcdst_lett = letter_inc(srcdst_lett)
+elif reg_rd:
+retstr += src_lett
+mapdict[src_lett] = reg
+src_lett = letter_inc(src_lett)
+elif reg_wr:
+retstr += dst_lett
+mapdict[dst_lett] = reg
+dst_lett = letter_inc(dst_lett)
+return retstr,mapdict
+
+def calculate_regid_letters(tag):
+retstr,mapdict = calculate_regid_reg(tag)
+return retstr
+
+def strip_verif_info_in_regs(x):
+y=x.replace('UREG.','')
+y=y.replace('MREG.','')
+return y.replace('GREG.','')
+
+f = StringIO()
+
+for tag in tags:
+regs = tagregs[tag]
+rregs = []
+wregs = []
+regids = ""
+for regtype,regid,toss,numregs in regs:
+if is_read(regid):
+if regid[0] not in regids: regids += regid[0]
+rregs.append(regtype+regid+numregs)
+if is_written(regid):
+wregs.append(regtype+regid+numregs)
+if regid[0] not in regids: regids += regid[0]
+for attrib in attribdict[tag]:
+if attribinfo[attrib]['rreg']:
+rregs.append(strip_verif_info_in_regs(attribinfo[attrib]['rreg']))
+if attribinfo[attrib]['wreg']:
+wregs.append(strip_verif_info_in_regs(attribinfo[attrib]['wreg']))
+regids += calculate_regid_letters(tag)
+f.write('REGINFO(%s,"%s",\t/*RD:*/\t"%s",\t/*WR:*/\t"%s")\n' % \
+(tag,regids,",".join(rregs),",".join(wregs)))
+
+for tag in tags:
+imms = tagimms[tag]
+f.write( 'IMMINFO(%s' % tag)
+if not imms:
+f.write(''','u',0,0,'U',0,0''')
+for sign,size,shamt in imms:
+if sign == 'r': sign = 's'
+if not shamt:
+shamt = "0"
+f.write(''','%s',%s,%s''' % (sign,size,shamt))
+if len(imms) == 1:
+if sign.isupper():
+myu = 'u'
+else:
+myu = 'U'
+f.write(''','%s',0,0''' % myu)
+f.write(')\n')
+
+realf = open('op_regs_generated.h','w')
+realf.write(f.getvalue())
+realf.close()
+f.close()
+
-- 
2.7.4

Re: [PATCH v2] qapi/machine: Place the 'Notes' tag after the 'Since' tag

2020-02-28 Thread Markus Armbruster

Philippe Mathieu-Daudé  writes:

> On 2/28/20 7:56 AM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé  writes:
>>> On 2/27/20 3:55 PM, Philippe Mathieu-Daudé wrote:
 On 2/27/20 3:52 PM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé  writes:
>
>> This fixes when adding a 'Since' tag:
>>
>>     In file included from qapi/qapi-schema.json:105:
>>     qapi/machine.json:25:1: '@arch:' can't follow 'Notes' section
>
> I'm confused.  This error is detected in scripts/qapi/parser.py, and it
> is fatal.  Is the build broken for you?  It isn't for me.  Moreover,
> where is @arch?  I can't see it anywhere close to the two spots the
> patch patches.

 I get the error after trying to fix what Eric commented here:
 https://www.mail-archive.com/qemu-devel@nongnu.org/msg682344.html
>>>
>>> Using:
>>> ---
>>> diff --git a/qapi/machine.json b/qapi/machine.json
>>> index 6c11e3cf3a..40a36d6276 100644
>>> --- a/qapi/machine.json
>>> +++ b/qapi/machine.json
>>> @@ -20,13 +20,15 @@
>>>   #prefix to produce the corresponding QEMU executable name. This
>>>   #is true even for "qemu-system-x86_64".
>>>   #
>>> +# @rx: since 5.0
>>> +#
>>>   # Since: 3.0
>>>   ##
>>>   { 'enum' : 'SysEmuTarget',
>>> 'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32',
>>>'m68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
>>>'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
>>> - 'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
>>> + 'ppc64', 'riscv32', 'riscv64', 'rx', 's390x', 'sh4',
>>>'sh4eb', 'sparc', 'sparc64', 'tricore', 'unicore32',
>>>'x86_64', 'xtensa', 'xtensaeb' ] }
>>> ---
>>>
>>> or
>>>
>>> ---
>>> diff --git a/qapi/machine.json b/qapi/machine.json
>>> index 6c11e3cf3a..4b59e87b6f 100644
>>> --- a/qapi/machine.json
>>> +++ b/qapi/machine.json
>>> @@ -21,12 +21,14 @@
>>>   #is true even for "qemu-system-x86_64".
>>>   #
>>>   # Since: 3.0
>>> +#
>>> +# @rx: since 5.0
>>>   ##
>>>   { 'enum' : 'SysEmuTarget',
>>> 'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32',
>>>'m68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
>>>'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
>>> - 'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
>>> + 'ppc64', 'riscv32', 'riscv64', 'rx', 's390x', 'sh4',
>>>'sh4eb', 'sparc', 'sparc64', 'tricore', 'unicore32',
>>>'x86_64', 'xtensa', 'xtensaeb' ] }
>>> ---
>>>
>>> I get:
>>>
>>>GEN qapi-gen
>>>GEN rx-softmmu/config-devices.mak
>>> In file included from qapi/qapi-schema.json:105:
>>> qapi/machine.json:23:1: '@rx:' can't follow 'Notes' section
>>> make: *** [Makefile:645: qapi-gen-timestamp] Error 1
>>>
>>> This works however:
>>>
>>> ---
>>>   ##
>>>   # @SysEmuTarget:
>>>   #
>>>   # The comprehensive enumeration of QEMU system emulation ("softmmu")
>>>   # targets. Run "./configure --help" in the project root directory, and
>>>   # look for the *-softmmu targets near the "--target-list" option. The
>>>   # individual target constants are not documented here, for the time
>>>   # being.
>>>   #
>>> +# @rx: since 5.0
>>> +#
>>>   # Notes: The resulting QMP strings can be appended to the "qemu-system-"
>>>   #prefix to produce the corresponding QEMU executable name. This
>>>   #is true even for "qemu-system-x86_64".
>>>   #
>>>   # Since: 3.0
>>>   ##
>>>   { 'enum' : 'SysEmuTarget',
>>> 'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32',
>>>'m68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
>>>'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
>>> - 'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
>>> + 'ppc64', 'riscv32', 'riscv64', 'rx', 's390x', 'sh4',
>>>'sh4eb', 'sparc', 'sparc64', 'tricore', 'unicore32',
>>>'x86_64', 'xtensa', 'xtensaeb' ] }
>>> ---
>>
>> This one adds it to the correct spot.
>
> OK I'll use that then.
>
>>
>> qapi-code-gen.txt:
>>
>>  Definition documentation starts with a line naming the definition,
>>  followed by an optional overview, a description of each argument (for
>>  commands and events), member (for structs and unions), branch (for
>>  alternates), or value (for enums), and finally optional tagged
>>  sections.
>
> I was confused because I understood "@rx: since 5.0" as a tagged
> section, not as an "Optional overview".

It's actually "a description of a value", not "optional overview".

[...]

[RFC PATCH v2 54/67] Hexagon - Add Hexagon Vector eXtensions (HVX) to core definition

HVX is a set of wide vector instructions.  Machine state includes
vector registers (VRegs)
vector predicate registers (QRegs)
temporary registers for packet semantics
store buffer (masked stores and scatter/gather)

Signed-off-by: Taylor Simpson 
---
 target/hexagon/cpu.h | 42 +
 target/hexagon/insn.h| 16 
 target/hexagon/internal.h|  2 +
 target/hexagon/mmvec/mmvec.h | 87 
 target/hexagon/cpu.c | 51 +-
 5 files changed, 197 insertions(+), 1 deletion(-)
 create mode 100644 target/hexagon/mmvec/mmvec.h

diff --git a/target/hexagon/cpu.h b/target/hexagon/cpu.h
index 6146561..6215f91 100644
--- a/target/hexagon/cpu.h
+++ b/target/hexagon/cpu.h
@@ -30,6 +30,7 @@ typedef struct CPUHexagonState CPUHexagonState;
 #include "qemu-common.h"
 #include "exec/cpu-defs.h"
 #include "hex_regs.h"
+#include "mmvec/mmvec.h"
 
 #define NUM_PREGS 4
 #ifdef CONFIG_USER_ONLY
@@ -42,6 +43,7 @@ typedef struct CPUHexagonState CPUHexagonState;
 #define STORES_MAX 2
 #define REG_WRITES_MAX 32
 #define PRED_WRITES_MAX 5   /* 4 insns + endloop */
+#define VSTORES_MAX 2
 
 #define TYPE_HEXAGON_CPU "hexagon-cpu"
 
@@ -60,6 +62,19 @@ struct MemLog {
 uint64_t data64;
 };
 
+typedef struct {
+target_ulong va;
+int size;
+mmvector_t mask;
+mmvector_t data;
+} vstorelog_t;
+
+typedef struct {
+unsigned char cdata[256];
+uint32_t range;
+uint8_t format;
+} mem_access_info_t;
+
 #define EXEC_STATUS_OK  0x
 #define EXEC_STATUS_STOP0x0002
 #define EXEC_STATUS_REPLAY  0x0010
@@ -72,6 +87,9 @@ struct MemLog {
 #define CLEAR_EXCEPTION (env->status &= (~EXEC_STATUS_EXCEPTION))
 #define SET_EXCEPTION   (env->status |= EXEC_STATUS_EXCEPTION)
 
+/* This needs to be large enough for all the reads and writes in a packet */
+#define TEMP_VECTORS_MAX25
+
 struct CPUHexagonState {
 target_ulong gpr[TOTAL_PER_THREAD_REGS];
 target_ulong pred[NUM_PREGS];
@@ -110,6 +128,30 @@ struct CPUHexagonState {
 
 target_ulong is_gather_store_insn;
 target_ulong gather_issued;
+
+mmvector_t VRegs[NUM_VREGS];
+mmvector_t future_VRegs[NUM_VREGS];
+mmvector_t tmp_VRegs[NUM_VREGS];
+
+VRegMask VRegs_updated_tmp;
+VRegMask VRegs_updated;
+VRegMask VRegs_select;
+
+mmqreg_t QRegs[NUM_QREGS];
+mmqreg_t future_QRegs[NUM_QREGS];
+QRegMask QRegs_updated;
+
+vstorelog_t vstore[VSTORES_MAX];
+uint8_t store_pending[VSTORES_MAX];
+uint8_t vstore_pending[VSTORES_MAX];
+uint8_t vtcm_pending;
+vtcm_storelog_t vtcm_log;
+mem_access_info_t mem_access[SLOTS_MAX];
+
+int status;
+
+mmvector_t temp_vregs[TEMP_VECTORS_MAX];
+mmqreg_t temp_qregs[TEMP_VECTORS_MAX];
 };
 
 #define HEXAGON_CPU_CLASS(klass) \
diff --git a/target/hexagon/insn.h b/target/hexagon/insn.h
index a80bcb9..16d298d 100644
--- a/target/hexagon/insn.h
+++ b/target/hexagon/insn.h
@@ -49,12 +49,16 @@ struct Instruction {
 size4u_t is_dcfetch:1;   /* Has an A_DCFETCH attribute */
 size4u_t is_load:1;  /* Has A_LOAD attribute */
 size4u_t is_store:1; /* Has A_STORE attribute */
+size4u_t is_vmem_ld:1;   /* Has an A_LOAD and an A_VMEM attribute */
+size4u_t is_vmem_st:1;   /* Has an A_STORE and an A_VMEM attribute */
+size4u_t is_scatgath:1;  /* Has an A_CVI_GATHER or A_CVI_SCATTER attr */
 size4u_t is_memop:1; /* Has A_MEMOP attribute */
 size4u_t is_dealloc:1;   /* Is a dealloc return or dealloc frame */
 size4u_t is_aia:1;   /* Is a post increment */
 size4u_t is_endloop:1;   /* This is an end of loop */
 size4u_t is_2nd_jump:1;  /* This is the second jump of a dual-jump packet 
*/
 size4u_t new_value_producer_slot:4;
+size4u_t hvx_resource:8;
 size4s_t immed[IMMEDS_MAX];/* immediate field */
 };
 
@@ -121,10 +125,22 @@ struct Packet {
 
 /* Misc */
 size8u_t num_rops:4;/* Num risc ops in the packet */
+size8u_t pkt_has_vtcm_access:1; /* Is a vmem access going to VTCM */
 size8u_t pkt_access_count:2;/* Is a vmem access going to VTCM */
 size8u_t pkt_ldaccess_l2:2; /* vmem ld access to l2 */
 size8u_t pkt_ldaccess_vtcm:2;   /* vmem ld access to vtcm */
 
+/* Count the types of HVX instructions */
+size8u_t pkt_hvx_va:4;
+size8u_t pkt_hvx_vx:4;
+size8u_t pkt_hvx_vp:4;
+size8u_t pkt_hvx_vs:4;
+size8u_t pkt_hvx_all:4;
+size8u_t pkt_hvx_none:4;
+
+size8u_t pkt_has_hvx:1;
+size8u_t pkt_has_extension:1;
+
 insn_t insn[INSTRUCTIONS_MAX];
 };
 
diff --git a/target/hexagon/internal.h b/target/hexagon/internal.h
index 092dedc..4ff7020 100644
--- a/target/hexagon/internal.h
+++ b/target/hexagon/internal.h
@@ -39,6 +39,8 @@
 extern int hexagon_gdb_read_register(CPUState *cpu, uint8_t *buf, int reg);
 extern int hexagon_gdb_write_register(CPUState *cpu, uint8_t

Re: [PATCH] block: Remove trailing newline in format used by error_report API

2020-02-28 Thread Markus Armbruster

Philippe Mathieu-Daudé  writes:

> The error_report API doesn't want trailing newline characters.
> Remove it, to avoid and error when moving the code around:
>
>   ERROR: Error messages should not contain newlines

Commit 312fd5f2909 has a Coccinelle script.  It should be committed and
re-run.

> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  block.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/block.c b/block.c
> index 1bdb9c679d..e466d15914 100644
> --- a/block.c
> +++ b/block.c
> @@ -5994,7 +5994,7 @@ void bdrv_img_create(const char *filename, const char 
> *fmt,
   bs = bdrv_open(full_backing, NULL, backing_options, back_flags,
  _err);
   g_free(full_backing);
   if (!bs && size != -1) {
>  /* Couldn't open BS, but we have a size, so it's nonfatal */
>  warn_reportf_err(local_err,
>  "Could not verify backing image. "
> -"This may become an error in future 
> versions.\n");
> +"This may become an error in future versions.");
>  local_err = NULL;
>  } else if (!bs) {
>  /* Couldn't open bs, do not have size */

warn_reportf_err() is a convenience function to error_prepend(),
warn_report() and free @local_err.

When @local_err holds a message like "pants on fire", the code before
the patch prints something like

qemu-system-x86_64: warning: Could not verify backing image. This may 
become an error in future versions.
pants on fire

The patch "improves" it to

qemu-system-x86_64: warning: Could not verify backing image. This may 
become an error in future versions.pants on fire

General advice: this misuse of warn_reportf_err() is an excusable
mistake, but when you *test* the error path, you can't *not* see that
the actual message is crap.  Test your errors!

Actual improvement:

   warn_reportf_err(local_err, "Could not verify backing image: ");
   error_printf("This may become an error in future versions.\n");

This should print

qemu-system-x86_64: warning: Could not verify backing image: pants on fire
This may become an error in future versions.

[RFC PATCH v2 42/67] Hexagon TCG generation - step 04

Override store instructions

Signed-off-by: Taylor Simpson 
---
 target/hexagon/helper_overrides.h | 241 ++
 1 file changed, 241 insertions(+)

diff --git a/target/hexagon/helper_overrides.h 
b/target/hexagon/helper_overrides.h
index 20d8584..fdcc517 100644
--- a/target/hexagon/helper_overrides.h
+++ b/target/hexagon/helper_overrides.h
@@ -636,4 +636,245 @@
 #define fWRAP_L4_ploadrdfnew_abs(GENHLPR, SHORTCODE) \
 fWRAP_PRED_LOAD_PAIR(fEA_IMM(uiV), fLSBNEWNOT(PtN))
 
+/* load-locked and store-locked */
+#define fWRAP_L2_loadw_locked(GENHLPR, SHORTCODE) \
+SHORTCODE
+#define fWRAP_L4_loadd_locked(GENHLPR, SHORTCODE) \
+SHORTCODE
+#define fWRAP_S2_storew_locked(GENHLPR, SHORTCODE) \
+do { SHORTCODE; READ_PREG(PdV, PdN); } while (0)
+#define fWRAP_S4_stored_locked(GENHLPR, SHORTCODE) \
+do { SHORTCODE; READ_PREG(PdV, PdN); } while (0)
+
+#define fWRAP_STORE(SHORTCODE) \
+do { \
+TCGv HALF = tcg_temp_new(); \
+TCGv BYTE = tcg_temp_new(); \
+TCGv NEWREG_ST = tcg_temp_new(); \
+TCGv tmp = tcg_temp_new(); \
+SHORTCODE; \
+tcg_temp_free(HALF); \
+tcg_temp_free(BYTE); \
+tcg_temp_free(NEWREG_ST); \
+tcg_temp_free(tmp); \
+} while (0)
+
+#define fWRAP_STORE_ap(STORE) \
+do { \
+TCGv HALF = tcg_temp_new(); \
+TCGv BYTE = tcg_temp_new(); \
+TCGv NEWREG_ST = tcg_temp_new(); \
+{ \
+fEA_IMM(UiV); \
+STORE; \
+tcg_gen_movi_tl(ReV, UiV); \
+} \
+tcg_temp_free(HALF); \
+tcg_temp_free(BYTE); \
+tcg_temp_free(NEWREG_ST); \
+} while (0)
+
+#define fWRAP_STORE_pcr(SHIFT, STORE) \
+do { \
+TCGv ireg = tcg_temp_new(); \
+TCGv HALF = tcg_temp_new(); \
+TCGv BYTE = tcg_temp_new(); \
+TCGv NEWREG_ST = tcg_temp_new(); \
+TCGv tmp = tcg_temp_new(); \
+fEA_REG(RxV); \
+fPM_CIRR(RxV, fREAD_IREG(MuV, SHIFT), MuV); \
+STORE; \
+tcg_temp_free(ireg); \
+tcg_temp_free(HALF); \
+tcg_temp_free(BYTE); \
+tcg_temp_free(NEWREG_ST); \
+tcg_temp_free(tmp); \
+} while (0)
+
+#define fWRAP_S2_storerb_io(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerb_pi(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S4_storerb_ap(GENHLPR, SHORTCODE) \
+fWRAP_STORE_ap(fSTORE(1, 1, EA, fGETBYTE(0, RtV)))
+#define fWRAP_S2_storerb_pr(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S4_storerb_ur(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerb_pbr(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerb_pci(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerb_pcr(GENHLPR, SHORTCODE) \
+fWRAP_STORE_pcr(0, fSTORE(1, 1, EA, fGETBYTE(0, RtV)))
+#define fWRAP_S4_storerb_rr(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S4_storerbnew_rr(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S4_storeirb_io(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerbgp(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_SS1_storeb_io(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_SS2_storebi0(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+
+#define fWRAP_S2_storerh_io(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerh_pi(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S4_storerh_ap(GENHLPR, SHORTCODE) \
+fWRAP_STORE_ap(fSTORE(1, 2, EA, fGETHALF(0, RtV)))
+#define fWRAP_S2_storerh_pr(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S4_storerh_ur(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerh_pbr(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerh_pci(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerh_pcr(GENHLPR, SHORTCODE) \
+fWRAP_STORE_pcr(1, fSTORE(1, 2, EA, fGETHALF(0, RtV)))
+#define fWRAP_S4_storerh_rr(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S4_storeirh_io(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerhgp(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_SS2_storeh_io(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+
+#define fWRAP_S2_storerf_io(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerf_pi(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S4_storerf_ap(GENHLPR, SHORTCODE) \
+fWRAP_STORE_ap(fSTORE(1, 2, EA, fGETHALF(1, RtV)))
+#define fWRAP_S2_storerf_pr(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S4_storerf_ur(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerf_pbr(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define fWRAP_S2_storerf_pci(GENHLPR, SHORTCODE) \
+fWRAP_STORE(SHORTCODE)
+#define

[RFC PATCH v2 56/67] Hexagon HVX import instruction encodings

Signed-off-by: Taylor Simpson 
---
 target/hexagon/imported/allextenc.def|  20 +
 target/hexagon/imported/encode.def   |   1 +
 target/hexagon/imported/mmvec/encode_ext.def | 830 +++
 3 files changed, 851 insertions(+)
 create mode 100644 target/hexagon/imported/allextenc.def
 create mode 100644 target/hexagon/imported/mmvec/encode_ext.def

diff --git a/target/hexagon/imported/allextenc.def 
b/target/hexagon/imported/allextenc.def
new file mode 100644
index 000..9af9412
--- /dev/null
+++ b/target/hexagon/imported/allextenc.def
@@ -0,0 +1,20 @@
+/*
+ *  Copyright(c) 2019-2020 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 .
+ */
+
+#define EXTNAME mmvec
+#include "mmvec/encode_ext.def"
+#undef EXTNAME
diff --git a/target/hexagon/imported/encode.def 
b/target/hexagon/imported/encode.def
index ae23301..7eb40be 100644
--- a/target/hexagon/imported/encode.def
+++ b/target/hexagon/imported/encode.def
@@ -71,6 +71,7 @@
 
 #include "encode_pp.def"
 #include "encode_subinsn.def"
+#include "allextenc.def"
 
 #ifdef __SELF_DEF_FIELD32
 #undef __SELF_DEF_FIELD32
diff --git a/target/hexagon/imported/mmvec/encode_ext.def 
b/target/hexagon/imported/mmvec/encode_ext.def
new file mode 100644
index 000..e2db99b
--- /dev/null
+++ b/target/hexagon/imported/mmvec/encode_ext.def
@@ -0,0 +1,830 @@
+/*
+ *  Copyright(c) 2019-2020 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 .
+ */
+
+#define CONCAT(A,B) A##B
+#define EXTEXTNAME(X) CONCAT(EXT_,X)
+#define DEF_ENC(TAG,STR) DEF_EXT_ENC(TAG,EXTEXTNAME(EXTNAME),STR)
+
+
+#ifndef NO_MMVEC
+DEF_ENC(V6_extractw,  ICLASS_LD" 001 0 000s  PP0u  --1d") /* 
coproc insn, returns Rd */
+#endif
+
+
+#ifndef NO_MMVEC
+
+
+
+DEF_CLASS32(ICLASS_NCJ" 1---  PP-- ",COPROC_VMEM)
+DEF_CLASS32(ICLASS_NCJ" 1000 0-0t PPi--iii ---d",BaseOffset_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1000 1-0t PPivviii 
---d",BaseOffset_if_Pv_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1000 0-1t PPi--iii 
",BaseOffset_VMEM_Stores1)
+DEF_CLASS32(ICLASS_NCJ" 1000 1-0t PPi--iii 
00--",BaseOffset_VMEM_Stores2)
+DEF_CLASS32(ICLASS_NCJ" 1000 1-1t PPivviii 
",BaseOffset_if_Pv_VMEM_Stores)
+
+DEF_CLASS32(ICLASS_NCJ" 1001 0-0x PP---iii ---d",PostImm_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1001 1-0x PP-vviii 
---d",PostImm_if_Pv_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1001 0-1x PP---iii ",PostImm_VMEM_Stores1)
+DEF_CLASS32(ICLASS_NCJ" 1001 1-0x PP---iii 00--",PostImm_VMEM_Stores2)
+DEF_CLASS32(ICLASS_NCJ" 1001 1-1x PP-vviii 
",PostImm_if_Pv_VMEM_Stores)
+
+DEF_CLASS32(ICLASS_NCJ" 1011 0-0x PPu- ---d",PostM_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1011 1-0x PPuvv--- 
---d",PostM_if_Pv_VMEM_Loads)
+DEF_CLASS32(ICLASS_NCJ" 1011 0-1x PPu- ",PostM_VMEM_Stores1)
+DEF_CLASS32(ICLASS_NCJ" 1011 1-0x PPu- 00--",PostM_VMEM_Stores2)
+DEF_CLASS32(ICLASS_NCJ" 1011 1-1x PPuvv--- 
",PostM_if_Pv_VMEM_Stores)
+
+DEF_CLASS32(ICLASS_NCJ" 110- 0--- PP-- ",Z_Load)
+DEF_CLASS32(ICLASS_NCJ" 110- 1--- PP-- ",Z_Load_if_Pv)
+
+DEF_CLASS32(ICLASS_NCJ"  000t PPu--0-- ---v",Gather)
+DEF_CLASS32(ICLASS_NCJ"  000t PPu--1-- -ssv",Gather_if_Qs)
+DEF_CLASS32(ICLASS_NCJ"  001t PPuv ---w",Scatter)
+DEF_CLASS32(ICLASS_NCJ"  001t PPuv -sss",Scatter_New)
+DEF_CLASS32(ICLASS_NCJ"  1--t PPuv -ssw",Scatter_if_Qs)
+
+
+DEF_FIELD32(ICLASS_NCJ" 1--- -!-- PP-- ",NT,"NonTemporal")
+
+
+
+DEF_FIELDROW_DESC32(

[RFC PATCH v2 50/67] Hexagon TCG generation - step 12

Override miscellaneous instructions identified during profiling

Signed-off-by: Taylor Simpson 
---
 target/hexagon/helper_overrides.h | 296 ++
 1 file changed, 296 insertions(+)

diff --git a/target/hexagon/helper_overrides.h 
b/target/hexagon/helper_overrides.h
index ad9a88c..b796ced 100644
--- a/target/hexagon/helper_overrides.h
+++ b/target/hexagon/helper_overrides.h
@@ -1551,4 +1551,300 @@
 #define fWRAP_J2_jumptnewpt(GENHLPR, SHORTCODE) \
 gen_cond_jump(PuN, riV)
 
+/*
+ * New value compare & jump instructions
+ * if ([!]COND(r0.new, r1) jump:t address
+ * if ([!]COND(r0.new, #7) jump:t address
+ */
+#define fWRAP_J4_cmpgt_f_jumpnv_t(GENHLPR, SHORTCODE) \
+gen_cmp_jumpnv(TCG_COND_LE, NsX, RtV, riV)
+#define fWRAP_J4_cmpeq_f_jumpnv_nt(GENHLPR, SHORTCODE) \
+gen_cmp_jumpnv(TCG_COND_NE, NsX, RtV, riV)
+#define fWRAP_J4_cmpgt_t_jumpnv_t(GENHLPR, SHORTCODE) \
+gen_cmp_jumpnv(TCG_COND_GT, NsX, RtV, riV)
+#define fWRAP_J4_cmpeqi_t_jumpnv_nt(GENHLPR, SHORTCODE) \
+gen_cmpi_jumpnv(TCG_COND_EQ, NsX, UiV, riV)
+#define fWRAP_J4_cmpltu_f_jumpnv_t(GENHLPR, SHORTCODE) \
+gen_cmp_jumpnv(TCG_COND_GEU, NsX, RtV, riV)
+#define fWRAP_J4_cmpgtui_t_jumpnv_t(GENHLPR, SHORTCODE) \
+gen_cmpi_jumpnv(TCG_COND_GTU, NsX, UiV, riV)
+#define fWRAP_J4_cmpeq_f_jumpnv_t(GENHLPR, SHORTCODE) \
+gen_cmp_jumpnv(TCG_COND_NE, NsX, RtV, riV)
+#define fWRAP_J4_cmpeqi_f_jumpnv_t(GENHLPR, SHORTCODE) \
+gen_cmpi_jumpnv(TCG_COND_NE, NsX, UiV, riV)
+#define fWRAP_J4_cmpgtu_t_jumpnv_t(GENHLPR, SHORTCODE) \
+gen_cmp_jumpnv(TCG_COND_GTU, NsX, RtV, riV)
+#define fWRAP_J4_cmpgtu_f_jumpnv_t(GENHLPR, SHORTCODE) \
+gen_cmp_jumpnv(TCG_COND_LEU, NsX, RtV, riV)
+#define fWRAP_J4_cmplt_t_jumpnv_t(GENHLPR, SHORTCODE) \
+gen_cmp_jumpnv(TCG_COND_LT, NsX, RtV, riV)
+
+/* r0 = r1 ; jump address */
+#define fWRAP_J4_jumpsetr(GENHLPR, SHORTCODE) \
+do { \
+tcg_gen_mov_tl(RdV, RsV); \
+gen_jump(riV); \
+} while (0)
+
+/* r0 = lsr(r1, #5) */
+#define fWRAP_S2_lsr_i_r(GENHLPR, SHORTCODE) \
+fLSHIFTR(RdV, RsV, IMMNO(0), 4_4)
+
+/* r0 += lsr(r1, #5) */
+#define fWRAP_S2_lsr_i_r_acc(GENHLPR, SHORTCODE) \
+do { \
+TCGv tmp = tcg_temp_new(); \
+fLSHIFTR(tmp, RsV, IMMNO(0), 4_4); \
+tcg_gen_add_tl(RxV, RxV, tmp); \
+tcg_temp_free(tmp); \
+} while (0)
+
+/* r0 ^= lsr(r1, #5) */
+#define fWRAP_S2_lsr_i_r_xacc(GENHLPR, SHORTCODE) \
+do { \
+TCGv tmp = tcg_temp_new(); \
+fLSHIFTR(tmp, RsV, IMMNO(0), 4_4); \
+tcg_gen_xor_tl(RxV, RxV, tmp); \
+tcg_temp_free(tmp); \
+} while (0)
+
+/* r0 = asr(r1, #5) */
+#define fWRAP_S2_asr_i_r(GENHLPR, SHORTCODE) \
+fASHIFTR(RdV, RsV, IMMNO(0), 4_4)
+
+/* r0 = addasl(r1, r2, #3) */
+#define fWRAP_S2_addasl_rrri(GENHLPR, SHORTCODE) \
+do { \
+TCGv tmp = tcg_temp_new(); \
+fASHIFTL(tmp, RsV, IMMNO(0), 4_4); \
+tcg_gen_add_tl(RdV, RtV, tmp); \
+tcg_temp_free(tmp); \
+} while (0)
+
+/* r0 |= asl(r1, r2) */
+#define fWRAP_S2_asl_r_r_or(GENHLPR, SHORTCODE) \
+gen_asl_r_r_or(RxV, RsV, RtV)
+
+/* r0 = asl(r1, #5) */
+#define fWRAP_S2_asl_i_r(GENHLPR, SHORTCODE) \
+fASHIFTL(RdV, RsV, IMMNO(0), 4_4)
+
+/* r0 |= asl(r1, #5) */
+#define fWRAP_S2_asl_i_r_or(GENHLPR, SHORTCODE) \
+do { \
+TCGv tmp = tcg_temp_new(); \
+fASHIFTL(tmp, RsV, IMMNO(0), 4_4); \
+tcg_gen_or_tl(RxV, RxV, tmp); \
+tcg_temp_free(tmp); \
+} while (0)
+
+/* r0 = vsplatb(r1) */
+#define fWRAP_S2_vsplatrb(GENHLPR, SHORTCODE) \
+do { \
+TCGv tmp = tcg_temp_new(); \
+int i; \
+tcg_gen_movi_tl(RdV, 0); \
+tcg_gen_andi_tl(tmp, RsV, 0xff); \
+for (i = 0; i < 4; i++) { \
+tcg_gen_shli_tl(RdV, RdV, 8); \
+tcg_gen_or_tl(RdV, RdV, tmp); \
+} \
+tcg_temp_free(tmp); \
+} while (0)
+
+#define fWRAP_SA1_seti(GENHLPR, SHORTCODE) \
+tcg_gen_movi_tl(RdV, IMMNO(0))
+
+#define fWRAP_S2_insert(GENHLPR, SHORTCODE) \
+tcg_gen_deposit_i32(RxV, RxV, RsV, IMMNO(1), IMMNO(0))
+
+#define fWRAP_S2_extractu(GENHLPR, SHORTCODE) \
+tcg_gen_extract_i32(RdV, RsV, IMMNO(1), IMMNO(0))
+
+#define fWRAP_A2_combinew(GENHLPR, SHORTCODE) \
+tcg_gen_concat_i32_i64(RddV, RtV, RsV)
+#define fWRAP_A2_combineii(GENHLPR, SHORTCODE) \
+do { \
+TCGv tmp_lo = tcg_const_tl(SiV); \
+TCGv tmp_hi = tcg_const_tl(siV); \
+tcg_gen_concat_i32_i64(RddV, tmp_lo, tmp_hi); \
+tcg_temp_free(tmp_lo); \
+tcg_temp_free(tmp_hi); \
+} while (0)
+#define fWRAP_A4_combineri(GENHLPR, SHORTCODE) \
+do { \
+TCGv tmp_lo = tcg_const_tl(siV); \
+tcg_gen_concat_i32_i64(RddV, tmp_lo, RsV); \
+tcg_temp_free(tmp_lo); \
+} while (0)
+#define fWRAP_A4_combineir(GENHLPR, SHORTCODE) \
+do { \
+TCGv tmp_hi = tcg_const_tl(siV); \
+tcg_gen_concat_i32_i64(RddV, RsV, tmp_hi); \
+

[RFC PATCH v2 58/67] Hexagon HVX import macro definitions

Imported from the Hexagon architecture library
imported/allext_macros.def   Top level macro include for all extensions
imported/mmvec/macros.defHVX macro definitions
The macro definition files specify instruction attributes that are applied
to each instruction that reverences the macro.

Signed-off-by: Taylor Simpson 
---
 target/hexagon/imported/allext_macros.def |   25 +
 target/hexagon/imported/mmvec/macros.def  | 1110 +
 2 files changed, 1135 insertions(+)
 create mode 100644 target/hexagon/imported/allext_macros.def
 create mode 100755 target/hexagon/imported/mmvec/macros.def

diff --git a/target/hexagon/imported/allext_macros.def 
b/target/hexagon/imported/allext_macros.def
new file mode 100644
index 000..e1f16eb
--- /dev/null
+++ b/target/hexagon/imported/allext_macros.def
@@ -0,0 +1,25 @@
+/*
+ *  Copyright(c) 2019-2020 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 .
+ */
+
+/*
+ * Top level file for all instruction set extensions
+ */
+#define EXTNAME mmvec
+#define EXTSTR "mmvec"
+#include "mmvec/macros.def"
+#undef EXTNAME
+#undef EXTSTR
diff --git a/target/hexagon/imported/mmvec/macros.def 
b/target/hexagon/imported/mmvec/macros.def
new file mode 100755
index 000..fa0beb1
--- /dev/null
+++ b/target/hexagon/imported/mmvec/macros.def
@@ -0,0 +1,1110 @@
+/*
+ *  Copyright(c) 2019-2020 Qualcomm Innovation Center, Inc. All Rights 
Reserved.
+ *
+ *  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 .
+ */
+
+DEF_MACRO(fDUMPQ,(STR,REG),
+   "dump REG",
+   "dump REG",
+   do {
+   printf(STR ":" #REG ": 0x%016llx\n",REG.ud[0]);
+   } while (0),
+   ()
+)
+
+DEF_MACRO(fUSE_LOOKUP_ADDRESS_BY_REV,(PROC),
+   "",
+   "Use full VA address for lookup and exception based on REV ",
+   PROC->arch_proc_options->mmvec_use_full_va_for_lookup,
+   ()
+)
+
+DEF_MACRO(fUSE_LOOKUP_ADDRESS,(),
+   "",
+   "Use full VA address for lookup and exception",
+   1,
+   ()
+)
+
+DEF_MACRO(fRT8NOTE, (),
+   "",
+   "",
+   ,
+   (A_NOTE_RT8)
+)
+
+DEF_MACRO(fNOTQ,(VAL),
+   "~VAL",
+   "~VAL",
+   /* Will break Visual Studio? */
+   ({mmqreg_t _ret = {0}; int _i_; for (_i_ = 0; _i_ < fVECSIZE()/64; 
_i_++) _ret.ud[_i_] = ~VAL.ud[_i_]; _ret;}),
+   ()
+)
+
+DEF_MACRO(fGETQBITS,(REG,WIDTH,MASK,BITNO),
+   "REG[BITNO+WIDTH-1:BITNO]",
+   "Get MASK bits at BITNO from REG",
+   ((MASK) & (REG.w[(BITNO)>>5] >> ((BITNO) & 0x1f))),
+   ()
+)
+
+DEF_MACRO(fGETQBIT,(REG,BITNO),
+   "REG[BITNO]",
+   "Get bit BITNO from REG",
+   fGETQBITS(REG,1,1,BITNO),
+   ()
+)
+
+DEF_MACRO(fGENMASKW,(QREG,IDX),
+   "maskw(QREG,IDX)",
+   "Generate mask from QREG for word IDX",
+   (((fGETQBIT(QREG,(IDX*4+0)) ? 0xFF : 0x0) << 0)
+   |((fGETQBIT(QREG,(IDX*4+1)) ? 0xFF : 0x0) << 8)
+   |((fGETQBIT(QREG,(IDX*4+2)) ? 0xFF : 0x0) << 16)
+   |((fGETQBIT(QREG,(IDX*4+3)) ? 0xFF : 0x0) << 24)),
+   ()
+)
+DEF_MACRO(fGET10BIT,(COE,VAL,POS),
+   "COE=(fGETUBYTE(3,VAL) >> (2 * POS)) & 3) << 8) | 
fGETUBYTE(POS,VAL)) << 6) >> 6;",
+   "Get 10-bit coefficient from current word value and byte position",
+   {
+   COE = (fGETUBYTE(3,VAL) >> (2 * POS)) & 3) << 8) | 
fGETUBYTE(POS,VAL)) << 6);
+   COE >>= 6;
+   },
+   ()
+)
+
+DEF_MACRO(fVMAX,(X,Y),
+   "max(X,Y)",
+   "",
+   (X>Y) ? X : Y,
+   ()
+)
+
+
+DEF_MACRO(fREAD_VEC,
+(DST,IDX),
+"DST=VREG[IDX]",   /* short desc */
+"Read Vector IDX", /* long desc */
+   (DST = READ_VREG(fMODCIRCU((IDX),5))),
+()
+)
+
+DEF_MACRO(fGETNIBBLE,(IDX,SRC),
+

[RFC PATCH v2 38/67] Hexagon TCG generation helpers - step 5

Helpers for instructions overriden for optimization

Signed-off-by: Taylor Simpson 
---
 target/hexagon/genptr_helpers.h | 314 
 1 file changed, 314 insertions(+)

diff --git a/target/hexagon/genptr_helpers.h b/target/hexagon/genptr_helpers.h
index 9917d72..e342f29 100644
--- a/target/hexagon/genptr_helpers.h
+++ b/target/hexagon/genptr_helpers.h
@@ -530,4 +530,318 @@ static inline void gen_cond_return(TCGv pred, TCGv addr)
 tcg_temp_free(zero);
 }
 
+static inline void gen_loop0r(TCGv RsV, int riV, insn_t *insn)
+{
+TCGv tmp = tcg_temp_new();
+fIMMEXT(riV);
+fPCALIGN(riV);
+/* fWRITE_LOOP_REGS0( fREAD_PC()+riV, RsV); */
+tcg_gen_addi_tl(tmp, hex_gpr[HEX_REG_PC], riV);
+gen_log_reg_write(HEX_REG_LC0, RsV, insn->slot, 0);
+gen_log_reg_write(HEX_REG_SA0, tmp, insn->slot, 0);
+fSET_LPCFG(0);
+tcg_temp_free(tmp);
+}
+
+static inline void gen_loop1r(TCGv RsV, int riV, insn_t *insn)
+{
+TCGv tmp = tcg_temp_new();
+fIMMEXT(riV);
+fPCALIGN(riV);
+/* fWRITE_LOOP_REGS1( fREAD_PC()+riV, RsV); */
+tcg_gen_addi_tl(tmp, hex_gpr[HEX_REG_PC], riV);
+gen_log_reg_write(HEX_REG_LC1, RsV, insn->slot, 0);
+gen_log_reg_write(HEX_REG_SA1, tmp, insn->slot, 0);
+tcg_temp_free(tmp);
+}
+
+static inline void gen_compare(TCGCond cond, TCGv res, TCGv arg1, TCGv arg2)
+{
+TCGv one = tcg_const_tl(0xff);
+TCGv zero = tcg_const_tl(0);
+
+tcg_gen_movcond_tl(cond, res, arg1, arg2, one, zero);
+
+tcg_temp_free(one);
+tcg_temp_free(zero);
+}
+
+static inline void gen_comparei(TCGCond cond, TCGv res, TCGv arg1, int arg2)
+{
+TCGv tmp = tcg_const_tl(arg2);
+gen_compare(cond, res, arg1, tmp);
+tcg_temp_free(tmp);
+}
+
+static inline void gen_compare_i64(TCGCond cond, TCGv res,
+   TCGv_i64 arg1, TCGv_i64 arg2)
+{
+TCGv_i64 one = tcg_const_i64(0xff);
+TCGv_i64 zero = tcg_const_i64(0);
+TCGv_i64 temp = tcg_temp_new_i64();
+
+tcg_gen_movcond_i64(cond, temp, arg1, arg2, one, zero);
+tcg_gen_extrl_i64_i32(res, temp);
+tcg_gen_andi_tl(res, res, 0xff);
+
+tcg_temp_free_i64(one);
+tcg_temp_free_i64(zero);
+tcg_temp_free_i64(temp);
+}
+
+static inline void gen_cmpnd_cmp_jmp(int pnum, TCGCond cond, bool sense,
+ TCGv arg1, TCGv arg2, int pc_off)
+{
+TCGv new_pc = tcg_temp_new();
+TCGv pred = tcg_temp_new();
+TCGv zero = tcg_const_tl(0);
+TCGv one = tcg_const_tl(1);
+
+tcg_gen_addi_tl(new_pc, hex_gpr[HEX_REG_PC], pc_off);
+gen_compare(cond, pred, arg1, arg2);
+gen_log_pred_write(pnum, pred);
+if (!sense) {
+tcg_gen_xori_tl(pred, pred, 0xff);
+}
+
+/* If there are multiple branches in a packet, ignore the second one */
+tcg_gen_movcond_tl(TCG_COND_NE, pred, hex_branch_taken, zero, zero, pred);
+
+tcg_gen_movcond_tl(TCG_COND_NE, hex_next_PC, pred, zero,
+   new_pc, hex_next_PC);
+tcg_gen_movcond_tl(TCG_COND_NE, hex_branch_taken, pred, zero,
+   one, hex_branch_taken);
+
+tcg_temp_free(new_pc);
+tcg_temp_free(pred);
+tcg_temp_free(zero);
+tcg_temp_free(one);
+}
+
+static inline void gen_cmpnd_cmpi_jmp(int pnum, TCGCond cond, bool sense,
+  TCGv arg1, int arg2, int pc_off)
+{
+TCGv tmp = tcg_const_tl(arg2);
+gen_cmpnd_cmp_jmp(pnum, cond, sense, arg1, tmp, pc_off);
+tcg_temp_free(tmp);
+
+}
+
+static inline void gen_cmpnd_cmp_n1_jmp(int pnum, TCGCond cond, bool sense,
+TCGv arg, int pc_off)
+{
+gen_cmpnd_cmpi_jmp(pnum, cond, sense, arg, -1, pc_off);
+}
+
+
+static inline void gen_jump(int pc_off)
+{
+TCGv new_pc = tcg_temp_new();
+tcg_gen_addi_tl(new_pc, hex_gpr[HEX_REG_PC], pc_off);
+gen_write_new_pc(new_pc);
+tcg_temp_free(new_pc);
+}
+
+static inline void gen_cond_jumpr(TCGv pred, TCGv dst_pc)
+{
+TCGv zero = tcg_const_tl(0);
+TCGv one = tcg_const_tl(1);
+TCGv new_pc = tcg_temp_new();
+
+tcg_gen_movcond_tl(TCG_COND_EQ, new_pc, pred, zero, hex_next_PC, dst_pc);
+
+/* If there are multiple jumps in a packet, only the first one is taken */
+tcg_gen_movcond_tl(TCG_COND_NE, hex_next_PC, hex_branch_taken, zero,
+   hex_next_PC, new_pc);
+tcg_gen_movcond_tl(TCG_COND_EQ, hex_branch_taken, pred, zero,
+   hex_branch_taken, one);
+
+tcg_temp_free(zero);
+tcg_temp_free(one);
+tcg_temp_free(new_pc);
+}
+
+static inline void gen_cond_jump(TCGv pred, int pc_off)
+{
+TCGv new_pc = tcg_temp_new();
+
+tcg_gen_addi_tl(new_pc, hex_gpr[HEX_REG_PC], pc_off);
+gen_cond_jumpr(pred, new_pc);
+
+tcg_temp_free(new_pc);
+}
+
+static inline void gen_call(int pc_off)
+{
+gen_log_reg_write(HEX_REG_LR, hex_next_PC, 4, false);
+gen_jump(pc_off);
+}
+
+static inline void gen_callr(TCGv new_pc)
+{
+

[RFC PATCH v2 36/67] Hexagon TCG generation helpers - step 3

Helpers for store instructions

Signed-off-by: Taylor Simpson 
---
 target/hexagon/genptr_helpers.h | 77 +
 1 file changed, 77 insertions(+)

diff --git a/target/hexagon/genptr_helpers.h b/target/hexagon/genptr_helpers.h
index c0e4c39..0e2d7b9 100644
--- a/target/hexagon/genptr_helpers.h
+++ b/target/hexagon/genptr_helpers.h
@@ -386,4 +386,81 @@ static inline void gen_store_conditional8(CPUHexagonState 
*env,
 tcg_temp_free(tmp);
 }
 
+static inline void gen_store32(TCGv vaddr, TCGv src, int width, int slot)
+{
+tcg_gen_mov_tl(hex_store_addr[slot], vaddr);
+tcg_gen_movi_tl(hex_store_width[slot], width);
+tcg_gen_mov_tl(hex_store_val32[slot], src);
+}
+
+static inline void gen_store1(TCGv_env cpu_env, TCGv vaddr, TCGv src,
+  DisasContext *ctx, int slot)
+{
+TCGv tmp = tcg_const_tl(slot);
+gen_store32(vaddr, src, 1, slot);
+tcg_temp_free(tmp);
+ctx->ctx_store_width[slot] = 1;
+}
+
+static inline void gen_store1i(TCGv_env cpu_env, TCGv vaddr, int32_t src,
+   DisasContext *ctx, int slot)
+{
+TCGv tmp = tcg_const_tl(src);
+gen_store1(cpu_env, vaddr, tmp, ctx, slot);
+tcg_temp_free(tmp);
+}
+
+static inline void gen_store2(TCGv_env cpu_env, TCGv vaddr, TCGv src,
+  DisasContext *ctx, int slot)
+{
+TCGv tmp = tcg_const_tl(slot);
+gen_store32(vaddr, src, 2, slot);
+tcg_temp_free(tmp);
+ctx->ctx_store_width[slot] = 2;
+}
+
+static inline void gen_store2i(TCGv_env cpu_env, TCGv vaddr, int32_t src,
+   DisasContext *ctx, int slot)
+{
+TCGv tmp = tcg_const_tl(src);
+gen_store2(cpu_env, vaddr, tmp, ctx, slot);
+tcg_temp_free(tmp);
+}
+
+static inline void gen_store4(TCGv_env cpu_env, TCGv vaddr, TCGv src,
+  DisasContext *ctx, int slot)
+{
+TCGv tmp = tcg_const_tl(slot);
+gen_store32(vaddr, src, 4, slot);
+tcg_temp_free(tmp);
+ctx->ctx_store_width[slot] = 4;
+}
+
+static inline void gen_store4i(TCGv_env cpu_env, TCGv vaddr, int32_t src,
+   DisasContext *ctx, int slot)
+{
+TCGv tmp = tcg_const_tl(src);
+gen_store4(cpu_env, vaddr, tmp, ctx, slot);
+tcg_temp_free(tmp);
+}
+
+static inline void gen_store8(TCGv_env cpu_env, TCGv vaddr, TCGv_i64 src,
+  DisasContext *ctx, int slot)
+{
+TCGv tmp = tcg_const_tl(slot);
+tcg_gen_mov_tl(hex_store_addr[slot], vaddr);
+tcg_gen_movi_tl(hex_store_width[slot], 8);
+tcg_gen_mov_i64(hex_store_val64[slot], src);
+tcg_temp_free(tmp);
+ctx->ctx_store_width[slot] = 8;
+}
+
+static inline void gen_store8i(TCGv_env cpu_env, TCGv vaddr, int64_t src,
+   DisasContext *ctx, int slot)
+{
+TCGv_i64 tmp = tcg_const_i64(src);
+gen_store8(cpu_env, vaddr, tmp, ctx, slot);
+tcg_temp_free_i64(tmp);
+}
+
 #endif
-- 
2.7.4

[RFC PATCH v2 66/67] Hexagon HVX translation