Re: [PATCH v6 01/11] qapi/error: add (Error **errp) cleaning APIs

[Greg Kurz]

On Fri, 10 Jan 2020 22:41:48 +0300
Vladimir Sementsov-Ogievskiy  wrote:

> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
> 

Reviewed-by: Greg Kurz 

> CC: Cornelia Huck 
> CC: Eric Blake 
> CC: Kevin Wolf 
> CC: Max Reitz 
> CC: Greg Kurz 
> CC: Stefan Hajnoczi 
> CC: Stefano Stabellini 
> CC: Anthony Perard 
> CC: Paul Durrant 
> CC: "Philippe Mathieu-Daudé" 
> CC: Laszlo Ersek 
> CC: Gerd Hoffmann 
> CC: Stefan Berger 
> CC: Markus Armbruster 
> CC: Michael Roth 
> CC: qemu-bl...@nongnu.org
> CC: xen-de...@lists.xenproject.org
> 
>  include/qapi/error.h | 26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/include/qapi/error.h b/include/qapi/error.h
> index ad5b6e896d..fa8d51fd6d 100644
> --- a/include/qapi/error.h
> +++ b/include/qapi/error.h
> @@ -309,6 +309,32 @@ void warn_reportf_err(Error *err, const char *fmt, ...)
>  void error_reportf_err(Error *err, const char *fmt, ...)
>  GCC_FMT_ATTR(2, 3);
>  
> +/*
> + * Functions to clean Error **errp: call corresponding Error *err cleaning
> + * function an set pointer to NULL
> + */
> +static inline void error_free_errp(Error **errp)
> +{
> +assert(errp && *errp);
> +error_free(*errp);
> +*errp = NULL;
> +}
> +
> +static inline void error_report_errp(Error **errp)
> +{
> +assert(errp && *errp);
> +error_report_err(*errp);
> +*errp = NULL;
> +}
> +
> +static inline void warn_report_errp(Error **errp)
> +{
> +assert(errp && *errp);
> +warn_report_err(*errp);
> +*errp = NULL;
> +}
> +
> +
>  /*
>   * Just like error_setg(), except you get to specify the error class.
>   * Note: use of error classes other than ERROR_CLASS_GENERIC_ERROR is

Re: [PATCH] monitor: fix memory leak in monitor_fdset_dup_fd_find_remove

[Marc-André Lureau]

On Wed, Jan 15, 2020 at 11:21 AM  wrote:
>
> From: Chen Qun 
>
> When remove dup_fd in monitor_fdset_dup_fd_find_remove function,
> we need to free mon_fdset_fd_dup. ASAN shows memory leak stack:
>
> Direct leak of 96 byte(s) in 3 object(s) allocated from:
> #0 0xfffd37b033b3 in __interceptor_calloc (/lib64/libasan.so.4+0xd33b3)
> #1 0xfffd375c71cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb)
> #2 0xaaae25bf1c17 in monitor_fdset_dup_fd_add /qemu/monitor/misc.c:1724
> #3 0xaaae265cfd8f in qemu_open /qemu/util/osdep.c:315
> #4 0xaaae264e2b2b in qmp_chardev_open_file_source 
> /qemu/chardev/char-fd.c:122
> #5 0xaaae264e47cf in qmp_chardev_open_file /qemu/chardev/char-file.c:81
> #6 0xaaae264e118b in qemu_char_open /qemu/chardev/char.c:237
> #7 0xaaae264e118b in qemu_chardev_new /qemu/chardev/char.c:964
> #8 0xaaae264e1543 in qemu_chr_new_from_opts /qemu/chardev/char.c:680
> #9 0xaaae25e12e0f in chardev_init_func /qemu/vl.c:2083
> #10 0xaaae26603823 in qemu_opts_foreach /qemu/util/qemu-option.c:1170
> #11 0xaaae258c9787 in main /qemu/vl.c:4089
> #12 0xfffd35b80b9f in __libc_start_main (/lib64/libc.so.6+0x20b9f)
> #13 0xaaae258d7b63  
> (/qemu/build/aarch64-softmmu/qemu-system-aarch64+0x8b7b63)
>
> Reported-by: Euler Robot 
> Signed-off-by: Chen Qun 

Reviewed-by: Marc-André Lureau 


> ---
>  monitor/misc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/monitor/misc.c b/monitor/misc.c
> index a04d7edde0..cf79d36100 100644
> --- a/monitor/misc.c
> +++ b/monitor/misc.c
> @@ -1744,6 +1744,7 @@ static int64_t monitor_fdset_dup_fd_find_remove(int 
> dup_fd, bool remove)
>  if (mon_fdset_fd_dup->fd == dup_fd) {
>  if (remove) {
>  QLIST_REMOVE(mon_fdset_fd_dup, next);
> +g_free(mon_fdset_fd_dup);
>  if (QLIST_EMPTY(_fdset->dup_fds)) {
>  monitor_fdset_cleanup(mon_fdset);
>  }
> --
> 2.23.0
>
>
>


-- 
Marc-André Lureau

Re: [PATCH 1/3] target/i386: Renumber EXCP_SYSCALL

[Philippe Mathieu-Daudé]

On 1/14/20 10:09 PM, Richard Henderson wrote:

We are not short of numbers for EXCP_*.  There is no need to confuse things
by having EXCP_VMEXIT and EXCP_SYSCALL overlap, even though the former is
only used for system mode and the latter is only used for user mode.

Signed-off-by: Richard Henderson 
---
  target/i386/cpu.h | 5 ++---
  1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 594326a794..164d038d1f 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -998,9 +998,8 @@ typedef uint64_t FeatureWordArray[FEATURE_WORDS];
  #define EXCP11_ALGN   17
  #define EXCP12_MCHK   18
  
-#define EXCP_SYSCALL0x100 /* only happens in user only emulation

- for syscall instruction */
-#define EXCP_VMEXIT 0x100
+#define EXCP_VMEXIT 0x100 /* only for system emulation */
+#define EXCP_SYSCALL0x101 /* only for user emulation */
  
  /* i386-specific interrupt pending bits.  */

  #define CPU_INTERRUPT_POLL  CPU_INTERRUPT_TGT_EXT_1



Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH 2/3] linux-user/i386: Split out gen_signal

[Philippe Mathieu-Daudé]

On 1/14/20 10:09 PM, Richard Henderson wrote:

This is a bit tidier than open-coding the 5 lines necessary
to initialize the target_siginfo_t.  In addition, this zeros
the remaining bytes of the target_siginfo_t, rather than
passing in garbage.

Signed-off-by: Richard Henderson 
---
  linux-user/i386/cpu_loop.c | 93 ++
  1 file changed, 33 insertions(+), 60 deletions(-)

diff --git a/linux-user/i386/cpu_loop.c b/linux-user/i386/cpu_loop.c
index 024b6f4d58..e217cca5ee 100644
--- a/linux-user/i386/cpu_loop.c
+++ b/linux-user/i386/cpu_loop.c
@@ -81,13 +81,23 @@ static void set_idt(int n, unsigned int dpl)
  }
  #endif
  
+static void gen_signal(CPUX86State *env, int sig, int code, abi_ptr addr)

+{
+target_siginfo_t info = {
+.si_signo = sig,
+.si_code = code,
+._sifields._sigfault._addr = addr
+};
+
+queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+}
+
  void cpu_loop(CPUX86State *env)
  {
  CPUState *cs = env_cpu(env);
  int trapnr;
  abi_ulong pc;
  abi_ulong ret;
-target_siginfo_t info;
  
  for(;;) {

  cpu_exec_start(cs);
@@ -134,70 +144,45 @@ void cpu_loop(CPUX86State *env)
  #endif
  case EXCP0B_NOSEG:
  case EXCP0C_STACK:
-info.si_signo = TARGET_SIGBUS;
-info.si_errno = 0;
-info.si_code = TARGET_SI_KERNEL;
-info._sifields._sigfault._addr = 0;
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+gen_signal(env, TARGET_SIGBUS, TARGET_SI_KERNEL, 0);
  break;
  case EXCP0D_GPF:
  /* XXX: potential problem if ABI32 */
  #ifndef TARGET_X86_64
  if (env->eflags & VM_MASK) {
  handle_vm86_fault(env);
-} else
-#endif
-{
-info.si_signo = TARGET_SIGSEGV;
-info.si_errno = 0;
-info.si_code = TARGET_SI_KERNEL;
-info._sifields._sigfault._addr = 0;
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+break;
  }
+#endif
+gen_signal(env, TARGET_SIGSEGV, TARGET_SI_KERNEL, 0);
  break;
  case EXCP0E_PAGE:
-info.si_signo = TARGET_SIGSEGV;
-info.si_errno = 0;
-if (!(env->error_code & 1))
-info.si_code = TARGET_SEGV_MAPERR;
-else
-info.si_code = TARGET_SEGV_ACCERR;
-info._sifields._sigfault._addr = env->cr[2];
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+gen_signal(env, TARGET_SIGSEGV,
+   (env->error_code & 1 ?
+TARGET_SEGV_ACCERR : TARGET_SEGV_MAPERR),
+   env->cr[2]);
  break;
  case EXCP00_DIVZ:
  #ifndef TARGET_X86_64
  if (env->eflags & VM_MASK) {
  handle_vm86_trap(env, trapnr);
-} else
-#endif
-{
-/* division by zero */
-info.si_signo = TARGET_SIGFPE;
-info.si_errno = 0;
-info.si_code = TARGET_FPE_INTDIV;
-info._sifields._sigfault._addr = env->eip;
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+break;
  }
+#endif
+gen_signal(env, TARGET_SIGFPE, TARGET_FPE_INTDIV, env->eip);
  break;
  case EXCP01_DB:
  case EXCP03_INT3:
  #ifndef TARGET_X86_64
  if (env->eflags & VM_MASK) {
  handle_vm86_trap(env, trapnr);
-} else
+break;
+}
  #endif
-{
-info.si_signo = TARGET_SIGTRAP;
-info.si_errno = 0;
-if (trapnr == EXCP01_DB) {
-info.si_code = TARGET_TRAP_BRKPT;
-info._sifields._sigfault._addr = env->eip;
-} else {
-info.si_code = TARGET_SI_KERNEL;
-info._sifields._sigfault._addr = 0;
-}
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+if (trapnr == EXCP01_DB) {
+gen_signal(env, TARGET_SIGTRAP, TARGET_TRAP_BRKPT, env->eip);
+} else {
+gen_signal(env, TARGET_SIGTRAP, TARGET_SI_KERNEL, 0);
  }
  break;
  case EXCP04_INTO:
@@ -205,31 +190,19 @@ void cpu_loop(CPUX86State *env)
  #ifndef TARGET_X86_64
  if (env->eflags & VM_MASK) {
  handle_vm86_trap(env, trapnr);
-} else
-#endif
-{
-info.si_signo = TARGET_SIGSEGV;
-info.si_errno = 0;
-info.si_code = TARGET_SI_KERNEL;
-info._sifields._sigfault._addr = 0;
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+break;
  }
+#endif
+

[PATCH] monitor: fix memory leak in monitor_fdset_dup_fd_find_remove

[kuhn.chenqun]

From: Chen Qun 

When remove dup_fd in monitor_fdset_dup_fd_find_remove function,
we need to free mon_fdset_fd_dup. ASAN shows memory leak stack:

Direct leak of 96 byte(s) in 3 object(s) allocated from:
#0 0xfffd37b033b3 in __interceptor_calloc (/lib64/libasan.so.4+0xd33b3)
#1 0xfffd375c71cb in g_malloc0 (/lib64/libglib-2.0.so.0+0x571cb)
#2 0xaaae25bf1c17 in monitor_fdset_dup_fd_add /qemu/monitor/misc.c:1724
#3 0xaaae265cfd8f in qemu_open /qemu/util/osdep.c:315
#4 0xaaae264e2b2b in qmp_chardev_open_file_source 
/qemu/chardev/char-fd.c:122
#5 0xaaae264e47cf in qmp_chardev_open_file /qemu/chardev/char-file.c:81
#6 0xaaae264e118b in qemu_char_open /qemu/chardev/char.c:237
#7 0xaaae264e118b in qemu_chardev_new /qemu/chardev/char.c:964
#8 0xaaae264e1543 in qemu_chr_new_from_opts /qemu/chardev/char.c:680
#9 0xaaae25e12e0f in chardev_init_func /qemu/vl.c:2083
#10 0xaaae26603823 in qemu_opts_foreach /qemu/util/qemu-option.c:1170
#11 0xaaae258c9787 in main /qemu/vl.c:4089
#12 0xfffd35b80b9f in __libc_start_main (/lib64/libc.so.6+0x20b9f)
#13 0xaaae258d7b63  
(/qemu/build/aarch64-softmmu/qemu-system-aarch64+0x8b7b63)

Reported-by: Euler Robot 
Signed-off-by: Chen Qun 
---
 monitor/misc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/monitor/misc.c b/monitor/misc.c
index a04d7edde0..cf79d36100 100644
--- a/monitor/misc.c
+++ b/monitor/misc.c
@@ -1744,6 +1744,7 @@ static int64_t monitor_fdset_dup_fd_find_remove(int 
dup_fd, bool remove)
 if (mon_fdset_fd_dup->fd == dup_fd) {
 if (remove) {
 QLIST_REMOVE(mon_fdset_fd_dup, next);
+g_free(mon_fdset_fd_dup);
 if (QLIST_EMPTY(_fdset->dup_fds)) {
 monitor_fdset_cleanup(mon_fdset);
 }
-- 
2.23.0

Re: [PATCH 0/3] linux-user: Implement x86_64 vsyscalls

[Laurent Desnogues]

On Tue, Jan 14, 2020 at 10:09 PM Richard Henderson
 wrote:
[...]
> I vaguely remember someone (Paolo?) implementing something like
> this many years ago, but clearly it never got merged.

That was me back in 2009:

https://lists.gnu.org/archive/html/qemu-devel/2009-07/msg00881.html

Glad it will finally get an official fix.

Thanks,

Laurent

Re: [PATCH v3 3/3] target/riscv: update mstatus.SD when FS is set dirty

[Alistair Francis]

On Wed, Jan 15, 2020 at 4:19 PM  wrote:
>
> remove the check becuase SD bit should summarize FS and XS fields
> unconditionally.
>
> Signed-off-by: ShihPo Hung 
> Reviewed-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/csr.c   | 3 +--
>  target/riscv/translate.c | 2 +-
>  2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index da02f9f..0e34c29 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -341,8 +341,7 @@ static int write_mstatus(CPURISCVState *env, int csrno, 
> target_ulong val)
>
>  mstatus = (mstatus & ~mask) | (val & mask);
>
> -dirty = (riscv_cpu_fp_enabled(env) &&
> - ((mstatus & MSTATUS_FS) == MSTATUS_FS)) |
> +dirty = ((mstatus & MSTATUS_FS) == MSTATUS_FS) |
>  ((mstatus & MSTATUS_XS) == MSTATUS_XS);
>  mstatus = set_field(mstatus, MSTATUS_SD, dirty);
>  env->mstatus = mstatus;
> diff --git a/target/riscv/translate.c b/target/riscv/translate.c
> index ab6a891..8e40ed3 100644
> --- a/target/riscv/translate.c
> +++ b/target/riscv/translate.c
> @@ -394,7 +394,7 @@ static void mark_fs_dirty(DisasContext *ctx)
>
>  tmp = tcg_temp_new();
>  tcg_gen_ld_tl(tmp, cpu_env, offsetof(CPURISCVState, mstatus));
> -tcg_gen_ori_tl(tmp, tmp, MSTATUS_FS);
> +tcg_gen_ori_tl(tmp, tmp, MSTATUS_FS | MSTATUS_SD);
>  tcg_gen_st_tl(tmp, cpu_env, offsetof(CPURISCVState, mstatus));
>  tcg_temp_free(tmp);
>  }
> --
> 2.7.4
>
>

Re: [PATCH v3 2/3] target/riscv: fsd/fsw doesn't dirty FP state

[Alistair Francis]

On Wed, Jan 15, 2020 at 4:18 PM  wrote:
>
> Signed-off-by: ShihPo Hung 
> Reviewed-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/insn_trans/trans_rvd.inc.c | 1 -
>  target/riscv/insn_trans/trans_rvf.inc.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/target/riscv/insn_trans/trans_rvd.inc.c 
> b/target/riscv/insn_trans/trans_rvd.inc.c
> index 393fa02..ea1044f 100644
> --- a/target/riscv/insn_trans/trans_rvd.inc.c
> +++ b/target/riscv/insn_trans/trans_rvd.inc.c
> @@ -43,7 +43,6 @@ static bool trans_fsd(DisasContext *ctx, arg_fsd *a)
>
>  tcg_gen_qemu_st_i64(cpu_fpr[a->rs2], t0, ctx->mem_idx, MO_TEQ);
>
> -mark_fs_dirty(ctx);
>  tcg_temp_free(t0);
>  return true;
>  }
> diff --git a/target/riscv/insn_trans/trans_rvf.inc.c 
> b/target/riscv/insn_trans/trans_rvf.inc.c
> index 172dbfa..e23cd63 100644
> --- a/target/riscv/insn_trans/trans_rvf.inc.c
> +++ b/target/riscv/insn_trans/trans_rvf.inc.c
> @@ -52,7 +52,6 @@ static bool trans_fsw(DisasContext *ctx, arg_fsw *a)
>  tcg_gen_qemu_st_i64(cpu_fpr[a->rs2], t0, ctx->mem_idx, MO_TEUL);
>
>  tcg_temp_free(t0);
> -mark_fs_dirty(ctx);
>  return true;
>  }
>
> --
> 2.7.4
>
>

Re: [PATCH 2/2] arm/virt/acpi: remove _ADR from devices identified by _HID

[Michael S. Tsirkin]

Problem is IASL disassembler still doesn't work on all hosts
we want to support. And its output isn't really stable enough
to act as a golden master.

Until we have a better tool, I propose the contributor just follows all
steps 1-6.  The reason they have been listed as maintainer action items
is really just so that multiple patches affecting same ACPI table
can be applied, with maintainer resolving conflicts himself.
But this job can be pushed to contributors if as in the case of ARM
maintainer isn't really interested in reading ACPI code anyway.

So I propose the following patch - comments?

Signed-off-by: Michael S. Tsirkin 


diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index f1ac2d7e96..3a6a3e7257 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -16,7 +16,10 @@
  * 1. add empty files for new tables, if any, under tests/data/acpi
  * 2. list any changed files in tests/bios-tables-test-allowed-diff.h
  * 3. commit the above *before* making changes that affect the tables
- * Maintainer:
+ *
+ * Contributor or ACPI Maintainer (steps 4-7 need to be redone to resolve 
conflicts
+ * in binary commit created in step 6):
+ *
  * After 1-3 above tests will pass but ignore differences with the expected 
files.
  * You will also notice that tests/bios-tables-test-allowed-diff.h lists
  * a bunch of files. This is your hint that you need to do the below:
@@ -28,13 +31,17 @@
  * output. If not - disassemble them yourself in any way you like.
  * Look at the differences - make sure they make sense and match what the
  * changes you are merging are supposed to do.
+ * Save the changes, preferably in form of ASL diff for the the commit log in
+ * step 6.
  *
  * 5. From build directory, run:
  *  $(SRC_PATH)/tests/data/acpi/rebuild-expected-aml.sh
- * 6. Now commit any changes.
- * 7. Before doing a pull request, make sure 
tests/bios-tables-test-allowed-diff.h
- *is empty - this will ensure following changes to ACPI tables will
- *be noticed.
+ * 6. Now commit any changes to the expected binary, include diff from step 4
+ *in commit log.
+ * 7. Before sending patches to the list (Contributor)
+ *or before doing a pull request (Maintainer), make sure
+ *tests/bios-tables-test-allowed-diff.h is empty - this will ensure
+ *following changes to ACPI tables will be noticed.
  */
 
 #include "qemu/osdep.h"

Re: [PATCH v3 1/3] target/riscv: Fix tb->flags FS status

[Alistair Francis]

On Wed, Jan 15, 2020 at 4:18 PM  wrote:
>
> It was found that running libquantum on riscv-linux qemu produced an
> incorrect result. After investigation, FP registers are not saved
> during context switch due to incorrect mstatus.FS.
>
> In current implementation tb->flags merges all non-disabled state to
> dirty. This means the code in mark_fs_dirty in translate.c that
> handles initial and clean states is unreachable.
>
> This patch fixes it and is successfully tested with:
>   libquantum
>
> Thanks to Richard for pointing out the actual bug.
>
> v3: remove the redundant condition
> v2: root cause FS problem
>
> Suggested-by: Richard Henderson 
> Signed-off-by: ShihPo Hung 
> Reviewed-by: Richard Henderson 
> ---
>  target/riscv/cpu.h | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
> index e59343e..de0a8d8 100644
> --- a/target/riscv/cpu.h
> +++ b/target/riscv/cpu.h
> @@ -293,10 +293,7 @@ static inline void cpu_get_tb_cpu_state(CPURISCVState 
> *env, target_ulong *pc,
>  #ifdef CONFIG_USER_ONLY
>  *flags = TB_FLAGS_MSTATUS_FS;
>  #else
> -*flags = cpu_mmu_index(env, 0);
> -if (riscv_cpu_fp_enabled(env)) {
> -*flags |= TB_FLAGS_MSTATUS_FS;
> -}
> +*flags = cpu_mmu_index(env, 0) | (env->mstatus & MSTATUS_FS);

I don't think this is right, you should use the riscv_cpu_fp_enabled() function.

Right now it's the same as env->mstatus & MSTATUS_FS but when the
Hypervisor extension goes in riscv_cpu_fp_enabled() will be more
complex.

Alistair

>  #endif
>  }
>
> --
> 2.7.4
>
>

[PATCH v2] vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks

[pannengyuan]

From: Pan Nengyuan 

Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This
patch save receive/transmit vq pointer in realize() and cleanup vqs
through those vq pointers in unrealize(). The leak stack is as follow:

Direct leak of 21504 byte(s) in 3 object(s) allocated from:
  #0 0x7f86a1356970 (/lib64/libasan.so.5+0xef970)  ??:?
  #1 0x7f86a09aa49d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
  #2 0x5604852f85ca (./x86_64-softmmu/qemu-system-x86_64+0x2c3e5ca)  
/mnt/sdb/qemu/hw/virtio/virtio.c:2333
  #3 0x560485356208 (./x86_64-softmmu/qemu-system-x86_64+0x2c9c208)  
/mnt/sdb/qemu/hw/virtio/vhost-vsock.c:339
  #4 0x560485305a17 (./x86_64-softmmu/qemu-system-x86_64+0x2c4ba17)  
/mnt/sdb/qemu/hw/virtio/virtio.c:3531
  #5 0x5604858e6b65 (./x86_64-softmmu/qemu-system-x86_64+0x322cb65)  
/mnt/sdb/qemu/hw/core/qdev.c:865
  #6 0x5604861e6c41 (./x86_64-softmmu/qemu-system-x86_64+0x3b2cc41)  
/mnt/sdb/qemu/qom/object.c:2102

Reported-by: Euler Robot 
Signed-off-by: Pan Nengyuan 
---
Changes V2 to V1:
- delete virtqueues after vhost cleanup to avoid use-after-free
- aslo delete virtqueues in the error path of realize()
---
 hw/virtio/vhost-vsock.c | 12 ++--
 include/hw/virtio/vhost-vsock.h |  2 ++
 2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c
index f5744363a8..b6cee479bb 100644
--- a/hw/virtio/vhost-vsock.c
+++ b/hw/virtio/vhost-vsock.c
@@ -335,8 +335,10 @@ static void vhost_vsock_device_realize(DeviceState *dev, 
Error **errp)
 sizeof(struct virtio_vsock_config));
 
 /* Receive and transmit queues belong to vhost */
-virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE, vhost_vsock_handle_output);
-virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE, vhost_vsock_handle_output);
+vsock->recv_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
+  vhost_vsock_handle_output);
+vsock->trans_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
+   vhost_vsock_handle_output);
 
 /* The event queue belongs to QEMU */
 vsock->event_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
@@ -363,6 +365,9 @@ static void vhost_vsock_device_realize(DeviceState *dev, 
Error **errp)
 err_vhost_dev:
 vhost_dev_cleanup(>vhost_dev);
 err_virtio:
+virtio_delete_queue(vsock->recv_vq);
+virtio_delete_queue(vsock->trans_vq);
+virtio_delete_queue(vsock->event_vq);
 virtio_cleanup(vdev);
 close(vhostfd);
 return;
@@ -379,6 +384,9 @@ static void vhost_vsock_device_unrealize(DeviceState *dev, 
Error **errp)
 vhost_vsock_set_status(vdev, 0);
 
 vhost_dev_cleanup(>vhost_dev);
+virtio_delete_queue(vsock->recv_vq);
+virtio_delete_queue(vsock->trans_vq);
+virtio_delete_queue(vsock->event_vq);
 virtio_cleanup(vdev);
 }
 
diff --git a/include/hw/virtio/vhost-vsock.h b/include/hw/virtio/vhost-vsock.h
index d509d67c4a..bc5a988ee5 100644
--- a/include/hw/virtio/vhost-vsock.h
+++ b/include/hw/virtio/vhost-vsock.h
@@ -33,6 +33,8 @@ typedef struct {
 struct vhost_virtqueue vhost_vqs[2];
 struct vhost_dev vhost_dev;
 VirtQueue *event_vq;
+VirtQueue *recv_vq;
+VirtQueue *trans_vq;
 QEMUTimer *post_load_timer;
 
 /*< public >*/
-- 
2.21.0.windows.1

[PATCH v3 3/3] target/riscv: update mstatus.SD when FS is set dirty

[shihpo . hung]

remove the check becuase SD bit should summarize FS and XS fields
unconditionally.

Signed-off-by: ShihPo Hung 
Reviewed-by: Richard Henderson 
---
 target/riscv/csr.c   | 3 +--
 target/riscv/translate.c | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index da02f9f..0e34c29 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -341,8 +341,7 @@ static int write_mstatus(CPURISCVState *env, int csrno, 
target_ulong val)
 
 mstatus = (mstatus & ~mask) | (val & mask);
 
-dirty = (riscv_cpu_fp_enabled(env) &&
- ((mstatus & MSTATUS_FS) == MSTATUS_FS)) |
+dirty = ((mstatus & MSTATUS_FS) == MSTATUS_FS) |
 ((mstatus & MSTATUS_XS) == MSTATUS_XS);
 mstatus = set_field(mstatus, MSTATUS_SD, dirty);
 env->mstatus = mstatus;
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index ab6a891..8e40ed3 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -394,7 +394,7 @@ static void mark_fs_dirty(DisasContext *ctx)
 
 tmp = tcg_temp_new();
 tcg_gen_ld_tl(tmp, cpu_env, offsetof(CPURISCVState, mstatus));
-tcg_gen_ori_tl(tmp, tmp, MSTATUS_FS);
+tcg_gen_ori_tl(tmp, tmp, MSTATUS_FS | MSTATUS_SD);
 tcg_gen_st_tl(tmp, cpu_env, offsetof(CPURISCVState, mstatus));
 tcg_temp_free(tmp);
 }
-- 
2.7.4

[PATCH v3 1/3] target/riscv: Fix tb->flags FS status

[shihpo . hung]

It was found that running libquantum on riscv-linux qemu produced an
incorrect result. After investigation, FP registers are not saved
during context switch due to incorrect mstatus.FS.

In current implementation tb->flags merges all non-disabled state to
dirty. This means the code in mark_fs_dirty in translate.c that
handles initial and clean states is unreachable.

This patch fixes it and is successfully tested with:
  libquantum

Thanks to Richard for pointing out the actual bug.

v3: remove the redundant condition
v2: root cause FS problem

Suggested-by: Richard Henderson 
Signed-off-by: ShihPo Hung 
Reviewed-by: Richard Henderson 
---
 target/riscv/cpu.h | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index e59343e..de0a8d8 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -293,10 +293,7 @@ static inline void cpu_get_tb_cpu_state(CPURISCVState 
*env, target_ulong *pc,
 #ifdef CONFIG_USER_ONLY
 *flags = TB_FLAGS_MSTATUS_FS;
 #else
-*flags = cpu_mmu_index(env, 0);
-if (riscv_cpu_fp_enabled(env)) {
-*flags |= TB_FLAGS_MSTATUS_FS;
-}
+*flags = cpu_mmu_index(env, 0) | (env->mstatus & MSTATUS_FS);
 #endif
 }
 
-- 
2.7.4

[PATCH v3 2/3] target/riscv: fsd/fsw doesn't dirty FP state

[shihpo . hung]

Signed-off-by: ShihPo Hung 
Reviewed-by: Richard Henderson 
---
 target/riscv/insn_trans/trans_rvd.inc.c | 1 -
 target/riscv/insn_trans/trans_rvf.inc.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/target/riscv/insn_trans/trans_rvd.inc.c 
b/target/riscv/insn_trans/trans_rvd.inc.c
index 393fa02..ea1044f 100644
--- a/target/riscv/insn_trans/trans_rvd.inc.c
+++ b/target/riscv/insn_trans/trans_rvd.inc.c
@@ -43,7 +43,6 @@ static bool trans_fsd(DisasContext *ctx, arg_fsd *a)
 
 tcg_gen_qemu_st_i64(cpu_fpr[a->rs2], t0, ctx->mem_idx, MO_TEQ);
 
-mark_fs_dirty(ctx);
 tcg_temp_free(t0);
 return true;
 }
diff --git a/target/riscv/insn_trans/trans_rvf.inc.c 
b/target/riscv/insn_trans/trans_rvf.inc.c
index 172dbfa..e23cd63 100644
--- a/target/riscv/insn_trans/trans_rvf.inc.c
+++ b/target/riscv/insn_trans/trans_rvf.inc.c
@@ -52,7 +52,6 @@ static bool trans_fsw(DisasContext *ctx, arg_fsw *a)
 tcg_gen_qemu_st_i64(cpu_fpr[a->rs2], t0, ctx->mem_idx, MO_TEUL);
 
 tcg_temp_free(t0);
-mark_fs_dirty(ctx);
 return true;
 }
 
-- 
2.7.4

Re: [PATCH v2 1/3] target/riscv: Fix tb->flags FS status

[ShihPo Hung]

On Tue, Jan 14, 2020 at 11:29 PM Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 1/14/20 12:13 AM, shihpo.h...@sifive.com wrote:
> >  if (riscv_cpu_fp_enabled(env)) {
> > -*flags |= TB_FLAGS_MSTATUS_FS;
> > +*flags |= env->mstatus & MSTATUS_FS;
> >  }
>
> Note that riscv_cpu_fp_enabled is *also* testing env->mstatus, and that
> this
> assignment can be made unconditional.
>
> Otherwise,
> Reviewed-by: Richard Henderson 
>

I'll send v3 that cleans up the patch accordingly.
Thanks for the review!

Re: [PATCH v5 08/22] gdbstub: extend GByteArray to read register helpers

[David Gibson]

On Tue, Jan 14, 2020 at 03:09:39PM +, Alex Bennée wrote:
> Instead of passing a pointer to memory now just extend the GByteArray
> to all the read register helpers. They can then safely append their
> data through the normal way. We don't bother with this abstraction for
> write registers as we have already ensured the buffer being copied
> from is the correct size.
> 
> Signed-off-by: Alex Bennée 
> Reviewed-by: Richard Henderson 

ppc parts
Acked-by: David Gibson 

> 
> ---
> v4
>   - fix mem_buf calculation for ppc_maybe_bswap_register
> v5
>   - introduce gdb_get_reg_ptr and use for ppc
> ---
>  include/exec/gdbstub.h  | 59 +++--
>  include/hw/core/cpu.h   |  2 +-
>  target/alpha/cpu.h  |  2 +-
>  target/arm/cpu.h|  4 +--
>  target/cris/cpu.h   |  4 +--
>  target/hppa/cpu.h   |  2 +-
>  target/i386/cpu.h   |  2 +-
>  target/lm32/cpu.h   |  2 +-
>  target/m68k/cpu.h   |  2 +-
>  target/microblaze/cpu.h |  2 +-
>  target/mips/internal.h  |  2 +-
>  target/openrisc/cpu.h   |  2 +-
>  target/ppc/cpu.h|  4 +--
>  target/riscv/cpu.h  |  2 +-
>  target/s390x/internal.h |  2 +-
>  target/sh4/cpu.h|  2 +-
>  target/sparc/cpu.h  |  2 +-
>  target/xtensa/cpu.h |  2 +-
>  gdbstub.c   | 20 +--
>  hw/core/cpu.c   |  2 +-
>  target/alpha/gdbstub.c  |  2 +-
>  target/arm/gdbstub.c|  2 +-
>  target/arm/gdbstub64.c  |  2 +-
>  target/arm/helper.c | 19 +--
>  target/cris/gdbstub.c   |  4 +--
>  target/hppa/gdbstub.c   |  2 +-
>  target/i386/gdbstub.c   |  2 +-
>  target/lm32/gdbstub.c   |  2 +-
>  target/m68k/gdbstub.c   |  2 +-
>  target/m68k/helper.c|  4 +--
>  target/microblaze/gdbstub.c |  2 +-
>  target/mips/gdbstub.c   |  2 +-
>  target/nios2/cpu.c  |  2 +-
>  target/openrisc/gdbstub.c   |  2 +-
>  target/ppc/gdbstub.c| 48 +++
>  target/ppc/translate_init.inc.c | 54 --
>  target/riscv/gdbstub.c  | 18 +-
>  target/s390x/gdbstub.c  | 30 -
>  target/sh4/gdbstub.c|  2 +-
>  target/sparc/gdbstub.c  |  2 +-
>  target/xtensa/gdbstub.c |  2 +-
>  41 files changed, 178 insertions(+), 148 deletions(-)
> 
> diff --git a/include/exec/gdbstub.h b/include/exec/gdbstub.h
> index 59e366ba3a..30b909ebd2 100644
> --- a/include/exec/gdbstub.h
> +++ b/include/exec/gdbstub.h
> @@ -68,53 +68,76 @@ void gdb_signalled(CPUArchState *, int);
>  void gdbserver_fork(CPUState *);
>  #endif
>  /* Get or set a register.  Returns the size of the register.  */
> -typedef int (*gdb_reg_cb)(CPUArchState *env, uint8_t *buf, int reg);
> +typedef int (*gdb_get_reg_cb)(CPUArchState *env, GByteArray *buf, int reg);
> +typedef int (*gdb_set_reg_cb)(CPUArchState *env, uint8_t *buf, int reg);
>  void gdb_register_coprocessor(CPUState *cpu,
> -  gdb_reg_cb get_reg, gdb_reg_cb set_reg,
> +  gdb_get_reg_cb get_reg, gdb_set_reg_cb set_reg,
>int num_regs, const char *xml, int g_pos);
>  
> -/* The GDB remote protocol transfers values in target byte order.  This means
> - * we can use the raw memory access routines to access the value buffer.
> - * Conveniently, these also handle the case where the buffer is mis-aligned.
> +/*
> + * The GDB remote protocol transfers values in target byte order. As
> + * the gdbstub may be batching up several register values we always
> + * append to the array.
>   */
>  
> -static inline int gdb_get_reg8(uint8_t *mem_buf, uint8_t val)
> +static inline int gdb_get_reg8(GByteArray *buf, uint8_t val)
>  {
> -stb_p(mem_buf, val);
> +g_byte_array_append(buf, , 1);
>  return 1;
>  }
>  
> -static inline int gdb_get_reg16(uint8_t *mem_buf, uint16_t val)
> +static inline int gdb_get_reg16(GByteArray *buf, uint16_t val)
>  {
> -stw_p(mem_buf, val);
> +uint16_t to_word = tswap16(val);
> +g_byte_array_append(buf, (uint8_t *) _word, 2);
>  return 2;
>  }
>  
> -static inline int gdb_get_reg32(uint8_t *mem_buf, uint32_t val)
> +static inline int gdb_get_reg32(GByteArray *buf, uint32_t val)
>  {
> -stl_p(mem_buf, val);
> +uint32_t to_long = tswap32(val);
> +g_byte_array_append(buf, (uint8_t *) _long, 4);
>  return 4;
>  }
>  
> -static inline int gdb_get_reg64(uint8_t *mem_buf, uint64_t val)
> +static inline int gdb_get_reg64(GByteArray *buf, uint64_t val)
>  {
> -stq_p(mem_buf, val);
> +uint64_t to_quad = tswap64(val);
> +g_byte_array_append(buf, (uint8_t *) _quad, 8);
>  return 8;
>  }
>  
> -static inline int gdb_get_reg128(uint8_t *mem_buf, uint64_t val_hi,
> 

Re: [PATCH V2] vhost-user-test: fix a memory leak

[Pan Nengyuan]

On 1/13/2020 10:32 AM, Pan Nengyuan wrote:
> 
> 
> On 1/12/2020 6:39 PM, Thomas Huth wrote:
>> On 10/01/2020 15.07, Thomas Huth wrote:
>>> On 20/12/2019 02.26, pannengy...@huawei.com wrote:
 From: Pan Nengyuan 

 Spotted by ASAN.

 Reported-by: Euler Robot 
 Signed-off-by: Pan Nengyuan 
 ---
 Changes V2 to V1:
 - use a "goto cleanup", instead of duplicating the "free" functions.
 - free "dest_cmdline" at the end.
 ---
>>>
>>> Reviewed-by: Thomas Huth 
>>>
>>> ... and picked up to my qtest-next tree.
>>
>> ... and now I had to unqueue the patch again. It is reproducibly causing
>> one of the gitlab CI pipelines to fail with a timeout, e.g.:
>>
>>  https://gitlab.com/huth/qemu/-/jobs/400101552
>>
>> Not sure what is going on here, though, there is no obvious error
>> message in the output... this needs some more investigation... do you
>> have a gitlab account and could have a look?
>>
> 
> OK, I will register a account and have a look.
> 

I'm sorry, I build and test with the same params, but I can't reproduce it.
Could you add "V=1 or V=2" params to get more information ?

>>  Thomas
>>
>> .
>>

RE: [PATCH RFC 01/12] migration: Add multiRDMA capability support

[fengzhimin]

Thanks for your review. I will fix these errors in the next version(V2).
I hope you can busy schedule to find time to check other patches about 
Multi-RDMA.

-Original Message-
From: Eric Blake [mailto:ebl...@redhat.com] 
Sent: Tuesday, January 14, 2020 12:27 AM
To: fengzhimin ; quint...@redhat.com; 
dgilb...@redhat.com; arm...@redhat.com
Cc: qemu-devel@nongnu.org; Zhanghailiang ; 
jemmy858...@gmail.com
Subject: Re: [PATCH RFC 01/12] migration: Add multiRDMA capability support

On 1/8/20 10:59 PM, Zhimin Feng wrote:
> From: fengzhimin 
> 
> Signed-off-by: fengzhimin 
> ---

> +++ b/qapi/migration.json
> @@ -421,6 +421,8 @@
>   # @validate-uuid: Send the UUID of the source to allow the destination
>   # to ensure it is the same. (since 4.2)
>   #
> +# @multirdma: Use more than one channels for rdma migration. (since 4.2)

We've missed 4.2; the next release will be 5.0.

> +#
>   # Since: 1.2
>   ##
>   { 'enum': 'MigrationCapability',
> @@ -428,7 +430,7 @@
>  'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
>  'block', 'return-path', 'pause-before-switchover', 'multifd',
>  'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate',
> -   'x-ignore-shared', 'validate-uuid' ] }
> +   'x-ignore-shared', 'validate-uuid', 'multirdma' ] }
>   
>   ##
>   # @MigrationCapabilityStatus:
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: [PATCH 2/2] arm/virt/acpi: remove _ADR from devices identified by _HID

[Guoheyi]

Hi Peter, Michael,

Have we come to conclusion on how to submit patches for ARM ACPI tables?

Some rough thoughts: is it possible to use the disassembled ASL file as 
the 'golden master' data? One problem I can imagine is that this may 
introduce dependency on the version of iASL tool. If so, how about 
adding acpica source code as a submodule, just like what we did for the 
device tree compile "dtc".


There may be much more which I missed; looking forward to your comments.

Thanks,

Heyi

在 2020/1/6 23:51, Peter Maydell 写道:

On Sun, 5 Jan 2020 at 12:34, Michael S. Tsirkin  wrote:

On Thu, Dec 19, 2019 at 02:47:59PM +0800, Heyi Guo wrote:

  hw/arm/virt-acpi-build.c  |   8 
  tests/data/acpi/virt/DSDT | Bin 18449 -> 18426 bytes
  tests/data/acpi/virt/DSDT.memhp   | Bin 19786 -> 19763 bytes
  tests/data/acpi/virt/DSDT.numamem | Bin 18449 -> 18426 bytes
  4 files changed, 8 deletions(-)

Please do not include binary changes in acpi patches.

See comment at the top of tests/bios-tables-test.c for documentation
on how to update these.

If you want the patches not to include binary changes then
you will need to take these yourself through your own tree.
As the Arm subtree maintainer I am not going to follow a
specific process for acpi related patches that requires me
  to do anything other than "apply patches from email, test
them, send pull request". I also have no way to
identify whether any differences that I might see if I
disassembled the ACPI tables make sense, as that comment
suggests I should be doing. The differences in the tables need
to be checked by the people reviewing the patches, which will
not be me for anything ACPI related -- I just don't know
enough about the ACPI specs.

Patches should be self contained, including updating test
cases as required. The underlying problem here is that
the 'golden master' data for the acpi tests is a pile
of binary blobs rather than something that's human
readable and reviewable as part of a patch.

thanks
-- PMM

.

RE: [PATCH RFC 03/12] migration: Create the multi-rdma-channels parameter

[fengzhimin]

Thanks for your review. I will fix these errors in the next version(V2).

-Original Message-
From: Markus Armbruster [mailto:arm...@redhat.com] 
Sent: Monday, January 13, 2020 11:35 PM
To: fengzhimin 
Cc: quint...@redhat.com; dgilb...@redhat.com; ebl...@redhat.com; 
jemmy858...@gmail.com; qemu-devel@nongnu.org; Zhanghailiang 

Subject: Re: [PATCH RFC 03/12] migration: Create the multi-rdma-channels 
parameter

Zhimin Feng  writes:

> From: fengzhimin 
>
> Indicates the number of RDMA threads that we would create.
> By default we create 2 threads for RDMA migration.
>
> Signed-off-by: fengzhimin 
[...]
> diff --git a/qapi/migration.json b/qapi/migration.json index 
> c995ffdc4c..ab79bf0600 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -588,6 +588,10 @@
>  # @max-cpu-throttle: maximum cpu throttle percentage.
>  #Defaults to 99. (Since 3.1)
>  #
> +# @multi-rdma-channels: Number of channels used to migrate data in
> +#   parallel. This is the same number that the

same number as

> +#   number of multiRDMA used for migration.  The

Pardon my ignorance: what's "the number of multiRDMA used for migration"?

> +#   default value is 2 (since 4.2)

(since 5.0)

>  # Since: 2.4
>  ##
>  { 'enum': 'MigrationParameter',
> @@ -600,7 +604,8 @@
> 'downtime-limit', 'x-checkpoint-delay', 'block-incremental',
> 'multifd-channels',
> 'xbzrle-cache-size', 'max-postcopy-bandwidth',
> -   'max-cpu-throttle' ] }
> +   'max-cpu-throttle',
> +   'multi-rdma-channels'] }
>  
>  ##
>  # @MigrateSetParameters:
> @@ -690,6 +695,10 @@
>  # @max-cpu-throttle: maximum cpu throttle percentage.
>  #The default value is 99. (Since 3.1)
>  #
> +# @multi-rdma-channels: Number of channels used to migrate data in
> +#   parallel. This is the same number that the
> +#   number of multiRDMA used for migration.  The
> +#   default value is 2 (since 4.2)

See above.

>  # Since: 2.4
>  ##
>  # TODO either fuse back into MigrationParameters, or make @@ -715,7 
> +724,8 @@
>  '*multifd-channels': 'int',
>  '*xbzrle-cache-size': 'size',
>  '*max-postcopy-bandwidth': 'size',
> - '*max-cpu-throttle': 'int' } }
> + '*max-cpu-throttle': 'int',

Please use spaces instead of tab.

> +'*multi-rdma-channels': 'int'} }
>  
>  ##
>  # @migrate-set-parameters:
> @@ -825,6 +835,10 @@
>  #Defaults to 99.
>  # (Since 3.1)
>  #
> +# @multi-rdma-channels: Number of channels used to migrate data in
> +#   parallel. This is the same number that the
> +#   number of multiRDMA used for migration.  The
> +#   default value is 2 (since 4.2)
>  # Since: 2.4

See above.

>  ##
>  { 'struct': 'MigrationParameters',
> @@ -847,8 +861,9 @@
>  '*block-incremental': 'bool' ,
>  '*multifd-channels': 'uint8',
>  '*xbzrle-cache-size': 'size',
> - '*max-postcopy-bandwidth': 'size',
> -'*max-cpu-throttle':'uint8'} }
> + '*max-postcopy-bandwidth': 'size',
> +'*max-cpu-throttle':'uint8',
> +'*multi-rdma-channels':'uint8'} }
>  
>  ##
>  # @query-migrate-parameters:

Please use spaces instead of tab.

RE: [PATCH RFC 01/12] migration: Add multiRDMA capability support

[fengzhimin]

Thanks for your review. I will change it in the next version(V2).

-Original Message-
From: Markus Armbruster [mailto:arm...@redhat.com] 
Sent: Monday, January 13, 2020 11:30 PM
To: fengzhimin 
Cc: quint...@redhat.com; dgilb...@redhat.com; ebl...@redhat.com; 
jemmy858...@gmail.com; qemu-devel@nongnu.org; Zhanghailiang 

Subject: Re: [PATCH RFC 01/12] migration: Add multiRDMA capability support

Zhimin Feng  writes:

> From: fengzhimin 
>
> Signed-off-by: fengzhimin 
> ---
[...]
> diff --git a/qapi/migration.json b/qapi/migration.json index 
> b7348d0c8b..c995ffdc4c 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -421,6 +421,8 @@
>  # @validate-uuid: Send the UUID of the source to allow the destination
>  # to ensure it is the same. (since 4.2)
>  #
> +# @multirdma: Use more than one channels for rdma migration. (since 
> +4.2) #
>  # Since: 1.2
>  ##
>  { 'enum': 'MigrationCapability',
> @@ -428,7 +430,7 @@
> 'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
> 'block', 'return-path', 'pause-before-switchover', 'multifd',
> 'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate',
> -   'x-ignore-shared', 'validate-uuid' ] }
> +   'x-ignore-shared', 'validate-uuid', 'multirdma' ] }
>  
>  ##
>  # @MigrationCapabilityStatus:

Spell it multi-rdma?

[Bug 1849644] Re: QEMU VNC websocket proxy requires non-standard 'binary' subprotocol

[yuchenlin]

Hi, Samuel

This patch has been viewed by Daniel.
Please see 
https://lists.nongnu.org/archive/html/qemu-devel/2019-12/msg00264.html

However, Daniel has not sent a PR which includes this patch.

Thanks.

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

Title:
  QEMU VNC websocket proxy requires non-standard 'binary' subprotocol

Status in QEMU:
  New

Bug description:
  When running a machine using "-vnc" and the "websocket" option QEMU
  seems to require the subprotocol called 'binary'. This subprotocol
  does not exist in the WebSocket specification. In fact it has never
  existed in the spec, in one of the very early drafts of WebSockets it
  was briefly mentioned but it never made it to a final version.

  When the WebSocket server requires a non-standard subprotocol any
  WebSocket client that works correctly won't be able to connect.

  One example of such a client is noVNC, it tells the server that it
  doesn't want to use any subprotocol. QEMU's WebSocket proxy doesn't
  let noVNC connect. If noVNC is modified to ask for 'binary' it will
  work, this is, however, incorrect behavior.

  Looking at the code in "io/channel-websock.c" it seems it's quite
  hard-coded to binary:

  Look at line 58 and 433 here:
  https://git.qemu.org/?p=qemu.git;a=blob;f=io/channel-websock.c

  This code has to be made more dynamic, and shouldn't require binary.

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

Re: [PATCH] vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks

[Pan Nengyuan]

On 1/15/2020 12:59 AM, Stefano Garzarella wrote:
> On Tue, Jan 14, 2020 at 5:45 PM Stefan Hajnoczi  wrote:
>>
>> On Tue, Jan 14, 2020 at 03:52:29PM +0800, pannengy...@huawei.com wrote:
>>> From: Pan Nengyuan 
>>>
>>> Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This
>>> patch save receive/transmit vq pointer in realize() and cleanup vqs
>>> through those vq pointers in unrealize(). The leak stack is as follow:
>>>
>>> Direct leak of 21504 byte(s) in 3 object(s) allocated from:
>>>   #0 0x7f86a1356970 (/lib64/libasan.so.5+0xef970)  ??:?
>>>   #1 0x7f86a09aa49d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
>>>   #2 0x5604852f85ca (./x86_64-softmmu/qemu-system-x86_64+0x2c3e5ca)  
>>> /mnt/sdb/qemu/hw/virtio/virtio.c:2333
>>>   #3 0x560485356208 (./x86_64-softmmu/qemu-system-x86_64+0x2c9c208)  
>>> /mnt/sdb/qemu/hw/virtio/vhost-vsock.c:339
>>>   #4 0x560485305a17 (./x86_64-softmmu/qemu-system-x86_64+0x2c4ba17)  
>>> /mnt/sdb/qemu/hw/virtio/virtio.c:3531
>>>   #5 0x5604858e6b65 (./x86_64-softmmu/qemu-system-x86_64+0x322cb65)  
>>> /mnt/sdb/qemu/hw/core/qdev.c:865
>>>   #6 0x5604861e6c41 (./x86_64-softmmu/qemu-system-x86_64+0x3b2cc41)  
>>> /mnt/sdb/qemu/qom/object.c:2102
>>>
>>> Reported-by: Euler Robot 
>>> Signed-off-by: Pan Nengyuan 
>>> ---
>>>  hw/virtio/vhost-vsock.c | 9 +++--
>>>  include/hw/virtio/vhost-vsock.h | 2 ++
>>>  2 files changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c
>>> index f5744363a8..896c0174c1 100644
>>> --- a/hw/virtio/vhost-vsock.c
>>> +++ b/hw/virtio/vhost-vsock.c
>>> @@ -335,8 +335,10 @@ static void vhost_vsock_device_realize(DeviceState 
>>> *dev, Error **errp)
>>>  sizeof(struct virtio_vsock_config));
>>>
>>>  /* Receive and transmit queues belong to vhost */
>>> -virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE, 
>>> vhost_vsock_handle_output);
>>> -virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE, 
>>> vhost_vsock_handle_output);
>>> +vsock->recv_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
>>> +  vhost_vsock_handle_output);
>>> +vsock->trans_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
>>> +   vhost_vsock_handle_output);
>>>
>>>  /* The event queue belongs to QEMU */
>>>  vsock->event_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
>>> @@ -378,6 +380,9 @@ static void vhost_vsock_device_unrealize(DeviceState 
>>> *dev, Error **errp)
>>>  /* This will stop vhost backend if appropriate. */
>>>  vhost_vsock_set_status(vdev, 0);
>>>
>>> +virtio_delete_queue(vsock->recv_vq);
>>> +virtio_delete_queue(vsock->trans_vq);
>>> +virtio_delete_queue(vsock->event_vq);
>>>  vhost_dev_cleanup(>vhost_dev);
>>>  virtio_cleanup(vdev);
>>>  }
>>
>> Please delete the virtqueues after vhost cleanup (the reverse
>> initialization order).  There is currently no reason why it has to be
>> done in reverse initialization order, your patch should work too, but
>> it's a good default for avoiding user-after-free bugs.
>>
> 
> Agree!
> 
> Since we are here, should we delete the queues also in the error path
> of vhost_vsock_device_realize()?

Yes, I will change the cleanup order and aslo delete in the error path.

Thanks.

> 
> Thanks,
> Stefano
> 
> .
> 

Re: [PATCH] virtio-9p-device: fix memleak in virtio_9p_device_unrealize

[Pan Nengyuan]

On 1/14/2020 10:17 PM, Christian Schoenebeck wrote:
> On Dienstag, 14. Januar 2020 11:08:59 CET Christian Schoenebeck wrote:
>> On Dienstag, 14. Januar 2020 08:40:20 CET pannengy...@huawei.com wrote:
>>> From: Pan Nengyuan 
>>>
>>> v->vq forgot to cleanup in virtio_9p_device_unrealize, the memory leak
>>> stack is as follow:
>>>
>>> Direct leak of 14336 byte(s) in 2 object(s) allocated from:
>>>   #0 0x7f819ae43970 (/lib64/libasan.so.5+0xef970)  ??:?
>>>   #1 0x7f819872f49d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
>>>   #2 0x55a3a58da624 (./x86_64-softmmu/qemu-system-x86_64+0x2c14624)
>>>
>>> /mnt/sdb/qemu/hw/virtio/virtio.c:2327 #3 0x55a3a571bac7
>>> (./x86_64-softmmu/qemu-system-x86_64+0x2a55ac7)
>>> /mnt/sdb/qemu/hw/9pfs/virtio-9p-device.c:209 #4 0x55a3a58e7bc6
>>> (./x86_64-softmmu/qemu-system-x86_64+0x2c21bc6)
>>> /mnt/sdb/qemu/hw/virtio/virtio.c:3504 #5 0x55a3a5ebfb37
>>> (./x86_64-softmmu/qemu-system-x86_64+0x31f9b37)
>>> /mnt/sdb/qemu/hw/core/qdev.c:876
>>>
>>> Reported-by: Euler Robot 
>>> Signed-off-by: Pan Nengyuan 
>>> ---
>>>
>>>  hw/9pfs/virtio-9p-device.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c
>>> index b5a7c03f26..b146387ae2 100644
>>> --- a/hw/9pfs/virtio-9p-device.c
>>> +++ b/hw/9pfs/virtio-9p-device.c
>>> @@ -215,6 +215,7 @@ static void virtio_9p_device_unrealize(DeviceState
>>> *dev, Error **errp) V9fsVirtioState *v = VIRTIO_9P(dev);
>>>
>>>  V9fsState *s = >state;
>>>
>>> +virtio_delete_queue(v->vq);
>>>
>>>  virtio_cleanup(vdev);
>>>  v9fs_device_unrealize_common(s, errp);
>>>  
>>>  }
>>
>> Looks like you are using an old interface. The new one is
>>
>>  void virtio_del_queue(VirtIODevice *vdev, int n);
> 
> Ah, my bad, it is actually the other way around, that is I was not up to 
> date; 
> virtio_delete_queue() was apparently introduced a week ago:
> https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg00723.html
> 
> The old virtio_del_queue() still exists though:
> https://github.com/qemu/qemu/blob/master/hw/virtio/virtio.c#L2339
> 
> Having said that, it would probably still make sense to use 
> virtio_del_queue() 
> instead for now to make it easier for stable branches to merge this fix?
> 

virtio_delete_queue makes the cleanup more clear and it tends to replace the 
old one gradually.
So I think it would probably still use virtio_delete_queue.

Given that, maybe we can split this patch?
For example:
1. use virtio_del_queue to fix memleak, it's easier for stable to merge.
2. rename virtio_del_queue to virtio_delete_queue

> Best regards,
> Christian Schoenebeck
> 
> 
> 
> 
> .
> 

Re: [PATCH 2/2] arm/virt/acpi: remove _ADR from devices identified by _HID

[Guoheyi]

在 2020/1/13 23:26, Andrew Jones 写道:

On Mon, Jan 13, 2020 at 09:57:55PM +0800, Guoheyi wrote:

在 2020/1/13 20:08, Igor Mammedov 写道:

On Thu, 19 Dec 2019 14:47:59 +0800
Heyi Guo  wrote:


According to ACPI spec, _ADR should be used for device which is on a
bus that has a standard enumeration algorithm. It does not make sense
to have a _ADR object for devices which already have _HID and will be
enumerated by OSPM.

Signed-off-by: Heyi Guo 

Are you sure it's does not make sense?
Have you checked commit f264d51d8, that added _ADR?

I searched in SPCR spec and ACPI spec, but didn't find such requirement for
serial port device description.

Hi Andrew,

Could you help to explain the reason?

tl;dr: It was a mistake and I agree with removing _ADR from SPCR.

The long version is that ACPI support for ARM took a long time to get
merged upstream. In the meantime Linaro and Red Hat had ACPI support
in their downstream trees. The initial, never upstreamed implementation
of Linux SPCR support used _ADR to find the console UART (probably
because some vendor hacked their ACPI tables that way). I made the
mistake of using the out-of-tree Linux kernel code as my "specification".

Upstream kernels never had this problem and I don't think we need to
worry about any of those downstream kernels which did. They'd be five
years old by now anyway.

Thanks,
drew


Thanks for your confirmation, Andrew.

Hi Igor,

On arm64 physical machine, we didn't have _ADR for SPCR serial port 
device attached to system bus either, and we never saw any problem.


Thanks,

Heyi


Thanks,

Heyi




---
Cc: Shannon Zhao 
Cc: Peter Maydell 
Cc: "Michael S. Tsirkin" 
Cc: Igor Mammedov 
Cc: qemu-...@nongnu.org
Cc: qemu-devel@nongnu.org
---
   hw/arm/virt-acpi-build.c  |   8 
   tests/data/acpi/virt/DSDT | Bin 18449 -> 18426 bytes
   tests/data/acpi/virt/DSDT.memhp   | Bin 19786 -> 19763 bytes
   tests/data/acpi/virt/DSDT.numamem | Bin 18449 -> 18426 bytes
   4 files changed, 8 deletions(-)

diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 9f4c7d1889..be752c0ad8 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -78,11 +78,6 @@ static void acpi_dsdt_add_uart(Aml *scope, const MemMapEntry 
*uart_memmap,
AML_EXCLUSIVE, _irq, 1));
   aml_append(dev, aml_name_decl("_CRS", crs));
-/* The _ADR entry is used to link this device to the UART described
- * in the SPCR table, i.e. SPCR.base_address.address == _ADR.
- */
-aml_append(dev, aml_name_decl("_ADR", aml_int(uart_memmap->base)));
-
   aml_append(scope, dev);
   }
@@ -170,7 +165,6 @@ static void acpi_dsdt_add_pci(Aml *scope, const MemMapEntry 
*memmap,
   aml_append(dev, aml_name_decl("_CID", aml_string("PNP0A03")));
   aml_append(dev, aml_name_decl("_SEG", aml_int(0)));
   aml_append(dev, aml_name_decl("_BBN", aml_int(0)));
-aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
   aml_append(dev, aml_name_decl("_UID", aml_string("PCI0")));
   aml_append(dev, aml_name_decl("_STR", aml_unicode("PCIe 0 Device")));
   aml_append(dev, aml_name_decl("_CCA", aml_int(1)));
@@ -334,7 +328,6 @@ static void acpi_dsdt_add_gpio(Aml *scope, const 
MemMapEntry *gpio_memmap,
   {
   Aml *dev = aml_device("GPO0");
   aml_append(dev, aml_name_decl("_HID", aml_string("ARMH0061")));
-aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
   aml_append(dev, aml_name_decl("_UID", aml_int(0)));
   Aml *crs = aml_resource_template();
@@ -364,7 +357,6 @@ static void acpi_dsdt_add_power_button(Aml *scope)
   {
   Aml *dev = aml_device(ACPI_POWER_BUTTON_DEVICE);
   aml_append(dev, aml_name_decl("_HID", aml_string("PNP0C0C")));
-aml_append(dev, aml_name_decl("_ADR", aml_int(0)));
   aml_append(dev, aml_name_decl("_UID", aml_int(0)));
   aml_append(scope, dev);
   }
diff --git a/tests/data/acpi/virt/DSDT b/tests/data/acpi/virt/DSDT
index 
b5895cb22446860a0b9be3d32ec856feb388be4c..a759ff739a071d5fbf50519a6aea296e5e0f1e0c
 100644
GIT binary patch
delta 72
zcmbO@f$>*ABbQ6COUN_q{66S<_BT5Bh^tIeLL4lL8ZSqD=gU!!5x$Pt+
c1HyxxIO07#U3dfh0t}oDoEbRcLp@y>07w882mk;8

delta 94
zcmey>@cBbQ6CONgKc0|V26iCof5J#`b+RhV2^Ci+-%al|{i1o1F1FmP^cRp4ao
tnY@hCfEg`7$S;oxFTNc#soEyoaX?Z-8HbfwO@#16Tu)4E1zj005fm7mWY_

diff --git a/tests/data/acpi/virt/DSDT.memhp b/tests/data/acpi/virt/DSDT.memhp
index 
69ad844f65d047973a3e55198beecd45a35b8fce..6e5cc61977e4cd24f765fec0693f75a528c144c1
 100644
GIT binary patch
delta 72
zcmX>#i*fTTMlP3Nmk?uL1_q|eiCof5eHSLGt1wzk^tIeLL4lL8ZSqD=gU!!5U7RH)
c1HyxxIO07#U3dfh0t}oDoEbRcLp@y>03)CjmjD0&

delta 94
zcmdlyi}BPfMlP3Nmk=*s1_q}3iCof5t(PXMt1!8;O!Tqj;)r*23F2X3VBp-?s=&$E
tGkF=O0W(l&^JPwVXL*ABbQ6COUN_q{66S<_BT5Bh^tIeLL4lL8ZSqD=gU!!5x$Pt+
c1HyxxIO07#U3dfh0t}oDoEbRcLp@y>07w882mk;8

delta 94
zcmey>@cBbQ6CONgKc0|V26iCof5J#`b+RhV2^Ci+-%al|{i1o1F1FmP^cRp4ao
tnY@hCfEg`7$S;oxFTNc#soEyoaX?Z-8HbfwO@#16Tu)4E1zj005fm7mWY_


.




.

Re: Semihosting, arm, riscv, ppc and common code

[Benjamin Herrenschmidt]

On Tue, 2020-01-14 at 09:59 +, Peter Maydell wrote:
> Note that semihosting is not a "here's a handy QEMU feature"
> thing. It's an architecture-specific API and ABI, which should
> be defined somewhere in a standard external to QEMU.

There is no such standard for powerpc today that I know of.

> You need to start by having a definition for PPC of what
> semihosting is. If you're starting from scratch there, there
> are some important things you should do differently to Arm --
> there is no benefit to repeating the mistakes of API definition
> that we made! Most notably, you want to specify and require
> that any unrecognized semihosting call function fails in a
> clean and detectable way; you also should have a semihosting
> function for "ask for a feature bit mask" so you don't need
> the silly magic-filename approach Arm had to go for. You
> also want to standardize what the errno values are, which Arm
> forgot to do and which makes the errno handling in the spec
> pretty useless.

Keith and I are somewhat of a different mind here. From the perspective
of the user of that API (picolibc is one), it's easier to deal with a
single one and have everybody inherit the same bugs.

Now I understand the point of wanting to fix the mistakes made but I
would suggest we do so by proposing extensions to the existing one to
do so.

> TLDR: don't start by writing code, start by writing the *API/ABI
> spec*.
> I tried to push the RISCV folks in this direction as well.

AFAIK they are still just doing what ARM does for the above reason.

Cheers,
Ben.

Re: Semihosting, arm, riscv, ppc and common code

[Benjamin Herrenschmidt]

On Tue, 2020-01-14 at 09:51 +, Alex Bennée wrote:
> > Well, one of the LCA talks wasn't that interesting so I started
> > doing
> > it and am almost done :-)
> > 
> > I'll look at doing something for arm, riscv and ppc and send
> > patches
> > once I get it working.
> 
> Cool. Are you considering linux-user as well or are these only things
> that make sense for system emulation?

There seem to be some linux-user stuff in there, I'm mostly considering
whatever ARM does today but we can certainly extend later.

The idea is to make sure ARM, RiscV and POWER use the same protocol and
code base to make picolibc (and others) life easier. Bug compatible :-)

Cheers,
Ben.

Re: [PATCH 0/3] linux-user: Implement x86_64 vsyscalls

[Paolo Bonzini]

On 14/01/20 22:09, Richard Henderson wrote:
> I vaguely remember someone (Paolo?) implementing something like
> this many years ago, but clearly it never got merged.

Nope, certainly not me.

> In any case, this emulation has been missing for too long.
> 
> 
> r~
> 
> 
> Richard Henderson (3):
>   target/i386: Renumber EXCP_SYSCALL
>   linux-user/i386: Split out gen_signal
>   linux-user/i386: Emulate x86_64 vsyscalls
> 
>  target/i386/cpu.h  |   6 +-
>  linux-user/i386/cpu_loop.c | 197 ++---
>  target/i386/translate.c|  16 ++-
>  3 files changed, 155 insertions(+), 64 deletions(-)
> 

Reviewed-by: Paolo Bonzini 

Re: [PATCH v28 22/22] qemu-doc.texi: Add RX section.

[Aleksandar Markovic]

On Sunday, January 12, 2020, Yoshinori Sato 
wrote:

> Signed-off-by: Yoshinori Sato 
> ---
>  qemu-doc.texi | 25 +
>  1 file changed, 25 insertions(+)
>
>
It would be nice if you provided an example of qemu command line invocation
that btings RX machine up (see nanomips section as example).

Also, you are missing the commit message. At least add a sentence
elaborating what you added in a more verbose fashion.

Yours,
Aleksandar



> diff --git a/qemu-doc.texi b/qemu-doc.texi
> index 39f950471f..81f76074c4 100644
> --- a/qemu-doc.texi
> +++ b/qemu-doc.texi
> @@ -1741,6 +1741,7 @@ differences are mentioned in the following sections.
>  * Microblaze System emulator::
>  * SH4 System emulator::
>  * Xtensa System emulator::
> +* RX System emulator::
>  @end menu
>
>  @node PowerPC System emulator
> @@ -2514,6 +2515,30 @@ so should only be used with trusted guest OS.
>
>  @c man end
>
> +@node RX System emulator
> +@section RX System emulator
> +@cindex system emulation (RX)
> +
> +Use the executable @file{qemu-system-rx} to simulate a Virtual RX target.
> +This target emulated following devices.
> +
> +@itemize @minus
> +@item
> +R5F562N8 MCU
> +@item
> +On-chip memory (ROM 512KB, RAM 96KB)
> +@item
> +Interrupt Control Unit (ICUa)
> +@item
> +8Bit Timer x 1CH (TMR0,1)
> +@item
> +Compare Match Timer x 2CH (CMT0,1)
> +@item
> +Serial Communication Interface x 1CH (SCI0)
> +@item
> +External memory 16MByte
> +@end itemize
> +
>  @node QEMU User space emulator
>  @chapter QEMU User space emulator
>
> --
> 2.20.1
>
>
>

Re: [PATCH v3 10/17] hw/arm/allwinner-h3: add Boot ROM support

[Niek Linnenbank]

On Tue, Jan 14, 2020 at 12:28 AM Philippe Mathieu-Daudé 
wrote:

> On 1/8/20 9:00 PM, Niek Linnenbank wrote:
> > A real Allwinner H3 SoC contains a Boot ROM which is the
> > first code that runs right after the SoC is powered on.
> > The Boot ROM is responsible for loading user code (e.g. a bootloader)
> > from any of the supported external devices and writing the downloaded
> > code to internal SRAM. After loading the SoC begins executing the code
> > written to SRAM. This commits adds emulation of the Boot ROM firmware
> > setup functionality by loading user code from SD card.
> >
> > Signed-off-by: Niek Linnenbank 
> > ---
> >   include/hw/arm/allwinner-h3.h | 23 +++
> >   hw/arm/allwinner-h3.c | 28 
> >   hw/arm/orangepi.c |  3 +++
> >   3 files changed, 54 insertions(+)
> >
> > diff --git a/include/hw/arm/allwinner-h3.h
> b/include/hw/arm/allwinner-h3.h
> > index 5d74cca28e..4b66227ac4 100644
> > --- a/include/hw/arm/allwinner-h3.h
> > +++ b/include/hw/arm/allwinner-h3.h
> > @@ -50,6 +50,7 @@
> >   #include "hw/sd/allwinner-sdhost.h"
> >   #include "hw/net/allwinner-sun8i-emac.h"
> >   #include "target/arm/cpu.h"
> > +#include "sysemu/block-backend.h"
> >
> >   /**
> >* Allwinner H3 device list
> > @@ -130,4 +131,26 @@ typedef struct AwH3State {
> >   MemoryRegion sram_c;
> >   } AwH3State;
> >
> > +/**
> > + * Emulate Boot ROM firmware setup functionality.
> > + *
> > + * A real Allwinner H3 SoC contains a Boot ROM
> > + * which is the first code that runs right after
> > + * the SoC is powered on. The Boot ROM is responsible
> > + * for loading user code (e.g. a bootloader) from any
> > + * of the supported external devices and writing the
> > + * downloaded code to internal SRAM. After loading the SoC
> > + * begins executing the code written to SRAM.
> > + *
> > + * This function emulates the Boot ROM by copying 32 KiB
> > + * of data from the given block device and writes it to
> > + * the start of the first internal SRAM memory.
> > + *
> > + * @s: Allwinner H3 state object pointer
> > + * @blk: Block backend device object pointer
> > + * @errp: Error object pointer for raising errors
> > + */
> > +void allwinner_h3_bootrom_setup(AwH3State *s, BlockBackend *blk,
> > +Error **errp);
> > +
> >   #endif /* HW_ARM_ALLWINNER_H3_H */
> > diff --git a/hw/arm/allwinner-h3.c b/hw/arm/allwinner-h3.c
> > index e692432b4e..e7b768ad5b 100644
> > --- a/hw/arm/allwinner-h3.c
> > +++ b/hw/arm/allwinner-h3.c
> > @@ -27,6 +27,7 @@
> >   #include "hw/char/serial.h"
> >   #include "hw/misc/unimp.h"
> >   #include "hw/usb/hcd-ehci.h"
> > +#include "hw/loader.h"
> >   #include "sysemu/sysemu.h"
> >   #include "hw/arm/allwinner-h3.h"
> >
> > @@ -168,6 +169,33 @@ enum {
> >   AW_H3_GIC_NUM_SPI   = 128
> >   };
> >
> > +void allwinner_h3_bootrom_setup(AwH3State *s, BlockBackend *blk, Error
> **errp)
> > +{
> > +uint8_t *buffer;
> > +int64_t rom_size = 32 * KiB;
>
> Why restrict to 32K? The A1 SRAM is 64K.
>

The reason is that the actual Boot ROM on the H3 also uses 32K:
https://linux-sunxi.org/BROM

See the 'U-Boot SPL Limitations' table at the end of the page.

You can see the comment in the table there regarding the 32 KiB:
  "Sizes larger than 32 KiB are rejected by the BROM. Exactly 32 KiB is
fine, as verified by writing a special pattern at the end of the SPL and
checking it in the SRAM."

Probably it would not harm to increase it to the full size of the SRAM, but
I tried to model
the behavior as close to the real hardware as possible.

Regards,
Niek


> > +
> > +int64_t blk_size = blk_getlength(blk);
> > +if (blk_size <= 0) {
> > +error_setg(errp, "%s: failed to get BlockBackend size",
> __func__);
> > +return;
> > +}
> > +
> > +if (rom_size > blk_size) {
> > +rom_size = blk_size;
> > +}
> > +
> > +buffer = g_new0(uint8_t, rom_size);
> > +if (blk_pread(blk, 8 * KiB, buffer, rom_size) < 0) {
> > +error_setg(errp, "%s: failed to read BlockBackend data",
> __func__);
> > +return;
> > +}
> > +
> > +rom_add_blob("allwinner-h3.bootrom", buffer, rom_size,
> > +  rom_size, s->memmap[AW_H3_SRAM_A1],
> > +  NULL, NULL, NULL, NULL, false);
> > +g_free(buffer);
> > +}
> > +
> >   static void allwinner_h3_init(Object *obj)
> >   {
> >   AwH3State *s = AW_H3(obj);
> > diff --git a/hw/arm/orangepi.c b/hw/arm/orangepi.c
> > index 0eb52eb813..b722f49485 100644
> > --- a/hw/arm/orangepi.c
> > +++ b/hw/arm/orangepi.c
> > @@ -93,6 +93,9 @@ static void orangepi_init(MachineState *machine)
> >   if (bios_name) {
> >   error_report("BIOS not supported for this machine");
> >   exit(1);
> > +} else if (!machine->kernel_filename && blk_is_available(blk)) {
> > +/* Use Boot ROM to copy data from SD card to SRAM */
> > +allwinner_h3_bootrom_setup(s->h3, blk, 

Re: [PATCH v28 17/22] hw/rx: RX Target hardware definition

[Aleksandar Markovic]

On Sunday, January 12, 2020, Yoshinori Sato 
wrote:

> rx62n - RX62N cpu.
> rx-virt - RX QEMU virtual target.
>
> v23 changes.
> Add missing includes.
>
> v21 changes.
> rx_load_image move to rx-virt.c
>
>
Hello, Yoshinori.


These lines:


> v23 changes.
> Add missing includes.
>
> v21 changes.
> rx_load_image move to rx-virt.c
>
>

should be moved further down, to be just above a section describing v19
changes.

The reson for that is that line with three dashes:

---

tells git that anything after that line is not a part of a commut message,
and at is what we desire: history is useful during review, but shoil net be
stored permanently as a part of a commit message.

Yours, Aleksandar




> Signed-off-by: Yoshinori Sato 
>
> Message-Id: <20190616142836.10614-17-ys...@users.sourceforge.jp>
> Tested-by: Philippe Mathieu-Daudé 
> Reviewed-by: Philippe Mathieu-Daudé 
> Message-Id: <20190607091116.49044-9-ys...@users.sourceforge.jp>
> Signed-off-by: Richard Henderson 
> [PMD: Use TYPE_RX62N_CPU, use #define for RX62N_NR_TMR/CMT/SCI,
>  renamed CPU -> MCU, device -> microcontroller]
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> v19: Fixed typo (Peter Maydell)
> Signed-off-by: Yoshinori Sato 
> ---
>  include/hw/rx/rx.h|   7 ++
>  include/hw/rx/rx62n.h |  91 
>  hw/rx/rx-virt.c   | 127 ++
>  hw/rx/rx62n.c | 239 ++
>  hw/rx/Kconfig |  14 +++
>  hw/rx/Makefile.objs   |   2 +
>  6 files changed, 480 insertions(+)
>  create mode 100644 include/hw/rx/rx.h
>  create mode 100644 include/hw/rx/rx62n.h
>  create mode 100644 hw/rx/rx-virt.c
>  create mode 100644 hw/rx/rx62n.c
>  create mode 100644 hw/rx/Kconfig
>  create mode 100644 hw/rx/Makefile.objs
>
> diff --git a/include/hw/rx/rx.h b/include/hw/rx/rx.h
> new file mode 100644
> index 00..ff5924b81f
> --- /dev/null
> +++ b/include/hw/rx/rx.h
> @@ -0,0 +1,7 @@
> +#ifndef QEMU_RX_H
> +#define QEMU_RX_H
> +/* Definitions for RX board emulation.  */
> +
> +#include "target/rx/cpu-qom.h"
> +
> +#endif
> diff --git a/include/hw/rx/rx62n.h b/include/hw/rx/rx62n.h
> new file mode 100644
> index 00..97ea8ddb8e
> --- /dev/null
> +++ b/include/hw/rx/rx62n.h
> @@ -0,0 +1,91 @@
> +/*
> + * RX62N MCU Object
> + *
> + * Datasheet: RX62N Group, RX621 Group User's Manual: Hardware
> + * (Rev.1.40 R01UH0033EJ0140)
> + *
> + * Copyright (c) 2019 Yoshinori Sato
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2 or later, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
> for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> along with
> + * this program.  If not, see .
> + */
> +
> +#ifndef HW_RX_RX62N_H
> +#define HW_RX_RX62N_H
> +
> +#include "hw/sysbus.h"
> +#include "hw/intc/rx_icu.h"
> +#include "hw/timer/renesas_tmr.h"
> +#include "hw/timer/renesas_cmt.h"
> +#include "hw/char/renesas_sci.h"
> +#include "target/rx/cpu.h"
> +#include "qemu/units.h"
> +
> +#define TYPE_RX62N "rx62n"
> +#define RX62N(obj) OBJECT_CHECK(RX62NState, (obj), TYPE_RX62N)
> +
> +#define RX62N_NR_TMR2
> +#define RX62N_NR_CMT2
> +#define RX62N_NR_SCI6
> +
> +typedef struct RX62NState {
> +SysBusDevice parent_obj;
> +
> +RXCPU cpu;
> +RXICUState icu;
> +RTMRState tmr[RX62N_NR_TMR];
> +RCMTState cmt[RX62N_NR_CMT];
> +RSCIState sci[RX62N_NR_SCI];
> +
> +MemoryRegion *sysmem;
> +bool kernel;
> +
> +MemoryRegion iram;
> +MemoryRegion iomem1;
> +MemoryRegion d_flash;
> +MemoryRegion iomem2;
> +MemoryRegion iomem3;
> +MemoryRegion c_flash;
> +qemu_irq irq[NR_IRQS];
> +} RX62NState;
> +
> +/*
> + * RX62N Peripheral Address
> + * See users manual section 5
> + */
> +#define RX62N_ICUBASE 0x00087000
> +#define RX62N_TMRBASE 0x00088200
> +#define RX62N_CMTBASE 0x00088000
> +#define RX62N_SCIBASE 0x00088240
> +
> +/*
> + * RX62N Peripheral IRQ
> + * See users manual section 11
> + */
> +#define RX62N_TMR_IRQBASE 174
> +#define RX62N_CMT_IRQBASE 28
> +#define RX62N_SCI_IRQBASE 214
> +
> +/*
> + * RX62N Internal Memory
> + * It is the value of R5F562N8.
> + * Please change the size for R5F562N7.
> + */
> +#define RX62N_IRAM_BASE 0x
> +#define RX62N_IRAM_SIZE (96 * KiB)
> +#define RX62N_DFLASH_BASE 0x0010
> +#define RX62N_DFLASH_SIZE (32 * KiB)
> +#define RX62N_CFLASH_BASE 0xfff8
> +#define RX62N_CFLASH_SIZE (512 * KiB)
> +
> +#define RX62N_PCLK (48 * 1000 * 1000)
> +#endif
> diff --git a/hw/rx/rx-virt.c b/hw/rx/rx-virt.c
> new file mode 100644
> index 00..4cfe2e3123
> --- /dev/null
> +++ 

[Bug 1859713] Re: ARM v8.3a pauth not working

[Richard Henderson]

** Changed in: qemu
   Status: New => Confirmed

** Changed in: qemu
 Assignee: (unassigned) => Richard Henderson (rth)

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

Title:
  ARM v8.3a pauth not working

Status in QEMU:
  Confirmed

Bug description:
  Host: Ubuntu 19.10 - x86_64 machine
  QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master)

  ARMV8.3 pauth is not working well.

  With a test code containing two pauth instructions:
  - paciasp that sign LR with A key and sp as context;
  - autiasp that verify the signature.

  Test:
  - Run the program and corrupt LR just before autiasp (ex 0x3e0400660 
instead of 0x3e00400664)

  Expected:
  - autiasp places an invalid pointer in LR

  Result:
  - autiasp successfully auth the pointer and places 0x0400660 in LR.

  Further explanations:
  Adding traces in qemu code shows that "pauth_computepac" is not robust 
enough against truncating.
  With 0x3100400664 as input of pauth_auth, we obtain 
"0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
  With 0x310040008743ec as input of pauth (with same key), we obtain 
"0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
  Values of top_bit and bottom_bit are strictly the same and it should not.

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

Re: [PATCH v3 06/17] hw/arm/allwinner: add CPU Configuration module

[Niek Linnenbank]

On Tue, Jan 14, 2020 at 12:14 AM Philippe Mathieu-Daudé 
wrote:

> On 1/8/20 9:00 PM, Niek Linnenbank wrote:
> > Various Allwinner System on Chip designs contain multiple processors
> > that can be configured and reset using the generic CPU Configuration
> > module interface. This commit adds support for the Allwinner CPU
> > configuration interface which emulates the following features:
> >
> >   * CPU reset
> >   * CPU status
> >   * Shared 64-bit timer
> >
> > Signed-off-by: Niek Linnenbank 
> > ---
> >   include/hw/arm/allwinner-h3.h  |   3 +
> >   include/hw/misc/allwinner-cpucfg.h |  54 ++
> >   hw/arm/allwinner-h3.c  |   9 +-
> >   hw/misc/allwinner-cpucfg.c | 282 +
> >   hw/misc/Makefile.objs  |   1 +
> >   hw/misc/trace-events   |   5 +
> >   6 files changed, 353 insertions(+), 1 deletion(-)
> >   create mode 100644 include/hw/misc/allwinner-cpucfg.h
> >   create mode 100644 hw/misc/allwinner-cpucfg.c
> >
> > diff --git a/include/hw/arm/allwinner-h3.h
> b/include/hw/arm/allwinner-h3.h
> > index 26706f4fa6..5a25a92eae 100644
> > --- a/include/hw/arm/allwinner-h3.h
> > +++ b/include/hw/arm/allwinner-h3.h
> > @@ -44,6 +44,7 @@
> >   #include "hw/timer/allwinner-a10-pit.h"
> >   #include "hw/intc/arm_gic.h"
> >   #include "hw/misc/allwinner-h3-ccu.h"
> > +#include "hw/misc/allwinner-cpucfg.h"
> >   #include "hw/misc/allwinner-h3-sysctrl.h"
> >   #include "target/arm/cpu.h"
> >
> > @@ -80,6 +81,7 @@ enum {
> >   AW_H3_GIC_CPU,
> >   AW_H3_GIC_HYP,
> >   AW_H3_GIC_VCPU,
> > +AW_H3_CPUCFG,
> >   AW_H3_SDRAM
> >   };
> >
> > @@ -111,6 +113,7 @@ typedef struct AwH3State {
> >   const hwaddr *memmap;
> >   AwA10PITState timer;
> >   AwH3ClockCtlState ccu;
> > +AwCpuCfgState cpucfg;
> >   AwH3SysCtrlState sysctrl;
> >   GICState gic;
> >   MemoryRegion sram_a1;
> > diff --git a/include/hw/misc/allwinner-cpucfg.h
> b/include/hw/misc/allwinner-cpucfg.h
> > new file mode 100644
> > index 00..2c0e5b7e03
> > --- /dev/null
> > +++ b/include/hw/misc/allwinner-cpucfg.h
> > @@ -0,0 +1,54 @@
> > +/*
> > + * Allwinner CPU Configuration Module emulation
> > + *
> > + * Copyright (C) 2019 Niek Linnenbank 
> > + *
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation, either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program.  If not, see  >.
> > + */
> > +
> > +#ifndef HW_MISC_ALLWINNER_CPUCFG_H
> > +#define HW_MISC_ALLWINNER_CPUCFG_H
> > +
> > +#include "qemu/osdep.h"
> > +#include "qom/object.h"
> > +#include "hw/sysbus.h"
> > +
> > +/**
> > + * Object model
> > + * @{
> > + */
> > +
> > +#define TYPE_AW_CPUCFG   "allwinner-cpucfg"
> > +#define AW_CPUCFG(obj) \
> > +OBJECT_CHECK(AwCpuCfgState, (obj), TYPE_AW_CPUCFG)
> > +
> > +/** @} */
> > +
> > +/**
> > + * Allwinner CPU Configuration Module instance state
> > + */
> > +typedef struct AwCpuCfgState {
> > +/*< private >*/
> > +SysBusDevice parent_obj;
> > +/*< public >*/
> > +
> > +MemoryRegion iomem;
> > +uint32_t gen_ctrl;
> > +uint32_t super_standby;
> > +uint32_t entry_addr;
> > +uint32_t counter_ctrl;
> > +
> > +} AwCpuCfgState;
> > +
> > +#endif /* HW_MISC_ALLWINNER_CPUCFG_H */
> > diff --git a/hw/arm/allwinner-h3.c b/hw/arm/allwinner-h3.c
> > index d261d7b2be..e9ad6d23df 100644
> > --- a/hw/arm/allwinner-h3.c
> > +++ b/hw/arm/allwinner-h3.c
> > @@ -54,6 +54,7 @@ const hwaddr allwinner_h3_memmap[] = {
> >   [AW_H3_GIC_CPU]= 0x01c82000,
> >   [AW_H3_GIC_HYP]= 0x01c84000,
> >   [AW_H3_GIC_VCPU]   = 0x01c86000,
> > +[AW_H3_CPUCFG] = 0x01f01c00,
> >   [AW_H3_SDRAM]  = 0x4000
> >   };
> >
> > @@ -120,7 +121,6 @@ struct AwH3Unimplemented {
> >   { "r_wdog",0x01f01000, 1 * KiB },
> >   { "r_prcm",0x01f01400, 1 * KiB },
> >   { "r_twd", 0x01f01800, 1 * KiB },
> > -{ "r_cpucfg",  0x01f01c00, 1 * KiB },
> >   { "r_cir-rx",  0x01f02000, 1 * KiB },
> >   { "r_twi", 0x01f02400, 1 * KiB },
> >   { "r_uart",0x01f02800, 1 * KiB },
> > @@ -193,6 +193,9 @@ static void allwinner_h3_init(Object *obj)
> >
> >   sysbus_init_child_obj(obj, "sysctrl", >sysctrl,
> sizeof(s->sysctrl),
> > TYPE_AW_H3_SYSCTRL);
> > +
> > +sysbus_init_child_obj(obj, "cpucfg", >cpucfg, sizeof(s->cpucfg),
> > +  

Re: [PATCH v3 12/17] hw/arm/allwinner: add RTC device support

[Niek Linnenbank]

On Tue, Jan 14, 2020 at 11:52 PM Niek Linnenbank 
wrote:

> Hi Philippe,
>
> On Mon, Jan 13, 2020 at 11:57 PM Philippe Mathieu-Daudé 
> wrote:
>
>> On 1/8/20 9:00 PM, Niek Linnenbank wrote:
>> > Allwinner System-on-Chips usually contain a Real Time Clock (RTC)
>> > for non-volatile system date and time keeping. This commit adds a
>> generic
>> > Allwinner RTC device that supports the RTC devices found in Allwinner
>> SoC
>> > family sun4i (A10), sun7i (A20) and sun6i and newer (A31, H2+, H3, etc).
>> > The following RTC functionality and features are implemented:
>> >
>> >   * Year-Month-Day read/write
>> >   * Hour-Minute-Second read/write
>> >   * General Purpose storage
>> >
>> > The following boards are extended with the RTC device:
>> >
>> >   * Cubieboard (hw/arm/cubieboard.c)
>> >   * Orange Pi PC (hw/arm/orangepi.c)
>> >
>> > Signed-off-by: Niek Linnenbank 
>> > ---
>> >   include/hw/arm/allwinner-a10.h |   4 +-
>> >   include/hw/arm/allwinner-h3.h  |   3 +
>> >   include/hw/rtc/allwinner-rtc.h | 129 +++
>> >   hw/arm/allwinner-a10.c |   7 +
>> >   hw/arm/allwinner-h3.c  |   9 +-
>> >   hw/rtc/allwinner-rtc.c | 386 +
>> >   hw/rtc/Makefile.objs   |   1 +
>> >   hw/rtc/trace-events|   4 +
>> >   8 files changed, 541 insertions(+), 2 deletions(-)
>> >   create mode 100644 include/hw/rtc/allwinner-rtc.h
>> >   create mode 100644 hw/rtc/allwinner-rtc.c
>> >
>> > diff --git a/include/hw/arm/allwinner-a10.h
>> b/include/hw/arm/allwinner-a10.h
>> > index 0e8250b244..81a16092e7 100644
>> > --- a/include/hw/arm/allwinner-a10.h
>> > +++ b/include/hw/arm/allwinner-a10.h
>> > @@ -9,6 +9,7 @@
>> >   #include "hw/net/allwinner_emac.h"
>> >   #include "hw/sd/allwinner-sdhost.h"
>> >   #include "hw/ide/ahci.h"
>> > +#include "hw/rtc/allwinner-rtc.h"
>> >
>> >   #include "target/arm/cpu.h"
>> >
>> > @@ -18,7 +19,7 @@
>> >   #define AW_A10_UART0_REG_BASE   0x01c28000
>> >   #define AW_A10_EMAC_BASE0x01c0b000
>> >   #define AW_A10_SATA_BASE0x01c18000
>> > -
>> > +#define AW_A10_RTC_BASE 0x01c20d00
>> >   #define AW_A10_SDRAM_BASE   0x4000
>> >
>> >   #define TYPE_AW_A10 "allwinner-a10"
>> > @@ -36,6 +37,7 @@ typedef struct AwA10State {
>> >   AwEmacState emac;
>> >   AllwinnerAHCIState sata;
>> >   AwSdHostState mmc0;
>> > +AwRtcState rtc;
>> >   MemoryRegion sram_a;
>> >   } AwA10State;
>> >
>> > diff --git a/include/hw/arm/allwinner-h3.h
>> b/include/hw/arm/allwinner-h3.h
>> > index d1b3d7ca67..1c275a34ed 100644
>> > --- a/include/hw/arm/allwinner-h3.h
>> > +++ b/include/hw/arm/allwinner-h3.h
>> > @@ -50,6 +50,7 @@
>> >   #include "hw/misc/allwinner-sid.h"
>> >   #include "hw/sd/allwinner-sdhost.h"
>> >   #include "hw/net/allwinner-sun8i-emac.h"
>> > +#include "hw/rtc/allwinner-rtc.h"
>> >   #include "target/arm/cpu.h"
>> >   #include "sysemu/block-backend.h"
>> >
>> > @@ -92,6 +93,7 @@ enum {
>> >   AW_H3_GIC_CPU,
>> >   AW_H3_GIC_HYP,
>> >   AW_H3_GIC_VCPU,
>> > +AW_H3_RTC,
>> >   AW_H3_CPUCFG,
>> >   AW_H3_SDRAM
>> >   };
>> > @@ -130,6 +132,7 @@ typedef struct AwH3State {
>> >   AwSidState sid;
>> >   AwSdHostState mmc0;
>> >   AwSun8iEmacState emac;
>> > +AwRtcState rtc;
>> >   GICState gic;
>> >   MemoryRegion sram_a1;
>> >   MemoryRegion sram_a2;
>> > diff --git a/include/hw/rtc/allwinner-rtc.h
>> b/include/hw/rtc/allwinner-rtc.h
>> > new file mode 100644
>> > index 00..e29dfc775f
>> > --- /dev/null
>> > +++ b/include/hw/rtc/allwinner-rtc.h
>> > @@ -0,0 +1,129 @@
>> > +/*
>> > + * Allwinner Real Time Clock emulation
>> > + *
>> > + * Copyright (C) 2019 Niek Linnenbank 
>> > + *
>> > + * This program is free software: you can redistribute it and/or modify
>> > + * it under the terms of the GNU General Public License as published by
>> > + * the Free Software Foundation, either version 2 of the License, or
>> > + * (at your option) any later version.
>> > + *
>> > + * This program is distributed in the hope that it will be useful,
>> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> > + * GNU General Public License for more details.
>> > + *
>> > + * You should have received a copy of the GNU General Public License
>> > + * along with this program.  If not, see > >.
>> > + */
>> > +
>> > +#ifndef HW_MISC_ALLWINNER_RTC_H
>> > +#define HW_MISC_ALLWINNER_RTC_H
>> > +
>> > +#include "qemu/osdep.h"
>> > +#include "qom/object.h"
>> > +#include "hw/sysbus.h"
>> > +
>> > +/**
>> > + * Constants
>> > + * @{
>> > + */
>> > +
>> > +/** Highest register address used by RTC device */
>> > +#define AW_RTC_REGS_MAXADDR (0x1F4)
>>
>> I'd start using 0x200 here so in case new SoC use registers in this
>> block range (or undocumented reg) so we don't have to modify
>> allwinner_rtc_vmstate.
>>
>
> Good point, 

Re: [PATCH v3 12/17] hw/arm/allwinner: add RTC device support

[Niek Linnenbank]

Hi Philippe,

On Mon, Jan 13, 2020 at 11:57 PM Philippe Mathieu-Daudé 
wrote:

> On 1/8/20 9:00 PM, Niek Linnenbank wrote:
> > Allwinner System-on-Chips usually contain a Real Time Clock (RTC)
> > for non-volatile system date and time keeping. This commit adds a generic
> > Allwinner RTC device that supports the RTC devices found in Allwinner SoC
> > family sun4i (A10), sun7i (A20) and sun6i and newer (A31, H2+, H3, etc).
> > The following RTC functionality and features are implemented:
> >
> >   * Year-Month-Day read/write
> >   * Hour-Minute-Second read/write
> >   * General Purpose storage
> >
> > The following boards are extended with the RTC device:
> >
> >   * Cubieboard (hw/arm/cubieboard.c)
> >   * Orange Pi PC (hw/arm/orangepi.c)
> >
> > Signed-off-by: Niek Linnenbank 
> > ---
> >   include/hw/arm/allwinner-a10.h |   4 +-
> >   include/hw/arm/allwinner-h3.h  |   3 +
> >   include/hw/rtc/allwinner-rtc.h | 129 +++
> >   hw/arm/allwinner-a10.c |   7 +
> >   hw/arm/allwinner-h3.c  |   9 +-
> >   hw/rtc/allwinner-rtc.c | 386 +
> >   hw/rtc/Makefile.objs   |   1 +
> >   hw/rtc/trace-events|   4 +
> >   8 files changed, 541 insertions(+), 2 deletions(-)
> >   create mode 100644 include/hw/rtc/allwinner-rtc.h
> >   create mode 100644 hw/rtc/allwinner-rtc.c
> >
> > diff --git a/include/hw/arm/allwinner-a10.h
> b/include/hw/arm/allwinner-a10.h
> > index 0e8250b244..81a16092e7 100644
> > --- a/include/hw/arm/allwinner-a10.h
> > +++ b/include/hw/arm/allwinner-a10.h
> > @@ -9,6 +9,7 @@
> >   #include "hw/net/allwinner_emac.h"
> >   #include "hw/sd/allwinner-sdhost.h"
> >   #include "hw/ide/ahci.h"
> > +#include "hw/rtc/allwinner-rtc.h"
> >
> >   #include "target/arm/cpu.h"
> >
> > @@ -18,7 +19,7 @@
> >   #define AW_A10_UART0_REG_BASE   0x01c28000
> >   #define AW_A10_EMAC_BASE0x01c0b000
> >   #define AW_A10_SATA_BASE0x01c18000
> > -
> > +#define AW_A10_RTC_BASE 0x01c20d00
> >   #define AW_A10_SDRAM_BASE   0x4000
> >
> >   #define TYPE_AW_A10 "allwinner-a10"
> > @@ -36,6 +37,7 @@ typedef struct AwA10State {
> >   AwEmacState emac;
> >   AllwinnerAHCIState sata;
> >   AwSdHostState mmc0;
> > +AwRtcState rtc;
> >   MemoryRegion sram_a;
> >   } AwA10State;
> >
> > diff --git a/include/hw/arm/allwinner-h3.h
> b/include/hw/arm/allwinner-h3.h
> > index d1b3d7ca67..1c275a34ed 100644
> > --- a/include/hw/arm/allwinner-h3.h
> > +++ b/include/hw/arm/allwinner-h3.h
> > @@ -50,6 +50,7 @@
> >   #include "hw/misc/allwinner-sid.h"
> >   #include "hw/sd/allwinner-sdhost.h"
> >   #include "hw/net/allwinner-sun8i-emac.h"
> > +#include "hw/rtc/allwinner-rtc.h"
> >   #include "target/arm/cpu.h"
> >   #include "sysemu/block-backend.h"
> >
> > @@ -92,6 +93,7 @@ enum {
> >   AW_H3_GIC_CPU,
> >   AW_H3_GIC_HYP,
> >   AW_H3_GIC_VCPU,
> > +AW_H3_RTC,
> >   AW_H3_CPUCFG,
> >   AW_H3_SDRAM
> >   };
> > @@ -130,6 +132,7 @@ typedef struct AwH3State {
> >   AwSidState sid;
> >   AwSdHostState mmc0;
> >   AwSun8iEmacState emac;
> > +AwRtcState rtc;
> >   GICState gic;
> >   MemoryRegion sram_a1;
> >   MemoryRegion sram_a2;
> > diff --git a/include/hw/rtc/allwinner-rtc.h
> b/include/hw/rtc/allwinner-rtc.h
> > new file mode 100644
> > index 00..e29dfc775f
> > --- /dev/null
> > +++ b/include/hw/rtc/allwinner-rtc.h
> > @@ -0,0 +1,129 @@
> > +/*
> > + * Allwinner Real Time Clock emulation
> > + *
> > + * Copyright (C) 2019 Niek Linnenbank 
> > + *
> > + * This program is free software: you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation, either version 2 of the License, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program.  If not, see  >.
> > + */
> > +
> > +#ifndef HW_MISC_ALLWINNER_RTC_H
> > +#define HW_MISC_ALLWINNER_RTC_H
> > +
> > +#include "qemu/osdep.h"
> > +#include "qom/object.h"
> > +#include "hw/sysbus.h"
> > +
> > +/**
> > + * Constants
> > + * @{
> > + */
> > +
> > +/** Highest register address used by RTC device */
> > +#define AW_RTC_REGS_MAXADDR (0x1F4)
>
> I'd start using 0x200 here so in case new SoC use registers in this
> block range (or undocumented reg) so we don't have to modify
> allwinner_rtc_vmstate.
>

Good point, I'll change it to 0x200.


> > +
> > +/** Total number of known registers */
> > +#define AW_RTC_REGS_NUM (AW_RTC_REGS_MAXADDR / sizeof(uint32_t))
> > +
> > +/** @} */
> > +
> > +/**
> > + * Object 

[Bug 1859723] [NEW] Qemu ungrabs before cursor reaches border

[Nils ANDRÉ-CHANG]

Public bug reported:

This was first reported
https://bugzilla.redhat.com/show_bug.cgi?id=1285378

video: https://peertube.co.uk/videos/watch/fedaa432-79ef-4d30-bd0e-
26c806e48db0

version: QEMU emulator version 4.2.0

** 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/1859723

Title:
  Qemu ungrabs before cursor reaches border

Status in QEMU:
  New

Bug description:
  This was first reported
  https://bugzilla.redhat.com/show_bug.cgi?id=1285378

  video: https://peertube.co.uk/videos/watch/fedaa432-79ef-4d30-bd0e-
  26c806e48db0

  version: QEMU emulator version 4.2.0

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

Re: [RFC PATCH] hw/arm/virt: Support NMI injection

[Gavin Shan]

On 12/19/19 3:06 PM, Gavin Shan wrote:

This supports NMI injection for virtual machine and currently it's only
supported on GICv3 controller, which is emulated by qemu or host kernel.
The design is highlighted as below:

* The NMI is identified by its priority (0x20). In the guest (linux)
  kernel, the GICC_PMR is set to 0x80, to block all interrupts except
  the NMIs when the external interrupt is disabled. It means the FIQ
  and IRQ bit in PSTATE isn't touched when the functionality (NMI) is
  functional.
* LPIs aren't considered as NMIs because of their nature. It means NMI
  is either SPI or PPI. Besides, the NMIs are injected in round-robin
  fashion is there are multiple NMIs existing.
* When the GICv3 controller is emulated by qemu, the interrupt states
  (e.g. enabled, priority) is fetched from the corresponding data struct
  directly. However, we have to pause all CPUs to fetch the interrupt
  states from host in advance if the GICv3 controller is emulated by
  host.

The testing scenario is to tweak guest (linux) kernel where the pl011 SPI
can be enabled as NMI by request_nmi(). Check "/proc/interrupts" after injecting
several NMIs, to see if the interrupt count is increased or not. The result
is just as expected.

Signed-off-by: Gavin Shan 
---
  hw/arm/virt.c  | 24 
  hw/intc/arm_gicv3.c| 76 
  hw/intc/arm_gicv3_kvm.c| 92 ++
  include/hw/intc/arm_gicv3_common.h |  2 +
  4 files changed, 194 insertions(+)



Peter, could you please take a look when you have free time? Thanks in advance
for your comments :)

Thanks,
Gavin


diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 39ab5f47e0..fc58ee70b4 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -71,6 +71,8 @@
  #include "hw/mem/pc-dimm.h"
  #include "hw/mem/nvdimm.h"
  #include "hw/acpi/generic_event_device.h"
+#include "hw/nmi.h"
+#include "hw/intc/arm_gicv3.h"
  
  #define DEFINE_VIRT_MACHINE_LATEST(major, minor, latest) \

  static void virt_##major##_##minor##_class_init(ObjectClass *oc, \
@@ -1980,6 +1982,25 @@ static void 
virt_machine_device_unplug_request_cb(HotplugHandler *hotplug_dev,
 " type: %s", object_get_typename(OBJECT(dev)));
  }
  
+static void virt_nmi(NMIState *n, int cpu_index, Error **errp)

+{
+VirtMachineState *vms = VIRT_MACHINE(n);
+ARMGICv3CommonClass *agcc;
+
+if (vms->gic_version != 3) {
+error_setg(errp, "NMI is only supported by GICv3");
+return;
+}
+
+agcc = ARM_GICV3_COMMON_GET_CLASS(vms->gic);
+if (agcc->inject_nmi) {
+agcc->inject_nmi(vms->gic, cpu_index, errp);
+} else {
+error_setg(errp, "NMI injection isn't supported by %s",
+   object_get_typename(OBJECT(vms->gic)));
+}
+}
+
  static HotplugHandler *virt_machine_get_hotplug_handler(MachineState *machine,
  DeviceState *dev)
  {
@@ -2025,6 +2046,7 @@ static void virt_machine_class_init(ObjectClass *oc, void 
*data)
  {
  MachineClass *mc = MACHINE_CLASS(oc);
  HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
+NMIClass *nc = NMI_CLASS(oc);
  
  mc->init = machvirt_init;

  /* Start with max_cpus set to 512, which is the maximum supported by KVM.
@@ -2051,6 +2073,7 @@ static void virt_machine_class_init(ObjectClass *oc, void 
*data)
  hc->pre_plug = virt_machine_device_pre_plug_cb;
  hc->plug = virt_machine_device_plug_cb;
  hc->unplug_request = virt_machine_device_unplug_request_cb;
+nc->nmi_monitor_handler = virt_nmi;
  mc->numa_mem_supported = true;
  mc->auto_enable_numa_with_memhp = true;
  }
@@ -2136,6 +2159,7 @@ static const TypeInfo virt_machine_info = {
  .instance_init = virt_instance_init,
  .interfaces = (InterfaceInfo[]) {
   { TYPE_HOTPLUG_HANDLER },
+ { TYPE_NMI },
   { }
  },
  };
diff --git a/hw/intc/arm_gicv3.c b/hw/intc/arm_gicv3.c
index 66eaa97198..d3409cb6ef 100644
--- a/hw/intc/arm_gicv3.c
+++ b/hw/intc/arm_gicv3.c
@@ -338,6 +338,81 @@ static void gicv3_set_irq(void *opaque, int irq, int level)
  }
  }
  
+static bool arm_gicv3_inject_nmi_once(GICv3State*s, int start, int end)

+{
+GICv3CPUState *cs;
+int irq_count = (s->num_irq + (GIC_INTERNAL * (s->num_cpu - 1)));
+int i, cpu, irq;
+
+/* SPIs */
+for (i = start; (i < end) && (i < (s->num_irq - GIC_INTERNAL)); i++) {
+if (gicv3_gicd_enabled_test(s, i + GIC_INTERNAL) &&
+s->gicd_ipriority[i + GIC_INTERNAL] == 0x20) {
+
+/*
+ * Reset the level and toggling the pending bit will ensure
+ * the interrupt is queued.
+ */
+if (gicv3_gicd_level_test(s, i + GIC_INTERNAL)) {
+gicv3_set_irq(s, i, false);
+}
+
+gicv3_gicd_pending_set(s, i + GIC_INTERNAL);
+ 

Re: [PATCH] qcow2: Use a GString in report_unsupported_feature()

[Alex Bennée]

Philippe Mathieu-Daudé  writes:

> On 1/14/20 7:08 PM, Alex Bennée wrote:
>> Alberto Garcia  writes:
>> 
>>> This is a bit more efficient than having to allocate and free memory
>>> for each item.
>>>
>>> The default size (60) is enough for all the existing incompatible
>>> features.
>>>
>>> Suggested-by: Philippe Mathieu-Daudé 
>>> Signed-off-by: Alberto Garcia 
>>> ---
>>>   block/qcow2.c | 24 
>>>   1 file changed, 12 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/block/qcow2.c b/block/qcow2.c
>>> index cef9d72b3a..ecf6827420 100644
>>> --- a/block/qcow2.c
>>> +++ b/block/qcow2.c
>>> @@ -453,16 +453,15 @@ static void 
>>> cleanup_unknown_header_ext(BlockDriverState *bs)
>>>   static void report_unsupported_feature(Error **errp, Qcow2Feature *table,
>>>  uint64_t mask)
>>>   {
>>> -char *features = g_strdup("");
>>> -char *old;
>>> +GString *features = g_string_sized_new(60);
>> g_autoptr(GString) features = g_string_sized_new(60);
>> will save you the clean-up later.
>
> Does this work with g_string_free() too?

It does:

static inline void g_autoptr_cleanup_gstring_free (GString *string)
{
if (string)
   g_string_free (string, TRUE);
}

If you want to keep the allocated string but drop the GString you are
still best doing that yourself.

>
>>> while (table && table->name[0] != '\0') {
>>>   if (table->type == QCOW2_FEAT_TYPE_INCOMPATIBLE) {
>>>   if (mask & (1ULL << table->bit)) {
>>> -old = features;
>>> -features = g_strdup_printf("%s%s%.46s", old, *old ? ", " : 
>>> "",
>>> -   table->name);
>>> -g_free(old);
>>> +if (features->len > 0) {
>>> +g_string_append(features, ", ");
>>> +}
>>> +g_string_append_printf(features, "%.46s",
>>>   table->name);
>> We have a number of cases of this sort of idiom in the code base. I
>> wonder if it calls for a utility function:
>> qemu_append_with_sep(features, ", ", "%.46s", table->name)
>
> Good idea for https://wiki.qemu.org/Contribute/BiteSizedTasks
>
>> Anyway not mandatory for this patch so with the autoptr fix:
>> Reviewed-by: Alex Bennée 
>> 
>>>   mask &= ~(1ULL << table->bit);
>>>   }
>>>   }
>>> @@ -470,14 +469,15 @@ static void report_unsupported_feature(Error **errp, 
>>> Qcow2Feature *table,
>>>   }
>>> if (mask) {
>>> -old = features;
>>> -features = g_strdup_printf("%s%sUnknown incompatible feature: %" 
>>> PRIx64,
>>> -   old, *old ? ", " : "", mask);
>>> -g_free(old);
>>> +if (features->len > 0) {
>>> +g_string_append(features, ", ");
>>> +}
>>> +g_string_append_printf(features,
>>> +   "Unknown incompatible feature: %" PRIx64, 
>>> mask);
>>>   }
>>>   -error_setg(errp, "Unsupported qcow2 feature(s): %s",
>>> features);
>>> -g_free(features);
>>> +error_setg(errp, "Unsupported qcow2 feature(s): %s", features->str);
>>> +g_string_free(features, TRUE);
>>>   }
>>> /*
>> 


-- 
Alex Bennée

[Bug 1859713] [NEW] ARM v8.3a pauth not working

[Adrien Grassein]

Public bug reported:

Host: Ubuntu 19.10 - x86_64 machine
QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master)

ARMV8.3 pauth is not working well.

With a test code containing two pauth instructions:
- paciasp that sign LR with A key and sp as context;
- autiasp that verify the signature.

Test:
- Run the program and corrupt LR just before autiasp (ex 0x3e0400660 
instead of 0x3e00400664)

Expected:
- autiasp places an invalid pointer in LR

Result:
- autiasp successfully auth the pointer and places 0x0400660 in LR.

Further explanations:
Adding traces in qemu code shows that "pauth_computepac" is not robust 
enough against truncating.
With 0x3100400664 as input of pauth_auth, we obtain 
"0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
With 0x310040008743ec as input of pauth (with same key), we obtain 
"0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
Values of top_bit and bottom_bit are strictly the same and it should not.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: arm

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

Title:
  ARM v8.3a pauth not working

Status in QEMU:
  New

Bug description:
  Host: Ubuntu 19.10 - x86_64 machine
  QEMU version: 3a63b24a1bbf166e6f455fe43a6bbd8dea413d92 (master)

  ARMV8.3 pauth is not working well.

  With a test code containing two pauth instructions:
  - paciasp that sign LR with A key and sp as context;
  - autiasp that verify the signature.

  Test:
  - Run the program and corrupt LR just before autiasp (ex 0x3e0400660 
instead of 0x3e00400664)

  Expected:
  - autiasp places an invalid pointer in LR

  Result:
  - autiasp successfully auth the pointer and places 0x0400660 in LR.

  Further explanations:
  Adding traces in qemu code shows that "pauth_computepac" is not robust 
enough against truncating.
  With 0x3100400664 as input of pauth_auth, we obtain 
"0x55b1d65b2c138e14" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
  With 0x310040008743ec as input of pauth (with same key), we obtain 
"0x55b1d65b2c138ef4" for PAC, "0x30" for bot_bit and "0x38" for top_bit.
  Values of top_bit and bottom_bit are strictly the same and it should not.

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

Re: [PATCH 00/13] LUKS: encryption slot management using amend interface

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200114193350.10830-1-mlevi...@redhat.com/



Hi,

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

Subject: [PATCH 00/13] LUKS: encryption slot management using amend interface
Type: series
Message-id: 20200114193350.10830-1-mlevi...@redhat.com

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

Switched to a new branch 'test'
c97e00f iotests: add tests for blockdev-amend
005f7d8 block/qcow2: implement blockdev-amend
fcf block/crypto: implement blockdev-amend
97610b5 block: add generic infrastructure for x-blockdev-amend qmp command
b93e775 qemu-iotests: qemu-img tests for luks key management
9730684 iotests: filter few more luks specific create options
f98c145 qcow2: extend qemu-img amend interface with crypto options
dd5bc1c block/crypto: implement the encryption key management
ad24636 block/crypto: rename two functions
88f372b block: amend: separate amend and create options for qemu-img
e9720f3 block: amend: add 'force' option
d96c666 qcrypto-luks: implement encryption key management
c41fba3 qcrypto: add generic infrastructure for crypto options amendment

=== OUTPUT BEGIN ===
1/13 Checking commit c41fba3b83a1 (qcrypto: add generic infrastructure for 
crypto options amendment)
2/13 Checking commit d96c6663e39d (qcrypto-luks: implement encryption key 
management)
3/13 Checking commit e9720f380038 (block: amend: add 'force' option)
4/13 Checking commit 88f372b238fc (block: amend: separate amend and create 
options for qemu-img)
ERROR: Macros with multiple statements should be enclosed in a do - while loop
#30: FILE: block/qcow2.c:5448:
+#define QCOW_COMMON_OPTIONS \
+{   \
+.name = BLOCK_OPT_SIZE, \
+.type = QEMU_OPT_SIZE,  \
+.help = "Virtual disk size" \
+},  \
+{   \
+.name = BLOCK_OPT_COMPAT_LEVEL, \
+.type = QEMU_OPT_STRING,\
+.help = "Compatibility level (v2 [0.10] or v3 [1.1])"   \
+},  \
+{   \
+.name = BLOCK_OPT_BACKING_FILE, \
+.type = QEMU_OPT_STRING,\
+.help = "File name of a base image" \
+},  \
+{   \
+.name = BLOCK_OPT_BACKING_FMT,  \
+.type = QEMU_OPT_STRING,\
+.help = "Image format of the base image"\
+},  \
+{   \
+.name = BLOCK_OPT_DATA_FILE,\
+.type = QEMU_OPT_STRING,\
+.help = "File name of an external data file"\
+},  \
+{   \
+.name = BLOCK_OPT_DATA_FILE_RAW,\
+.type = QEMU_OPT_BOOL,  \
+.help = "The external data file must stay valid "   \
+"as a raw image"\
+},  \
+{   \
+.name = BLOCK_OPT_ENCRYPT,  \
+.type = QEMU_OPT_BOOL,  \
+.help = "Encrypt the image with format 'aes'. (Deprecated " \
+"in favor of " BLOCK_OPT_ENCRYPT_FORMAT "=aes)",\
+},  \
+{   \
+.name = BLOCK_OPT_ENCRYPT_FORMAT,   \
+.type = QEMU_OPT_STRING,\
+.help = "Encrypt the image, format choices: 'aes', 'luks'", \
+},  \
+BLOCK_CRYPTO_OPT_DEF_KEY_SECRET("encrypt.", \
+   

Re: [PATCH 00/13] LUKS: encryption slot management using amend interface

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200114193350.10830-1-mlevi...@redhat.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

Not run: 301 303
Failures: 049 300
Failed 2 of 110 iotests
make: *** [check-tests/check-block.sh] Error 1
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 662, in 
sys.exit(main())
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=1fad358ccc2746a4b0095e3abd7d4c78', '-u', 
'1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-lks33yi2/src/docker-src.2020-01-14-16.05.10.20352:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=1fad358ccc2746a4b0095e3abd7d4c78
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-lks33yi2/src'
make: *** [docker-run-test-quick@centos7] Error 2

real11m29.420s
user0m8.596s


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

[PATCH 3/3] linux-user/i386: Emulate x86_64 vsyscalls

[Richard Henderson]

Notice the magic page during translate, much like we already
do for the arm32 commpage.  At runtime, raise an exception to
return cpu_loop for emulation.

Signed-off-by: Richard Henderson 
---
 target/i386/cpu.h  |   1 +
 linux-user/i386/cpu_loop.c | 104 +
 target/i386/translate.c|  16 +-
 3 files changed, 120 insertions(+), 1 deletion(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 164d038d1f..3fb2d2a986 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1000,6 +1000,7 @@ typedef uint64_t FeatureWordArray[FEATURE_WORDS];
 
 #define EXCP_VMEXIT 0x100 /* only for system emulation */
 #define EXCP_SYSCALL0x101 /* only for user emulation */
+#define EXCP_VSYSCALL   0x102 /* only for user emulation */
 
 /* i386-specific interrupt pending bits.  */
 #define CPU_INTERRUPT_POLL  CPU_INTERRUPT_TGT_EXT_1
diff --git a/linux-user/i386/cpu_loop.c b/linux-user/i386/cpu_loop.c
index e217cca5ee..8b7c9f7337 100644
--- a/linux-user/i386/cpu_loop.c
+++ b/linux-user/i386/cpu_loop.c
@@ -92,6 +92,105 @@ static void gen_signal(CPUX86State *env, int sig, int code, 
abi_ptr addr)
 queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
 }
 
+#ifdef TARGET_X86_64
+static bool write_ok_or_segv(CPUX86State *env, abi_ptr addr, size_t len)
+{
+/*
+ * For all the vsyscalls, NULL means "don't write anything" not
+ * "write it at address 0".
+ */
+if (addr == 0 || access_ok(VERIFY_WRITE, addr, len)) {
+return true;
+}
+
+gen_signal(env, TARGET_SIGSEGV, TARGET_SEGV_MAPERR, addr);
+return false;
+}
+
+/*
+ * Since v3.1, the kernel traps and emulates the vsyscall page.
+ * Entry points other than the official generate SIGSEGV.
+ */
+static void emulate_vsyscall(CPUX86State *env)
+{
+int syscall;
+abi_ulong ret;
+uint64_t caller;
+
+/*
+ * Validate the entry point.  We have already validated the page
+ * during translation, now verify the offset.
+ */
+switch (env->eip & ~TARGET_PAGE_MASK) {
+case 0x000:
+syscall = TARGET_NR_gettimeofday;
+break;
+case 0x400:
+syscall = TARGET_NR_time;
+break;
+case 0x800:
+syscall = TARGET_NR_getcpu;
+break;
+default:
+sigsegv:
+/* Like force_sig(SIGSEGV).  */
+gen_signal(env, TARGET_SIGSEGV, TARGET_SI_KERNEL, 0);
+return;
+}
+
+/*
+ * Validate the return address.
+ * Note that the kernel treats this the same as an invalid entry point.
+ */
+if (get_user_u64(caller, env->regs[R_ESP])) {
+goto sigsegv;
+}
+
+/*
+ * Validate the the pointer arguments.
+ */
+switch (syscall) {
+case TARGET_NR_gettimeofday:
+if (!write_ok_or_segv(env, env->regs[R_EDI],
+  sizeof(struct target_timeval)) ||
+!write_ok_or_segv(env, env->regs[R_ESI],
+  sizeof(struct target_timezone))) {
+return;
+}
+break;
+case TARGET_NR_time:
+if (!write_ok_or_segv(env, env->regs[R_EDI], sizeof(abi_long))) {
+return;
+}
+break;
+case TARGET_NR_getcpu:
+if (!write_ok_or_segv(env, env->regs[R_EDI], sizeof(uint32_t)) ||
+!write_ok_or_segv(env, env->regs[R_ESI], sizeof(uint32_t))) {
+return;
+}
+break;
+default:
+g_assert_not_reached();
+}
+
+/*
+ * Perform the syscall.  None of the vsyscalls should need restarting,
+ * and all faults should have been caught above.
+ */
+ret = do_syscall(env, syscall, env->regs[R_EDI], env->regs[R_ESI],
+ env->regs[R_EDX], env->regs[10], env->regs[8],
+ env->regs[9], 0, 0);
+g_assert(ret != -TARGET_ERESTARTSYS);
+g_assert(ret != -TARGET_QEMU_ESIGRETURN);
+g_assert(ret != -TARGET_EFAULT);
+env->regs[R_EAX] = ret;
+
+/* Emulate a ret instruction to leave the vsyscall page.  */
+env->eip = caller;
+env->regs[R_ESP] += 8;
+}
+#endif
+
 void cpu_loop(CPUX86State *env)
 {
 CPUState *cs = env_cpu(env);
@@ -141,6 +240,11 @@ void cpu_loop(CPUX86State *env)
 env->regs[R_EAX] = ret;
 }
 break;
+#endif
+#ifdef TARGET_X86_64
+case EXCP_VSYSCALL:
+emulate_vsyscall(env);
+break;
 #endif
 case EXCP0B_NOSEG:
 case EXCP0C_STACK:
diff --git a/target/i386/translate.c b/target/i386/translate.c
index 7c99ef1385..391b4ef149 100644
--- a/target/i386/translate.c
+++ b/target/i386/translate.c
@@ -8555,7 +8555,21 @@ static bool i386_tr_breakpoint_check(DisasContextBase 
*dcbase, CPUState *cpu,
 static void i386_tr_translate_insn(DisasContextBase *dcbase, CPUState *cpu)
 {
 DisasContext *dc = container_of(dcbase, DisasContext, base);
-target_ulong pc_next = disas_insn(dc, cpu);
+target_ulong pc_next;
+
+#if defined(TARGET_X86_64) && \
+

[PATCH 1/3] target/i386: Renumber EXCP_SYSCALL

[Richard Henderson]

We are not short of numbers for EXCP_*.  There is no need to confuse things
by having EXCP_VMEXIT and EXCP_SYSCALL overlap, even though the former is
only used for system mode and the latter is only used for user mode.

Signed-off-by: Richard Henderson 
---
 target/i386/cpu.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 594326a794..164d038d1f 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -998,9 +998,8 @@ typedef uint64_t FeatureWordArray[FEATURE_WORDS];
 #define EXCP11_ALGN17
 #define EXCP12_MCHK18
 
-#define EXCP_SYSCALL0x100 /* only happens in user only emulation
- for syscall instruction */
-#define EXCP_VMEXIT 0x100
+#define EXCP_VMEXIT 0x100 /* only for system emulation */
+#define EXCP_SYSCALL0x101 /* only for user emulation */
 
 /* i386-specific interrupt pending bits.  */
 #define CPU_INTERRUPT_POLL  CPU_INTERRUPT_TGT_EXT_1
-- 
2.20.1

[PATCH 2/3] linux-user/i386: Split out gen_signal

[Richard Henderson]

This is a bit tidier than open-coding the 5 lines necessary
to initialize the target_siginfo_t.  In addition, this zeros
the remaining bytes of the target_siginfo_t, rather than
passing in garbage.

Signed-off-by: Richard Henderson 
---
 linux-user/i386/cpu_loop.c | 93 ++
 1 file changed, 33 insertions(+), 60 deletions(-)

diff --git a/linux-user/i386/cpu_loop.c b/linux-user/i386/cpu_loop.c
index 024b6f4d58..e217cca5ee 100644
--- a/linux-user/i386/cpu_loop.c
+++ b/linux-user/i386/cpu_loop.c
@@ -81,13 +81,23 @@ static void set_idt(int n, unsigned int dpl)
 }
 #endif
 
+static void gen_signal(CPUX86State *env, int sig, int code, abi_ptr addr)
+{
+target_siginfo_t info = {
+.si_signo = sig,
+.si_code = code,
+._sifields._sigfault._addr = addr
+};
+
+queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+}
+
 void cpu_loop(CPUX86State *env)
 {
 CPUState *cs = env_cpu(env);
 int trapnr;
 abi_ulong pc;
 abi_ulong ret;
-target_siginfo_t info;
 
 for(;;) {
 cpu_exec_start(cs);
@@ -134,70 +144,45 @@ void cpu_loop(CPUX86State *env)
 #endif
 case EXCP0B_NOSEG:
 case EXCP0C_STACK:
-info.si_signo = TARGET_SIGBUS;
-info.si_errno = 0;
-info.si_code = TARGET_SI_KERNEL;
-info._sifields._sigfault._addr = 0;
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+gen_signal(env, TARGET_SIGBUS, TARGET_SI_KERNEL, 0);
 break;
 case EXCP0D_GPF:
 /* XXX: potential problem if ABI32 */
 #ifndef TARGET_X86_64
 if (env->eflags & VM_MASK) {
 handle_vm86_fault(env);
-} else
-#endif
-{
-info.si_signo = TARGET_SIGSEGV;
-info.si_errno = 0;
-info.si_code = TARGET_SI_KERNEL;
-info._sifields._sigfault._addr = 0;
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+break;
 }
+#endif
+gen_signal(env, TARGET_SIGSEGV, TARGET_SI_KERNEL, 0);
 break;
 case EXCP0E_PAGE:
-info.si_signo = TARGET_SIGSEGV;
-info.si_errno = 0;
-if (!(env->error_code & 1))
-info.si_code = TARGET_SEGV_MAPERR;
-else
-info.si_code = TARGET_SEGV_ACCERR;
-info._sifields._sigfault._addr = env->cr[2];
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+gen_signal(env, TARGET_SIGSEGV,
+   (env->error_code & 1 ?
+TARGET_SEGV_ACCERR : TARGET_SEGV_MAPERR),
+   env->cr[2]);
 break;
 case EXCP00_DIVZ:
 #ifndef TARGET_X86_64
 if (env->eflags & VM_MASK) {
 handle_vm86_trap(env, trapnr);
-} else
-#endif
-{
-/* division by zero */
-info.si_signo = TARGET_SIGFPE;
-info.si_errno = 0;
-info.si_code = TARGET_FPE_INTDIV;
-info._sifields._sigfault._addr = env->eip;
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+break;
 }
+#endif
+gen_signal(env, TARGET_SIGFPE, TARGET_FPE_INTDIV, env->eip);
 break;
 case EXCP01_DB:
 case EXCP03_INT3:
 #ifndef TARGET_X86_64
 if (env->eflags & VM_MASK) {
 handle_vm86_trap(env, trapnr);
-} else
+break;
+}
 #endif
-{
-info.si_signo = TARGET_SIGTRAP;
-info.si_errno = 0;
-if (trapnr == EXCP01_DB) {
-info.si_code = TARGET_TRAP_BRKPT;
-info._sifields._sigfault._addr = env->eip;
-} else {
-info.si_code = TARGET_SI_KERNEL;
-info._sifields._sigfault._addr = 0;
-}
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+if (trapnr == EXCP01_DB) {
+gen_signal(env, TARGET_SIGTRAP, TARGET_TRAP_BRKPT, env->eip);
+} else {
+gen_signal(env, TARGET_SIGTRAP, TARGET_SI_KERNEL, 0);
 }
 break;
 case EXCP04_INTO:
@@ -205,31 +190,19 @@ void cpu_loop(CPUX86State *env)
 #ifndef TARGET_X86_64
 if (env->eflags & VM_MASK) {
 handle_vm86_trap(env, trapnr);
-} else
-#endif
-{
-info.si_signo = TARGET_SIGSEGV;
-info.si_errno = 0;
-info.si_code = TARGET_SI_KERNEL;
-info._sifields._sigfault._addr = 0;
-queue_signal(env, info.si_signo, QEMU_SI_FAULT, );
+break;
 }
+#endif
+gen_signal(env, TARGET_SIGSEGV, TARGET_SI_KERNEL, 0);
 break;
 case EXCP06_ILLOP:
- 

[PATCH 0/3] linux-user: Implement x86_64 vsyscalls

[Richard Henderson]

The x86_64 abi has a legacy vsyscall page.  The kernel folk
have been trying to deprecate this since at least v3.1, but

(1) We don't implement the vdso that replaces vsyscalls,
(2) As of v5.5, the vsyscall page is still enabled by default.

This lack is affecting Peter's linux-user testing.

The dependency is not obvious because Peter is running the tests
on x86_64, so the host is providing a vsyscall page to qemu.

Because of how user-only memory operations are handled, with no
validation of guest vs host pages, so long as qemu chooses to
run with guest_base == 0, the guest may Just So Happen to read
the host's vsyscall page.

Complicating this, new OS releases may use a kernel configured
with CONFIG_LEGACY_VSYSCALL_XONLY=y, which means the the vsyscall
page cannot be read, only executed.  Which means that the guest
then cannot read the host vsyscall page during translation and
will SIGSEGV.

Exactly which of these many variables is affecting Peter's testing
with Ubuntu 18.04 of my TCG merge, I'm not exactly sure.  I suspect
that it is the change to drop the textseg_addr adjustment to user-only
static binaries.  IIRC bionic does not support -static-pie, which is
the preferred replacement.  This could mean that the host and guest
binaries overlap, which leads to guest_base != 0.

I vaguely remember someone (Paolo?) implementing something like
this many years ago, but clearly it never got merged.

In any case, this emulation has been missing for too long.


r~


Richard Henderson (3):
  target/i386: Renumber EXCP_SYSCALL
  linux-user/i386: Split out gen_signal
  linux-user/i386: Emulate x86_64 vsyscalls

 target/i386/cpu.h  |   6 +-
 linux-user/i386/cpu_loop.c | 197 ++---
 target/i386/translate.c|  16 ++-
 3 files changed, 155 insertions(+), 64 deletions(-)

-- 
2.20.1

Re: [PATCH] target/m68k: Allow movec only on 68010+

[Laurent Vivier]

Le 14/01/2020 à 21:13, BALATON Zoltan a écrit :
> The movec opcode does not exist on 68000 and should raise an
> exception. Fix the feature mask to only allow movec on newer 68k CPUs.
> 
> Signed-off-by: BALATON Zoltan 
> ---
>  target/m68k/translate.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/m68k/translate.c b/target/m68k/translate.c
> index fcdb7bc8e4..f19da064c8 100644
> --- a/target/m68k/translate.c
> +++ b/target/m68k/translate.c
> @@ -5988,7 +5988,7 @@ void register_m68k_insns (CPUM68KState *env)
>  BASE(stop,  4e72, );
>  BASE(rte,   4e73, );
>  INSN(cf_movec,  4e7b, , CF_ISA_A);
> -INSN(m68k_movec, 4e7a, fffe, M68000);
> +INSN(m68k_movec, 4e7a, fffe, FPU);
>  #endif
>  BASE(nop,   4e71, );
>  INSN(rtd,   4e74, , RTD);
> 

Good point. But as movec is not related to FPU I don't think this is the
good flag to use.

Lucien has sent a patch to fix this issue last year:

  [5/6] MOVEC insn. doesnt generate exception if wrong CR is accessed
  https://patchwork.kernel.org/patch/10997467/

it needs a rework (M680x0 feature flags are now specific to each CPU, so
the table cannot be set to the older one, 68010, and 68060 is missing)
but I think it's a better approach.

Thanks,
Laurent

Re: [PATCH v2 0/4] qmp: Optionally run handlers in coroutines

[no-reply]

Patchew URL: https://patchew.org/QEMU/20200114182735.5553-1-kw...@redhat.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

aio_co_schedule: Co-routine was already scheduled in 'aio_co_schedule'
Broken pipe
/tmp/qemu-test/src/tests/qtest/libqtest.c:149: kill_qemu() detected QEMU death 
from signal 6 (Aborted) (core dumped)
ERROR - too few tests run (expected 4, got 1)
make: *** [check-qtest-aarch64] Error 1
make: *** Waiting for unfinished jobs
  TESTiotest-qcow2: 117
  TESTiotest-qcow2: 120
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=7a16af349113413b993a610a9cc5ed59', '-u', 
'1001', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-0jve889m/src/docker-src.2020-01-14-15.32.21.3694:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=7a16af349113413b993a610a9cc5ed59
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-0jve889m/src'
make: *** [docker-run-test-quick@centos7] Error 2

real9m18.352s
user0m9.409s


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

[PATCH] target/m68k: Allow movec only on 68010+

[BALATON Zoltan]

The movec opcode does not exist on 68000 and should raise an
exception. Fix the feature mask to only allow movec on newer 68k CPUs.

Signed-off-by: BALATON Zoltan 
---
 target/m68k/translate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/m68k/translate.c b/target/m68k/translate.c
index fcdb7bc8e4..f19da064c8 100644
--- a/target/m68k/translate.c
+++ b/target/m68k/translate.c
@@ -5988,7 +5988,7 @@ void register_m68k_insns (CPUM68KState *env)
 BASE(stop,  4e72, );
 BASE(rte,   4e73, );
 INSN(cf_movec,  4e7b, , CF_ISA_A);
-INSN(m68k_movec, 4e7a, fffe, M68000);
+INSN(m68k_movec, 4e7a, fffe, FPU);
 #endif
 BASE(nop,   4e71, );
 INSN(rtd,   4e74, , RTD);
-- 
2.13.7

Re: [PATCH] tests: acpi: update path in rebuild-expected-aml

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200114165138.15716-1-shameerali.kolothum.th...@huawei.com/



Hi,

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

Subject: [PATCH] tests: acpi: update path in rebuild-expected-aml
Type: series
Message-id: 20200114165138.15716-1-shameerali.kolothum.th...@huawei.com

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

From https://github.com/patchew-project/qemu
 * [new tag] 
patchew/20200114165138.15716-1-shameerali.kolothum.th...@huawei.com -> 
patchew/20200114165138.15716-1-shameerali.kolothum.th...@huawei.com
Switched to a new branch 'test'
d4dcd84 tests: acpi: update path in rebuild-expected-aml

=== OUTPUT BEGIN ===
ERROR: line over 90 characters
#42: FILE: tests/data/acpi/rebuild-expected-aml.sh:34:
+echo '/* List of comma-separated changed AML files to ignore */' > 
${SRC_PATH}/tests/qtest/bios-tables-test-allowed-diff.h

total: 1 errors, 0 warnings, 21 lines checked

Commit d4dcd849a42e (tests: acpi: update path in rebuild-expected-aml) has 
style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


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

[PATCH 08/13] iotests: filter few more luks specific create options

[Maxim Levitsky]

This allows more tests to be able to have same output on both qcow2 luks 
encrypted images
and raw luks images

Signed-off-by: Maxim Levitsky 
---
 tests/qemu-iotests/087.out   | 6 +++---
 tests/qemu-iotests/134.out   | 2 +-
 tests/qemu-iotests/158.out   | 4 ++--
 tests/qemu-iotests/188.out   | 2 +-
 tests/qemu-iotests/189.out   | 4 ++--
 tests/qemu-iotests/198.out   | 4 ++--
 tests/qemu-iotests/common.filter | 6 --
 7 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/tests/qemu-iotests/087.out b/tests/qemu-iotests/087.out
index 2d92ea847b..b61ba638af 100644
--- a/tests/qemu-iotests/087.out
+++ b/tests/qemu-iotests/087.out
@@ -34,7 +34,7 @@ QMP_VERSION
 
 === Encrypted image QCow ===
 
-Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encryption=on 
encrypt.key-secret=sec0
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encryption=on
 Testing:
 QMP_VERSION
 {"return": {}}
@@ -46,7 +46,7 @@ QMP_VERSION
 
 === Encrypted image LUKS ===
 
-Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encrypt.format=luks 
encrypt.key-secret=sec0
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
 Testing:
 QMP_VERSION
 {"return": {}}
@@ -58,7 +58,7 @@ QMP_VERSION
 
 === Missing driver ===
 
-Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encryption=on 
encrypt.key-secret=sec0
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encryption=on
 Testing: -S
 QMP_VERSION
 {"return": {}}
diff --git a/tests/qemu-iotests/134.out b/tests/qemu-iotests/134.out
index 09d46f6b17..4abc5b5f7d 100644
--- a/tests/qemu-iotests/134.out
+++ b/tests/qemu-iotests/134.out
@@ -1,5 +1,5 @@
 QA output created by 134
-Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encryption=on 
encrypt.key-secret=sec0
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 encryption=on
 
 == reading whole image ==
 read 134217728/134217728 bytes at offset 0
diff --git a/tests/qemu-iotests/158.out b/tests/qemu-iotests/158.out
index 6def216e55..f28a17626b 100644
--- a/tests/qemu-iotests/158.out
+++ b/tests/qemu-iotests/158.out
@@ -1,6 +1,6 @@
 QA output created by 158
 == create base ==
-Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=134217728 encryption=on 
encrypt.key-secret=sec0
+Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=134217728 encryption=on
 
 == writing whole image ==
 wrote 134217728/134217728 bytes at offset 0
@@ -10,7 +10,7 @@ wrote 134217728/134217728 bytes at offset 0
 read 134217728/134217728 bytes at offset 0
 128 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 == create overlay ==
-Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 
backing_file=TEST_DIR/t.IMGFMT.base encryption=on encrypt.key-secret=sec0
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 
backing_file=TEST_DIR/t.IMGFMT.base encryption=on
 
 == writing part of a cluster ==
 wrote 1024/1024 bytes at offset 0
diff --git a/tests/qemu-iotests/188.out b/tests/qemu-iotests/188.out
index c568ef3701..5426861b18 100644
--- a/tests/qemu-iotests/188.out
+++ b/tests/qemu-iotests/188.out
@@ -1,5 +1,5 @@
 QA output created by 188
-Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216 encrypt.format=luks 
encrypt.key-secret=sec0 encrypt.iter-time=10
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216
 
 == reading whole image ==
 read 16777216/16777216 bytes at offset 0
diff --git a/tests/qemu-iotests/189.out b/tests/qemu-iotests/189.out
index a0b7c9c24c..bc213cbe14 100644
--- a/tests/qemu-iotests/189.out
+++ b/tests/qemu-iotests/189.out
@@ -1,6 +1,6 @@
 QA output created by 189
 == create base ==
-Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=16777216 
encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10
+Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=16777216
 
 == writing whole image ==
 wrote 16777216/16777216 bytes at offset 0
@@ -10,7 +10,7 @@ wrote 16777216/16777216 bytes at offset 0
 read 16777216/16777216 bytes at offset 0
 16 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 == create overlay ==
-Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216 
backing_file=TEST_DIR/t.IMGFMT.base encrypt.format=luks encrypt.key-secret=sec1 
encrypt.iter-time=10
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216 
backing_file=TEST_DIR/t.IMGFMT.base
 
 == writing part of a cluster ==
 wrote 1024/1024 bytes at offset 0
diff --git a/tests/qemu-iotests/198.out b/tests/qemu-iotests/198.out
index 831ce3a289..acfdf96b0c 100644
--- a/tests/qemu-iotests/198.out
+++ b/tests/qemu-iotests/198.out
@@ -1,12 +1,12 @@
 QA output created by 198
 == create base ==
-Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=16777216 
encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10
+Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=16777216
 
 == writing whole image base ==
 wrote 16777216/16777216 bytes at offset 0
 16 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 == create overlay ==
-Formatting 

Re: [PATCH v2 0/3] block/io: serialising request clean up and locking fix

[Paolo Bonzini]

On 14/01/20 17:28, Stefan Hajnoczi wrote:
> On Wed, Jan 08, 2020 at 03:55:53PM +0100, Paolo Bonzini wrote:
>> Peter Lieven noticed that reqs->overlap_offset and reqs->overlap_bytes
>> are written outside bs->reqs_lock.  Patch 3 fixes it, while patches 1
>> and 2 are preparatory cleanups.
>>
>> v1->v2: fix comment in patch 2, commit message in patch 3 [Kevin]
>>
>> Paolo Bonzini (3):
>>   block: eliminate BDRV_REQ_NO_SERIALISING
>>   block/io: wait for serialising requests when a request becomes
>> serialising
>>   block/io: take bs->reqs_lock in bdrv_mark_request_serialising
>>
>>  block/file-posix.c|   1 -
>>  block/io.c| 162 
>> +++---
>>  include/block/block.h |  12 
>>  include/block/block_int.h |   3 +-
>>  4 files changed, 81 insertions(+), 97 deletions(-)
> Is it possible to trigger the bug somehow?
> 
> Can you implement a test case?

No, it was found by inspection only, and it's actually protected by the
AioContext lock for now.

Paolo



signature.asc
Description: OpenPGP digital signature

[PATCH 09/13] qemu-iotests: qemu-img tests for luks key management

[Maxim Levitsky]

This commit adds two tests, which test the new amend interface
of both luks raw images and qcow2 luks encrypted images.

Signed-off-by: Maxim Levitsky 
---
 tests/qemu-iotests/300 | 207 +
 tests/qemu-iotests/300.out |  99 ++
 tests/qemu-iotests/301 |  90 
 tests/qemu-iotests/301.out |  30 ++
 tests/qemu-iotests/group   |   3 +
 5 files changed, 429 insertions(+)
 create mode 100755 tests/qemu-iotests/300
 create mode 100644 tests/qemu-iotests/300.out
 create mode 100755 tests/qemu-iotests/301
 create mode 100644 tests/qemu-iotests/301.out

diff --git a/tests/qemu-iotests/300 b/tests/qemu-iotests/300
new file mode 100755
index 00..b1a6b37772
--- /dev/null
+++ b/tests/qemu-iotests/300
@@ -0,0 +1,207 @@
+#!/usr/bin/env bash
+#
+# Test encryption key management with luks
+# Based on 134
+#
+# Copyright (C) 2019 Red Hat, Inc.
+#
+# 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 .
+#
+
+# creator
+owner=mlevi...@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+status=1   # failure is the default!
+
+_cleanup()
+{
+   _cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt qcow2 luks
+_supported_proto file #TODO
+
+QEMU_IO_OPTIONS=$QEMU_IO_OPTIONS_NO_FMT
+
+if [ "$IMGFMT" = "qcow2" ] ; then
+   PR="encrypt."
+   EXTRA_IMG_ARGS="-o encrypt.format=luks"
+fi
+
+
+# secrets: you are supposed to see the password as ***, see :-)
+S0="--object secret,id=sec0,data=hunter0"
+S1="--object secret,id=sec1,data=hunter1"
+S2="--object secret,id=sec2,data=hunter2"
+S3="--object secret,id=sec3,data=hunter3"
+S4="--object secret,id=sec4,data=hunter4"
+SECRETS="$S0 $S1 $S2 $S3 $S4"
+
+# image with given secret
+IMGS0="--image-opts 
driver=$IMGFMT,file.filename=$TEST_IMG,${PR}key-secret=sec0"
+IMGS1="--image-opts 
driver=$IMGFMT,file.filename=$TEST_IMG,${PR}key-secret=sec1"
+IMGS2="--image-opts 
driver=$IMGFMT,file.filename=$TEST_IMG,${PR}key-secret=sec2"
+IMGS3="--image-opts 
driver=$IMGFMT,file.filename=$TEST_IMG,${PR}key-secret=sec3"
+IMGS4="--image-opts 
driver=$IMGFMT,file.filename=$TEST_IMG,${PR}key-secret=sec4"
+
+
+echo "== creating a test image =="
+_make_test_img $S0 $EXTRA_IMG_ARGS -o ${PR}key-secret=sec0,${PR}iter-time=10 
32M
+
+echo
+echo "== test that key 0 opens the image =="
+$QEMU_IO $S0 -c "read 0 4096" $IMGS0 | _filter_qemu_io | _filter_testdir
+
+echo
+echo "== adding a password to slot 4 =="
+$QEMU_IMG amend $SECRETS $IMGS0 -o 
${PR}keys.0.new-secret=sec4,${PR}keys.0.iter-time=10,${PR}keys.0.keyslot=4
+echo "== adding a password to slot 1 =="
+$QEMU_IMG amend $SECRETS $IMGS0 -o 
${PR}keys.0.new-secret=sec1,${PR}keys.0.iter-time=10
+echo "== adding a password to slot 3 =="
+$QEMU_IMG amend $SECRETS $IMGS1 -o 
${PR}keys.0.new-secret=sec3,${PR}keys.0.iter-time=10,${PR}keys.0.keyslot=3
+
+echo "== adding a password to slot 2 =="
+$QEMU_IMG amend $SECRETS $IMGS3 -o 
${PR}keys.0.new-secret=sec2,${PR}keys.0.iter-time=10
+
+
+echo "== erase slot 4 =="
+$QEMU_IMG amend $SECRETS $IMGS1 -o 
${PR}keys.0.new-secret="",${PR}keys.0.keyslot=4 | _filter_img_create
+
+
+echo
+echo "== all secrets should work =="
+for IMG in "$IMGS0" "$IMGS1" "$IMGS2" "$IMGS3"; do
+   $QEMU_IO $SECRETS -c "read 0 4096" $IMG | _filter_qemu_io | 
_filter_testdir
+done
+
+echo
+echo "== erase slot 0 and try it =="
+$QEMU_IMG amend $SECRETS $IMGS1 -o 
${PR}keys.0.new-secret="",${PR}keys.0.old-secret=sec0 | _filter_img_create
+$QEMU_IO $SECRETS -c "read 0 4096" $IMGS0 | _filter_qemu_io | _filter_testdir
+
+echo
+echo "== erase slot 2 and try it =="
+$QEMU_IMG amend $SECRETS $IMGS1 -o 
${PR}keys.0.new-secret="",${PR}keys.0.keyslot=2 | _filter_img_create
+$QEMU_IO $SECRETS -c "read 0 4096" $IMGS2 | _filter_qemu_io | _filter_testdir
+
+
+# at this point slots 1 and 3 should be active
+
+echo
+echo "== filling  4 slots with secret 2 =="
+for i in $(seq 0 3) ; do
+   $QEMU_IMG amend $SECRETS $IMGS3 -o 
${PR}keys.0.new-secret=sec2,${PR}keys.0.iter-time=10
+done
+
+echo
+echo "== adding secret 0 =="
+   $QEMU_IMG amend $SECRETS $IMGS3 -o 
${PR}keys.0.new-secret=sec0,${PR}keys.0.iter-time=10
+
+echo
+echo "== adding secret 3 (last slot) =="
+   $QEMU_IMG amend $SECRETS $IMGS3 -o 

[PATCH 13/13] iotests: add tests for blockdev-amend

[Maxim Levitsky]

This commit adds two tests that cover the
new blockdev-amend functionality of luks and qcow2 driver

Signed-off-by: Maxim Levitsky 
---
 tests/qemu-iotests/302 | 284 +
 tests/qemu-iotests/302.out |  40 ++
 tests/qemu-iotests/303 | 235 ++
 tests/qemu-iotests/303.out |  33 +
 tests/qemu-iotests/group   |   3 +
 5 files changed, 595 insertions(+)
 create mode 100644 tests/qemu-iotests/302
 create mode 100644 tests/qemu-iotests/302.out
 create mode 100644 tests/qemu-iotests/303
 create mode 100644 tests/qemu-iotests/303.out

diff --git a/tests/qemu-iotests/302 b/tests/qemu-iotests/302
new file mode 100644
index 00..bc507377a5
--- /dev/null
+++ b/tests/qemu-iotests/302
@@ -0,0 +1,284 @@
+#!/usr/bin/env python
+#
+# Test case QMP's encrypted key management
+#
+# Copyright (C) 2019 Red Hat, Inc.
+#
+# 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 .
+#
+
+import iotests
+import os
+import time
+import json
+
+test_img = os.path.join(iotests.test_dir, 'test.img')
+
+class Secret:
+def __init__(self, index):
+self._id = "keysec" + str(index)
+# you are not supposed to see the password...
+self._secret = "hunter" + str(index)
+
+def id(self):
+return self._id
+
+def secret(self):
+return self._secret
+
+def to_cmdline_object(self):
+return  [ "secret,id=" + self._id + ",data=" + self._secret]
+
+def to_qmp_object(self):
+return { "qom_type" : "secret", "id": self.id(),
+ "props": { "data": self.secret() } }
+
+
+class EncryptionSetupTestCase(iotests.QMPTestCase):
+
+# test case startup
+def setUp(self):
+# start the VM
+self.vm = iotests.VM()
+self.vm.launch()
+
+# create the secrets and load 'em into the VM
+self.secrets = [ Secret(i) for i in range(0, 6) ]
+for secret in self.secrets:
+result = self.vm.qmp("object-add", **secret.to_qmp_object())
+self.assert_qmp(result, 'return', {})
+
+if iotests.imgfmt == "qcow2":
+self.pfx = "encrypt."
+self.img_opts = [ '-o', "encrypt.format=luks" ]
+else:
+self.pfx = ""
+self.img_opts = []
+
+# test case shutdown
+def tearDown(self):
+# stop the VM
+self.vm.shutdown()
+
+###
+# create the encrypted block device
+def createImg(self, file, secret):
+
+iotests.qemu_img(
+'create',
+'--object', *secret.to_cmdline_object(),
+'-f', iotests.imgfmt,
+'-o', self.pfx + 'key-secret=' + secret.id(),
+'-o', self.pfx + 'iter-time=10',
+*self.img_opts,
+file,
+'1M')
+
+###
+# open an encrypted block device
+def openImageQmp(self, id, file, secret, read_only = False):
+
+encrypt_options = {
+'key-secret' : secret.id()
+}
+
+if iotests.imgfmt == "qcow2":
+encrypt_options = {
+'encrypt': {
+'format':'luks',
+**encrypt_options
+}
+}
+
+result = self.vm.qmp('blockdev-add', **
+{
+'driver': iotests.imgfmt,
+'node-name': id,
+'read-only': read_only,
+
+**encrypt_options,
+
+'file': {
+'driver': 'file',
+'filename': test_img,
+}
+}
+)
+self.assert_qmp(result, 'return', {})
+
+# close the encrypted block device
+def closeImageQmp(self, id):
+result = self.vm.qmp('blockdev-del', **{ 'node-name': id })
+self.assert_qmp(result, 'return', {})
+
+###
+# add a key to an encrypted block device
+def addKeyQmp(self, id, secret, unlock_secret = None,
+  slot = None, force = False):
+
+keyupdate0 = {
+'new-secret' : secret.id(),
+'iter-time' : 10
+}
+
+if slot 

[PATCH 11/13] block/crypto: implement blockdev-amend

[Maxim Levitsky]

Signed-off-by: Maxim Levitsky 
---
 block/crypto.c   | 70 
 qapi/block-core.json | 14 -
 2 files changed, 64 insertions(+), 20 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index 081880bced..6836337863 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -697,32 +697,21 @@ block_crypto_get_specific_info_luks(BlockDriverState *bs, 
Error **errp)
 }
 
 static int
-block_crypto_amend_options(BlockDriverState *bs,
-   QemuOpts *opts,
-   BlockDriverAmendStatusCB *status_cb,
-   void *cb_opaque,
-   bool force,
-   Error **errp)
+block_crypto_amend_options_generic(BlockDriverState *bs,
+   QCryptoBlockAmendOptions *amend_options,
+   bool force,
+   Error **errp)
 {
 BlockCrypto *crypto = bs->opaque;
-QDict *cryptoopts = NULL;
-QCryptoBlockAmendOptions *amend_options = NULL;
 int ret;
 
 assert(crypto);
 assert(crypto->block);
-crypto->updating_keys = true;
 
+/* apply for exclusive read/write permissions to the underlying file*/
+crypto->updating_keys = true;
 ret = bdrv_child_refresh_perms(bs, bs->file, errp);
-if (ret < 0) {
-goto cleanup;
-}
-
-cryptoopts = qemu_opts_to_qdict(opts, NULL);
-qdict_put_str(cryptoopts, "format", "luks");
-amend_options = block_crypto_amend_opts_init(cryptoopts, errp);
-if (!amend_options) {
-ret = -EINVAL;
+if (ret) {
 goto cleanup;
 }
 
@@ -734,13 +723,55 @@ block_crypto_amend_options(BlockDriverState *bs,
   force,
   errp);
 cleanup:
+/* release exclusive read/write permissions to the underlying file*/
 crypto->updating_keys = false;
 bdrv_child_refresh_perms(bs, bs->file, errp);
-qapi_free_QCryptoBlockAmendOptions(amend_options);
+return ret;
+}
+
+static int
+block_crypto_amend_options(BlockDriverState *bs,
+   QemuOpts *opts,
+   BlockDriverAmendStatusCB *status_cb,
+   void *cb_opaque,
+   bool force,
+   Error **errp)
+{
+BlockCrypto *crypto = bs->opaque;
+QDict *cryptoopts = NULL;
+QCryptoBlockAmendOptions *amend_options = NULL;
+int ret = -EINVAL;
+
+assert(crypto);
+assert(crypto->block);
+
+cryptoopts = qemu_opts_to_qdict(opts, NULL);
+qdict_put_str(cryptoopts, "format", "luks");
+amend_options = block_crypto_amend_opts_init(cryptoopts, errp);
 qobject_unref(cryptoopts);
+if (!amend_options) {
+goto cleanup;
+}
+ret = block_crypto_amend_options_generic(bs, amend_options, force, errp);
+cleanup:
+qapi_free_QCryptoBlockAmendOptions(amend_options);
 return ret;
 }
 
+static int
+coroutine_fn block_crypto_co_amend(BlockDriverState *bs,
+   BlockdevAmendOptions *opts,
+   bool force,
+   Error **errp)
+{
+QCryptoBlockAmendOptions amend_opts;
+
+amend_opts = (QCryptoBlockAmendOptions) {
+.format = Q_CRYPTO_BLOCK_FORMAT_LUKS,
+.u.luks = *qapi_BlockdevAmendOptionsLUKS_base(>u.luks),
+};
+return block_crypto_amend_options_generic(bs, _opts, force, errp);
+}
 
 static void
 block_crypto_child_perms(BlockDriverState *bs, BdrvChild *c,
@@ -812,6 +843,7 @@ static BlockDriver bdrv_crypto_luks = {
 .bdrv_get_info  = block_crypto_get_info_luks,
 .bdrv_get_specific_info = block_crypto_get_specific_info_luks,
 .bdrv_amend_options = block_crypto_amend_options,
+.bdrv_co_amend  = block_crypto_co_amend,
 
 .strong_runtime_opts = block_crypto_strong_runtime_opts,
 };
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 601f7dc9a4..790aa40991 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -4743,6 +4743,18 @@
   'data': { 'job-id': 'str',
 'options': 'BlockdevCreateOptions' } }
 
+##
+# @BlockdevAmendOptionsLUKS:
+#
+# Driver specific image amend options for LUKS.
+#
+# Since: 5.0
+##
+{ 'struct': 'BlockdevAmendOptionsLUKS',
+  'base': 'QCryptoBlockAmendOptionsLUKS',
+  'data': { }
+}
+
 ##
 # @BlockdevAmendOptions:
 #
@@ -4757,7 +4769,7 @@
   'driver': 'BlockdevDriver' },
   'discriminator': 'driver',
   'data': {
-  } }
+  'luks':   'BlockdevAmendOptionsLUKS' } }
 
 ##
 # @x-blockdev-amend:
-- 
2.17.2

[PATCH 02/13] qcrypto-luks: implement encryption key management

[Maxim Levitsky]

Next few patches will expose that functionality
to the user.

Signed-off-by: Maxim Levitsky 
---
 crypto/block-luks.c | 374 +++-
 qapi/crypto.json|  50 +-
 2 files changed, 421 insertions(+), 3 deletions(-)

diff --git a/crypto/block-luks.c b/crypto/block-luks.c
index 4861db810c..349e95fed3 100644
--- a/crypto/block-luks.c
+++ b/crypto/block-luks.c
@@ -32,6 +32,7 @@
 #include "qemu/uuid.h"
 
 #include "qemu/coroutine.h"
+#include "qemu/bitmap.h"
 
 /*
  * Reference for the LUKS format implemented here is
@@ -70,6 +71,9 @@ typedef struct QCryptoBlockLUKSKeySlot 
QCryptoBlockLUKSKeySlot;
 
 #define QCRYPTO_BLOCK_LUKS_SECTOR_SIZE 512LL
 
+#define QCRYPTO_BLOCK_LUKS_DEFAULT_ITER_TIME_MS 2000
+#define QCRYPTO_BLOCK_LUKS_ERASE_ITERATIONS 40
+
 static const char qcrypto_block_luks_magic[QCRYPTO_BLOCK_LUKS_MAGIC_LEN] = {
 'L', 'U', 'K', 'S', 0xBA, 0xBE
 };
@@ -219,6 +223,9 @@ struct QCryptoBlockLUKS {
 
 /* Hash algorithm used in pbkdf2 function */
 QCryptoHashAlgorithm hash_alg;
+
+/* Name of the secret that was used to open the image */
+char *secret;
 };
 
 
@@ -1069,6 +1076,112 @@ qcrypto_block_luks_find_key(QCryptoBlock *block,
 return -1;
 }
 
+/*
+ * Returns true if a slot i is marked as active
+ * (contains encrypted copy of the master key)
+ */
+static bool
+qcrypto_block_luks_slot_active(const QCryptoBlockLUKS *luks,
+   unsigned int slot_idx)
+{
+uint32_t val = luks->header.key_slots[slot_idx].active;
+return val ==  QCRYPTO_BLOCK_LUKS_KEY_SLOT_ENABLED;
+}
+
+/*
+ * Returns the number of slots that are marked as active
+ * (slots that contain encrypted copy of the master key)
+ */
+static unsigned int
+qcrypto_block_luks_count_active_slots(const QCryptoBlockLUKS *luks)
+{
+size_t i = 0;
+unsigned int ret = 0;
+
+for (i = 0; i < QCRYPTO_BLOCK_LUKS_NUM_KEY_SLOTS; i++) {
+if (qcrypto_block_luks_slot_active(luks, i)) {
+ret++;
+}
+}
+return ret;
+}
+
+/*
+ * Finds first key slot which is not active
+ * Returns the key slot index, or -1 if it doesn't exist
+ */
+static int
+qcrypto_block_luks_find_free_keyslot(const QCryptoBlockLUKS *luks)
+{
+size_t i;
+
+for (i = 0; i < QCRYPTO_BLOCK_LUKS_NUM_KEY_SLOTS; i++) {
+if (!qcrypto_block_luks_slot_active(luks, i)) {
+return i;
+}
+}
+return -1;
+
+}
+
+/*
+ * Erases an keyslot given its index
+ * Returns:
+ *0 if the keyslot was erased successfully
+ *   -1 if a error occurred while erasing the keyslot
+ *
+ */
+static int
+qcrypto_block_luks_erase_key(QCryptoBlock *block,
+ unsigned int slot_idx,
+ QCryptoBlockWriteFunc writefunc,
+ void *opaque,
+ Error **errp)
+{
+QCryptoBlockLUKS *luks = block->opaque;
+QCryptoBlockLUKSKeySlot *slot = >header.key_slots[slot_idx];
+g_autofree uint8_t *garbagesplitkey = NULL;
+size_t splitkeylen = luks->header.master_key_len * slot->stripes;
+size_t i;
+
+assert(slot_idx < QCRYPTO_BLOCK_LUKS_NUM_KEY_SLOTS);
+assert(splitkeylen > 0);
+
+garbagesplitkey = g_new0(uint8_t, splitkeylen);
+
+/* Reset the key slot header */
+memset(slot->salt, 0, QCRYPTO_BLOCK_LUKS_SALT_LEN);
+slot->iterations = 0;
+slot->active = QCRYPTO_BLOCK_LUKS_KEY_SLOT_DISABLED;
+
+qcrypto_block_luks_store_header(block,  writefunc, opaque, errp);
+
+/*
+ * Now try to erase the key material, even if the header
+ * update failed
+ */
+for (i = 0; i < QCRYPTO_BLOCK_LUKS_ERASE_ITERATIONS; i++) {
+if (qcrypto_random_bytes(garbagesplitkey, splitkeylen, errp) < 0) {
+/*
+ * If we failed to get the random data, still write
+ * at least zeros to the key slot at least once
+ */
+if (i > 0) {
+return -1;
+}
+}
+
+if (writefunc(block,
+  slot->key_offset_sector * QCRYPTO_BLOCK_LUKS_SECTOR_SIZE,
+  garbagesplitkey,
+  splitkeylen,
+  opaque,
+  errp) != splitkeylen) {
+return -1;
+}
+}
+return 0;
+}
 
 static int
 qcrypto_block_luks_open(QCryptoBlock *block,
@@ -1099,6 +1212,7 @@ qcrypto_block_luks_open(QCryptoBlock *block,
 
 luks = g_new0(QCryptoBlockLUKS, 1);
 block->opaque = luks;
+luks->secret = g_strdup(options->u.luks.key_secret);
 
 if (qcrypto_block_luks_load_header(block, readfunc, opaque, errp) < 0) {
 goto fail;
@@ -1164,6 +1278,7 @@ qcrypto_block_luks_open(QCryptoBlock *block,
  fail:
 qcrypto_block_free_cipher(block);
 qcrypto_ivgen_free(block->ivgen);
+g_free(luks->secret);
 g_free(luks);
 return -1;
 }
@@ -1204,7 +1319,7 @@ qcrypto_block_luks_create(QCryptoBlock *block,
 
 memcpy(_opts, >u.luks, 

[PATCH 06/13] block/crypto: implement the encryption key management

[Maxim Levitsky]

This implements the encryption key management using the generic code in
qcrypto layer and exposes it to the user via qemu-img

This code adds another 'write_func' because the initialization
write_func works directly on the underlying file, and amend
works on instance of luks device.

This commit also adds a 'hack/workaround' I and Kevin Wolf (thanks)
made to make the driver both support write sharing (to avoid breaking the 
users),
and be safe against concurrent  metadata update (the keyslots)

Eventually the write sharing for luks driver will be deprecated
and removed together with this hack.

The hack is that we ask (as a format driver) for BLK_PERM_CONSISTENT_READ
and then when we want to update the keys, we unshare that permission.
So if someone else has the image open, even readonly, encryption
key update will fail gracefully.

Also thanks to Daniel Berrange for the idea of
unsharing read, rather that write permission which allows
to avoid cases when the other user had opened the image read-only.

Signed-off-by: Maxim Levitsky 
---
 block/crypto.c | 130 +++--
 block/crypto.h |  31 
 2 files changed, 158 insertions(+), 3 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index 0b37dae564..081880bced 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -36,6 +36,7 @@ typedef struct BlockCrypto BlockCrypto;
 
 struct BlockCrypto {
 QCryptoBlock *block;
+bool updating_keys;
 };
 
 
@@ -70,6 +71,24 @@ static ssize_t block_crypto_read_func(QCryptoBlock *block,
 return ret;
 }
 
+static ssize_t block_crypto_write_func(QCryptoBlock *block,
+   size_t offset,
+   const uint8_t *buf,
+   size_t buflen,
+   void *opaque,
+   Error **errp)
+{
+BlockDriverState *bs = opaque;
+ssize_t ret;
+
+ret = bdrv_pwrite(bs->file, offset, buf, buflen);
+if (ret < 0) {
+error_setg_errno(errp, -ret, "Could not write encryption header");
+return ret;
+}
+return ret;
+}
+
 
 struct BlockCryptoCreateData {
 BlockBackend *blk;
@@ -148,6 +167,22 @@ static QemuOptsList block_crypto_create_opts_luks = {
 };
 
 
+static QemuOptsList block_crypto_amend_opts_luks = {
+.name = "crypto",
+.head = QTAILQ_HEAD_INITIALIZER(block_crypto_create_opts_luks.head),
+.desc = {
+BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.0."),
+BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.1."),
+BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.2."),
+BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.3."),
+BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.4."),
+BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.5."),
+BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.6."),
+BLOCK_CRYPTO_OPT_DEF_LUKS_KEYSLOT_UPDATE("keys.7."),
+{ /* end of list */ }
+},
+};
+
 QCryptoBlockOpenOptions *
 block_crypto_open_opts_init(QDict *opts, Error **errp)
 {
@@ -661,6 +696,95 @@ block_crypto_get_specific_info_luks(BlockDriverState *bs, 
Error **errp)
 return spec_info;
 }
 
+static int
+block_crypto_amend_options(BlockDriverState *bs,
+   QemuOpts *opts,
+   BlockDriverAmendStatusCB *status_cb,
+   void *cb_opaque,
+   bool force,
+   Error **errp)
+{
+BlockCrypto *crypto = bs->opaque;
+QDict *cryptoopts = NULL;
+QCryptoBlockAmendOptions *amend_options = NULL;
+int ret;
+
+assert(crypto);
+assert(crypto->block);
+crypto->updating_keys = true;
+
+ret = bdrv_child_refresh_perms(bs, bs->file, errp);
+if (ret < 0) {
+goto cleanup;
+}
+
+cryptoopts = qemu_opts_to_qdict(opts, NULL);
+qdict_put_str(cryptoopts, "format", "luks");
+amend_options = block_crypto_amend_opts_init(cryptoopts, errp);
+if (!amend_options) {
+ret = -EINVAL;
+goto cleanup;
+}
+
+ret = qcrypto_block_amend_options(crypto->block,
+  block_crypto_read_func,
+  block_crypto_write_func,
+  bs,
+  amend_options,
+  force,
+  errp);
+cleanup:
+crypto->updating_keys = false;
+bdrv_child_refresh_perms(bs, bs->file, errp);
+qapi_free_QCryptoBlockAmendOptions(amend_options);
+qobject_unref(cryptoopts);
+return ret;
+}
+
+
+static void
+block_crypto_child_perms(BlockDriverState *bs, BdrvChild *c,
+ const BdrvChildRole *role,
+ BlockReopenQueue *reopen_queue,
+ uint64_t perm, uint64_t shared,
+ uint64_t *nperm, uint64_t 

[PATCH 12/13] block/qcow2: implement blockdev-amend

[Maxim Levitsky]

Currently the implementation only supports amending the encryption
options, unlike the qemu-img version

Signed-off-by: Maxim Levitsky 
---
 block/qcow2.c| 39 +++
 qapi/block-core.json | 16 +++-
 2 files changed, 54 insertions(+), 1 deletion(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index 1b01174aed..8b74471bc6 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -5444,6 +5444,44 @@ static int qcow2_amend_options(BlockDriverState *bs, 
QemuOpts *opts,
 return 0;
 }
 
+static int coroutine_fn qcow2_co_amend(BlockDriverState *bs,
+   BlockdevAmendOptions *opts,
+   bool force,
+   Error **errp)
+{
+BlockdevAmendOptionsQcow2 *qopts = >u.qcow2;
+BDRVQcow2State *s = bs->opaque;
+int ret = 0;
+
+if (qopts->has_encrypt) {
+if (!s->crypto) {
+error_setg(errp, "image is not encrypted, can't amend");
+return -EOPNOTSUPP;
+}
+
+if (qopts->encrypt->format != Q_CRYPTO_BLOCK_FORMAT_LUKS) {
+error_setg(errp,
+   "Amend can't be used to change the qcow2 encryption 
format");
+return -EOPNOTSUPP;
+}
+
+if (s->crypt_method_header != QCOW_CRYPT_LUKS) {
+error_setg(errp,
+   "Only LUKS encryption options can be amended for qcow2 
with blockdev-amend");
+return -EOPNOTSUPP;
+}
+
+ret = qcrypto_block_amend_options(s->crypto,
+  qcow2_crypto_hdr_read_func,
+  qcow2_crypto_hdr_write_func,
+  bs,
+  qopts->encrypt,
+  force,
+  errp);
+}
+return ret;
+}
+
 /*
  * If offset or size are negative, respectively, they will not be included in
  * the BLOCK_IMAGE_CORRUPTED event emitted.
@@ -5656,6 +5694,7 @@ BlockDriver bdrv_qcow2 = {
 .mutable_opts= mutable_opts,
 .bdrv_co_check   = qcow2_co_check,
 .bdrv_amend_options  = qcow2_amend_options,
+.bdrv_co_amend   = qcow2_co_amend,
 
 .bdrv_detach_aio_context  = qcow2_detach_aio_context,
 .bdrv_attach_aio_context  = qcow2_attach_aio_context,
diff --git a/qapi/block-core.json b/qapi/block-core.json
index 790aa40991..2cf1f443e5 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -4755,6 +4755,19 @@
   'data': { }
 }
 
+##
+# @BlockdevAmendOptionsQcow2:
+#
+# Driver specific image amend options for qcow2.
+# For now, only encryption options can be amended
+#
+# @encrypt  Encryption options to be amended
+#
+# Since: 5.0
+##
+{ 'struct': 'BlockdevAmendOptionsQcow2',
+  'data': { '*encrypt': 'QCryptoBlockAmendOptions' } }
+
 ##
 # @BlockdevAmendOptions:
 #
@@ -4769,7 +4782,8 @@
   'driver': 'BlockdevDriver' },
   'discriminator': 'driver',
   'data': {
-  'luks':   'BlockdevAmendOptionsLUKS' } }
+  'luks':   'BlockdevAmendOptionsLUKS',
+  'qcow2':  'BlockdevAmendOptionsQcow2' } }
 
 ##
 # @x-blockdev-amend:
-- 
2.17.2

[PATCH 10/13] block: add generic infrastructure for x-blockdev-amend qmp command

[Maxim Levitsky]

blockdev-amend will be used similiar to blockdev-create
to allow on the fly changes of the structure of the format based block devices.

Current plan is to first support encryption keyslot management for luks
based formats (raw and embedded in qcow2)

Signed-off-by: Maxim Levitsky 
---
 block/Makefile.objs   |   2 +-
 block/amend.c | 108 ++
 include/block/block_int.h |  21 +---
 qapi/block-core.json  |  42 +++
 qapi/job.json |   4 +-
 5 files changed, 169 insertions(+), 8 deletions(-)
 create mode 100644 block/amend.c

diff --git a/block/Makefile.objs b/block/Makefile.objs
index 330529b0b7..eb5ddb7158 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -18,7 +18,7 @@ block-obj-y += block-backend.o snapshot.o qapi.o
 block-obj-$(CONFIG_WIN32) += file-win32.o win32-aio.o
 block-obj-$(CONFIG_POSIX) += file-posix.o
 block-obj-$(CONFIG_LINUX_AIO) += linux-aio.o
-block-obj-y += null.o mirror.o commit.o io.o create.o
+block-obj-y += null.o mirror.o commit.o io.o create.o amend.o
 block-obj-y += throttle-groups.o
 block-obj-$(CONFIG_LINUX) += nvme.o
 
diff --git a/block/amend.c b/block/amend.c
new file mode 100644
index 00..2db7b1eafc
--- /dev/null
+++ b/block/amend.c
@@ -0,0 +1,108 @@
+/*
+ * Block layer code related to image options amend
+ *
+ * Copyright (c) 2018 Kevin Wolf 
+ * Copyright (c) 2019 Maxim Levitsky 
+ *
+ * Heavily based on create.c
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include "qemu/osdep.h"
+#include "block/block_int.h"
+#include "qemu/job.h"
+#include "qemu/main-loop.h"
+#include "qapi/qapi-commands-block-core.h"
+#include "qapi/qapi-visit-block-core.h"
+#include "qapi/clone-visitor.h"
+#include "qapi/error.h"
+
+typedef struct BlockdevAmendJob {
+Job common;
+BlockdevAmendOptions *opts;
+BlockDriverState *bs;
+bool force;
+} BlockdevAmendJob;
+
+static int coroutine_fn blockdev_amend_run(Job *job, Error **errp)
+{
+BlockdevAmendJob *s = container_of(job, BlockdevAmendJob, common);
+int ret;
+
+job_progress_set_remaining(>common, 1);
+ret = s->bs->drv->bdrv_co_amend(s->bs, s->opts, s->force, errp);
+job_progress_update(>common, 1);
+qapi_free_BlockdevAmendOptions(s->opts);
+return ret;
+}
+
+static const JobDriver blockdev_amend_job_driver = {
+.instance_size = sizeof(BlockdevAmendJob),
+.job_type  = JOB_TYPE_AMEND,
+.run   = blockdev_amend_run,
+};
+
+void qmp_x_blockdev_amend(const char *job_id,
+  const char *node_name,
+  BlockdevAmendOptions *options,
+  bool has_force,
+  bool force,
+  Error **errp)
+{
+BlockdevAmendJob *s;
+const char *fmt = BlockdevDriver_str(options->driver);
+BlockDriver *drv = bdrv_find_format(fmt);
+BlockDriverState *bs = bdrv_find_node(node_name);
+
+/*
+ * If the driver is in the schema, we know that it exists. But it may not
+ * be whitelisted.
+ */
+assert(drv);
+if (bdrv_uses_whitelist() && !bdrv_is_whitelisted(drv, false)) {
+error_setg(errp, "Driver is not whitelisted");
+return;
+}
+
+if (bs->drv != drv) {
+error_setg(errp,
+   "x-blockdev-amend doesn't support changing the block 
driver");
+return;
+}
+
+/* Error out if the driver doesn't support .bdrv_co_amend */
+if (!drv->bdrv_co_amend) {
+error_setg(errp, "Driver does not support x-blockdev-amend");
+return;
+}
+
+/* Create the block job */
+s = job_create(job_id, _amend_job_driver, NULL,
+   bdrv_get_aio_context(bs), JOB_DEFAULT | JOB_MANUAL_DISMISS,
+   NULL, NULL, errp);
+if (!s) {
+return;
+}
+
+s->bs = bs,
+s->opts = QAPI_CLONE(BlockdevAmendOptions, options),
+s->force = 

[PATCH 05/13] block/crypto: rename two functions

[Maxim Levitsky]

rename the write_func to create_write_func, and init_func to create_init_func.
This is preparation for other write_func that will be used to update the 
encryption keys.

No functional changes

Signed-off-by: Maxim Levitsky 
Reviewed-by: Daniel P. Berrangé 
---
 block/crypto.c | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/block/crypto.c b/block/crypto.c
index ecf96a7a9b..0b37dae564 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -78,12 +78,12 @@ struct BlockCryptoCreateData {
 };
 
 
-static ssize_t block_crypto_write_func(QCryptoBlock *block,
-   size_t offset,
-   const uint8_t *buf,
-   size_t buflen,
-   void *opaque,
-   Error **errp)
+static ssize_t block_crypto_create_write_func(QCryptoBlock *block,
+  size_t offset,
+  const uint8_t *buf,
+  size_t buflen,
+  void *opaque,
+  Error **errp)
 {
 struct BlockCryptoCreateData *data = opaque;
 ssize_t ret;
@@ -96,11 +96,10 @@ static ssize_t block_crypto_write_func(QCryptoBlock *block,
 return ret;
 }
 
-
-static ssize_t block_crypto_init_func(QCryptoBlock *block,
-  size_t headerlen,
-  void *opaque,
-  Error **errp)
+static ssize_t block_crypto_create_init_func(QCryptoBlock *block,
+ size_t headerlen,
+ void *opaque,
+ Error **errp)
 {
 struct BlockCryptoCreateData *data = opaque;
 
@@ -296,8 +295,8 @@ static int block_crypto_co_create_generic(BlockDriverState 
*bs,
 };
 
 crypto = qcrypto_block_create(opts, NULL,
-  block_crypto_init_func,
-  block_crypto_write_func,
+  block_crypto_create_init_func,
+  block_crypto_create_write_func,
   ,
   errp);
 
-- 
2.17.2

[PATCH 01/13] qcrypto: add generic infrastructure for crypto options amendment

[Maxim Levitsky]

This will be used first to implement luks keyslot management.

block_crypto_amend_opts_init will be used to convert
qemu-img cmdline to QCryptoBlockAmendOptions

Signed-off-by: Maxim Levitsky 
---
 block/crypto.c | 17 +
 block/crypto.h |  3 +++
 crypto/block.c | 31 +++
 crypto/blockpriv.h |  8 
 include/crypto/block.h | 22 ++
 qapi/crypto.json   | 16 
 6 files changed, 97 insertions(+)

diff --git a/block/crypto.c b/block/crypto.c
index 24823835c1..ecf96a7a9b 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -184,6 +184,23 @@ block_crypto_create_opts_init(QDict *opts, Error **errp)
 return ret;
 }
 
+QCryptoBlockAmendOptions *
+block_crypto_amend_opts_init(QDict *opts, Error **errp)
+{
+Visitor *v;
+QCryptoBlockAmendOptions *ret;
+
+v = qobject_input_visitor_new_flat_confused(opts, errp);
+if (!v) {
+return NULL;
+}
+
+visit_type_QCryptoBlockAmendOptions(v, NULL, , errp);
+
+visit_free(v);
+return ret;
+}
+
 
 static int block_crypto_open_generic(QCryptoBlockFormat format,
  QemuOptsList *opts_spec,
diff --git a/block/crypto.h b/block/crypto.h
index b935695e79..06e044c9be 100644
--- a/block/crypto.h
+++ b/block/crypto.h
@@ -91,6 +91,9 @@
 QCryptoBlockCreateOptions *
 block_crypto_create_opts_init(QDict *opts, Error **errp);
 
+QCryptoBlockAmendOptions *
+block_crypto_amend_opts_init(QDict *opts, Error **errp);
+
 QCryptoBlockOpenOptions *
 block_crypto_open_opts_init(QDict *opts, Error **errp);
 
diff --git a/crypto/block.c b/crypto/block.c
index 325752871c..0ce67db641 100644
--- a/crypto/block.c
+++ b/crypto/block.c
@@ -115,6 +115,37 @@ QCryptoBlock 
*qcrypto_block_create(QCryptoBlockCreateOptions *options,
 }
 
 
+int qcrypto_block_amend_options(QCryptoBlock *block,
+QCryptoBlockReadFunc readfunc,
+QCryptoBlockWriteFunc writefunc,
+void *opaque,
+QCryptoBlockAmendOptions *options,
+bool force,
+Error **errp)
+{
+if (options->format != block->format) {
+error_setg(errp,
+   "Cannot amend encryption format");
+return -1;
+}
+
+if (!block->driver->amend) {
+error_setg(errp,
+   "Crypto format %s doesn't support format options amendment",
+   QCryptoBlockFormat_str(block->format));
+return -1;
+}
+
+return block->driver->amend(block,
+readfunc,
+writefunc,
+opaque,
+options,
+force,
+errp);
+}
+
+
 QCryptoBlockInfo *qcrypto_block_get_info(QCryptoBlock *block,
  Error **errp)
 {
diff --git a/crypto/blockpriv.h b/crypto/blockpriv.h
index 71c59cb542..3c7ccea504 100644
--- a/crypto/blockpriv.h
+++ b/crypto/blockpriv.h
@@ -62,6 +62,14 @@ struct QCryptoBlockDriver {
   void *opaque,
   Error **errp);
 
+int (*amend)(QCryptoBlock *block,
+ QCryptoBlockReadFunc readfunc,
+ QCryptoBlockWriteFunc writefunc,
+ void *opaque,
+ QCryptoBlockAmendOptions *options,
+ bool force,
+ Error **errp);
+
 int (*get_info)(QCryptoBlock *block,
 QCryptoBlockInfo *info,
 Error **errp);
diff --git a/include/crypto/block.h b/include/crypto/block.h
index d49d2c2da9..e4553cf33d 100644
--- a/include/crypto/block.h
+++ b/include/crypto/block.h
@@ -144,6 +144,28 @@ QCryptoBlock 
*qcrypto_block_create(QCryptoBlockCreateOptions *options,
void *opaque,
Error **errp);
 
+/**
+ * qcrypto_block_amend_options:
+ * @block: the block encryption object
+ *
+ * @readfunc: callback for reading data from the volume header
+ * @writefunc: callback for writing data to the volume header
+ * @opaque: data to pass to @readfunc and @writefunc
+ * @options: the new/amended encryption options
+ * @force: hint for the driver to allow unsafe operation
+ * @errp: error pointer
+ *
+ * Changes the crypto options of the encryption format
+ *
+ */
+int qcrypto_block_amend_options(QCryptoBlock *block,
+QCryptoBlockReadFunc readfunc,
+QCryptoBlockWriteFunc writefunc,
+void *opaque,
+QCryptoBlockAmendOptions *options,
+bool force,
+Error **errp);
+
 
 /**
  * qcrypto_block_get_info:
diff --git a/qapi/crypto.json 

[PATCH 07/13] qcow2: extend qemu-img amend interface with crypto options

[Maxim Levitsky]

Now that we have all the infrastructure in place,
wire it in the qcow2 driver and expose this to the user.

Signed-off-by: Maxim Levitsky 
---
 block/qcow2.c | 101 +++---
 1 file changed, 79 insertions(+), 22 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index c6c2deee75..1b01174aed 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -173,6 +173,19 @@ static ssize_t qcow2_crypto_hdr_write_func(QCryptoBlock 
*block, size_t offset,
 return ret;
 }
 
+static QDict*
+qcow2_extract_crypto_opts(QemuOpts *opts, const char *fmt, Error **errp)
+{
+QDict *cryptoopts_qdict;
+QDict *opts_qdict;
+
+/* Extract "encrypt." options into a qdict */
+opts_qdict = qemu_opts_to_qdict(opts, NULL);
+qdict_extract_subqdict(opts_qdict, _qdict, "encrypt.");
+qobject_unref(opts_qdict);
+qdict_put_str(cryptoopts_qdict, "format", "luks");
+return cryptoopts_qdict;
+}
 
 /* 
  * read qcow2 extension and fill bs
@@ -4631,20 +4644,18 @@ static ssize_t 
qcow2_measure_crypto_hdr_write_func(QCryptoBlock *block,
 static bool qcow2_measure_luks_headerlen(QemuOpts *opts, size_t *len,
  Error **errp)
 {
-QDict *opts_qdict;
-QDict *cryptoopts_qdict;
 QCryptoBlockCreateOptions *cryptoopts;
+QDict* crypto_opts_dict;
 QCryptoBlock *crypto;
 
-/* Extract "encrypt." options into a qdict */
-opts_qdict = qemu_opts_to_qdict(opts, NULL);
-qdict_extract_subqdict(opts_qdict, _qdict, "encrypt.");
-qobject_unref(opts_qdict);
+crypto_opts_dict = qcow2_extract_crypto_opts(opts, "luks", errp);
+if (!crypto_opts_dict) {
+return false;
+}
+
+cryptoopts = block_crypto_create_opts_init(crypto_opts_dict, errp);
+qobject_unref(crypto_opts_dict);
 
-/* Build QCryptoBlockCreateOptions object from qdict */
-qdict_put_str(cryptoopts_qdict, "format", "luks");
-cryptoopts = block_crypto_create_opts_init(cryptoopts_qdict, errp);
-qobject_unref(cryptoopts_qdict);
 if (!cryptoopts) {
 return false;
 }
@@ -5083,6 +5094,7 @@ typedef enum Qcow2AmendOperation {
 QCOW2_NO_OPERATION = 0,
 
 QCOW2_UPGRADING,
+QCOW2_UPDATING_ENCRYPTION,
 QCOW2_CHANGING_REFCOUNT_ORDER,
 QCOW2_DOWNGRADING,
 } Qcow2AmendOperation;
@@ -5167,6 +5179,7 @@ static int qcow2_amend_options(BlockDriverState *bs, 
QemuOpts *opts,
 int ret;
 QemuOptDesc *desc = opts->list->desc;
 Qcow2AmendHelperCBInfo helper_cb_info;
+bool encryption_update = false;
 
 while (desc && desc->name) {
 if (!qemu_opt_find(opts, desc->name)) {
@@ -5215,9 +5228,17 @@ static int qcow2_amend_options(BlockDriverState *bs, 
QemuOpts *opts,
 return -ENOTSUP;
 }
 } else if (g_str_has_prefix(desc->name, "encrypt.")) {
-error_setg(errp,
-   "Changing the encryption parameters is not supported");
-return -ENOTSUP;
+if (!s->crypto) {
+error_setg(errp,
+   "Can't amend encryption options - encryption not 
present");
+return -EINVAL;
+}
+if (s->crypt_method_header != QCOW_CRYPT_LUKS) {
+error_setg(errp,
+   "Only LUKS encryption options can be amended");
+return -ENOTSUP;
+}
+encryption_update = true;
 } else if (!strcmp(desc->name, BLOCK_OPT_CLUSTER_SIZE)) {
 cluster_size = qemu_opt_get_size(opts, BLOCK_OPT_CLUSTER_SIZE,
  cluster_size);
@@ -5267,7 +5288,8 @@ static int qcow2_amend_options(BlockDriverState *bs, 
QemuOpts *opts,
 .original_status_cb = status_cb,
 .original_cb_opaque = cb_opaque,
 .total_operations = (new_version != old_version)
-  + (s->refcount_bits != refcount_bits)
+  + (s->refcount_bits != refcount_bits) +
+(encryption_update == true)
 };
 
 /* Upgrade first (some features may require compat=1.1) */
@@ -5280,6 +5302,33 @@ static int qcow2_amend_options(BlockDriverState *bs, 
QemuOpts *opts,
 }
 }
 
+if (encryption_update) {
+QDict *amend_opts_dict;
+QCryptoBlockAmendOptions *amend_opts;
+
+helper_cb_info.current_operation = QCOW2_UPDATING_ENCRYPTION;
+amend_opts_dict = qcow2_extract_crypto_opts(opts, "luks", errp);
+if (!amend_opts_dict) {
+return -EINVAL;
+}
+amend_opts = block_crypto_amend_opts_init(amend_opts_dict, errp);
+qobject_unref(amend_opts_dict);
+if (!amend_opts) {
+return -EINVAL;
+}
+ret = qcrypto_block_amend_options(s->crypto,
+  qcow2_crypto_hdr_read_func,
+  qcow2_crypto_hdr_write_func,
+  

[PATCH 00/13] LUKS: encryption slot management using amend interface

[Maxim Levitsky]

Hi!

Here is the updated series of my patches, incorporating all the feedback I 
received.

Patches are strictly divided by topic to 3 groups, and each group depends on 
former groups.

* Patches 1,2 implement qcrypto generic amend interface, including definition
  of structs used in crypto.json and implement this in luks crypto driver
  Nothing is exposed to the user at this stage

* Patches 3-9 use the code from patches 1,2 to implement qemu-img amend based 
encryption slot management
  for luks and for qcow2, and add a bunch of iotests to cover that.

* Patches 10-13 add x-blockdev-amend (I'll drop the -x prefix if you like), and 
wire it
  to luks and qcow2 driver to implement qmp based encryption slot management 
also using
  the code from patches 1,2, and also add a bunch of iotests to cover this.

Best regards,
Maxim Levitsky

Maxim Levitsky (13):
  qcrypto: add generic infrastructure for crypto options amendment
  qcrypto-luks: implement encryption key management
  block: amend: add 'force' option
  block: amend: separate amend and create options for qemu-img
  block/crypto: rename two functions
  block/crypto: implement the encryption key management
  qcow2: extend qemu-img amend interface with crypto options
  iotests: filter few more luks specific create options
  qemu-iotests: qemu-img tests for luks key management
  block: add generic infrastructure for x-blockdev-amend qmp command
  block/crypto: implement blockdev-amend
  block/qcow2: implement blockdev-amend
  iotests: add tests for blockdev-amend

 block.c  |   4 +-
 block/Makefile.objs  |   2 +-
 block/amend.c| 108 +
 block/crypto.c   | 204 +++--
 block/crypto.h   |  34 +++
 block/qcow2.c| 269 +++---
 crypto/block-luks.c  | 374 ++-
 crypto/block.c   |  31 +++
 crypto/blockpriv.h   |   8 +
 include/block/block.h|   1 +
 include/block/block_int.h|  24 +-
 include/crypto/block.h   |  22 ++
 qapi/block-core.json |  68 ++
 qapi/crypto.json |  64 ++
 qapi/job.json|   4 +-
 qemu-img-cmds.hx |   4 +-
 qemu-img.c   |  26 ++-
 qemu-img.texi|   6 +-
 tests/qemu-iotests/087.out   |   6 +-
 tests/qemu-iotests/134.out   |   2 +-
 tests/qemu-iotests/158.out   |   4 +-
 tests/qemu-iotests/188.out   |   2 +-
 tests/qemu-iotests/189.out   |   4 +-
 tests/qemu-iotests/198.out   |   4 +-
 tests/qemu-iotests/300   | 207 +
 tests/qemu-iotests/300.out   |  99 
 tests/qemu-iotests/301   |  90 
 tests/qemu-iotests/301.out   |  30 +++
 tests/qemu-iotests/302   | 284 +++
 tests/qemu-iotests/302.out   |  40 
 tests/qemu-iotests/303   | 235 +++
 tests/qemu-iotests/303.out   |  33 +++
 tests/qemu-iotests/common.filter |   6 +-
 tests/qemu-iotests/group |   6 +
 34 files changed, 2174 insertions(+), 131 deletions(-)
 create mode 100644 block/amend.c
 create mode 100755 tests/qemu-iotests/300
 create mode 100644 tests/qemu-iotests/300.out
 create mode 100755 tests/qemu-iotests/301
 create mode 100644 tests/qemu-iotests/301.out
 create mode 100644 tests/qemu-iotests/302
 create mode 100644 tests/qemu-iotests/302.out
 create mode 100644 tests/qemu-iotests/303
 create mode 100644 tests/qemu-iotests/303.out

-- 
2.17.2

[PATCH 04/13] block: amend: separate amend and create options for qemu-img

[Maxim Levitsky]

Some options are only useful for creation
(or hard to be amended, like cluster size for qcow2), while some other
options are only useful for amend, like upcoming keyslot management
options for luks

Since currently only qcow2 supports amend, move all its options
to a common macro and then include it in each action option list.

In future it might be useful to remove some options which are
not supported anyway from amend list, which currently
cause an error message if amended.

Signed-off-by: Maxim Levitsky 
---
 block/qcow2.c | 160 +-
 include/block/block_int.h |   4 +
 qemu-img.c|  18 ++---
 3 files changed, 100 insertions(+), 82 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index 6bcf4a5fc4..c6c2deee75 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -5445,83 +5445,96 @@ void qcow2_signal_corruption(BlockDriverState *bs, bool 
fatal, int64_t offset,
 s->signaled_corruption = true;
 }
 
+#define QCOW_COMMON_OPTIONS \
+{   \
+.name = BLOCK_OPT_SIZE, \
+.type = QEMU_OPT_SIZE,  \
+.help = "Virtual disk size" \
+},  \
+{   \
+.name = BLOCK_OPT_COMPAT_LEVEL, \
+.type = QEMU_OPT_STRING,\
+.help = "Compatibility level (v2 [0.10] or v3 [1.1])"   \
+},  \
+{   \
+.name = BLOCK_OPT_BACKING_FILE, \
+.type = QEMU_OPT_STRING,\
+.help = "File name of a base image" \
+},  \
+{   \
+.name = BLOCK_OPT_BACKING_FMT,  \
+.type = QEMU_OPT_STRING,\
+.help = "Image format of the base image"\
+},  \
+{   \
+.name = BLOCK_OPT_DATA_FILE,\
+.type = QEMU_OPT_STRING,\
+.help = "File name of an external data file"\
+},  \
+{   \
+.name = BLOCK_OPT_DATA_FILE_RAW,\
+.type = QEMU_OPT_BOOL,  \
+.help = "The external data file must stay valid "   \
+"as a raw image"\
+},  \
+{   \
+.name = BLOCK_OPT_ENCRYPT,  \
+.type = QEMU_OPT_BOOL,  \
+.help = "Encrypt the image with format 'aes'. (Deprecated " \
+"in favor of " BLOCK_OPT_ENCRYPT_FORMAT "=aes)",\
+},  \
+{   \
+.name = BLOCK_OPT_ENCRYPT_FORMAT,   \
+.type = QEMU_OPT_STRING,\
+.help = "Encrypt the image, format choices: 'aes', 'luks'", \
+},  \
+BLOCK_CRYPTO_OPT_DEF_KEY_SECRET("encrypt.", \
+"ID of secret providing qcow AES key or LUKS passphrase"),  \
+BLOCK_CRYPTO_OPT_DEF_LUKS_CIPHER_ALG("encrypt."),   \
+BLOCK_CRYPTO_OPT_DEF_LUKS_CIPHER_MODE("encrypt."),  \
+BLOCK_CRYPTO_OPT_DEF_LUKS_IVGEN_ALG("encrypt."),\
+BLOCK_CRYPTO_OPT_DEF_LUKS_IVGEN_HASH_ALG("encrypt."),   \
+BLOCK_CRYPTO_OPT_DEF_LUKS_HASH_ALG("encrypt."), \
+BLOCK_CRYPTO_OPT_DEF_LUKS_ITER_TIME("encrypt."),\
+{   \
+.name = BLOCK_OPT_CLUSTER_SIZE, \
+.type = QEMU_OPT_SIZE,  \
+.help = "qcow2 cluster size",   \
+.def_value_str = stringify(DEFAULT_CLUSTER_SIZE)\
+},   

[PATCH 03/13] block: amend: add 'force' option

[Maxim Levitsky]

'force' option will be used for some unsafe amend operations.

This includes things like erasing last keyslot in luks based formats
(which destroys the data, unless the master key is backed up
by external means), but that _might_ be desired result.

Signed-off-by: Maxim Levitsky 
Reviewed-by: Daniel P. Berrangé 
---
 block.c   | 4 +++-
 block/qcow2.c | 1 +
 include/block/block.h | 1 +
 include/block/block_int.h | 1 +
 qemu-img-cmds.hx  | 4 ++--
 qemu-img.c| 8 +++-
 qemu-img.texi | 6 +-
 7 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/block.c b/block.c
index ecd09dbbfd..cb9d5f1965 100644
--- a/block.c
+++ b/block.c
@@ -6164,6 +6164,7 @@ void bdrv_remove_aio_context_notifier(BlockDriverState 
*bs,
 
 int bdrv_amend_options(BlockDriverState *bs, QemuOpts *opts,
BlockDriverAmendStatusCB *status_cb, void *cb_opaque,
+   bool force,
Error **errp)
 {
 if (!bs->drv) {
@@ -6175,7 +6176,8 @@ int bdrv_amend_options(BlockDriverState *bs, QemuOpts 
*opts,
bs->drv->format_name);
 return -ENOTSUP;
 }
-return bs->drv->bdrv_amend_options(bs, opts, status_cb, cb_opaque, errp);
+return bs->drv->bdrv_amend_options(bs, opts, status_cb,
+   cb_opaque, force, errp);
 }
 
 /* This function will be called by the bdrv_recurse_is_first_non_filter method
diff --git a/block/qcow2.c b/block/qcow2.c
index cef9d72b3a..6bcf4a5fc4 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -5150,6 +5150,7 @@ static void qcow2_amend_helper_cb(BlockDriverState *bs,
 static int qcow2_amend_options(BlockDriverState *bs, QemuOpts *opts,
BlockDriverAmendStatusCB *status_cb,
void *cb_opaque,
+   bool force,
Error **errp)
 {
 BDRVQcow2State *s = bs->opaque;
diff --git a/include/block/block.h b/include/block/block.h
index e9dcfef7fa..d0cd1b2da0 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -399,6 +399,7 @@ typedef void BlockDriverAmendStatusCB(BlockDriverState *bs, 
int64_t offset,
   int64_t total_work_size, void *opaque);
 int bdrv_amend_options(BlockDriverState *bs_new, QemuOpts *opts,
BlockDriverAmendStatusCB *status_cb, void *cb_opaque,
+   bool force,
Error **errp);
 
 /* external snapshots */
diff --git a/include/block/block_int.h b/include/block/block_int.h
index dd033d0b37..810a9ecb86 100644
--- a/include/block/block_int.h
+++ b/include/block/block_int.h
@@ -427,6 +427,7 @@ struct BlockDriver {
 int (*bdrv_amend_options)(BlockDriverState *bs, QemuOpts *opts,
   BlockDriverAmendStatusCB *status_cb,
   void *cb_opaque,
+  bool force,
   Error **errp);
 
 void (*bdrv_debug_event)(BlockDriverState *bs, BlkdebugEvent event);
diff --git a/qemu-img-cmds.hx b/qemu-img-cmds.hx
index 1c93e6d185..323ea10ad0 100644
--- a/qemu-img-cmds.hx
+++ b/qemu-img-cmds.hx
@@ -14,9 +14,9 @@ STEXI
 ETEXI
 
 DEF("amend", img_amend,
-"amend [--object objectdef] [--image-opts] [-p] [-q] [-f fmt] [-t cache] 
-o options filename")
+"amend [--object objectdef] [--image-opts] [-p] [-q] [-f fmt] [-t cache] 
[--force] -o options filename")
 STEXI
-@item amend [--object @var{objectdef}] [--image-opts] [-p] [-q] [-f @var{fmt}] 
[-t @var{cache}] -o @var{options} @var{filename}
+@item amend [--object @var{objectdef}] [--image-opts] [-p] [-q] [-f @var{fmt}] 
[-t @var{cache}] [--force] -o @var{options} @var{filename}
 ETEXI
 
 DEF("bench", img_bench,
diff --git a/qemu-img.c b/qemu-img.c
index 6233b8ca56..a79f3904db 100644
--- a/qemu-img.c
+++ b/qemu-img.c
@@ -70,6 +70,7 @@ enum {
 OPTION_PREALLOCATION = 265,
 OPTION_SHRINK = 266,
 OPTION_SALVAGE = 267,
+OPTION_FORCE = 268,
 };
 
 typedef enum OutputFormat {
@@ -3900,6 +3901,7 @@ static int img_amend(int argc, char **argv)
 BlockBackend *blk = NULL;
 BlockDriverState *bs = NULL;
 bool image_opts = false;
+bool force = false;
 
 cache = BDRV_DEFAULT_CACHE;
 for (;;) {
@@ -3907,6 +3909,7 @@ static int img_amend(int argc, char **argv)
 {"help", no_argument, 0, 'h'},
 {"object", required_argument, 0, OPTION_OBJECT},
 {"image-opts", no_argument, 0, OPTION_IMAGE_OPTS},
+{"force", no_argument, 0, OPTION_FORCE},
 {0, 0, 0, 0}
 };
 c = getopt_long(argc, argv, ":ho:f:t:pq",
@@ -3962,6 +3965,9 @@ static int img_amend(int argc, char **argv)
 case OPTION_IMAGE_OPTS:
 image_opts = true;
 break;
+case OPTION_FORCE:
+force = true;
+break;
 }
 }
 
@@ -4039,7 

Re: [PATCH v12 12/13] virtio-iommu: Support migration

[Peter Xu]

On Thu, Jan 09, 2020 at 03:43:18PM +0100, Eric Auger wrote:
> Add Migration support. We rely on recently added gtree and qlist
> migration. We only migrate the domain gtree. The endpoint gtree
> is re-constructed in a post-load operation.
> 
> Signed-off-by: Eric Auger 

Acked-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v12 09/13] virtio-iommu: Implement fault reporting

[Peter Xu]

On Thu, Jan 09, 2020 at 03:43:15PM +0100, Eric Auger wrote:
> The event queue allows to report asynchronous errors.
> The translate function now injects faults when relevant.
> 
> Signed-off-by: Eric Auger 
> 
> ---
> 
> v11 -> v12:
> - reporting the addr associated with the fault and set the
>   VIRTIO_IOMMU_FAULT_F_ADDRESS flag.
> - added cpu_to_le
> 
> v10 -> v11:
> - change a virtio_error into an error_report_once
>   (no buffer available for output faults)
> ---
>  hw/virtio/trace-events   |  1 +
>  hw/virtio/virtio-iommu.c | 73 +---
>  2 files changed, 69 insertions(+), 5 deletions(-)
> 
> diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
> index 095aa8b509..e83500bee9 100644
> --- a/hw/virtio/trace-events
> +++ b/hw/virtio/trace-events
> @@ -72,3 +72,4 @@ virtio_iommu_put_endpoint(uint32_t ep_id) "Free endpoint=%d"
>  virtio_iommu_get_domain(uint32_t domain_id) "Alloc domain=%d"
>  virtio_iommu_put_domain(uint32_t domain_id) "Free domain=%d"
>  virtio_iommu_translate_out(uint64_t virt_addr, uint64_t phys_addr, uint32_t 
> sid) "0x%"PRIx64" -> 0x%"PRIx64 " for sid=%d"
> +virtio_iommu_report_fault(uint8_t reason, uint32_t flags, uint32_t endpoint, 
> uint64_t addr) "FAULT reason=%d flags=%d endpoint=%d address =0x%"PRIx64
> diff --git a/hw/virtio/virtio-iommu.c b/hw/virtio/virtio-iommu.c
> index d192bcb505..09193970ee 100644
> --- a/hw/virtio/virtio-iommu.c
> +++ b/hw/virtio/virtio-iommu.c
> @@ -477,6 +477,51 @@ out:
>  }
>  }
>  
> +static void virtio_iommu_report_fault(VirtIOIOMMU *viommu, uint8_t reason,
> +  int flags, uint32_t endpoint,
> +  uint64_t address)
> +{
> +VirtIODevice *vdev = >parent_obj;
> +VirtQueue *vq = viommu->event_vq;
> +struct virtio_iommu_fault fault;
> +VirtQueueElement *elem;
> +size_t sz;
> +
> +memset(, 0, sizeof(fault));
> +fault.reason = reason;
> +fault.flags = cpu_to_le32(flags);
> +fault.endpoint = cpu_to_le32(endpoint);
> +fault.address = cpu_to_le64(address);
> +
> +for (;;) {
> +elem = virtqueue_pop(vq, sizeof(VirtQueueElement));
> +
> +if (!elem) {
> +error_report_once(
> +"no buffer available in event queue to report event");

(Should this also be a guest issue?  IIRC you are still using a
 mixture of both qemu_log_mask and error_report()... I'll stop
 commenting on this, assuming that you prefer both ways to be used...)

> +return;
> +}
> +
> +if (iov_size(elem->in_sg, elem->in_num) < sizeof(fault)) {
> +virtio_error(vdev, "error buffer of wrong size");
> +virtqueue_detach_element(vq, elem, 0);
> +g_free(elem);
> +continue;

If virtio_error(), should we stop rather than continue?

> +}
> +break;
> +}
> +/* we have a buffer to fill in */
> +sz = iov_from_buf(elem->in_sg, elem->in_num, 0,
> +  , sizeof(fault));
> +assert(sz == sizeof(fault));
> +
> +trace_virtio_iommu_report_fault(reason, flags, endpoint, address);
> +virtqueue_push(vq, elem, sz);
> +virtio_notify(vdev, vq);
> +g_free(elem);
> +
> +}
> +
>  static IOMMUTLBEntry virtio_iommu_translate(IOMMUMemoryRegion *mr, hwaddr 
> addr,
>  IOMMUAccessFlags flag,
>  int iommu_idx)
> @@ -485,9 +530,10 @@ static IOMMUTLBEntry 
> virtio_iommu_translate(IOMMUMemoryRegion *mr, hwaddr addr,
>  VirtIOIOMMUInterval interval, *mapping_key;
>  VirtIOIOMMUMapping *mapping_value;
>  VirtIOIOMMU *s = sdev->viommu;
> +bool read_fault, write_fault;
>  VirtIOIOMMUEndpoint *ep;
> +uint32_t sid, flags;
>  bool bypass_allowed;
> -uint32_t sid;
>  bool found;
>  
>  interval.low = addr;
> @@ -513,6 +559,9 @@ static IOMMUTLBEntry 
> virtio_iommu_translate(IOMMUMemoryRegion *mr, hwaddr addr,
>  if (!ep) {
>  if (!bypass_allowed) {
>  error_report_once("%s sid=%d is not known!!", __func__, sid);
> +virtio_iommu_report_fault(s, VIRTIO_IOMMU_FAULT_R_UNKNOWN,
> +  VIRTIO_IOMMU_FAULT_F_ADDRESS,
> +  sid, addr);
>  } else {
>  entry.perm = flag;
>  }
> @@ -524,6 +573,9 @@ static IOMMUTLBEntry 
> virtio_iommu_translate(IOMMUMemoryRegion *mr, hwaddr addr,
>  error_report_once("%s %02x:%02x.%01x not attached to any domain",
>__func__, PCI_BUS_NUM(sid),
>PCI_SLOT(sid), PCI_FUNC(sid));
> +virtio_iommu_report_fault(s, VIRTIO_IOMMU_FAULT_R_DOMAIN,
> +  VIRTIO_IOMMU_FAULT_F_ADDRESS,
> +  sid, addr);
>  } else {
>  entry.perm = flag;
>  }
> @@ -536,15 

Re: [PATCH v2 0/4] qmp: Optionally run handlers in coroutines

[Kevin Wolf]

Am 14.01.2020 um 19:45 hat Daniel P. Berrangé geschrieben:
> On Tue, Jan 14, 2020 at 07:27:31PM +0100, Kevin Wolf wrote:
> > Some QMP command handlers can block the main loop for a relatively long
> > time, for example because they perform some I/O. This is quite nasty.
> > Allowing such handlers to run in a coroutine where they can yield (and
> > therefore release the BQL) while waiting for an event such as I/O
> > completion solves the problem.
> 
> Am I right that with this approach, there's no functional difference
> to QMP from a mgmt app POV ? ie this is purely focused on avoiding
> stalls in the main event loop which impact the guest OS and other
> parts of QEMU ?
> 
> IOW, the response to the QMP command being executed will get sent
> back to the mgmt app as normal when the command completes, and the
> QMP monitor still serializes execution of commands ?

Yes, the QMP dispatcher still processes one request after another. The
only visible effect should be that the guest and other background tasks
aren't blocked.

> > This series adds the infrastructure to allow this and switches
> > block_resize to run in a coroutine as a first example.
> > 
> > This is an alternative solution to Marc-André's "monitor: add
> > asynchronous command type" series.
> 
> Where as this is an actual functional improvement to QMP from
> the mgmt app POV in allowing background commands & thus
> concurrent execution ?
> 
> If this is correct, then the two proposals are somewhat
> complementary 

Marc-André's first proposal (maybe two years ago) actually added real
asynchronous commands to the protocol. But his latest versions gave up
on this and made commands only internally asynchronous, with pretty much
the same effect as this series.

If we ever do want to extend the protocol to have async commands on the
protocol level, this can still be done on top. There is no fundamental
problem that would prevent just launching a coroutine for each parallel
request. In fact, this series is probably the first step that you would
make anyway to even have something that can be parallelised.

Kevin

Re: [PATCH v5 00/22] gdbstub refactor and SVE support (+check-tcg tweaks)

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20200114150953.27659-1-alex.ben...@linaro.org/



Hi,

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

Subject: [PATCH v5 00/22] gdbstub refactor and SVE support (+check-tcg tweaks)
Type: series
Message-id: 20200114150953.27659-1-alex.ben...@linaro.org

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

Switched to a new branch 'test'
f83dc98 gdbstub: do not split gdb_monitor_write payload
7bf749e gdbstub: change GDBState.last_packet to GByteArray
2b88cdc tests/tcg/aarch64: add test-sve-ioctl guest-debug test
754f7ef tests/tcg/aarch64: add SVE iotcl test
c5d2630 tests/tcg/aarch64: add a gdbstub testcase for SVE registers
a80564a tests/guest-debug: add a simple test runner
edea27c configure: allow user to specify what gdb to use
c8e17aa tests/tcg/aarch64: userspace system register test
6f35e94 target/arm: don't bother with id_aa64pfr0_read for USER_ONLY
3bc14fe tests/tcg: add a configure compiler check for ARMv8.1 and SVE
2b904bc target/arm: generate xml description of our SVE registers
38d665c target/arm: default SVE length to 64 bytes for linux-user
8c07558 target/arm: explicitly encode regnum in our XML
37f8e9f target/arm: prepare for multiple dynamic XMLs
f13a871 gdbstub: extend GByteArray to read register helpers
3576ab6 target/m68k: use gdb_get_reg helpers
a25d2c6 target/arm: use gdb_get_reg helpers
d257321 gdbstub: add helper for 128 bit registers
718b8ce gdbstub: move mem_buf to GDBState and use GByteArray
e289622 gdbstub: move str_buf to GDBState and use GString
c29be44 gdbstub: stop passing GDBState * around and use global
dbb9c64 gdbstub: make GDBState static and have common init function

=== OUTPUT BEGIN ===
1/22 Checking commit dbb9c64bfad9 (gdbstub: make GDBState static and have 
common init function)
ERROR: braces {} are necessary for all arms of this statement
#128: FILE: gdbstub.c:2743:
+if (!gdbserver_state.init)
[...]

ERROR: suspect code indent for conditional statements (2, 6)
#178: FILE: gdbstub.c:2962:
+  if (!gdbserver_state.init) {
   return;

ERROR: suspect code indent for conditional statements (2, 6)
#183: FILE: gdbstub.c:2966:
+  if (gdbserver_fd < 0 || gdbserver_state.fd < 0) {
   return;

total: 3 errors, 0 warnings, 384 lines checked

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

2/22 Checking commit c29be445fc79 (gdbstub: stop passing GDBState * around and 
use global)
WARNING: line over 80 characters
#754: FILE: gdbstub.c:1762:
+if (target_memory_rw_debug(gdbserver_state.g_cpu, 
gdb_ctx->params[0].val_ull,

WARNING: line over 80 characters
#782: FILE: gdbstub.c:1785:
+if (target_memory_rw_debug(gdbserver_state.g_cpu, 
gdb_ctx->params[0].val_ull,

WARNING: line over 80 characters
#1009: FILE: gdbstub.c:2022:
+gdbserver_state.query_cpu = 
gdb_next_attached_cpu(gdbserver_state.query_cpu);

ERROR: line over 90 characters
#1370: FILE: gdbstub.c:2817:
+put_buffer((uint8_t *)gdbserver_state.last_packet, 
gdbserver_state.last_packet_len);

ERROR: space required before the open parenthesis '('
#1388: FILE: gdbstub.c:2836:
+switch(gdbserver_state.state) {

ERROR: line over 90 characters
#1420: FILE: gdbstub.c:2859:
+} else if (gdbserver_state.line_buf_index >= 
sizeof(gdbserver_state.line_buf) - 1) {

ERROR: line over 90 characters
#1438: FILE: gdbstub.c:2872:
+} else if (gdbserver_state.line_buf_index >= 
sizeof(gdbserver_state.line_buf) - 1) {

WARNING: line over 80 characters
#1448: FILE: gdbstub.c:2878:
+gdbserver_state.line_buf[gdbserver_state.line_buf_index++] = 
ch ^ 0x20;

ERROR: line over 90 characters
#1464: FILE: gdbstub.c:2895:
+if (gdbserver_state.line_buf_index + repeat >= 
sizeof(gdbserver_state.line_buf) - 1) {

WARNING: line over 80 characters
#1482: FILE: gdbstub.c:2905:
+memset(gdbserver_state.line_buf + 
gdbserver_state.line_buf_index,

ERROR: line over 90 characters
#1483: FILE: gdbstub.c:2906:
+   
gdbserver_state.line_buf[gdbserver_state.line_buf_index - 1], repeat);

WARNING: line over 80 characters
#1518: FILE: gdbstub.c:2933:
+if (gdbserver_state.line_csum != (gdbserver_state.line_sum & 
0xff)) {

ERROR: line over 90 characters
#1519: FILE: gdbstub.c:2934:
+trace_gdbstub_err_checksum_incorrect(gdbserver_state.line_sum, 
gdbserver_state.line_csum);

WARNING: line over 80 characters
#1532: FILE: gdbstub.c:2943:
+gdbserver_state.state = 
gdb_handle_packet(gdbserver_state.line_buf);

ERROR: line over 90 characters
#1647: FILE: gdbstub.c:3305:
+

Re: [PATCH v12 07/13] virtio-iommu: Implement map/unmap

[Peter Xu]

On Thu, Jan 09, 2020 at 03:43:13PM +0100, Eric Auger wrote:
> This patch implements virtio_iommu_map/unmap.
> 
> Signed-off-by: Eric Auger 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH] hw/vfio: Move the IGD quirk code to a separate file

[Philippe Mathieu-Daudé]

On 1/14/20 7:47 PM, Alex Williamson wrote:

On Tue, 14 Jan 2020 18:10:26 +0100
Philippe Mathieu-Daudé  wrote:


On 1/14/20 5:17 PM, Thomas Huth wrote:

The IGD quirk code defines a separate device, the so-called
"vfio-pci-igd-lpc-bridge" which shows up as a user-creatable
device in all QEMU binaries that include the vfio code. This
is a little bit unfortunate for two reasons: First, this device
is completely useless in binaries like qemu-system-s390x.
Second we also would like to disable it in downstream RHEL
which currently requires some extra patches there since the
device does not have a proper Kconfig-style switch yet.

So it would be good if the device could be disabled more easily,
thus let's move the code to a separate file instead and introduce
a proper Kconfig switch for it which gets only enabled by default
if we also have CONFIG_PC_PCI enabled.

Signed-off-by: Thomas Huth 
---
   hw/vfio/Kconfig   |   5 +
   hw/vfio/Makefile.objs |   1 +
   hw/vfio/igd.c | 616 ++
   hw/vfio/pci-quirks.c  | 614 +
   hw/vfio/pci.h |  17 ++
   5 files changed, 642 insertions(+), 611 deletions(-)
   create mode 100644 hw/vfio/igd.c

diff --git a/hw/vfio/Kconfig b/hw/vfio/Kconfig
index f0eaa75ce7..7cdba0560a 100644
--- a/hw/vfio/Kconfig
+++ b/hw/vfio/Kconfig
@@ -36,3 +36,8 @@ config VFIO_AP
   default y
   select VFIO
   depends on LINUX && S390_CCW_VIRTIO
+
+config VFIO_IGD
+bool
+default y if PC_PCI


With the details from Alex here:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg663667.html

I'm tempted to use:

  default y if XEN
  depends on PC_PCI


I think you might be confused, there are two separate LPC bridges in
QEMU for IGD support, one specifically for Xen and this one
specifically for VFIO.  This one is never used in a Xen environment.


Argh I see, OK!


Watch out the Xen Kconfig seems fragile, yesterday using --enable-xen
--disable-tcg I hit this build error:

LINKi386-softmmu/qemu-system-i386
/usr/bin/ld: hw/xen/xen_pt.o: in function
`xen_igd_passthrough_isa_bridge_create':
/home/phil/source/qemu/hw/xen/xen_pt.c:701: undefined reference to
`igd_passthrough_isa_bridge_create'


+depends on VFIO_PCI
diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
index abad8b818c..9bb1c09e84 100644
--- a/hw/vfio/Makefile.objs
+++ b/hw/vfio/Makefile.objs
@@ -5,3 +5,4 @@ obj-$(CONFIG_VFIO_PLATFORM) += platform.o
   obj-$(CONFIG_VFIO_XGMAC) += calxeda-xgmac.o
   obj-$(CONFIG_VFIO_AMD_XGBE) += amd-xgbe.o
   obj-$(CONFIG_VFIO_AP) += ap.o
+obj-$(CONFIG_VFIO_IGD) += igd.o

Re: [PATCH v12 04/13] virtio-iommu: Add the iommu regions

[Peter Xu]

On Tue, Jan 14, 2020 at 09:37:51AM +0100, Auger Eric wrote:
> > In all cases, I see that virtio_iommu_mr() is introduced but not used.
> > Would be good to put it into the patch where it's firstly used.
> OK fair enough, I will put the helper in the same patch as the user as
> you have requested that since the beginning ;-) The resulting patch may
> be huge. Just hope nobody will request me to split it back ;-)

We can wait for a few more days and see whether someone will have a
different answer before you start to squash things. :)

In all cases, I think we should get rid of the compiler trick at
least.

Thanks,

-- 
Peter Xu

Re: [PATCH] hw/vfio: Move the IGD quirk code to a separate file

[Alex Williamson]

On Tue, 14 Jan 2020 18:10:26 +0100
Philippe Mathieu-Daudé  wrote:

> On 1/14/20 5:17 PM, Thomas Huth wrote:
> > The IGD quirk code defines a separate device, the so-called
> > "vfio-pci-igd-lpc-bridge" which shows up as a user-creatable
> > device in all QEMU binaries that include the vfio code. This
> > is a little bit unfortunate for two reasons: First, this device
> > is completely useless in binaries like qemu-system-s390x.
> > Second we also would like to disable it in downstream RHEL
> > which currently requires some extra patches there since the
> > device does not have a proper Kconfig-style switch yet.
> > 
> > So it would be good if the device could be disabled more easily,
> > thus let's move the code to a separate file instead and introduce
> > a proper Kconfig switch for it which gets only enabled by default
> > if we also have CONFIG_PC_PCI enabled.
> > 
> > Signed-off-by: Thomas Huth 
> > ---
> >   hw/vfio/Kconfig   |   5 +
> >   hw/vfio/Makefile.objs |   1 +
> >   hw/vfio/igd.c | 616 ++
> >   hw/vfio/pci-quirks.c  | 614 +
> >   hw/vfio/pci.h |  17 ++
> >   5 files changed, 642 insertions(+), 611 deletions(-)
> >   create mode 100644 hw/vfio/igd.c
> > 
> > diff --git a/hw/vfio/Kconfig b/hw/vfio/Kconfig
> > index f0eaa75ce7..7cdba0560a 100644
> > --- a/hw/vfio/Kconfig
> > +++ b/hw/vfio/Kconfig
> > @@ -36,3 +36,8 @@ config VFIO_AP
> >   default y
> >   select VFIO
> >   depends on LINUX && S390_CCW_VIRTIO
> > +
> > +config VFIO_IGD
> > +bool
> > +default y if PC_PCI  
> 
> With the details from Alex here:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg663667.html
> 
> I'm tempted to use:
> 
>  default y if XEN
>  depends on PC_PCI

I think you might be confused, there are two separate LPC bridges in
QEMU for IGD support, one specifically for Xen and this one
specifically for VFIO.  This one is never used in a Xen environment.
Thanks,

Alex

> Watch out the Xen Kconfig seems fragile, yesterday using --enable-xen 
> --disable-tcg I hit this build error:
> 
>LINKi386-softmmu/qemu-system-i386
> /usr/bin/ld: hw/xen/xen_pt.o: in function 
> `xen_igd_passthrough_isa_bridge_create':
> /home/phil/source/qemu/hw/xen/xen_pt.c:701: undefined reference to 
> `igd_passthrough_isa_bridge_create'
> 
> > +depends on VFIO_PCI
> > diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
> > index abad8b818c..9bb1c09e84 100644
> > --- a/hw/vfio/Makefile.objs
> > +++ b/hw/vfio/Makefile.objs
> > @@ -5,3 +5,4 @@ obj-$(CONFIG_VFIO_PLATFORM) += platform.o
> >   obj-$(CONFIG_VFIO_XGMAC) += calxeda-xgmac.o
> >   obj-$(CONFIG_VFIO_AMD_XGBE) += amd-xgbe.o
> >   obj-$(CONFIG_VFIO_AP) += ap.o
> > +obj-$(CONFIG_VFIO_IGD) += igd.o  
> 

Re: [PATCH v2 0/4] qmp: Optionally run handlers in coroutines

[Daniel P . Berrangé]

On Tue, Jan 14, 2020 at 07:27:31PM +0100, Kevin Wolf wrote:
> Some QMP command handlers can block the main loop for a relatively long
> time, for example because they perform some I/O. This is quite nasty.
> Allowing such handlers to run in a coroutine where they can yield (and
> therefore release the BQL) while waiting for an event such as I/O
> completion solves the problem.

Am I right that with this approach, there's no functional difference
to QMP from a mgmt app POV ? ie this is purely focused on avoiding
stalls in the main event loop which impact the guest OS and other
parts of QEMU ?

IOW, the response to the QMP command being executed will get sent
back to the mgmt app as normal when the command completes, and the
QMP monitor still serializes execution of commands ?

> This series adds the infrastructure to allow this and switches
> block_resize to run in a coroutine as a first example.
> 
> This is an alternative solution to Marc-André's "monitor: add
> asynchronous command type" series.

Where as this is an actual functional improvement to QMP from
the mgmt app POV in allowing background commands & thus
concurrent execution ?

If this is correct, then the two proposals are somewhat
complementary 

> 
> v2:
> - Fix typo in a commit message [Eric]
> - Use hyphen instead of underscore for the test command [Eric]
> - Mark qmp_block_resize() as coroutine_fn [Stefan]
> 
> 
> Kevin Wolf (4):
>   qapi: Add a 'coroutine' flag for commands
>   vl: Initialise main loop earlier
>   qmp: Move dispatcher to a coroutine
>   block: Mark 'block_resize' as coroutine
> 
>  qapi/block-core.json|  3 +-
>  tests/qapi-schema/qapi-schema-test.json |  1 +
>  docs/devel/qapi-code-gen.txt|  4 ++
>  include/qapi/qmp/dispatch.h |  3 +
>  monitor/monitor-internal.h  |  5 +-
>  blockdev.c  |  6 +-
>  monitor/monitor.c   | 24 ---
>  monitor/qmp.c   | 83 -
>  qapi/qmp-dispatch.c | 38 ++-
>  tests/test-qmp-cmds.c   |  4 ++
>  vl.c| 10 +--
>  scripts/qapi/commands.py| 17 +++--
>  scripts/qapi/doc.py |  2 +-
>  scripts/qapi/expr.py|  4 +-
>  scripts/qapi/introspect.py  |  2 +-
>  scripts/qapi/schema.py  |  9 ++-
>  tests/qapi-schema/qapi-schema-test.out  |  2 +
>  tests/qapi-schema/test-qapi.py  |  7 ++-
>  18 files changed, 158 insertions(+), 66 deletions(-)
> 
> -- 
> 2.20.1
> 
> 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: [PATCH] qcow2: Use a GString in report_unsupported_feature()

[Philippe Mathieu-Daudé]

On 1/14/20 7:08 PM, Alex Bennée wrote:

Alberto Garcia  writes:


This is a bit more efficient than having to allocate and free memory
for each item.

The default size (60) is enough for all the existing incompatible
features.

Suggested-by: Philippe Mathieu-Daudé 
Signed-off-by: Alberto Garcia 
---
  block/qcow2.c | 24 
  1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index cef9d72b3a..ecf6827420 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -453,16 +453,15 @@ static void cleanup_unknown_header_ext(BlockDriverState 
*bs)
  static void report_unsupported_feature(Error **errp, Qcow2Feature *table,
 uint64_t mask)
  {
-char *features = g_strdup("");
-char *old;
+GString *features = g_string_sized_new(60);


g_autoptr(GString) features = g_string_sized_new(60);

will save you the clean-up later.


Does this work with g_string_free() too?

  
  while (table && table->name[0] != '\0') {

  if (table->type == QCOW2_FEAT_TYPE_INCOMPATIBLE) {
  if (mask & (1ULL << table->bit)) {
-old = features;
-features = g_strdup_printf("%s%s%.46s", old, *old ? ", " : "",
-   table->name);
-g_free(old);
+if (features->len > 0) {
+g_string_append(features, ", ");
+}
+g_string_append_printf(features, "%.46s",
  table->name);


We have a number of cases of this sort of idiom in the code base. I
wonder if it calls for a utility function:

qemu_append_with_sep(features, ", ", "%.46s", table->name)


Good idea for https://wiki.qemu.org/Contribute/BiteSizedTasks


Anyway not mandatory for this patch so with the autoptr fix:

Reviewed-by: Alex Bennée 


  mask &= ~(1ULL << table->bit);
  }
  }
@@ -470,14 +469,15 @@ static void report_unsupported_feature(Error **errp, 
Qcow2Feature *table,
  }
  
  if (mask) {

-old = features;
-features = g_strdup_printf("%s%sUnknown incompatible feature: %" 
PRIx64,
-   old, *old ? ", " : "", mask);
-g_free(old);
+if (features->len > 0) {
+g_string_append(features, ", ");
+}
+g_string_append_printf(features,
+   "Unknown incompatible feature: %" PRIx64, mask);
  }
  
-error_setg(errp, "Unsupported qcow2 feature(s): %s", features);

-g_free(features);
+error_setg(errp, "Unsupported qcow2 feature(s): %s", features->str);
+g_string_free(features, TRUE);
  }
  
  /*

[PATCH v2 1/4] qapi: Add a 'coroutine' flag for commands

[Kevin Wolf]

This patch adds a new 'coroutine' flag to QMP command definitions that
tells the QMP dispatcher that the command handler is safe to be run in a
coroutine.

Signed-off-by: Kevin Wolf 
Reviewed-by: Marc-André Lureau 
---
 tests/qapi-schema/qapi-schema-test.json |  1 +
 docs/devel/qapi-code-gen.txt|  4 
 include/qapi/qmp/dispatch.h |  1 +
 tests/test-qmp-cmds.c   |  4 
 scripts/qapi/commands.py| 17 +++--
 scripts/qapi/doc.py |  2 +-
 scripts/qapi/expr.py|  4 ++--
 scripts/qapi/introspect.py  |  2 +-
 scripts/qapi/schema.py  |  9 ++---
 tests/qapi-schema/qapi-schema-test.out  |  2 ++
 tests/qapi-schema/test-qapi.py  |  7 ---
 11 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/tests/qapi-schema/qapi-schema-test.json 
b/tests/qapi-schema/qapi-schema-test.json
index 9abf175fe0..1a850fe171 100644
--- a/tests/qapi-schema/qapi-schema-test.json
+++ b/tests/qapi-schema/qapi-schema-test.json
@@ -147,6 +147,7 @@
   'returns': 'UserDefTwo' }
 
 { 'command': 'cmd-success-response', 'data': {}, 'success-response': false }
+{ 'command': 'coroutine-cmd', 'data': {}, 'coroutine': true }
 
 # Returning a non-dictionary requires a name from the whitelist
 { 'command': 'guest-get-time', 'data': {'a': 'int', '*b': 'int' },
diff --git a/docs/devel/qapi-code-gen.txt b/docs/devel/qapi-code-gen.txt
index 45c93a43cc..753f6711d3 100644
--- a/docs/devel/qapi-code-gen.txt
+++ b/docs/devel/qapi-code-gen.txt
@@ -457,6 +457,7 @@ Syntax:
 '*gen': false,
 '*allow-oob': true,
 '*allow-preconfig': true,
+'*coroutine': true,
 '*if': COND,
 '*features': FEATURES }
 
@@ -581,6 +582,9 @@ before the machine is built.  It defaults to false.  For 
example:
 QMP is available before the machine is built only when QEMU was
 started with --preconfig.
 
+Member 'coroutine' tells the QMP dispatcher whether the command handler
+is safe to be run in a coroutine. It defaults to false.
+
 The optional 'if' member specifies a conditional.  See "Configuring
 the schema" below for more on this.
 
diff --git a/include/qapi/qmp/dispatch.h b/include/qapi/qmp/dispatch.h
index 9aa426a398..d6ce9efc8e 100644
--- a/include/qapi/qmp/dispatch.h
+++ b/include/qapi/qmp/dispatch.h
@@ -24,6 +24,7 @@ typedef enum QmpCommandOptions
 QCO_NO_SUCCESS_RESP   =  (1U << 0),
 QCO_ALLOW_OOB =  (1U << 1),
 QCO_ALLOW_PRECONFIG   =  (1U << 2),
+QCO_COROUTINE =  (1U << 3),
 } QmpCommandOptions;
 
 typedef struct QmpCommand
diff --git a/tests/test-qmp-cmds.c b/tests/test-qmp-cmds.c
index 27b0afe55a..e2f71e42a1 100644
--- a/tests/test-qmp-cmds.c
+++ b/tests/test-qmp-cmds.c
@@ -34,6 +34,10 @@ void qmp_cmd_success_response(Error **errp)
 {
 }
 
+void qmp_coroutine_cmd(Error **errp)
+{
+}
+
 Empty2 *qmp_user_def_cmd0(Error **errp)
 {
 return g_new0(Empty2, 1);
diff --git a/scripts/qapi/commands.py b/scripts/qapi/commands.py
index ab98e504f3..97e51401f1 100644
--- a/scripts/qapi/commands.py
+++ b/scripts/qapi/commands.py
@@ -15,6 +15,7 @@ See the COPYING file in the top-level directory.
 
 from qapi.common import *
 from qapi.gen import QAPIGenCCode, QAPISchemaModularCVisitor, ifcontext
+from typing import List
 
 
 def gen_command_decl(name, arg_type, boxed, ret_type):
@@ -194,8 +195,9 @@ out:
 return ret
 
 
-def gen_register_command(name, success_response, allow_oob, allow_preconfig):
-options = []
+def gen_register_command(name: str, success_response: bool, allow_oob: bool,
+ allow_preconfig: bool, coroutine: bool) -> str:
+options = [] # type: List[str]
 
 if not success_response:
 options += ['QCO_NO_SUCCESS_RESP']
@@ -203,18 +205,20 @@ def gen_register_command(name, success_response, 
allow_oob, allow_preconfig):
 options += ['QCO_ALLOW_OOB']
 if allow_preconfig:
 options += ['QCO_ALLOW_PRECONFIG']
+if coroutine:
+options += ['QCO_COROUTINE']
 
 if not options:
 options = ['QCO_NO_OPTIONS']
 
-options = " | ".join(options)
+options_str = " | ".join(options)
 
 ret = mcgen('''
 qmp_register_command(cmds, "%(name)s",
  qmp_marshal_%(c_name)s, %(opts)s);
 ''',
 name=name, c_name=c_name(name),
-opts=options)
+opts=options_str)
 return ret
 
 
@@ -278,7 +282,7 @@ void %(c_prefix)sqmp_init_marshal(QmpCommandList *cmds);
 
 def visit_command(self, name, info, ifcond, arg_type, ret_type, gen,
   success_response, boxed, allow_oob, allow_preconfig,
-  features):
+  coroutine, features):
 if not gen:
 return
 # FIXME: If T is a user-defined type, the user is responsible
@@ -296,7 +300,8 @@ void 

[PATCH v2 0/4] qmp: Optionally run handlers in coroutines

[Kevin Wolf]

Some QMP command handlers can block the main loop for a relatively long
time, for example because they perform some I/O. This is quite nasty.
Allowing such handlers to run in a coroutine where they can yield (and
therefore release the BQL) while waiting for an event such as I/O
completion solves the problem.

This series adds the infrastructure to allow this and switches
block_resize to run in a coroutine as a first example.

This is an alternative solution to Marc-André's "monitor: add
asynchronous command type" series.

v2:
- Fix typo in a commit message [Eric]
- Use hyphen instead of underscore for the test command [Eric]
- Mark qmp_block_resize() as coroutine_fn [Stefan]


Kevin Wolf (4):
  qapi: Add a 'coroutine' flag for commands
  vl: Initialise main loop earlier
  qmp: Move dispatcher to a coroutine
  block: Mark 'block_resize' as coroutine

 qapi/block-core.json|  3 +-
 tests/qapi-schema/qapi-schema-test.json |  1 +
 docs/devel/qapi-code-gen.txt|  4 ++
 include/qapi/qmp/dispatch.h |  3 +
 monitor/monitor-internal.h  |  5 +-
 blockdev.c  |  6 +-
 monitor/monitor.c   | 24 ---
 monitor/qmp.c   | 83 -
 qapi/qmp-dispatch.c | 38 ++-
 tests/test-qmp-cmds.c   |  4 ++
 vl.c| 10 +--
 scripts/qapi/commands.py| 17 +++--
 scripts/qapi/doc.py |  2 +-
 scripts/qapi/expr.py|  4 +-
 scripts/qapi/introspect.py  |  2 +-
 scripts/qapi/schema.py  |  9 ++-
 tests/qapi-schema/qapi-schema-test.out  |  2 +
 tests/qapi-schema/test-qapi.py  |  7 ++-
 18 files changed, 158 insertions(+), 66 deletions(-)

-- 
2.20.1

[PATCH v2 4/4] block: Mark 'block_resize' as coroutine

[Kevin Wolf]

block_resize is safe to run in a coroutine, so use it as an example for
the new 'coroutine': true annotation in the QAPI schema.

Signed-off-by: Kevin Wolf 
Reviewed-by: Marc-André Lureau 
---
 qapi/block-core.json | 3 ++-
 blockdev.c   | 6 +++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index 7ff5e5edaf..1dbb2a9901 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1341,7 +1341,8 @@
 { 'command': 'block_resize',
   'data': { '*device': 'str',
 '*node-name': 'str',
-'size': 'int' } }
+'size': 'int' },
+  'coroutine': true }
 
 ##
 # @NewImageMode:
diff --git a/blockdev.c b/blockdev.c
index 8e029e9c01..b5e5d1e072 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3161,9 +3161,9 @@ void hmp_drive_del(Monitor *mon, const QDict *qdict)
 aio_context_release(aio_context);
 }
 
-void qmp_block_resize(bool has_device, const char *device,
-  bool has_node_name, const char *node_name,
-  int64_t size, Error **errp)
+void coroutine_fn qmp_block_resize(bool has_device, const char *device,
+   bool has_node_name, const char *node_name,
+   int64_t size, Error **errp)
 {
 Error *local_err = NULL;
 BlockBackend *blk = NULL;
-- 
2.20.1

[PATCH v2 2/4] vl: Initialise main loop earlier

[Kevin Wolf]

We want to be able to use qemu_aio_context in the monitor
initialisation.

Signed-off-by: Kevin Wolf 
Reviewed-by: Marc-André Lureau 
---
 vl.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/vl.c b/vl.c
index 86474a55c9..4c79a00857 100644
--- a/vl.c
+++ b/vl.c
@@ -2903,6 +2903,11 @@ int main(int argc, char **argv, char **envp)
 runstate_init();
 precopy_infrastructure_init();
 postcopy_infrastructure_init();
+
+if (qemu_init_main_loop(_loop_err)) {
+error_report_err(main_loop_err);
+exit(1);
+}
 monitor_init_globals();
 
 if (qcrypto_init() < 0) {
@@ -3817,11 +3822,6 @@ int main(int argc, char **argv, char **envp)
 qemu_unlink_pidfile_notifier.notify = qemu_unlink_pidfile;
 qemu_add_exit_notifier(_unlink_pidfile_notifier);
 
-if (qemu_init_main_loop(_loop_err)) {
-error_report_err(main_loop_err);
-exit(1);
-}
-
 #ifdef CONFIG_SECCOMP
 olist = qemu_find_opts_err("sandbox", NULL);
 if (olist) {
-- 
2.20.1

[PATCH v2 3/4] qmp: Move dispatcher to a coroutine

[Kevin Wolf]

This moves the QMP dispatcher to a coroutine and runs all QMP command
handlers that declare 'coroutine': true in coroutine context so they
can avoid blocking the main loop while doing I/O or waiting for other
events.

For commands that are not declared safe to run in a coroutine, the
dispatcher drops out of coroutine context by calling the QMP command
handler from a bottom half.

Signed-off-by: Kevin Wolf 
Reviewed-by: Marc-André Lureau 
---
 include/qapi/qmp/dispatch.h |  2 +
 monitor/monitor-internal.h  |  5 ++-
 monitor/monitor.c   | 24 +++
 monitor/qmp.c   | 83 +++--
 qapi/qmp-dispatch.c | 38 -
 5 files changed, 111 insertions(+), 41 deletions(-)

diff --git a/include/qapi/qmp/dispatch.h b/include/qapi/qmp/dispatch.h
index d6ce9efc8e..d6d5443391 100644
--- a/include/qapi/qmp/dispatch.h
+++ b/include/qapi/qmp/dispatch.h
@@ -30,6 +30,8 @@ typedef enum QmpCommandOptions
 typedef struct QmpCommand
 {
 const char *name;
+/* Runs in coroutine context if QCO_COROUTINE is set, except for OOB
+ * commands */
 QmpCommandFunc *fn;
 QmpCommandOptions options;
 QTAILQ_ENTRY(QmpCommand) node;
diff --git a/monitor/monitor-internal.h b/monitor/monitor-internal.h
index d78f5ca190..7389b6a56c 100644
--- a/monitor/monitor-internal.h
+++ b/monitor/monitor-internal.h
@@ -154,7 +154,8 @@ static inline bool monitor_is_qmp(const Monitor *mon)
 
 typedef QTAILQ_HEAD(MonitorList, Monitor) MonitorList;
 extern IOThread *mon_iothread;
-extern QEMUBH *qmp_dispatcher_bh;
+extern Coroutine *qmp_dispatcher_co;
+extern bool qmp_dispatcher_co_busy;
 extern QmpCommandList qmp_commands, qmp_cap_negotiation_commands;
 extern QemuMutex monitor_lock;
 extern MonitorList mon_list;
@@ -172,7 +173,7 @@ void monitor_fdsets_cleanup(void);
 
 void qmp_send_response(MonitorQMP *mon, const QDict *rsp);
 void monitor_data_destroy_qmp(MonitorQMP *mon);
-void monitor_qmp_bh_dispatcher(void *data);
+void coroutine_fn monitor_qmp_dispatcher_co(void *data);
 
 int get_monitor_def(int64_t *pval, const char *name);
 void help_cmd(Monitor *mon, const char *name);
diff --git a/monitor/monitor.c b/monitor/monitor.c
index 12898b6448..c72763fa4e 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -53,8 +53,9 @@ typedef struct {
 /* Shared monitor I/O thread */
 IOThread *mon_iothread;
 
-/* Bottom half to dispatch the requests received from I/O thread */
-QEMUBH *qmp_dispatcher_bh;
+/* Coroutine to dispatch the requests received from I/O thread */
+Coroutine *qmp_dispatcher_co;
+bool qmp_dispatcher_co_busy;
 
 /* Protects mon_list, monitor_qapi_event_state, monitor_destroyed.  */
 QemuMutex monitor_lock;
@@ -579,9 +580,16 @@ void monitor_cleanup(void)
 }
 qemu_mutex_unlock(_lock);
 
-/* QEMUBHs needs to be deleted before destroying the I/O thread */
-qemu_bh_delete(qmp_dispatcher_bh);
-qmp_dispatcher_bh = NULL;
+/* The dispatcher needs to stop before destroying the I/O thread */
+if (!atomic_mb_read(_dispatcher_co_busy)) {
+aio_co_schedule(iohandler_get_aio_context(), qmp_dispatcher_co);
+qmp_dispatcher_co = NULL;
+}
+
+AIO_WAIT_WHILE(qemu_get_aio_context(),
+   (aio_bh_poll(iohandler_get_aio_context()),
+atomic_mb_read(_dispatcher_co_busy)));
+
 if (mon_iothread) {
 iothread_destroy(mon_iothread);
 mon_iothread = NULL;
@@ -604,9 +612,9 @@ void monitor_init_globals_core(void)
  * have commands assuming that context.  It would be nice to get
  * rid of those assumptions.
  */
-qmp_dispatcher_bh = aio_bh_new(iohandler_get_aio_context(),
-   monitor_qmp_bh_dispatcher,
-   NULL);
+qmp_dispatcher_co = qemu_coroutine_create(monitor_qmp_dispatcher_co, NULL);
+atomic_mb_set(_dispatcher_co_busy, true);
+aio_co_schedule(iohandler_get_aio_context(), qmp_dispatcher_co);
 }
 
 QemuOptsList qemu_mon_opts = {
diff --git a/monitor/qmp.c b/monitor/qmp.c
index b67a8e7d1f..9fd66c7b97 100644
--- a/monitor/qmp.c
+++ b/monitor/qmp.c
@@ -133,6 +133,8 @@ static void monitor_qmp_respond(MonitorQMP *mon, QDict *rsp)
 }
 }
 
+/* Runs outside of coroutine context for OOB commands, but in coroutine context
+ * for everything else. */
 static void monitor_qmp_dispatch(MonitorQMP *mon, QObject *req)
 {
 Monitor *old_mon;
@@ -211,43 +213,62 @@ static QMPRequest 
*monitor_qmp_requests_pop_any_with_lock(void)
 return req_obj;
 }
 
-void monitor_qmp_bh_dispatcher(void *data)
+void coroutine_fn monitor_qmp_dispatcher_co(void *data)
 {
-QMPRequest *req_obj = monitor_qmp_requests_pop_any_with_lock();
+QMPRequest *req_obj = NULL;
 QDict *rsp;
 bool need_resume;
 MonitorQMP *mon;
 
-if (!req_obj) {
-return;
-}
+while (true) {
+assert(atomic_mb_read(_dispatcher_co_busy) == true);
+
+while (!(req_obj = 

[Bug 1859384] Re: arm gic: interrupt model never 1 on non-mpcore and race condition in gic_acknowledge_irq

[Alex Bennée]

** Tags added: testcase

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

Title:
  arm gic: interrupt model never 1 on non-mpcore and race condition in
  gic_acknowledge_irq

Status in QEMU:
  New

Bug description:
  For a 1-N interrupt (any SPI on the GICv2), as mandated by the TRM,
  only one CPU can acknowledge the IRQ until it becomes inactive.

  The TRM also mandates that SGIs and PPIs follow the N-N model and that
  SPIs follow the 1-N model.

  However this is not currently the case with QEMU. I have locally (no
  minimal test case) seen e.g. uart interrupts being acknowledged twice
  before having been deactivated (expected: irqId on one CPU and 1023 on
  the other instead).

  I have narrowed the issue down to the following:

  1) arm_gic_common_reset resets all irq_state[id] fields to 0. This
  means all IRQ will use the N-N model, and if s->revision !=
  REV_11MPCORE, then there's no way to set any interrupt to 1-N.

  If ""fixed"" locally with a hackjob, I still have the following trace:

  pl011_irq_state 534130.800 pid=2424 level=0x1
  gic_set_irq 2.900 pid=2424 irq=0x21 level=0x1 cpumask=0xff target=0xff
  gic_update_set_irq 3.300 pid=2424 cpu=0x0 name=irq level=0x1
  gic_update_set_irq 4.200 pid=2424 cpu=0x1 name=irq level=0x1
  gic_acknowledge_irq 539.400 pid=2424 s=cpu cpu=0x1 irq=0x21
  gic_update_set_irq 269.800 pid=2424 cpu=0x0 name=irq level=0x1
  gic_cpu_read 4.100 pid=2424 s=cpu cpu=0x1 addr=0xc val=0x21
  gic_acknowledge_irq 15.600 pid=2424 s=cpu cpu=0x0 irq=0x21
  gic_cpu_read 265.000 pid=2424 s=cpu cpu=0x0 addr=0xc val=0x21
  pl011_write 1594.700 pid=2424 addr=0x44 value=0x50
  pl011_irq_state 2.000 pid=2424 level=0x0
  gic_set_irq 1.300 pid=2424 irq=0x21 level=0x0 cpumask=0xff target=0xff
  pl011_write 30.700 pid=2424 addr=0x38 value=0x0
  pl011_irq_state 1.200 pid=2424 level=0x0
  gic_cpu_write 110.600 pid=2424 s=cpu cpu=0x0 addr=0x10 val=0x21
  gic_cpu_write 193.400 pid=2424 s=cpu cpu=0x0 addr=0x1000 val=0x21
  pl011_irq_state 1169.500 pid=2424 level=0x0

  This is because:

  2) gic_acknowledge_irq calls gic_clear_pending which uses
  GIC_DIST_CLEAR_PENDING but this usually has no effect on level-
  sensitive interrupts.

  With this often being a no-op (ie. assuming ispendr was not written
  to), any 1-n level-sensitive interrupt is still improperly pending on
  all the other cores.

  (Also, I don't really know how the qemu thread model works, there
  might be race conditions in the acknowledgment logic if
  gic_acknowledge_irq is called by multiple threads, too.)

  Option used:
  -nographic -machine virt,virtualization=on,accel=tcg,gic-version=2 -cpu 
cortex-a57 -smp 4 -m 1024
  -kernel whatever.elf -d unimp,guest_errors -semihosting-config 
enable,target=native
  -chardev stdio,id=uart -serial chardev:uart -monitor none
  -trace gic_update_set_irq -trace gic_acknowledge_irq -trace pl011_irq_state 
-trace pl011_write -trace gic_cpu_read -trace gic_cpu_write
  -trace gic_set_irq

  Commit used: dc65a5bdc9fa543690a775b50d4ffbeb22c56d6d "Merge remote-
  tracking branch 'remotes/dgibson/tags/ppc-for-5.0-20200108' into
  staging"

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

Re: [PATCH] qcow2: Use a GString in report_unsupported_feature()

[Alex Bennée]

Alberto Garcia  writes:

> This is a bit more efficient than having to allocate and free memory
> for each item.
>
> The default size (60) is enough for all the existing incompatible
> features.
>
> Suggested-by: Philippe Mathieu-Daudé 
> Signed-off-by: Alberto Garcia 
> ---
>  block/qcow2.c | 24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/block/qcow2.c b/block/qcow2.c
> index cef9d72b3a..ecf6827420 100644
> --- a/block/qcow2.c
> +++ b/block/qcow2.c
> @@ -453,16 +453,15 @@ static void cleanup_unknown_header_ext(BlockDriverState 
> *bs)
>  static void report_unsupported_feature(Error **errp, Qcow2Feature *table,
> uint64_t mask)
>  {
> -char *features = g_strdup("");
> -char *old;
> +GString *features = g_string_sized_new(60);

   g_autoptr(GString) features = g_string_sized_new(60);

will save you the clean-up later.

>  
>  while (table && table->name[0] != '\0') {
>  if (table->type == QCOW2_FEAT_TYPE_INCOMPATIBLE) {
>  if (mask & (1ULL << table->bit)) {
> -old = features;
> -features = g_strdup_printf("%s%s%.46s", old, *old ? ", " : 
> "",
> -   table->name);
> -g_free(old);
> +if (features->len > 0) {
> +g_string_append(features, ", ");
> +}
> +g_string_append_printf(features, "%.46s",
>  table->name);

We have a number of cases of this sort of idiom in the code base. I
wonder if it calls for a utility function:

   qemu_append_with_sep(features, ", ", "%.46s", table->name)

Anyway not mandatory for this patch so with the autoptr fix:

Reviewed-by: Alex Bennée 

>  mask &= ~(1ULL << table->bit);
>  }
>  }
> @@ -470,14 +469,15 @@ static void report_unsupported_feature(Error **errp, 
> Qcow2Feature *table,
>  }
>  
>  if (mask) {
> -old = features;
> -features = g_strdup_printf("%s%sUnknown incompatible feature: %" 
> PRIx64,
> -   old, *old ? ", " : "", mask);
> -g_free(old);
> +if (features->len > 0) {
> +g_string_append(features, ", ");
> +}
> +g_string_append_printf(features,
> +   "Unknown incompatible feature: %" PRIx64, 
> mask);
>  }
>  
> -error_setg(errp, "Unsupported qcow2 feature(s): %s", features);
> -g_free(features);
> +error_setg(errp, "Unsupported qcow2 feature(s): %s", features->str);
> +g_string_free(features, TRUE);
>  }
>  
>  /*


-- 
Alex Bennée

Re: [PATCH v12 05/13] virtio-iommu: Endpoint and domains structs and helpers

[Peter Xu]

On Tue, Jan 14, 2020 at 09:51:59AM +0100, Auger Eric wrote:
> Hi Peter,

Hi, Eric,

[...]

> > 
> >> +{
> >> +VirtIOIOMMUEndpoint *ep;
> >> +
> >> +ep = g_tree_lookup(s->endpoints, GUINT_TO_POINTER(ep_id));
> >> +if (ep) {
> >> +return ep;
> >> +}
> >> +if (!virtio_iommu_mr(s, ep_id)) {
> > 
> > Could I ask when this will trigger?
> 
> This can happen when a device is attached to a domain and its RID does
> not correspond to one of the devices protected by the iommu.

So will it happen only because of a kernel driver bug?

Also, I think the name of "virtio_iommu_mr" is confusing on that it
returned explicitly a MemoryRegion however it's never been used:

(since they're not in the same patch I'm pasting)

static IOMMUMemoryRegion *virtio_iommu_mr(VirtIOIOMMU *s, uint32_t sid)
{
uint8_t bus_n, devfn;
IOMMUPciBus *iommu_pci_bus;
IOMMUDevice *dev;

bus_n = PCI_BUS_NUM(sid);
iommu_pci_bus = iommu_find_iommu_pcibus(s, bus_n);
if (iommu_pci_bus) {
devfn = sid & 0xFF;
dev = iommu_pci_bus->pbdev[devfn];
if (dev) {
return >iommu_mr;
}
}
return NULL;
}

Maybe "return !!dev" would be enough, then make the return a boolean?
Then we can rename it to virtio_iommu_has_device().

PS. I think we can also drop IOMMU_PCI_DEVFN_MAX (after all you even
didn't use it here!) and use PCI_DEVFN_MAX, and replace 0xFF.

Thanks,

-- 
Peter Xu

Re: [Xen-devel] [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE

[Roger Pau Monné]

On Tue, Jan 14, 2020 at 09:41:46AM -0500, Jason Andryuk wrote:
> On Tue, Jan 14, 2020 at 5:04 AM Roger Pau Monné  wrote:
> >
> > On Mon, Jan 13, 2020 at 02:01:47PM -0500, Jason Andryuk wrote:
> > > On Fri, Mar 22, 2019 at 3:43 PM Jason Andryuk  wrote:
> > > >
> > > > On Thu, Mar 21, 2019 at 11:09 PM Roger Pau Monné  
> > > > wrote:
> > > > >
> > > > > The patch below should prevent hvmloader from placing multiple BARs on
> > > > > the same page, could you give it a try?
> > > > >
> > > > > Note that this is not going to prevent the guest from moving those
> > > > > BARs around and place them in the same page, thus breaking the initial
> > > > > placement done by hvmloader.
> > > > >
> > > > > Thanks, Roger.
> > > >
> > > > Hi, Roger.
> > > >
> > > > I've minimally tested this.  Yes, this patch seems to place small BARs
> > > > into separate pages.  The linux stubdom and QEMU then use the spacing
> > > > as provided by hvmloader.
> > >
> > > Roger,
> > >
> > > Would you mind submitting this patch to Xen?
> >
> > Hm, I'm half minded regarding this patch. It feels more like a bandaid
> > than a proper solution. Mapping BARs not multiple of page-sizes is
> > dangerous because AFAIK there's no entity that asserts there isn't any
> > other BAR from a different device on the same page, and hence you
> > might end up mapping some MMIO region from another device
> > inadvertently.
> 
> We have the guest, linux stubdom with qemu, & dom0. Are you concerned
> that all of them need a minimum of page alignment?

No, not really. The hardware domain (dom0 in normal deployments)
should be the one that makes sure there are no BARs sharing physical
pages.

> Linux PCI subsytem has an option resource_alignment that can be
> applied to either a single device or all devices.  Booting with
> pci=resource_aligment=4096 will align each device to a page.  Do you
> think pciback should force resource_alignment=4096 for dom0?

Ideally Xen should keep track of the BARs position and size and refuse
to passthrough devices that have BARs sharing a page with other
devices BARs.

> Are
> there other MMIO ranges to be concerned about adjacent to BARs?

IIRC you can have two BARs of different devices in the same 4K page,
BARs are only aligned to it's size, so BARs smaller than 4K are not
required to be page aligned.

> On my one test machine with a BAR smaller than 4096, the firmware
> already sets an alignment of 4096.  Linux dom0 seems to keep the
> firmware BAR alignment by default.

The PCI spec recommend BARs to be sized to a multiple of a page size, but
sadly that's not a mandatory requirement.

Will submit the patch now, thanks for the ping, I completely forgot
about this TBH.

Roger.

Re: Priority of -accel

[Daniel P . Berrangé]

On Tue, Jan 14, 2020 at 06:49:45PM +0100, Christophe de Dinechin wrote:
> 
> 
> > On 13 Jan 2020, at 17:25, Paolo Bonzini  wrote:
> > 
> > On 13/01/20 17:17, Markus Armbruster wrote:
> >> Perfect opportunity to change the default to something more useful.
> > 
> > I am not sure acutally if it's that more useful, now that we have
> > sanctioned qemu-kvm as the fast alternative.
> 
> OK, half a joke, but we should have tested on “q” at the beginning
> rather than “-kvm” at the end ;-)
> 
> emu being the slow one ;-)

IIRC, Debian had (still has ?) it called /usr/bin/kvm

The qemu-kvm naming came from RHEL / Fedora land originally,
when the project was literally forked as a "qemu-kvm" git repo.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|

Re: Priority of -accel

[Christophe de Dinechin]

> On 13 Jan 2020, at 17:25, Paolo Bonzini  wrote:
> 
> On 13/01/20 17:17, Markus Armbruster wrote:
>> Perfect opportunity to change the default to something more useful.
> 
> I am not sure acutally if it's that more useful, now that we have
> sanctioned qemu-kvm as the fast alternative.

OK, half a joke, but we should have tested on “q” at the beginning
rather than “-kvm” at the end ;-)

emu being the slow one ;-)

Re: Making QEMU easier for management tools and applications

[Christophe de Dinechin]

I started cutting some stuff out.

> On 14 Jan 2020, at 14:04, Markus Armbruster  wrote:
> 
> Prior art:
> 
>Presentation
>KVM Forum 2017: Towards a More Expressive and Introspectable QEMU
>Command Line
>https://www.youtube.com/watch?v=gtpOLQgnwug
>https://www.linux-kvm.org/images/f/f2/Armbru-qapi-cmdline_1.pdf
> 
>RFC patches
>https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg00209.html
>Message-Id: <20171002152552.27999-1-arm...@redhat.com>
>https://repo.or.cz/qemu/armbru.git/shortlog/refs/heads/qapi-cmdline

Very useful, thanks.

> 
>> Compatibility is much harder, which is not the least because the
>> existing command line options are bad (primarily: using inconsistent
>> syntax).
> 
> Semantics are just as problematic.

Yes, but often you can leverage something (e.g. JSON, XML, etc)

We could decide that the new QAPI language is a custom implementation
of Python ;-) Or more seriously, we could have some part of the JSON
schema that are “escapes” to C code that we put in some generated file.
I used {{ }} below for this escape, in which case the semantics would be
that of C plus some specific macros we insert in it.

{ 'option': '--add-fd',
 'data': { 'fd': 'int', 'set': 'int', '*opaque': 'str' },
 'help': [
"-add-fd fd=fd,set=set[,opaque=opaque]",
"Add 'fd' to fd 'set'”] 
 ‘validate’ : {{
error_if(QOPT.fd < 0, “fd option cannot be negative”);
error_if(QOPT.fd <= STDERR_FILENO, “fd cannot be a standard I/O stream”);
 }},
 ‘exec’ : {{
if (do_add_fd(QOPT.fd, QOPT.fset, QOPT.opaque) < 0) {
exit(1);
}
 }},

I’m not necessarily saying this is a good idea, mind you.

> 
> You mean the qemu-options.hx.  qemu-options.def is generated from it.

Oh, I had missed that, thanks.

>>> or build configuration (there is a hint of the connection between
>>> the two in the option ‘if’ member in the .json files).
> 
> I'm not sure what exactly you have in mind for build configuration.

I meant what you pointed out wrt. options, that this “language” needs to
know about the qemu configuration. There is ‘if’ today, you pointed
out arch-specific for options. But the configuration itself is yet
another “language” with its own semantics… which JSON knows
nothing about.

> 
>>> In other words, the language I have in mind would be something
>>> that I could auto-generate from, say, the current qapi-schema.json
>>> and the qemu-options.def. Maybe in the end, that would be simply
>>> by having qemu-options.def being used to build qemu-options.json,
>>> and then add the relevant entries in qemu-options.json. Maybe
>>> there is a better way.
>> 
>> I would rather say that .def should go away and its content should
>> be converted to a JSON schema that becomes the new source format rather
>> than an intermediate generated file. There is nothing in .def files that
>> couldn't be represented in the schema.
> 
> Yes.

Agreed too. The meta-schema would need to be extended.

>> 
>> To a certain degree, QAPI does just that, by supporting different data
>> types for options. If necessary, I'm sure the type system could be
>> extended, but it's not clear to me to which degree we actually need
>> this.
> 
> QAPI is much more expressive than qemu-options.hx.  All the latter can
> do is "has option argument" and "option is arch-specific".  QAPI lets
> you specify an option argument's structure, and supports compile-time
> conditionals.  It can't do things like "must specify either argument A
> or B", or "numeric argument C must not exceed argument D", or "multiple
> options combine vs. last one wins".  Mostly because "it’s already
> complicated enough as is".

Understood.


>> 
>> We could. But is it actually worth inventing a new programming language?
>> I think this is something that should be done in C code even in the
>> future. I think what we're looking for is a way to describe interfaces,
>> not implementations.
> 
> Sane sugar can be described declaratively as macro expansion.
> 
> Less than sane sugar takes code.
> 
> Desugaring in code promotes (accidental) abandonment of sanity.
> 
> That said, we have to keep things simple to succeed.  Declarative
> desugaring seems beyond our reach.

Well, “keeping things simple” is a complicated thing.

> 
>> Even just for adding more sophisticated constraints, like in the example
>> above that maxmem >= size, it's questionable whether doing this in the
>> schema provides enough value for actually implementing it there.
> 
> Yes.

If we do it, yes. If we delegate to an existing language (I showed C above),
maybe it adds clarity without too much of an additional cost.

> 
 I think the only thing in this list that can't obviously be covered
 easily by QAPI is QOM. Or rather, it's covered by passing through
 key=value lists without describing their structure
>>> 
>>> That’s close enough to me. (In my mind, that part was already “done”
>>> by QAPI, even if in the convoluted way you describe)
>> 
>> That's 

Re: [PATCH] hw/vfio: Move the IGD quirk code to a separate file

[Philippe Mathieu-Daudé]

On 1/14/20 5:17 PM, Thomas Huth wrote:

The IGD quirk code defines a separate device, the so-called
"vfio-pci-igd-lpc-bridge" which shows up as a user-creatable
device in all QEMU binaries that include the vfio code. This
is a little bit unfortunate for two reasons: First, this device
is completely useless in binaries like qemu-system-s390x.
Second we also would like to disable it in downstream RHEL
which currently requires some extra patches there since the
device does not have a proper Kconfig-style switch yet.

So it would be good if the device could be disabled more easily,
thus let's move the code to a separate file instead and introduce
a proper Kconfig switch for it which gets only enabled by default
if we also have CONFIG_PC_PCI enabled.

Signed-off-by: Thomas Huth 
---
  hw/vfio/Kconfig   |   5 +
  hw/vfio/Makefile.objs |   1 +
  hw/vfio/igd.c | 616 ++
  hw/vfio/pci-quirks.c  | 614 +
  hw/vfio/pci.h |  17 ++
  5 files changed, 642 insertions(+), 611 deletions(-)
  create mode 100644 hw/vfio/igd.c

diff --git a/hw/vfio/Kconfig b/hw/vfio/Kconfig
index f0eaa75ce7..7cdba0560a 100644
--- a/hw/vfio/Kconfig
+++ b/hw/vfio/Kconfig
@@ -36,3 +36,8 @@ config VFIO_AP
  default y
  select VFIO
  depends on LINUX && S390_CCW_VIRTIO
+
+config VFIO_IGD
+bool
+default y if PC_PCI


With the details from Alex here:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg663667.html

I'm tempted to use:

default y if XEN
depends on PC_PCI

Watch out the Xen Kconfig seems fragile, yesterday using --enable-xen 
--disable-tcg I hit this build error:


  LINKi386-softmmu/qemu-system-i386
/usr/bin/ld: hw/xen/xen_pt.o: in function 
`xen_igd_passthrough_isa_bridge_create':
/home/phil/source/qemu/hw/xen/xen_pt.c:701: undefined reference to 
`igd_passthrough_isa_bridge_create'



+depends on VFIO_PCI
diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
index abad8b818c..9bb1c09e84 100644
--- a/hw/vfio/Makefile.objs
+++ b/hw/vfio/Makefile.objs
@@ -5,3 +5,4 @@ obj-$(CONFIG_VFIO_PLATFORM) += platform.o
  obj-$(CONFIG_VFIO_XGMAC) += calxeda-xgmac.o
  obj-$(CONFIG_VFIO_AMD_XGBE) += amd-xgbe.o
  obj-$(CONFIG_VFIO_AP) += ap.o
+obj-$(CONFIG_VFIO_IGD) += igd.o

Re: [PATCH] tests: acpi: update path in rebuild-expected-aml

[Thomas Huth]

On 14/01/2020 17.51, Shameer Kolothum wrote:
> Since commit 1e8a1fae7464("test: Move qtests to a separate
> directory") qtests are now placed in a separate folder and
> this breaks the script used to rebuild the expected ACPI
> tables for bios-tables-test. Update the script with correct
> path.
> 
> Fixes: 1e8a1fae7464("test: Move qtests to a separate directory")
> Signed-off-by: Shameer Kolothum 
> ---
>  tests/data/acpi/rebuild-expected-aml.sh | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/data/acpi/rebuild-expected-aml.sh 
> b/tests/data/acpi/rebuild-expected-aml.sh
> index f89d4624bc..d44e511533 100755
> --- a/tests/data/acpi/rebuild-expected-aml.sh
> +++ b/tests/data/acpi/rebuild-expected-aml.sh
> @@ -14,7 +14,7 @@
>  
>  qemu_bins="x86_64-softmmu/qemu-system-x86_64 
> aarch64-softmmu/qemu-system-aarch64"
>  
> -if [ ! -e "tests/bios-tables-test" ]; then
> +if [ ! -e "tests/qtest/bios-tables-test" ]; then
>  echo "Test: bios-tables-test is required! Run make check before this 
> script."
>  echo "Run this script from the build directory."
>  exit 1;
> @@ -26,11 +26,11 @@ for qemu in $qemu_bins; do
>  echo "Also, run this script from the build directory."
>  exit 1;
>  fi
> -TEST_ACPI_REBUILD_AML=y QTEST_QEMU_BINARY=$qemu tests/bios-tables-test
> +TEST_ACPI_REBUILD_AML=y QTEST_QEMU_BINARY=$qemu 
> tests/qtest/bios-tables-test
>  done
>  
>  eval `grep SRC_PATH= config-host.mak`
>  
> -echo '/* List of comma-separated changed AML files to ignore */' > 
> ${SRC_PATH}/tests/bios-tables-test-allowed-diff.h
> +echo '/* List of comma-separated changed AML files to ignore */' > 
> ${SRC_PATH}/tests/qtest/bios-tables-test-allowed-diff.h
>  
>  echo "The files were rebuilt and can be added to git."

Oh, sorry for missing that in my patch series ... is there maybe a way
that we could test this script in one of our CI pipelines so that it is
not so easy to miss?

Anyway, for this patch:

Reviewed-by: Thomas Huth 

Re: [PATCH] vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks

[Stefano Garzarella]

On Tue, Jan 14, 2020 at 5:45 PM Stefan Hajnoczi  wrote:
>
> On Tue, Jan 14, 2020 at 03:52:29PM +0800, pannengy...@huawei.com wrote:
> > From: Pan Nengyuan 
> >
> > Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This
> > patch save receive/transmit vq pointer in realize() and cleanup vqs
> > through those vq pointers in unrealize(). The leak stack is as follow:
> >
> > Direct leak of 21504 byte(s) in 3 object(s) allocated from:
> >   #0 0x7f86a1356970 (/lib64/libasan.so.5+0xef970)  ??:?
> >   #1 0x7f86a09aa49d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
> >   #2 0x5604852f85ca (./x86_64-softmmu/qemu-system-x86_64+0x2c3e5ca)  
> > /mnt/sdb/qemu/hw/virtio/virtio.c:2333
> >   #3 0x560485356208 (./x86_64-softmmu/qemu-system-x86_64+0x2c9c208)  
> > /mnt/sdb/qemu/hw/virtio/vhost-vsock.c:339
> >   #4 0x560485305a17 (./x86_64-softmmu/qemu-system-x86_64+0x2c4ba17)  
> > /mnt/sdb/qemu/hw/virtio/virtio.c:3531
> >   #5 0x5604858e6b65 (./x86_64-softmmu/qemu-system-x86_64+0x322cb65)  
> > /mnt/sdb/qemu/hw/core/qdev.c:865
> >   #6 0x5604861e6c41 (./x86_64-softmmu/qemu-system-x86_64+0x3b2cc41)  
> > /mnt/sdb/qemu/qom/object.c:2102
> >
> > Reported-by: Euler Robot 
> > Signed-off-by: Pan Nengyuan 
> > ---
> >  hw/virtio/vhost-vsock.c | 9 +++--
> >  include/hw/virtio/vhost-vsock.h | 2 ++
> >  2 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c
> > index f5744363a8..896c0174c1 100644
> > --- a/hw/virtio/vhost-vsock.c
> > +++ b/hw/virtio/vhost-vsock.c
> > @@ -335,8 +335,10 @@ static void vhost_vsock_device_realize(DeviceState 
> > *dev, Error **errp)
> >  sizeof(struct virtio_vsock_config));
> >
> >  /* Receive and transmit queues belong to vhost */
> > -virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE, 
> > vhost_vsock_handle_output);
> > -virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE, 
> > vhost_vsock_handle_output);
> > +vsock->recv_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
> > +  vhost_vsock_handle_output);
> > +vsock->trans_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
> > +   vhost_vsock_handle_output);
> >
> >  /* The event queue belongs to QEMU */
> >  vsock->event_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
> > @@ -378,6 +380,9 @@ static void vhost_vsock_device_unrealize(DeviceState 
> > *dev, Error **errp)
> >  /* This will stop vhost backend if appropriate. */
> >  vhost_vsock_set_status(vdev, 0);
> >
> > +virtio_delete_queue(vsock->recv_vq);
> > +virtio_delete_queue(vsock->trans_vq);
> > +virtio_delete_queue(vsock->event_vq);
> >  vhost_dev_cleanup(>vhost_dev);
> >  virtio_cleanup(vdev);
> >  }
>
> Please delete the virtqueues after vhost cleanup (the reverse
> initialization order).  There is currently no reason why it has to be
> done in reverse initialization order, your patch should work too, but
> it's a good default for avoiding user-after-free bugs.
>

Agree!

Since we are here, should we delete the queues also in the error path
of vhost_vsock_device_realize()?

Thanks,
Stefano

[PATCH] tests: acpi: update path in rebuild-expected-aml

[Shameer Kolothum]

Since commit 1e8a1fae7464("test: Move qtests to a separate
directory") qtests are now placed in a separate folder and
this breaks the script used to rebuild the expected ACPI
tables for bios-tables-test. Update the script with correct
path.

Fixes: 1e8a1fae7464("test: Move qtests to a separate directory")
Signed-off-by: Shameer Kolothum 
---
 tests/data/acpi/rebuild-expected-aml.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/data/acpi/rebuild-expected-aml.sh 
b/tests/data/acpi/rebuild-expected-aml.sh
index f89d4624bc..d44e511533 100755
--- a/tests/data/acpi/rebuild-expected-aml.sh
+++ b/tests/data/acpi/rebuild-expected-aml.sh
@@ -14,7 +14,7 @@
 
 qemu_bins="x86_64-softmmu/qemu-system-x86_64 
aarch64-softmmu/qemu-system-aarch64"
 
-if [ ! -e "tests/bios-tables-test" ]; then
+if [ ! -e "tests/qtest/bios-tables-test" ]; then
 echo "Test: bios-tables-test is required! Run make check before this 
script."
 echo "Run this script from the build directory."
 exit 1;
@@ -26,11 +26,11 @@ for qemu in $qemu_bins; do
 echo "Also, run this script from the build directory."
 exit 1;
 fi
-TEST_ACPI_REBUILD_AML=y QTEST_QEMU_BINARY=$qemu tests/bios-tables-test
+TEST_ACPI_REBUILD_AML=y QTEST_QEMU_BINARY=$qemu 
tests/qtest/bios-tables-test
 done
 
 eval `grep SRC_PATH= config-host.mak`
 
-echo '/* List of comma-separated changed AML files to ignore */' > 
${SRC_PATH}/tests/bios-tables-test-allowed-diff.h
+echo '/* List of comma-separated changed AML files to ignore */' > 
${SRC_PATH}/tests/qtest/bios-tables-test-allowed-diff.h
 
 echo "The files were rebuilt and can be added to git."
-- 
2.17.1

Re: [PATCH] vhost-vsock: delete vqs in vhost_vsock_unrealize to avoid memleaks

[Stefan Hajnoczi]

On Tue, Jan 14, 2020 at 03:52:29PM +0800, pannengy...@huawei.com wrote:
> From: Pan Nengyuan 
> 
> Receive/transmit/event vqs forgot to cleanup in vhost_vsock_unrealize. This
> patch save receive/transmit vq pointer in realize() and cleanup vqs
> through those vq pointers in unrealize(). The leak stack is as follow:
> 
> Direct leak of 21504 byte(s) in 3 object(s) allocated from:
>   #0 0x7f86a1356970 (/lib64/libasan.so.5+0xef970)  ??:?
>   #1 0x7f86a09aa49d (/lib64/libglib-2.0.so.0+0x5249d)  ??:?
>   #2 0x5604852f85ca (./x86_64-softmmu/qemu-system-x86_64+0x2c3e5ca)  
> /mnt/sdb/qemu/hw/virtio/virtio.c:2333
>   #3 0x560485356208 (./x86_64-softmmu/qemu-system-x86_64+0x2c9c208)  
> /mnt/sdb/qemu/hw/virtio/vhost-vsock.c:339
>   #4 0x560485305a17 (./x86_64-softmmu/qemu-system-x86_64+0x2c4ba17)  
> /mnt/sdb/qemu/hw/virtio/virtio.c:3531
>   #5 0x5604858e6b65 (./x86_64-softmmu/qemu-system-x86_64+0x322cb65)  
> /mnt/sdb/qemu/hw/core/qdev.c:865
>   #6 0x5604861e6c41 (./x86_64-softmmu/qemu-system-x86_64+0x3b2cc41)  
> /mnt/sdb/qemu/qom/object.c:2102
> 
> Reported-by: Euler Robot 
> Signed-off-by: Pan Nengyuan 
> ---
>  hw/virtio/vhost-vsock.c | 9 +++--
>  include/hw/virtio/vhost-vsock.h | 2 ++
>  2 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/virtio/vhost-vsock.c b/hw/virtio/vhost-vsock.c
> index f5744363a8..896c0174c1 100644
> --- a/hw/virtio/vhost-vsock.c
> +++ b/hw/virtio/vhost-vsock.c
> @@ -335,8 +335,10 @@ static void vhost_vsock_device_realize(DeviceState *dev, 
> Error **errp)
>  sizeof(struct virtio_vsock_config));
>  
>  /* Receive and transmit queues belong to vhost */
> -virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE, 
> vhost_vsock_handle_output);
> -virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE, 
> vhost_vsock_handle_output);
> +vsock->recv_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
> +  vhost_vsock_handle_output);
> +vsock->trans_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
> +   vhost_vsock_handle_output);
>  
>  /* The event queue belongs to QEMU */
>  vsock->event_vq = virtio_add_queue(vdev, VHOST_VSOCK_QUEUE_SIZE,
> @@ -378,6 +380,9 @@ static void vhost_vsock_device_unrealize(DeviceState 
> *dev, Error **errp)
>  /* This will stop vhost backend if appropriate. */
>  vhost_vsock_set_status(vdev, 0);
>  
> +virtio_delete_queue(vsock->recv_vq);
> +virtio_delete_queue(vsock->trans_vq);
> +virtio_delete_queue(vsock->event_vq);
>  vhost_dev_cleanup(>vhost_dev);
>  virtio_cleanup(vdev);
>  }

Please delete the virtqueues after vhost cleanup (the reverse
initialization order).  There is currently no reason why it has to be
done in reverse initialization order, your patch should work too, but
it's a good default for avoiding user-after-free bugs.

Stefan


signature.asc
Description: PGP signature

Re: [PULL 0/2] Ui 20200114 patches

[Peter Maydell]

On Tue, 14 Jan 2020 at 10:05, Gerd Hoffmann  wrote:
>
> The following changes since commit 3c8a6575985b1652b45bfa670b5e1907d642cfa0:
>
>   Merge remote-tracking branch 
> 'remotes/kraxel/tags/usb-20200113-pull-request' into staging (2020-01-13 
> 14:19:57 +)
>
> are available in the Git repository at:
>
>   git://git.kraxel.org/qemu tags/ui-20200114-pull-request
>
> for you to fetch changes up to c4c00922cc948bb5e879bfae60764eba1f8745f3:
>
>   display/gtk: get proper refreshrate (2020-01-14 07:26:36 +0100)
>
> 
> ui: add "-display help", gtk refresh rate.
>
> 
>
> Nikola Pavlica (1):
>   display/gtk: get proper refreshrate
>
> Thomas Huth (1):
>   ui: Print available display backends with '-display help'


Applied, thanks.

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

-- PMM

Re: [PATCH v5 05/20] linux-user: mips: Update syscall numbers to kernel 5.5 rc3 level

[Laurent Vivier]

Le 13/01/2020 à 21:34, Aleksandar Markovic a écrit :
> From: Aleksandar Markovic 
> 
> Update mips syscall numbers based on Linux kernel tag v5.5-rc3
> (commit 46cf053e).
> 
> Signed-off-by: Aleksandar Markovic 
> ---
>  linux-user/mips/cpu_loop.c | 78 
> +-
>  linux-user/mips/syscall_nr.h   | 45 
>  linux-user/mips64/syscall_nr.h | 13 +++
>  3 files changed, 135 insertions(+), 1 deletion(-)
> 
> diff --git a/linux-user/mips/cpu_loop.c b/linux-user/mips/cpu_loop.c
> index 39915b3..b81479b 100644
> --- a/linux-user/mips/cpu_loop.c
> +++ b/linux-user/mips/cpu_loop.c
> @@ -25,8 +25,9 @@
>  #include "internal.h"
>  
>  # ifdef TARGET_ABI_MIPSO32
> +#  define MIPS_SYSCALL_NUMBER_UNUSED -1

I'm not sure you need to introduce this change.

The case already exists (stat, fstat, old_select, lstat, ...) and the
entry that was used is:

   MIPS_SYS(sys_ni_syscall , 0)

perhaps you can do the same ?

I think the do_syscall() will return -ENOSYS as the TARGET_NR_XXX is not
defined for o32 in linux-user/mips/syscall_nr.h.

Thanks,
Laurent

Re: [PATCH] vhost-user-blk: reset the device if supported

[Stefan Hajnoczi]

On Fri, Jan 10, 2020 at 08:22:03PM +0800, Yang Zhong wrote:
> As the vhost-user-scsi did in f04724, if the vhost-user-blk backend
> supports the VHOST_USER_F_RESET_DEVICE protocol feature, then the
> device can be reset when requested.
> 
> If this feature is not supported, this reset will directly return.
> 
> Signed-off-by: Yang Zhong 
> ---
>  hw/block/vhost-user-blk.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
> index 63da9bb619..16ddc9b70c 100644
> --- a/hw/block/vhost-user-blk.c
> +++ b/hw/block/vhost-user-blk.c
> @@ -50,6 +50,10 @@ static const int user_feature_bits[] = {
>  VHOST_INVALID_FEATURE_BIT
>  };
>  
> +enum VhostUserProtocolFeature {
> +VHOST_USER_PROTOCOL_F_RESET_DEVICE = 13,
> +};

vhost-user protocol constants should be defined in
hw/virtio/vhost-user.h and not duplicated in device implementations.

> +
>  static void vhost_user_blk_update_config(VirtIODevice *vdev, uint8_t *config)
>  {
>  VHostUserBlk *s = VHOST_USER_BLK(vdev);
> @@ -290,8 +294,23 @@ static void vhost_user_blk_handle_output(VirtIODevice 
> *vdev, VirtQueue *vq)
>  static void vhost_user_blk_reset(VirtIODevice *vdev)
>  {
>  VHostUserBlk *s = VHOST_USER_BLK(vdev);
> +struct vhost_dev *dev = >dev;
>  
>  vhost_dev_free_inflight(s->inflight);
> +
> +/*
> + * Historically, reset was not implemented so only reset devices
> + * that are expecting it.
> + */
> +if (!virtio_has_feature(dev->protocol_features,
> +VHOST_USER_PROTOCOL_F_RESET_DEVICE)) {
> +return;
> +}
> +
> +if (dev->vhost_ops->vhost_reset_device) {
> +dev->vhost_ops->vhost_reset_device(dev);
> +}
> +
>  }

This should be a generic protocol feature that all vhost-user device
implementations benefit from.  Devices shouldn't have to explicitly
implement it over and over again.

Why isn't vhost_user_reset_device() called already?  Then it wouldn't be
necessary to modify vhost_user_blk_reset().

Stefan


signature.asc
Description: PGP signature

Re: [PATCH 2/4] block: Mark 'block_resize' as coroutine

[Stefan Hajnoczi]

On Mon, Jan 13, 2020 at 06:10:09PM +0100, Kevin Wolf wrote:
> Am 13.01.2020 um 17:56 hat Stefan Hajnoczi geschrieben:
> > On Thu, Jan 09, 2020 at 07:35:43PM +0100, Kevin Wolf wrote:
> > > block_resize is safe to run in a coroutine, so use it as an example for
> > > the new 'coroutine': true annotation in the QAPI schema.
> > > 
> > > Signed-off-by: Kevin Wolf 
> > > ---
> > >  qapi/block-core.json | 3 ++-
> > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > > index 7ff5e5edaf..1dbb2a9901 100644
> > > --- a/qapi/block-core.json
> > > +++ b/qapi/block-core.json
> > > @@ -1341,7 +1341,8 @@
> > >  { 'command': 'block_resize',
> > >'data': { '*device': 'str',
> > >  '*node-name': 'str',
> > > -'size': 'int' } }
> > > +'size': 'int' },
> > > +  'coroutine': true }
> > >  
> > >  ##
> > >  # @NewImageMode:
> > 
> > coroutine_fn is missing on
> > blockdev.c:void qmp_block_resize(bool has_device, const char *device,
> 
> It wouldn't even be true until after patch 4. Should I reorder the
> patches so I can add coroutine_fn?

Yes, please.

Stefan


signature.asc
Description: PGP signature

Re: [PATCH v2 0/3] block/io: serialising request clean up and locking fix

[Stefan Hajnoczi]

On Wed, Jan 08, 2020 at 03:55:53PM +0100, Paolo Bonzini wrote:
> Peter Lieven noticed that reqs->overlap_offset and reqs->overlap_bytes
> are written outside bs->reqs_lock.  Patch 3 fixes it, while patches 1
> and 2 are preparatory cleanups.
> 
> v1->v2: fix comment in patch 2, commit message in patch 3 [Kevin]
> 
> Paolo Bonzini (3):
>   block: eliminate BDRV_REQ_NO_SERIALISING
>   block/io: wait for serialising requests when a request becomes
> serialising
>   block/io: take bs->reqs_lock in bdrv_mark_request_serialising
> 
>  block/file-posix.c|   1 -
>  block/io.c| 162 
> +++---
>  include/block/block.h |  12 
>  include/block/block_int.h |   3 +-
>  4 files changed, 81 insertions(+), 97 deletions(-)

Is it possible to trigger the bug somehow?

Can you implement a test case?

Thanks, applied to my block tree:
https://github.com/stefanha/qemu/commits/block

Stefan


signature.asc
Description: PGP signature

Re: PCIe device paththrough via vfio issue

[Alex Williamson]

On Tue, 14 Jan 2020 19:02:41 +0300
yurij  wrote:

> On 1/14/20 5:04 PM, Alex Williamson wrote:
> > On Tue, 14 Jan 2020 17:14:33 +1100
> > Alexey Kardashevskiy  wrote:
> >   
> >> On 14/01/2020 03:28, Alex Williamson wrote:  
> >>> On Mon, 13 Jan 2020 18:49:21 +0300
> >>> yurij  wrote:
> >>>  
>  Hello everybody!
> 
>  I have a specific PCIe device (sorry, but I can't tell about what is it
>  and what it does) but PCI configuration space consists of 4 BARs (lspci
>  output brief):
> 
>  lspci -s 84:00.00 -vvv
> 
>  . . .
>  Region 0: Memory at fa00 (64-bit, non-prefetchable) [size=16M]
>   Region 2: Memory at fb001000 (32-bit, non-prefetchable) [size=4K]
>   Region 3: Memory at fb00 (32-bit, non-prefetchable) [size=4K]
>   Region 4: Memory at f900 (64-bit, non-prefetchable) [size=16M]
>  . . .
>  Kernel driver in use: vfio-pci
>  . . .
> 
>  BAR0 merged with BAR1, BAR4 merged with BAR5 so they are 64 bit width.
> 
>  I put this PCIe device in virtual machine via vfio:
> 
>  -device vfio-pci,host=84:00.0,id=hostdev0,bus=pci.6,addr=0x0
> 
>  Virtual machine successfully boot. PCI configuration space in virtual
>  environment looks OK (lspci output brief):
> 
>  lspci -s 06:00.0 -vvv
> 
>  . . .
>  Region 0: Memory at f800 (64-bit, non-prefetchable) [size=16M]
>   Region 2: Memory at fa00 (32-bit, non-prefetchable) [size=4K]
>   Region 3: Memory at fa001000 (32-bit, non-prefetchable) [size=4K]
>   Region 4: Memory at f900 (64-bit, non-prefetchable) [size=16M]
>  . . .
>  Kernel driver in use: custom_driver
> 
>  BAR0 merged with BAR1 and BAR4 merged with BAR5 and so they are also 64
>  bit width.
> 
>  The main problem in 4K HOLE in REGION 0 in virtual environment. So some
>  device features don't work.
> 
>  I have enabled iommu trace in host system (trace_event=iommu) and
>  display all events (for i in $(find
>  /sys/kernel/debug/tracing/events/iommu/ -name enable);do echo 1 > $i;
>  done). I saw next events during virtual machine booting:
> 
>  # cat /sys/kernel/debug/tracing/trace
>  . . .
>   CPU 0/KVM-3046  [051]  63113.338894: map: IOMMU:
>  iova=0xf800 paddr=0xfa00 size=24576
>   CPU 0/KVM-3046  [051]  63113.339177: map: IOMMU:
>  iova=0xf8007000 paddr=0xfa007000 size=16748544
>   CPU 0/KVM-3046  [051]  63113.339444: map: IOMMU:
>  iova=0xfa00 paddr=0xfb001000 size=4096
>   CPU 0/KVM-3046  [051]  63113.339697: map: IOMMU:
>  iova=0xfa001000 paddr=0xfb00 size=4096
>   CPU 0/KVM-3046  [051]  63113.340209: map: IOMMU:
>  iova=0xf900 paddr=0xf900 size=16777216
>  . . .
> 
>  I have enabled qemu trace(-trace events=/root/qemu/trace_events). Trace
>  file consists of the falling functions:
>  vfio_region_mmap
>  vfio_get_dev_region
>  vfio_pci_size_rom
>  vfio_pci_read_config
>  vfio_pci_write_config
>  vfio_iommu_map_notify
>  vfio_listener_region_add_iommu
>  vfio_listener_region_add_ram
> 
>  Some important brief from qemu trace:
>  . . .
>  янв 13 18:17:24 VM qemu-system-x86_64[7131]: vfio_region_mmap Region
>  :84:00.0 BAR 0 mmaps[0] [0x0 - 0xff]
>  янв 13 18:17:24 VM qemu-system-x86_64[7131]: vfio_region_mmap Region
>  :84:00.0 BAR 2 mmaps[0] [0x0 - 0xfff]
>  янв 13 18:17:24 VM qemu-system-x86_64[7131]: vfio_region_mmap Region
>  :84:00.0 BAR 3 mmaps[0] [0x0 - 0xfff]
>  янв 13 18:17:24 VM qemu-system-x86_64[7131]: vfio_region_mmap Region
>  :84:00.0 BAR 4 mmaps[0] [0x0 - 0xff]
>  . . .
>  янв 13 18:17:37 VM qemu-system-x86_64[7131]:
>  vfio_listener_region_add_ram region_add [ram] 0xf800 - 0xf8005fff
>  [0x7f691e80]
>  янв 13 18:17:37 VM qemu-system-x86_64[7131]:
>  vfio_listener_region_add_ram region_add [ram] 0xf8007000 - 0xf8ff
>  [0x7f691e807000]
>  янв 13 18:17:37 VM qemu-system-x86_64[7131]:
>  vfio_listener_region_add_ram region_add [ram] 0xfa00 - 0xfa000fff
>  [0x7f6b5de37000]
>  янв 13 18:17:37 VM qemu-system-x86_64[7131]:
>  vfio_listener_region_add_ram region_add [ram] 0xfa001000 - 0xfa001fff
>  [0x7f6b58004000]
>  янв 13 18:17:37 VM qemu-system-x86_64[7131]:
>  vfio_listener_region_add_ram region_add [ram] 0xf900 - 0xf9ff
>  [0x7f691d80]
> 
>  I use qemu 4.0.0 which I rebuild for tracing support
>  (--enable-trace-backends=syslog).
> 
>  Please, help me solve this issue. Thank you!  
> >>>
> >>> Something has probably created a QEMU MemoryRegion overlapping the BAR,
> >>> we do this for quirks where we want to intercept a range of MMIO for
> >>> 

[PATCH] hw/vfio: Move the IGD quirk code to a separate file

[Thomas Huth]

The IGD quirk code defines a separate device, the so-called
"vfio-pci-igd-lpc-bridge" which shows up as a user-creatable
device in all QEMU binaries that include the vfio code. This
is a little bit unfortunate for two reasons: First, this device
is completely useless in binaries like qemu-system-s390x.
Second we also would like to disable it in downstream RHEL
which currently requires some extra patches there since the
device does not have a proper Kconfig-style switch yet.

So it would be good if the device could be disabled more easily,
thus let's move the code to a separate file instead and introduce
a proper Kconfig switch for it which gets only enabled by default
if we also have CONFIG_PC_PCI enabled.

Signed-off-by: Thomas Huth 
---
 hw/vfio/Kconfig   |   5 +
 hw/vfio/Makefile.objs |   1 +
 hw/vfio/igd.c | 616 ++
 hw/vfio/pci-quirks.c  | 614 +
 hw/vfio/pci.h |  17 ++
 5 files changed, 642 insertions(+), 611 deletions(-)
 create mode 100644 hw/vfio/igd.c

diff --git a/hw/vfio/Kconfig b/hw/vfio/Kconfig
index f0eaa75ce7..7cdba0560a 100644
--- a/hw/vfio/Kconfig
+++ b/hw/vfio/Kconfig
@@ -36,3 +36,8 @@ config VFIO_AP
 default y
 select VFIO
 depends on LINUX && S390_CCW_VIRTIO
+
+config VFIO_IGD
+bool
+default y if PC_PCI
+depends on VFIO_PCI
diff --git a/hw/vfio/Makefile.objs b/hw/vfio/Makefile.objs
index abad8b818c..9bb1c09e84 100644
--- a/hw/vfio/Makefile.objs
+++ b/hw/vfio/Makefile.objs
@@ -5,3 +5,4 @@ obj-$(CONFIG_VFIO_PLATFORM) += platform.o
 obj-$(CONFIG_VFIO_XGMAC) += calxeda-xgmac.o
 obj-$(CONFIG_VFIO_AMD_XGBE) += amd-xgbe.o
 obj-$(CONFIG_VFIO_AP) += ap.o
+obj-$(CONFIG_VFIO_IGD) += igd.o
diff --git a/hw/vfio/igd.c b/hw/vfio/igd.c
new file mode 100644
index 00..64e332746b
--- /dev/null
+++ b/hw/vfio/igd.c
@@ -0,0 +1,616 @@
+/*
+ * IGD device quirks
+ *
+ * Copyright Red Hat, Inc. 2016
+ *
+ * Authors:
+ *  Alex Williamson 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/units.h"
+#include "qapi/error.h"
+#include "hw/hw.h"
+#include "hw/nvram/fw_cfg.h"
+#include "pci.h"
+#include "trace.h"
+
+/*
+ * Intel IGD support
+ *
+ * Obviously IGD is not a discrete device, this is evidenced not only by it
+ * being integrated into the CPU, but by the various chipset and BIOS
+ * dependencies that it brings along with it.  Intel is trying to move away
+ * from this and Broadwell and newer devices can run in what Intel calls
+ * "Universal Pass-Through" mode, or UPT.  Theoretically in UPT mode, nothing
+ * more is required beyond assigning the IGD device to a VM.  There are
+ * however support limitations to this mode.  It only supports IGD as a
+ * secondary graphics device in the VM and it doesn't officially support any
+ * physical outputs.
+ *
+ * The code here attempts to enable what we'll call legacy mode assignment,
+ * IGD retains most of the capabilities we expect for it to have on bare
+ * metal.  To enable this mode, the IGD device must be assigned to the VM
+ * at PCI address 00:02.0, it must have a ROM, it very likely needs VGA
+ * support, we must have VM BIOS support for reserving and populating some
+ * of the required tables, and we need to tweak the chipset with revisions
+ * and IDs and an LPC/ISA bridge device.  The intention is to make all of
+ * this happen automatically by installing the device at the correct VM PCI
+ * bus address.  If any of the conditions are not met, we cross our fingers
+ * and hope the user knows better.
+ *
+ * NB - It is possible to enable physical outputs in UPT mode by supplying
+ * an OpRegion table.  We don't do this by default because the guest driver
+ * behaves differently if an OpRegion is provided and no monitor is attached
+ * vs no OpRegion and a monitor being attached or not.  Effectively, if a
+ * headless setup is desired, the OpRegion gets in the way of that.
+ */
+
+/*
+ * This presumes the device is already known to be an Intel VGA device, so we
+ * take liberties in which device ID bits match which generation.  This should
+ * not be taken as an indication that all the devices are supported, or even
+ * supportable, some of them don't even support VT-d.
+ * See linux:include/drm/i915_pciids.h for IDs.
+ */
+static int igd_gen(VFIOPCIDevice *vdev)
+{
+if ((vdev->device_id & 0xfff) == 0xa84) {
+return 8; /* Broxton */
+}
+
+switch (vdev->device_id & 0xff00) {
+/* Old, untested, unavailable, unknown */
+case 0x:
+case 0x2500:
+case 0x2700:
+case 0x2900:
+case 0x2a00:
+case 0x2e00:
+case 0x3500:
+case 0xa000:
+return -1;
+/* SandyBridge, IvyBridge, ValleyView, Haswell */
+case 0x0100:
+case 0x0400:
+case 0x0a00:
+case 0x0c00:
+case 0x0d00:
+case 0x0f00:
+return 6;
+/* BroadWell, 

Re: [BUG qemu 4.0] segfault when unplugging virtio-blk-pci device

[Stefan Hajnoczi]

On Tue, Jan 14, 2020 at 10:50:58AM +0800, Eryu Guan wrote:
> On Mon, Jan 13, 2020 at 04:38:55PM +, Stefan Hajnoczi wrote:
> > On Thu, Jan 09, 2020 at 12:58:06PM +0800, Eryu Guan wrote:
> > > On Tue, Jan 07, 2020 at 03:01:01PM +0100, Julia Suvorova wrote:
> > > > On Tue, Jan 7, 2020 at 2:06 PM Eryu Guan  
> > > > wrote:
> > > > >
> > > > > On Thu, Jan 02, 2020 at 10:08:50AM +0800, Eryu Guan wrote:
> > > > > > On Tue, Dec 31, 2019 at 11:51:35AM +0100, Igor Mammedov wrote:
> > > > > > > On Tue, 31 Dec 2019 18:34:34 +0800
> > > > > > > Eryu Guan  wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I'm using qemu 4.0 and hit segfault when tearing down kata 
> > > > > > > > sandbox, I
> > > > > > > > think it's because io completion hits use-after-free when 
> > > > > > > > device is
> > > > > > > > already gone. Is this a known bug that has been fixed? (I went 
> > > > > > > > through
> > > > > > > > the git log but didn't find anything obvious).
> > > > > > > >
> > > > > > > > gdb backtrace is:
> > > > > > > >
> > > > > > > > Core was generated by `/usr/local/libexec/qemu-kvm -name 
> > > > > > > > sandbox-5b8df8c6c6901c3c0a9b02879be10fe8d69d6'.
> > > > > > > > Program terminated with signal 11, Segmentation fault.
> > > > > > > > #0 object_get_class (obj=obj@entry=0x0) at 
> > > > > > > > /usr/src/debug/qemu-4.0/qom/object.c:903
> > > > > > > > 903return obj->class;
> > > > > > > > (gdb) bt
> > > > > > > > #0  object_get_class (obj=obj@entry=0x0) at 
> > > > > > > > /usr/src/debug/qemu-4.0/qom/object.c:903
> > > > > > > > #1  0x558a2c009e9b in virtio_notify_vector 
> > > > > > > > (vdev=0x558a2e7751d0,
> > > > > > > > vector=) at 
> > > > > > > > /usr/src/debug/qemu-4.0/hw/virtio/virtio.c:1118
> > > > > > > > #2  0x558a2bfdcb1e in 
> > > > > > > > virtio_blk_discard_write_zeroes_complete (
> > > > > > > > opaque=0x558a2f2fd420, ret=0)
> > > > > > > > at /usr/src/debug/qemu-4.0/hw/block/virtio-blk.c:186
> > > > > > > > #3  0x558a2c261c7e in blk_aio_complete (acb=0x558a2eed7420)
> > > > > > > > at /usr/src/debug/qemu-4.0/block/block-backend.c:1305
> > > > > > > > #4  0x558a2c3031db in coroutine_trampoline (i0= > > > > > > > out>,
> > > > > > > > i1=) at 
> > > > > > > > /usr/src/debug/qemu-4.0/util/coroutine-ucontext.c:116
> > > > > > > > #5  0x7f45b2f8b080 in ?? () from /lib64/libc.so.6
> > > > > > > > #6  0x7fff9ed75780 in ?? ()
> > > > > > > > #7  0x in ?? ()
> > > > > > > >
> > > > > > > > It seems like qemu was completing a discard/write_zero request, 
> > > > > > > > but
> > > > > > > > parent BusState was already freed & set to NULL.
> > > > > > > >
> > > > > > > > Do we need to drain all pending request before unrealizing 
> > > > > > > > virtio-blk
> > > > > > > > device? Like the following patch proposed?
> > > > > > > >
> > > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2017-06/msg02945.html
> > > > > > > >
> > > > > > > > If more info is needed, please let me know.
> > > > > > >
> > > > > > > may be this will help: 
> > > > > > > https://patchwork.kernel.org/patch/11213047/
> > > > > >
> > > > > > Yeah, this looks promising! I'll try it out (though it's a one-time
> > > > > > crash for me). Thanks!
> > > > >
> > > > > After applying this patch, I don't see the original segfaut and
> > > > > backtrace, but I see this crash
> > > > >
> > > > > [Thread debugging using libthread_db enabled]
> > > > > Using host libthread_db library "/lib64/libthread_db.so.1".
> > > > > Core was generated by `/usr/local/libexec/qemu-kvm -name 
> > > > > sandbox-a2f34a11a7e1449496503bbc4050ae040c0d3'.
> > > > > Program terminated with signal 11, Segmentation fault.
> > > > > #0  0x561216a57609 in virtio_pci_notify_write 
> > > > > (opaque=0x5612184747e0, addr=0, val=, size= > > > > out>) at /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324
> > > > > 1324VirtIOPCIProxy *proxy = 
> > > > > VIRTIO_PCI(DEVICE(vdev)->parent_bus->parent);
> > > > > Missing separate debuginfos, use: debuginfo-install 
> > > > > glib2-2.42.2-5.1.alios7.x86_64 glibc-2.17-260.alios7.x86_64 
> > > > > libgcc-4.8.5-28.alios7.1.x86_64 libseccomp-2.3.1-3.alios7.x86_64 
> > > > > libstdc++-4.8.5-28.alios7.1.x86_64 
> > > > > numactl-libs-2.0.9-5.1.alios7.x86_64 pixman-0.32.6-3.1.alios7.x86_64 
> > > > > zlib-1.2.7-16.2.alios7.x86_64
> > > > > (gdb) bt
> > > > > #0  0x561216a57609 in virtio_pci_notify_write 
> > > > > (opaque=0x5612184747e0, addr=0, val=, size= > > > > out>) at /usr/src/debug/qemu-4.0/hw/virtio/virtio-pci.c:1324
> > > > > #1  0x561216835b22 in memory_region_write_accessor (mr= > > > > out>, addr=, value=, size= > > > > out>, shift=, mask=, attrs=...) at 
> > > > > /usr/src/debug/qemu-4.0/memory.c:502
> > > > > #2  0x561216833c5d in access_with_adjusted_size 
> > > > > (addr=addr@entry=0, value=value@entry=0x7fcdeab1b8a8, 
> > > > > size=size@entry=2, access_size_min=, 
> > > > > access_size_max=, 

Re: [PATCH 2/4] linux-user: Use `qemu_log' for strace

[Paolo Bonzini]

On 14/01/20 10:09, Laurent Vivier wrote:
> Perhaps we can use flag LOG_TRACE? (cc Paolo)

No, LOG_TRACE is for trace-events tracepoints.  A new logging flag is
definitely the way to go.

Paolo