Re: [Qemu-devel] [PATCH v16 22/23] target/rx: Collect all bytes during disassembly

[Philippe Mathieu-Daudé]

On 5/31/19 3:43 PM, Richard Henderson wrote:
> Collected, to be used in the next patch.
> 
> Reviewed-by: Yoshinori Sato 
> Signed-off-by: Richard Henderson 
> ---
>  target/rx/disas.c | 62 ---
>  1 file changed, 42 insertions(+), 20 deletions(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index ebc1a44249..5a32a87534 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -25,43 +25,59 @@ typedef struct DisasContext {
>  disassemble_info *dis;
>  uint32_t addr;
>  uint32_t pc;
> +uint8_t len;
> +uint8_t bytes[8];
>  } DisasContext;
>  
>  
>  static uint32_t decode_load_bytes(DisasContext *ctx, uint32_t insn,
> -   int i, int n)
> +  int i, int n)
>  {
> -bfd_byte buf;
> +uint32_t addr = ctx->addr;
> +
> +g_assert(ctx->len == i);
> +g_assert(n <= ARRAY_SIZE(ctx->bytes));
> +
>  while (++i <= n) {
> -ctx->dis->read_memory_func(ctx->addr++, , 1, ctx->dis);
> -insn |= buf << (32 - i * 8);
> +ctx->dis->read_memory_func(addr++, >bytes[i - 1], 1, ctx->dis);
> +insn |= ctx->bytes[i - 1] << (32 - i * 8);
>  }
> +ctx->addr = addr;
> +ctx->len = n;
> +
>  return insn;
>  }
>  
>  static int32_t li(DisasContext *ctx, int sz)
>  {
> -int32_t addr;
> -bfd_byte buf[4];
> -addr = ctx->addr;
> +uint32_t addr = ctx->addr;
> +uintptr_t len = ctx->len;
>  
>  switch (sz) {
>  case 1:
> +g_assert(len + 1 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 1;
> -ctx->dis->read_memory_func(addr, buf, 1, ctx->dis);
> -return (int8_t)buf[0];
> +ctx->len += 1;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 1, ctx->dis);
> +return (int8_t)ctx->bytes[len];
>  case 2:
> +g_assert(len + 2 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 2;
> -ctx->dis->read_memory_func(addr, buf, 2, ctx->dis);
> -return ldsw_le_p(buf);
> +ctx->len += 2;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 2, ctx->dis);
> +return ldsw_le_p(ctx->bytes + len);
>  case 3:
> +g_assert(len + 3 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 3;
> -ctx->dis->read_memory_func(addr, buf, 3, ctx->dis);
> -return (int8_t)buf[2] << 16 | lduw_le_p(buf);
> +ctx->len += 3;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 3, ctx->dis);
> +return (int8_t)ctx->bytes[len + 2] << 16 | lduw_le_p(ctx->bytes + 
> len);
>  case 0:
> +g_assert(len + 4 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 4;
> -ctx->dis->read_memory_func(addr, buf, 4, ctx->dis);
> -return ldl_le_p(buf);
> +ctx->len += 4;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 4, ctx->dis);
> +return ldl_le_p(ctx->bytes + len);
>  default:
>  g_assert_not_reached();
>  }
> @@ -110,7 +126,7 @@ static const char psw[] = {
>  static void rx_index_addr(DisasContext *ctx, char out[8], int ld, int mi)
>  {
>  uint32_t addr = ctx->addr;
> -uint8_t buf[2];
> +uintptr_t len = ctx->len;
>  uint16_t dsp;
>  
>  switch (ld) {
> @@ -119,14 +135,18 @@ static void rx_index_addr(DisasContext *ctx, char 
> out[8], int ld, int mi)
>  out[0] = '\0';
>  return;
>  case 1:
> +g_assert(len + 1 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 1;
> -ctx->dis->read_memory_func(addr, buf, 1, ctx->dis);
> -dsp = buf[0];
> +ctx->len += 1;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 1, ctx->dis);
> +dsp = ctx->bytes[len];
>  break;
>  case 2:
> +g_assert(len + 2 <= ARRAY_SIZE(ctx->bytes));
>  ctx->addr += 2;
> -ctx->dis->read_memory_func(addr, buf, 2, ctx->dis);
> -dsp = lduw_le_p(buf);
> +ctx->len += 2;
> +ctx->dis->read_memory_func(addr, ctx->bytes + len, 2, ctx->dis);
> +dsp = lduw_le_p(ctx->bytes + len);
>  break;
>  default:
>  g_assert_not_reached();
> @@ -1392,8 +1412,10 @@ int print_insn_rx(bfd_vma addr, disassemble_info *dis)
>  DisasContext ctx;
>  uint32_t insn;
>  int i;
> +
>  ctx.dis = dis;
>  ctx.pc = ctx.addr = addr;
> +ctx.len = 0;
>  
>  insn = decode_load();
>  if (!decode(, insn)) {
> 

Reviewed-by: Philippe Mathieu-Daudé 

[Qemu-devel] [Bug 1831545] [NEW] "accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86 host

[Andrew Randrianasulu]

Public bug reported:

As described in https://lists.gnu.org/archive/html/qemu-
devel//2019-05/msg07362.html I run into TCG regression in qemu-git.

Unfortunately, fix from bug https://bugs.launchpad.net/qemu/+bug/1830872
seems to be nonn-effective for my case.

For reproduction (on 32-bit x86 host, in my case Slackware with gcc
5.5.0):

./configure --target-list=x86_64-softmmu --disable-werror --enable-
debug-tcg

make (-j5 in my case)

try to boot any 64-bit kernel:

x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64
-accel tcg

result is - qemu appear to hang right after "Booting the kernel" line.
Decompression (xz) was ok.

Tested with qemu-git commit  e2a58ff493a2e00db3e963c1839c5374500110f2

32-bit OS can be booted fine, and -enable-kvm also allow 64 bit
kernel/os to boot.

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: regression

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

Title:
  "accel/tcg: demacro cputlb" break qemu-system-x86_64 on 32-bit x86
  host

Status in QEMU:
  New

Bug description:
  As described in https://lists.gnu.org/archive/html/qemu-
  devel//2019-05/msg07362.html I run into TCG regression in qemu-git.

  Unfortunately, fix from bug
  https://bugs.launchpad.net/qemu/+bug/1830872 seems to be nonn-
  effective for my case.

  For reproduction (on 32-bit x86 host, in my case Slackware with gcc
  5.5.0):

  ./configure --target-list=x86_64-softmmu --disable-werror --enable-
  debug-tcg

  make (-j5 in my case)

  try to boot any 64-bit kernel:

  x86_64-softmmu/qemu-system-x86_64 -kernel /boot/bzImage-4.12.0-x64
  -accel tcg

  result is - qemu appear to hang right after "Booting the kernel" line.
  Decompression (xz) was ok.

  Tested with qemu-git commit  e2a58ff493a2e00db3e963c1839c5374500110f2

  32-bit OS can be booted fine, and -enable-kvm also allow 64 bit
  kernel/os to boot.

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

Re: [Qemu-devel] [PATCH v16 20/23] target/rx: Use prt_ldmi for XCHG_mr disassembly

[Philippe Mathieu-Daudé]

On 5/31/19 3:43 PM, Richard Henderson wrote:
> Note that the ld == 3 case handled by prt_ldmi is decoded as
> XCHG_rr and cannot appear here.
> 
> Reviewed-by: Yoshinori Sato 
> Signed-off-by: Richard Henderson 
> ---
>  target/rx/disas.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index 515b365528..db10385fd0 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -366,13 +366,7 @@ static bool trans_XCHG_rr(DisasContext *ctx, arg_XCHG_rr 
> *a)
>  /* xchg dsp[rs].,rd */
>  static bool trans_XCHG_mr(DisasContext *ctx, arg_XCHG_mr *a)
>  {
> -static const char msize[][4] = {
> -"b", "w", "l", "ub", "uw",
> -};
> -char dsp[8];
> -
> -rx_index_addr(ctx, dsp, a->ld, a->mi);
> -prt("xchg\t%s[r%d].%s, r%d", dsp, a->rs, msize[a->mi], a->rd);
> +prt_ldmi(ctx, "xchg", a->ld, a->mi, a->rs, a->rd);

:)

Reviewed-by: Philippe Mathieu-Daudé 

>  return true;
>  }
>  
> 

Re: [Qemu-devel] [PATCH v16 23/23] target/rx: Dump bytes for each insn during disassembly

[Philippe Mathieu-Daudé]

On 5/31/19 3:43 PM, Richard Henderson wrote:
> There are so many different forms of each RX instruction
> that it will be very useful to be able to look at the bytes
> to see on which path a bug may lie.
> 
> Reviewed-by: Yoshinori Sato 
> Signed-off-by: Richard Henderson 
> ---
>  target/rx/disas.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index 5a32a87534..d73b53db44 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -102,7 +102,21 @@ static int bdsp_s(DisasContext *ctx, int d)
>  /* Include the auto-generated decoder.  */
>  #include "decode.inc.c"
>  
> -#define prt(...) (ctx->dis->fprintf_func)((ctx->dis->stream), __VA_ARGS__)
> +static void dump_bytes(DisasContext *ctx)
> +{
> +int i, len = ctx->len;
> +
> +for (i = 0; i < len; ++i) {
> +ctx->dis->fprintf_func(ctx->dis->stream, "%02x ", ctx->bytes[i]);
> +}
> +ctx->dis->fprintf_func(ctx->dis->stream, "%*c", (8 - i) * 3, '\t');
> +}
> +
> +#define prt(...) \
> +do {\
> +dump_bytes(ctx);\
> +ctx->dis->fprintf_func(ctx->dis->stream, __VA_ARGS__);  \
> +} while (0)
>  
>  #define RX_MEMORY_BYTE 0
>  #define RX_MEMORY_WORD 1
> 

Reviewed-by: Philippe Mathieu-Daudé 

Re: [Qemu-devel] [PATCH v16 19/23] target/rx: Replace operand with prt_ldmi in disassembler

[Philippe Mathieu-Daudé]

On 5/31/19 3:43 PM, Richard Henderson wrote:
> This has consistency with prt_ri().  It loads all data before
> beginning output.  It uses exactly one call to prt() to emit
> the full instruction.
> 
> Reviewed-by: Yoshinori Sato 
> Signed-off-by: Richard Henderson 
> ---
>  target/rx/disas.c | 77 +--
>  1 file changed, 27 insertions(+), 50 deletions(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index 64342537ee..515b365528 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -135,18 +135,18 @@ static void rx_index_addr(DisasContext *ctx, char 
> out[8], int ld, int mi)
>  sprintf(out, "%u", dsp << (mi < 3 ? mi : 4 - mi));
>  }
>  
> -static void operand(DisasContext *ctx, int ld, int mi, int rs, int rd)
> +static void prt_ldmi(DisasContext *ctx, const char *insn,
> + int ld, int mi, int rs, int rd)
>  {
>  static const char sizes[][4] = {".b", ".w", ".l", ".uw", ".ub"};
>  char dsp[8];
>  
>  if (ld < 3) {
>  rx_index_addr(ctx, dsp, ld, mi);
> -prt("%s[r%d]%s", dsp, rs, sizes[mi]);
> +prt("%s\t%s[r%d]%s, r%d", insn, dsp, rs, sizes[mi], rd);
>  } else {
> -prt("r%d", rs);
> +prt("%s\tr%d, r%d", insn, rs, rd);
>  }
> -prt(", r%d", rd);
>  }
>  
>  static void prt_ir(DisasContext *ctx, const char *insn, int imm, int rd)
> @@ -416,8 +416,7 @@ static bool trans_AND_ir(DisasContext *ctx, arg_AND_ir *a)
>  /* and rs,rd */
>  static bool trans_AND_mr(DisasContext *ctx, arg_AND_mr *a)
>  {
> -prt("and\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "and", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -440,8 +439,7 @@ static bool trans_OR_ir(DisasContext *ctx, arg_OR_ir *a)
>  /* or rs,rd */
>  static bool trans_OR_mr(DisasContext *ctx, arg_OR_mr *a)
>  {
> -prt("or\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "or", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -463,8 +461,7 @@ static bool trans_XOR_ir(DisasContext *ctx, arg_XOR_ir *a)
>  /* xor rs,rd */
>  static bool trans_XOR_mr(DisasContext *ctx, arg_XOR_mr *a)
>  {
> -prt("xor\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "xor", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -479,8 +476,7 @@ static bool trans_TST_ir(DisasContext *ctx, arg_TST_ir *a)
>  /* tst rs, rd */
>  static bool trans_TST_mr(DisasContext *ctx, arg_TST_mr *a)
>  {
> -prt("tst\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "tst", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -548,8 +544,7 @@ static bool trans_ADD_irr(DisasContext *ctx, arg_ADD_irr 
> *a)
>  /* add dsp[rs], rd */
>  static bool trans_ADD_mr(DisasContext *ctx, arg_ADD_mr *a)
>  {
> -prt("add\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "add", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -573,8 +568,7 @@ static bool trans_CMP_ir(DisasContext *ctx, arg_CMP_ir *a)
>  /* cmp dsp[rs], rs2 */
>  static bool trans_CMP_mr(DisasContext *ctx, arg_CMP_mr *a)
>  {
> -prt("cmp\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "cmp", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -589,8 +583,7 @@ static bool trans_SUB_ir(DisasContext *ctx, arg_SUB_ir *a)
>  /* sub dsp[rs], rd */
>  static bool trans_SUB_mr(DisasContext *ctx, arg_SUB_mr *a)
>  {
> -prt("sub\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "sub", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -611,8 +604,7 @@ static bool trans_SBB_rr(DisasContext *ctx, arg_SBB_rr *a)
>  /* sbb dsp[rs], rd */
>  static bool trans_SBB_mr(DisasContext *ctx, arg_SBB_mr *a)
>  {
> -prt("sbb\t");
> -operand(ctx, a->ld, RX_IM_LONG, a->rs, a->rd);
> +prt_ldmi(ctx, "sbb", a->ld, RX_IM_LONG, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -640,8 +632,7 @@ static bool trans_MAX_ir(DisasContext *ctx, arg_MAX_ir *a)
>  /* max dsp[rs], rd */
>  static bool trans_MAX_mr(DisasContext *ctx, arg_MAX_mr *a)
>  {
> -prt("max\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "max", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -656,8 +647,7 @@ static bool trans_MIN_ir(DisasContext *ctx, arg_MIN_ir *a)
>  /* min dsp[rs], rd */
>  static bool trans_MIN_mr(DisasContext *ctx, arg_MIN_mr *a)
>  {
> -prt("max\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "min", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  
> @@ -673,8 +663,7 @@ static bool trans_MUL_ir(DisasContext *ctx, arg_MUL_ir *a)
>  /* mul dsp[rs], rd */
>  static bool trans_MUL_mr(DisasContext *ctx, arg_MUL_mr *a)
>  {
> -prt("mul\t");
> -operand(ctx, a->ld, a->mi, a->rs, a->rd);
> +prt_ldmi(ctx, "mul", a->ld, a->mi, a->rs, a->rd);
>  return true;
>  }
>  

Re: [Qemu-devel] [PATCH v16 21/23] target/rx: Emit all disassembly in one prt()

[Philippe Mathieu-Daudé]

On 5/31/19 3:43 PM, Richard Henderson wrote:
> Many of the multi-part prints have been eliminated by previous
> patches.  Eliminate the rest of them.
> 
> Reviewed-by: Yoshinori Sato 
> Signed-off-by: Richard Henderson 
> ---
>  target/rx/disas.c | 75 ---
>  1 file changed, 39 insertions(+), 36 deletions(-)
> 
> diff --git a/target/rx/disas.c b/target/rx/disas.c
> index db10385fd0..ebc1a44249 100644
> --- a/target/rx/disas.c
> +++ b/target/rx/disas.c
> @@ -228,24 +228,21 @@ static bool trans_MOV_ra(DisasContext *ctx, arg_MOV_ra 
> *a)
>  /* mov.[bwl] rs,rd */
>  static bool trans_MOV_mm(DisasContext *ctx, arg_MOV_mm *a)
>  {
> -char dspd[8], dsps[8];
> +char dspd[8], dsps[8], szc = size[a->sz];
>  
> -prt("mov.%c\t", size[a->sz]);
>  if (a->lds == 3 && a->ldd == 3) {
>  /* mov.[bwl] rs,rd */
> -prt("r%d, r%d", a->rs, a->rd);
> -return true;
> -}
> -if (a->lds == 3) {
> +prt("mov.%c\tr%d, r%d", szc, a->rs, a->rd);
> +} else if (a->lds == 3) {
>  rx_index_addr(ctx, dspd, a->ldd, a->sz);
> -prt("r%d, %s[r%d]", a->rs, dspd, a->rd);
> +prt("mov.%c\tr%d, %s[r%d]", szc, a->rs, dspd, a->rd);
>  } else if (a->ldd == 3) {
>  rx_index_addr(ctx, dsps, a->lds, a->sz);
> -prt("%s[r%d], r%d", dsps, a->rs, a->rd);
> +prt("mov.%c\t%s[r%d], r%d", szc, dsps, a->rs, a->rd);
>  } else {
>  rx_index_addr(ctx, dsps, a->lds, a->sz);
>  rx_index_addr(ctx, dspd, a->ldd, a->sz);
> -prt("%s[r%d], %s[r%d]", dsps, a->rs, dspd, a->rd);
> +prt("mov.%c\t%s[r%d], %s[r%d]", szc, dsps, a->rs, dspd, a->rd);
>  }
>  return true;
>  }
> @@ -254,8 +251,11 @@ static bool trans_MOV_mm(DisasContext *ctx, arg_MOV_mm 
> *a)
>  /* mov.[bwl] rs,[-rd] */
>  static bool trans_MOV_rp(DisasContext *ctx, arg_MOV_rp *a)
>  {
> -prt("mov.%c\tr%d, ", size[a->sz], a->rs);
> -prt((a->ad == 0) ? "[r%d+]" : "[-r%d]", a->rd);
> +if (a->ad) {
> +prt("mov.%c\tr%d, [-r%d]", size[a->sz], a->rs, a->rd);
> +} else {
> +prt("mov.%c\tr%d, [r%d+]", size[a->sz], a->rs, a->rd);
> +}
>  return true;
>  }
>  
> @@ -263,9 +263,11 @@ static bool trans_MOV_rp(DisasContext *ctx, arg_MOV_rp 
> *a)
>  /* mov.[bwl] [-rd],rs */
>  static bool trans_MOV_pr(DisasContext *ctx, arg_MOV_pr *a)
>  {
> -prt("mov.%c\t", size[a->sz]);
> -prt((a->ad == 0) ? "[r%d+]" : "[-r%d]", a->rd);
> -prt(", r%d", a->rs);
> +if (a->ad) {
> +prt("mov.%c\t[-r%d], r%d", size[a->sz], a->rd, a->rs);
> +} else {
> +prt("mov.%c\t[r%d+], r%d", size[a->sz], a->rd, a->rs);
> +}
>  return true;
>  }
>  
> @@ -299,9 +301,11 @@ static bool trans_MOVU_ar(DisasContext *ctx, arg_MOVU_ar 
> *a)
>  /* movu.[bw] [-rs],rd */
>  static bool trans_MOVU_pr(DisasContext *ctx, arg_MOVU_pr *a)
>  {
> -prt("movu.%c\t", size[a->sz]);
> -prt((a->ad == 0) ? "[r%d+]" : "[-r%d]", a->rd);
> -prt(", r%d", a->rs);
> +if (a->ad) {
> +prt("movu.%c\t[-r%d], r%d", size[a->sz], a->rd, a->rs);
> +} else {
> +prt("movu.%c\t[r%d+], r%d", size[a->sz], a->rd, a->rs);
> +}
>  return true;
>  }
>  
> @@ -478,11 +482,11 @@ static bool trans_TST_mr(DisasContext *ctx, arg_TST_mr 
> *a)
>  /* not rs, rd */
>  static bool trans_NOT_rr(DisasContext *ctx, arg_NOT_rr *a)
>  {
> -prt("not\t");
>  if (a->rs != a->rd) {
> -prt("r%d, ", a->rs);
> +prt("not\tr%d, r%d", a->rs, a->rd);
> +} else {
> +prt("not\tr%d", a->rs);
>  }
> -prt("r%d", a->rd);
>  return true;
>  }
>  
> @@ -490,11 +494,11 @@ static bool trans_NOT_rr(DisasContext *ctx, arg_NOT_rr 
> *a)
>  /* neg rs, rd */
>  static bool trans_NEG_rr(DisasContext *ctx, arg_NEG_rr *a)
>  {
> -prt("neg\t");
>  if (a->rs != a->rd) {
> -prt("r%d, ", a->rs);
> +prt("neg\tr%d, r%d", a->rs, a->rd);
> +} else {
> +prt("neg\tr%d", a->rs);
>  }
> -prt("r%d", a->rd);
>  return true;
>  }
>  
> @@ -606,11 +610,10 @@ static bool trans_SBB_mr(DisasContext *ctx, arg_SBB_mr 
> *a)
>  /* abs rs, rd */
>  static bool trans_ABS_rr(DisasContext *ctx, arg_ABS_rr *a)
>  {
> -prt("abs\t");
> -if (a->rs == a->rd) {
> -prt("r%d", a->rd);
> +if (a->rs != a->rd) {
> +prt("abs\tr%d, r%d", a->rs, a->rd);
>  } else {
> -prt("r%d, r%d", a->rs, a->rd);
> +prt("abs\tr%d", a->rs);
>  }
>  return true;
>  }
> @@ -733,11 +736,11 @@ static bool trans_DIVU_mr(DisasContext *ctx, 
> arg_DIVU_mr *a)
>  /* shll #imm:5, rs, rd */
>  static bool trans_SHLL_irr(DisasContext *ctx, arg_SHLL_irr *a)
>  {
> -prt("shll\t#%d, ", a->imm);
>  if (a->rs2 != a->rd) {
> -prt("r%d, ", a->rs2);
> +prt("shll\t#%d, r%d, r%d", a->imm, a->rs2, a->rd);
> +} else {
> +prt("shll\t#%d, r%d", a->imm, a->rd);
>  }
> -prt("r%d", a->rd);
>  return true;
>  }
>  

Re: [Qemu-devel] Deprecation policy and build dependencies

[Markus Armbruster]

Peter Maydell  writes:

> On Mon, 3 Jun 2019 at 19:21, John Snow  wrote:
>> I get it, we don't want to require Python 3.8 because some dev wanted
>> assignment conditionals -- but we're talking about Python 2 here, which
>> suffers its EOL by the end of this calendar year.

"Not because some dev wanted assignment conditionals" is the non-reason.
Let me spell out the reason: supporting Python 2 is expensive for us.
As the amount of Python code grows, it gets more and more expensive.

Is this really time and effort well spent?

>> So do we think it's reasonable to drop support for Python2 for the
>> release that comes out after Python2's EOL, or do we insist on 2x3
>> simultaneous support for years more?
>
> I don't have a strong opinion on Python in particular, but
> I think it would be nicer to avoid the "python is a special
> snowflake" effect.

Lots of things are nice.  Limited resources dictate we can only get some
of them.

>Would it really be so bad for it to just
> be "drop it when it falls off the last LTS distro" like the
> rest of our dependencies ?

In my experience maintaining and evolving the QAPI generators,
supporting both Python 2 and 3 is a constant distraction that adds up
over time.  It's all manual; we decided against adopting one of tool
chains made for dealing with this mess.  I'd rather think about how to
solve real user problems like deprecation information or command line
introspection than deal with Python 2 vs. 3 arcana.

Just the other day, I flagged an innocent-looking simplification of some
non-QAPI Python code that changed semantics subtly on Python 2, impact
unknown.  The developer did not know.  The fact that I waste precious
brain capacity on knowing this shit (pardon my French) is a bloody
shame.  Well, some of this shit, because I've screwed it up myself, too.

The sooner we stop the bleeding, the better.

Re: [Qemu-devel] [PATCH v16 15/23] hw/rx: Honor -accel qtest

[Philippe Mathieu-Daudé]

On 5/31/19 3:43 PM, Richard Henderson wrote:
> Issue an error if no kernel, no bios, and not qtest'ing.
> Fixes make check-qtest-rx: test/qom-test.
> 
> Signed-off-by: Richard Henderson 
> ---
>  hw/rx/rx62n.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/rx/rx62n.c b/hw/rx/rx62n.c
> index 3a8fe7b0bf..e55257c622 100644
> --- a/hw/rx/rx62n.c
> +++ b/hw/rx/rx62n.c
> @@ -21,11 +21,13 @@
>  
>  #include "qemu/osdep.h"
>  #include "qapi/error.h"
> +#include "qemu/error-report.h"
>  #include "hw/hw.h"
>  #include "hw/rx/rx62n.h"
>  #include "hw/loader.h"
>  #include "hw/sysbus.h"
>  #include "sysemu/sysemu.h"
> +#include "sysemu/qtest.h"
>  #include "cpu.h"
>  
>  /*
> @@ -190,8 +192,14 @@ static void rx62n_realize(DeviceState *dev, Error **errp)
>  memory_region_init_rom(>c_flash, NULL, "codeflash",
> RX62N_CFLASH_SIZE, errp);
>  memory_region_add_subregion(s->sysmem, RX62N_CFLASH_BASE, >c_flash);
> +
>  if (!s->kernel) {
> -rom_add_file_fixed(bios_name, RX62N_CFLASH_BASE, 0);
> +if (bios_name) {
> +rom_add_file_fixed(bios_name, RX62N_CFLASH_BASE, 0);
> +}  else if (!qtest_enabled()) {
> +error_report("No bios or kernel specified");
> +exit(1);
> +}
>  }
>  
>  object_initialize_child(OBJECT(s), "cpu", >cpu,
> 

Reviewed-by: Philippe Mathieu-Daudé 

Re: [Qemu-devel] [PATCH v3 00/14] tests/vm: serial console autoinstall, misc fixes.

[Philippe Mathieu-Daudé]

Cc'ing Paolo & Marc-André (and removing the BSD folks).

On 5/30/19 12:30 PM, Philippe Mathieu-Daudé wrote:
> Cc'ing the Python team.
> 
> On 5/30/19 12:18 PM, Alex Bennée wrote:
>>
>> Philippe Mathieu-Daudé  writes:
>>
>>> On 5/30/19 11:33 AM, Alex Bennée wrote:

 Gerd Hoffmann  writes:

> This patch series changes the way virtual machines for test builds are
> managed.  They are created locally on the developer machine now.  The
> installer is booted on the serial console and the scripts walks through
> the dialogs to install and configure the guest.
>
> That takes the download.patchew.org server out of the loop and makes it
> alot easier to tweak the guest images (adding build dependencies for
> example).
>
> The install scripts take care to apply host proxy settings (from *_proxy
> environment variables) to the guest, so any package downloads will be
> routed through the proxy and can be cached that way.  This also makes
> them work behind strict firewalls.
>
> There are also a bunch of smaller tweaks for tests/vm to fix issues I
> was struggling with.  See commit messages of individual patches for
> details.

 Queued to testing/next, thanks.

 One of the machines I'm testing on seems to have problems with getting
 the installer working over the serial link but it works on my main dev
 box and others have it working as well so I suspect it might be a local
 problem.
>>>
>>> Is this the same issue I described there?
>>> https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg06784.html
>>
>> Not quite.. on the failing machine I see it hang at:
>>
>>   make[1]: Leaving directory '/home/alex.bennee/lsrc/qemu.git/dtc'
>>   python3 -B /home/alex.bennee/lsrc/qemu.git/tests/vm/openbsd  --debug 
>> --image "/home/alex.bennee/.cache/qemu-vm/images/openbsd.img" --force 
>> --build-image /home/alex.bennee/.cache/qemu-vm/images/openbsd.img
>>   ### Downloading install iso ...
>>   ### Preparing iso and disk image ...
>>   Formatting '/home/alex.bennee/.cache/qemu-vm/images/openbsd.img.tmp', 
>> fmt=qcow2 size=21474836480 cluster_size=65536 lazy_refcounts=off 
>> refcount_bits=16
>>   ### Booting installer ...
>>   DEBUG:root:QEMU args: -nodefaults -m 4G -cpu max -netdev 
>> user,id=vnet,hostfwd=:127.0.0.1:0-:22 -device virtio-net-pci,netdev=vnet 
>> -vnc 127.0.0.1:0,to=20 -smp 18 -enable-kvm
>>   -device VGA -drive 
>> file=/home/alex.bennee/.cache/qemu-vm/images/openbsd.img.tmp,if=none,id=drive0,cache=writeback
>>  -device virtio-blk,drive=drive0,bootindex=0 -machine graphics=off -cdrom 
>> /home/alex.bennee/.cache/qemu-vm/images/openbsd.img.install.iso
>>   DEBUG:qemu:VM launch command: 'qemu-system-x86_64 -chardev 
>> socket,id=mon,path=/var/tmp/tmp0uvsee9z/qemu-18506-monitor.sock -mon 
>> chardev=mon,mode=control -display none -vga none -machine pc -chardev 
>> socket,id=console,path=/var/tmp/tmp0uvsee9z/qemu-18506-console.sock,server,nowait
>>  -serial chardev:console -nodefaults -m 4G -cpu max -netdev 
>> user,id=vnet,hostfwd=:127.0.0.1:0-:22 -device virtio-net-pci,netdev=vnet 
>> -vnc 127.0.0.1:0,to=20 -smp 18 -enable-kvm -device VGA -drive 
>> file=/home/alex.bennee/.cache/qemu-vm/images/openbsd.img.tmp,if=none,id=drive0,cache=writeback
>>  -device virtio-blk,drive=drive0,bootindex=0 -machine graphics=off -cdrom 
>> /home/alex.bennee/.cache/qemu-vm/images/openbsd.img.install.iso'
>>   DEBUG:QMP:>>> {'execute': 'qmp_capabilities'}
>>   DEBUG:QMP:<<< {'return': {}}
>>   DEBUG:QMP:>>> {'execute': 'human-monitor-command', 'arguments': 
>> {'command-line': 'info usernet'}}
>>   DEBUG:QMP:<<< {'return': 'VLAN -1 (vnet):\r\n  Protocol[State]FD  
>> Source Address  Port   Dest. Address  Port RecvQ SendQ\r\n  
>> TCP[HOST_FORWARD]  13   127.0.0.1 33465   10.0.2.1522 0 
>> 0\r\n'}
>>   console: *** read timeout ***
>>   console: waiting for: 'boot>'
>>   console: line buffer:
>>
>>
>>   Failed to prepare guest environment
>>   Traceback (most recent call last):
>> File "/home/alex.bennee/lsrc/qemu.git/tests/vm/basevm.py", line 350, in 
>> main
>>   return vm.build_image(args.image)
>> File "/home/alex.bennee/lsrc/qemu.git/tests/vm/openbsd", line 85, in 
>> build_image
>>   self.console_wait_send("boot>", "set tty com0\n")
>> File "/home/alex.bennee/lsrc/qemu.git/tests/vm/basevm.py", line 250, in 
>> console_wait_send
>>   self.console_wait(wait)
>> File "/home/alex.bennee/lsrc/qemu.git/tests/vm/basevm.py", line 212, in 
>> console_wait
>>   chars = vm.console_socket.recv(1024)
>>   socket.timeout: timed out
>>   DEBUG:QMP:>>> {'execute': 'quit'}
>>   DEBUG:QMP:<<< {'return': {}}
>>   /home/alex.bennee/lsrc/qemu.git/tests/vm/Makefile.include:47: recipe for 
>> target '/home/alex.bennee/.cache/qemu-vm/images/openbsd.img' failed
>>   make: *** [/home/alex.bennee/.cache/qemu-vm/images/openbsd.img] Error 2
>>
>> I can see the machine has actually booted as 

Re: [Qemu-devel] [PATCH v16 14/23] tests: Add rx to machine-none-test.c

[Philippe Mathieu-Daudé]

On 5/31/19 3:43 PM, Richard Henderson wrote:
> Fixes check-qtest-rx: tests/machine-none-test.
> 
> Cc: Thomas Huth 
> Cc: Laurent Vivier 
> Cc: Paolo Bonzini 
> Signed-off-by: Richard Henderson 
> ---
>  tests/machine-none-test.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/machine-none-test.c b/tests/machine-none-test.c
> index 4c6d470798..80df277357 100644
> --- a/tests/machine-none-test.c
> +++ b/tests/machine-none-test.c
> @@ -56,6 +56,7 @@ static struct arch2cpu cpus_map[] = {
>  { "hppa", "hppa" },
>  { "riscv64", "rv64gcsu-v1.10.0" },
>  { "riscv32", "rv32gcsu-v1.9.1" },
> +{ "rx", "rx62n" },
>  };
>  
>  static const char *get_cpu_model_by_arch(const char *arch)
> 

Reviewed-by: Philippe Mathieu-Daudé 

Re: [Qemu-devel] [PATCH v16 12/23] target/rx: Add RX to SysEmuTarget

[Philippe Mathieu-Daudé]

On 5/31/19 3:43 PM, Richard Henderson wrote:
> Fixes check-qtest-rx: tests/qmp-cmd-test
> 
> Cc: Eric Blake 
> Cc: Markus Armbruster 
> Signed-off-by: Richard Henderson 
> ---
>  qapi/common.json | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/qapi/common.json b/qapi/common.json
> index 99d313ef3b..d0fc931159 100644
> --- a/qapi/common.json
> +++ b/qapi/common.json
> @@ -183,6 +183,7 @@
>  #is true even for "qemu-system-x86_64".
>  #
>  # ppcemb: dropped in 3.1
> +# rx: added in 4.1
>  #
>  # Since: 3.0
>  ##
> @@ -190,6 +191,6 @@
>'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32',
>   'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
>   'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
> - 'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
> + 'ppc64', 'riscv32', 'riscv64', 'rx', 's390x', 'sh4',
>   'sh4eb', 'sparc', 'sparc64', 'tricore', 'unicore32',
>   'x86_64', 'xtensa', 'xtensaeb' ] }
> 

Reviewed-by: Philippe Mathieu-Daudé 

Re: [Qemu-devel] [PATCH v2] migratioin/ram: leave RAMBlock->bmap blank on allocating

[Wei Yang]

On Tue, Jun 04, 2019 at 11:51:24AM +0800, Peter Xu wrote:
>On Tue, Jun 04, 2019 at 08:28:10AM +0800, Wei Yang wrote:
>> During migration, we would sync bitmap from ram_list.dirty_memory to
>> RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().
>> 
>> Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this
>> means at the first round this sync is meaningless and is a duplicated
>> work.
>> 
>> Leaving RAMBlock->bmap blank on allocating would have a side effect on
>> migration_dirty_pages, since it is calculated from the result of
>> cpu_physical_memory_sync_dirty_bitmap(). To keep it right, we need to
>> set migration_dirty_pages to 0 in ram_state_init().
>> 
>> Signed-off-by: Wei Yang 
>> Reviewed-by: Dr. David Alan Gilbert 
>> 
>> ---
>> v2: add a comment explaining why leaving RAMBlock.bmap clear
>> ---
>>  migration/ram.c | 16 +---
>>  1 file changed, 9 insertions(+), 7 deletions(-)
>> 
>> diff --git a/migration/ram.c b/migration/ram.c
>> index 4c60869226..e9a27ea5e6 100644
>> --- a/migration/ram.c
>> +++ b/migration/ram.c
>> @@ -3181,12 +3181,7 @@ static int ram_state_init(RAMState **rsp)
>>  qemu_mutex_init(&(*rsp)->src_page_req_mutex);
>>  QSIMPLEQ_INIT(&(*rsp)->src_page_requests);
>>  
>> -/*
>> - * Count the total number of pages used by ram blocks not including any
>> - * gaps due to alignment or unplugs.
>> - */
>> -(*rsp)->migration_dirty_pages = ram_bytes_total() >> TARGET_PAGE_BITS;
>> -
>
>Since you've spent time discovering this relationship, we can also
>comment on this too to hint future readers:
>
>   /*
>* This must match with the initial values of dirty bitmap.
>* Currently we initialize the dirty bitmap to all zeros so
>* here the total dirty page count is zero.
>*/
>

You are right.

>> +(*rsp)->migration_dirty_pages = 0;
>>  ram_state_reset(*rsp);
>>  
>>  return 0;
>> @@ -3201,8 +3196,15 @@ static void ram_list_init_bitmaps(void)
>>  if (ram_bytes_total()) {
>>  RAMBLOCK_FOREACH_NOT_IGNORED(block) {
>>  pages = block->max_length >> TARGET_PAGE_BITS;
>> +/*
>> + * We leave RAMBlock.bmap clear here and they will be sync from
>> + * ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION] in
>> + * migration_bitmap_sync_precopy().
>
>(This sentence is a bit confusing to me)
>
>> + *
>> + * ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION] is set to all 1
>> + * in ram_block_add().
>
>How about:
>
>The initial dirty bitmap for migration must be set with all ones
>to make sure we'll migrate every guest RAM page to destination.
>Here we didn't set RAMBlock.bmap simply because it is already set
>in ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION] in ram_block_add,
>and that's where we'll sync the dirty bitmaps.  Here setting
>RAMBlock.bmap would be fine too but not necessary.
>
>?
>

Sounds better :-)

>> + */
>>  block->bmap = bitmap_new(pages);
>> -bitmap_set(block->bmap, 0, pages);
>>  if (migrate_postcopy_ram()) {
>>  block->unsentmap = bitmap_new(pages);
>>  bitmap_set(block->unsentmap, 0, pages);
>> -- 
>> 2.19.1
>> 
>
>Regards,
>
>-- 
>Peter Xu

-- 
Wei Yang
Help you, Help me

Re: [Qemu-devel] Deprecation policy and build dependencies

[Gerd Hoffmann]

  Hi,

> >> Normally I'd say it's only nice to also follow the depreciation policy
> >> for tooling as well to give people a chance to switch away, but with
> >> regards to Python2, I feel like we're in the clear to drop it for the
> >> first release that will happen after the Python2 doomsday clock.
> >>
> >> (So, probably 4.2.)

Makes sense to me.

> > RHEL-7 has Python 3 only in EPEL.

That'll change with 7.7 btw.  Beside that I'd say EPEL is good enough.

> What's the benefit of making sure that stable platforms can continue to
> run the *newest* QEMU?

Well, my development workstation runs RHEL-7 ...

cheers,
  Gerd

Re: [Qemu-devel] [PATCH v16 00/23] Add RX architecture

[Philippe Mathieu-Daudé]

On 5/31/19 3:42 PM, Richard Henderson wrote:
> The v14 patch set, from which I had prepared the pull request,
> contained errors within make check-qtest-rx.  I have added 4
> new patches, 12 through 15, to address those failures.  These
> are placed before the enablement patch 16 so that there is no
> point at which these tests both run and fail.
> 
> I have not tried to extract the changes that Sato-san made in
> his v15 patch set and folded in to previous patches.
> 
> I have appended the disassembler patches that have been reviewed.
> 
> Hopefully this is the version that can be merged, so that normal
> development can proceed from there.
> 
> 
> r~
> 
> 
> Richard Henderson (11):
>   target/rx: Convert to CPUClass::tlb_fill
>   target/rx: Add RX to SysEmuTarget
>   target/rx: Fix cpu types and names
>   tests: Add rx to machine-none-test.c
>   hw/rx: Honor -accel qtest
>   target/rx: Disassemble rx_index_addr into a string
>   target/rx: Replace operand with prt_ldmi in disassembler
>   target/rx: Use prt_ldmi for XCHG_mr disassembly
>   target/rx: Emit all disassembly in one prt()
>   target/rx: Collect all bytes during disassembly
>   target/rx: Dump bytes for each insn during disassembly
> 
> Yoshinori Sato (12):
>   target/rx: TCG translation
>   target/rx: TCG helper
>   target/rx: CPU definition
>   target/rx: RX disassembler
>   hw/intc: RX62N interrupt controller (ICUa)
>   hw/timer: RX62N internal timer modules
>   hw/char: RX62N serial communication interface (SCI)
>   hw/rx: RX Target hardware definition
>   qemu/bitops.h: Add extract8 and extract16
>   hw/registerfields.h: Add 8bit and 16bit register macros
>   Add rx-softmmu
>   MAINTAINERS: Add RX

Series:
Tested-by: Philippe Mathieu-Daudé 

You might want to include this test:
https://lists.gnu.org/archive/html/qemu-devel/2019-05/msg05747.html

To run it:

$ make check-venv
$ ./tests/venv/bin/python -m avocado --show=console run -t arch:rx
tests/acceptance/boot_linux_console.py
console: U-Boot 2016.05-rc3-23705-ga1ef3c71cb-dirty (Feb 05 2019 -
21:56:06 +0900)
console: Linux version 4.19.0+ (yo-satoh@yo-satoh-debian) (gcc version
9.0.0 20181105 (experimental) (GCC)) #137 Wed Feb 20 23:20:02 JST 2019
console: Built 1 zonelists, mobility grouping on.  Total pages: 8128
console: Kernel command line:
console: Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
console: Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
console: Memory: 14648K/32768K available (871K kernel code, 95K rwdata,
140K rodata, 96K init, 175K bss, 18120K reserved, 0K cma-reserved)
console: NR_IRQS: 256
console: rx-cmt: used for periodic clock events
console: clocksource: rx-tpu: mask: 0x max_cycles: 0x,
max_idle_ns: 1274173631191 ns
console: 96.00 BogoMIPS (lpj=48)
console: pid_max: default: 4096 minimum: 301
console: Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
console: Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
console: clocksource: jiffies: mask: 0x max_cycles: 0x,
max_idle_ns: 1911260446275 ns
console: clocksource: Switched to clocksource rx-tpu
console: workingset: timestamp_bits=30 max_order=12 bucket_order=0
console: SuperH (H)SCI(F) driver initialized
console: 88240.serial: ttySC0 at MMIO 0x88240 (irq = 215, base_baud = 0)
is a sci
console: console [ttySC0] enabled
console: 88248.serial: ttySC1 at MMIO 0x88248 (irq = 219, base_baud = 0)
is a sci
console: random: get_random_bytes called from 0x01002e48 with crng_init=0
console: Freeing unused kernel memory: 96K
console: This architecture does not have kernel memory protection.
console: Run /sbin/init as init process
console: Run /etc/init as init process
console: Run /bin/init as init process
console: Run /bin/sh as init process
console: Sash command shell (version 1.1.1)
console: /> printenv
console: HOME=/
console: TERM=linux

Re: [Qemu-devel] [PATCH v2] migratioin/ram: leave RAMBlock->bmap blank on allocating

[Peter Xu]

On Tue, Jun 04, 2019 at 08:28:10AM +0800, Wei Yang wrote:
> During migration, we would sync bitmap from ram_list.dirty_memory to
> RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().
> 
> Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this
> means at the first round this sync is meaningless and is a duplicated
> work.
> 
> Leaving RAMBlock->bmap blank on allocating would have a side effect on
> migration_dirty_pages, since it is calculated from the result of
> cpu_physical_memory_sync_dirty_bitmap(). To keep it right, we need to
> set migration_dirty_pages to 0 in ram_state_init().
> 
> Signed-off-by: Wei Yang 
> Reviewed-by: Dr. David Alan Gilbert 
> 
> ---
> v2: add a comment explaining why leaving RAMBlock.bmap clear
> ---
>  migration/ram.c | 16 +---
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 4c60869226..e9a27ea5e6 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3181,12 +3181,7 @@ static int ram_state_init(RAMState **rsp)
>  qemu_mutex_init(&(*rsp)->src_page_req_mutex);
>  QSIMPLEQ_INIT(&(*rsp)->src_page_requests);
>  
> -/*
> - * Count the total number of pages used by ram blocks not including any
> - * gaps due to alignment or unplugs.
> - */
> -(*rsp)->migration_dirty_pages = ram_bytes_total() >> TARGET_PAGE_BITS;
> -

Since you've spent time discovering this relationship, we can also
comment on this too to hint future readers:

   /*
* This must match with the initial values of dirty bitmap.
* Currently we initialize the dirty bitmap to all zeros so
* here the total dirty page count is zero.
*/

> +(*rsp)->migration_dirty_pages = 0;
>  ram_state_reset(*rsp);
>  
>  return 0;
> @@ -3201,8 +3196,15 @@ static void ram_list_init_bitmaps(void)
>  if (ram_bytes_total()) {
>  RAMBLOCK_FOREACH_NOT_IGNORED(block) {
>  pages = block->max_length >> TARGET_PAGE_BITS;
> +/*
> + * We leave RAMBlock.bmap clear here and they will be sync from
> + * ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION] in
> + * migration_bitmap_sync_precopy().

(This sentence is a bit confusing to me)

> + *
> + * ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION] is set to all 1
> + * in ram_block_add().

How about:

The initial dirty bitmap for migration must be set with all ones
to make sure we'll migrate every guest RAM page to destination.
Here we didn't set RAMBlock.bmap simply because it is already set
in ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION] in ram_block_add,
and that's where we'll sync the dirty bitmaps.  Here setting
RAMBlock.bmap would be fine too but not necessary.

?

> + */
>  block->bmap = bitmap_new(pages);
> -bitmap_set(block->bmap, 0, pages);
>  if (migrate_postcopy_ram()) {
>  block->unsentmap = bitmap_new(pages);
>  bitmap_set(block->unsentmap, 0, pages);
> -- 
> 2.19.1
> 

Regards,

-- 
Peter Xu

Re: [Qemu-devel] [PULL 00/28] Block layer patches

[no-reply]

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



Hi,

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

Subject: [Qemu-devel] [PULL 00/28] Block layer patches
Type: series
Message-id: 20190603150233.6614-1-kw...@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 ===

From https://github.com/patchew-project/qemu
   ad88e4252f..e2a58ff493  master -> master
From https://github.com/patchew-project/qemu
 * [new tag]   patchew/20190603150233.6614-1-kw...@redhat.com -> 
patchew/20190603150233.6614-1-kw...@redhat.com
Switched to a new branch 'test'
220e753b45 iotests: Fix duplicated diff output on failure
0b71e618fa block/io: bdrv_pdiscard: support int64_t bytes parameter
e7a4ac900f block/qcow2-refcount: add trace-point to qcow2_process_discards
4dad653c53 block: Remove bdrv_set_aio_context()
3ab629f6ae test-bdrv-drain: Use bdrv_try_set_aio_context()
a2c999ab92 iotests: Attach new devices to node in non-default iothread
9882a15cb7 virtio-scsi-test: Test attaching new overlay with iothreads
bad8ab68a2 block: Remove wrong bdrv_set_aio_context() calls
4b94672417 blockdev: Use bdrv_try_set_aio_context() for monitor commands
ac65c7ccfd block: Move node without parents to main AioContext
f3f5afac50 test-block-iothread: BlockBackend AioContext across root node change
5be6b76fd8 test-block-iothread: Test adding parent to iothread node
d44a5b97a1 block: Adjust AioContexts when attaching nodes
032072dbdd scsi-disk: Use qdev_prop_drive_iothread
08213d11da block: Add qdev_prop_drive_iothread property type
3143af0939 block: Add BlockBackend.ctx
0218a8120b block: Add Error to blk_set_aio_context()
8dec7e6e5d nbd-server: Call blk_set_allow_aio_context_change()
4fab052a83 test-block-iothread: Check filter node in test_propagate_mirror
bec547ff8c nvme: add Get/Set Feature Timestamp support
daedce9044 block/linux-aio: Drop unused BlockAIOCB submission method
a620ab7c2f iotests: Test cancelling a job and closing the VM
b13df9380c block/io: Delay decrementing the quiesce_counter
96436a8e4d block: avoid recursive block_status call if possible
3b06eca03a tests/perf: Test lseek influence on qcow2 block-status
24a7a53346 blockdev: fix missed target unref for drive-backup
73ec47bcf8 iotests: Test commit job start with concurrent I/O
c8758f4aab block: Drain source node in bdrv_replace_node()

=== OUTPUT BEGIN ===
1/28 Checking commit c8758f4aabfc (block: Drain source node in 
bdrv_replace_node())
2/28 Checking commit 73ec47bcf823 (iotests: Test commit job start with 
concurrent I/O)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#16: 
new file mode 100755

total: 0 errors, 1 warnings, 131 lines checked

Patch 2/28 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
3/28 Checking commit 24a7a533464e (blockdev: fix missed target unref for 
drive-backup)
4/28 Checking commit 3b06eca03aff (tests/perf: Test lseek influence on qcow2 
block-status)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#20: 
new file mode 100755

total: 0 errors, 1 warnings, 71 lines checked

Patch 4/28 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
5/28 Checking commit 96436a8e4dba (block: avoid recursive block_status call if 
possible)
6/28 Checking commit b13df9380cc9 (block/io: Delay decrementing the 
quiesce_counter)
7/28 Checking commit a620ab7c2f73 (iotests: Test cancelling a job and closing 
the VM)
8/28 Checking commit daedce9044d9 (block/linux-aio: Drop unused BlockAIOCB 
submission method)
9/28 Checking commit bec547ff8ce6 (nvme: add Get/Set Feature Timestamp support)
10/28 Checking commit 4fab052a83c2 (test-block-iothread: Check filter node in 
test_propagate_mirror)
11/28 Checking commit 8dec7e6e5db9 (nbd-server: Call 
blk_set_allow_aio_context_change())
12/28 Checking commit 0218a8120b5c (block: Add Error to blk_set_aio_context())
WARNING: Block comments use a leading /* on a separate line
#104: FILE: hw/block/dataplane/virtio-blk.c:289:
+/* Drain and try to switch bs back to the QEMU main loop. If other users

WARNING: Block comments use a trailing */ on a separate line
#105: FILE: hw/block/dataplane/virtio-blk.c:290:
+ * keep the BlockBackend in the iothread, that's ok */

total: 0 errors, 2 warnings, 259 lines checked

Patch 12/28 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
13/28 Checking commit 3143af09391d (block: Add BlockBackend.ctx)
WARNING: Block comments use a leading /* on a separate line
#96: FILE: 

Re: [Qemu-devel] [PATCH v2] target/arm: Vectorize USHL and SSHL

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190603232209.20704-1-richard.hender...@linaro.org/



Hi,

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

Subject: [Qemu-devel] [PATCH v2] target/arm: Vectorize USHL and SSHL
Type: series
Message-id: 20190603232209.20704-1-richard.hender...@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 ===

From https://github.com/patchew-project/qemu
 * [new tag]   
patchew/20190603232209.20704-1-richard.hender...@linaro.org -> 
patchew/20190603232209.20704-1-richard.hender...@linaro.org
Switched to a new branch 'test'
4e81ddf830 target/arm: Vectorize USHL and SSHL

=== OUTPUT BEGIN ===
ERROR: trailing statements should be on next line
#160: FILE: target/arm/translate.c:5377:
+case 2: gen_ushl_i32(var, var, shift); break;

ERROR: trailing statements should be on next line
#167: FILE: target/arm/translate.c:5383:
+case 2: gen_sshl_i32(var, var, shift); break;

total: 2 errors, 0 warnings, 570 lines checked

Commit 4e81ddf8304a (target/arm: Vectorize USHL and SSHL) 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/20190603232209.20704-1-richard.hender...@linaro.org/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [Qemu-devel] [PATCH 5/5] virtio: add "use-started" property

[Yongji Xie]

On Tue, 4 Jun 2019 at 04:49, Greg Kurz  wrote:
>
> On Wed, 29 May 2019 15:09:55 +0800
> elohi...@gmail.com wrote:
>
> > From: Xie Yongji 
> >
> > In order to avoid migration issues, we introduce a "use-started"
> > property to the base virtio device to indicate whether "started"
> > and "start_on_kick" flag could be used. This property will be
> > true by default and set to false when machine type <= 4.0.
> >
> > Suggested-by: Greg Kurz 
> > Signed-off-by: Xie Yongji 
> > ---
> >  hw/block/vhost-user-blk.c  |  8 ++--
> >  hw/core/machine.c  |  4 +++-
> >  hw/virtio/virtio.c |  7 ---
> >  include/hw/virtio/virtio.h | 10 ++
> >  4 files changed, 23 insertions(+), 6 deletions(-)
> >
> > diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
> > index 9cb61336a6..520c5d3d4b 100644
> > --- a/hw/block/vhost-user-blk.c
> > +++ b/hw/block/vhost-user-blk.c
> > @@ -191,9 +191,13 @@ static void vhost_user_blk_stop(VirtIODevice *vdev)
> >  static void vhost_user_blk_set_status(VirtIODevice *vdev, uint8_t status)
> >  {
> >  VHostUserBlk *s = VHOST_USER_BLK(vdev);
> > -bool should_start = vdev->started;
> > +bool should_start = status & VIRTIO_CONFIG_S_DRIVER_OK;
>
> I guess you need the above because the set_status callback is called
> before setting vdev->status, and virtio_device_started() thus doesn't
> return the expected result for older machine types ?
>

Yes, that's case.

> What about adding a status argument to virtio_device_started() ?
>
> bool should_start = virtio_device_started(vdev, status);
>

Looks fine to me.

> >  int ret;
> >
> > +if (virtio_device_started(vdev)) {
> > +should_start = true;
> > +}
> > +
> >  if (!vdev->vm_running) {
> >  should_start = false;
> >  }
> > @@ -317,7 +321,7 @@ static int vhost_user_blk_connect(DeviceState *dev)
> >  }
> >
> >  /* restore vhost state */
> > -if (vdev->started) {
> > +if (virtio_device_started(vdev)) {
>
> if (virtio_device_started(vdev, vdev->status)) {
>
> and so on...
>
> >  ret = vhost_user_blk_start(vdev);
> >  if (ret < 0) {
> >  error_report("vhost-user-blk: vhost start failed: %s",
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index 934c1bcceb..1730d28c1b 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -24,7 +24,9 @@
> >  #include "hw/pci/pci.h"
> >  #include "hw/mem/nvdimm.h"
> >
> > -GlobalProperty hw_compat_4_0[] = {};
> > +GlobalProperty hw_compat_4_0[] = {
> > +{ "virtio-device", "use-started", "false" },
> > +};
> >  const size_t hw_compat_4_0_len = G_N_ELEMENTS(hw_compat_4_0);
> >
> >  GlobalProperty hw_compat_3_1[] = {
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index 9e17293d46..4c05a9efe3 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -1803,14 +1803,14 @@ static bool virtio_started_needed(void *opaque)
> >  {
> >  VirtIODevice *vdev = opaque;
> >
> > -return vdev->started;
> > +return vdev->started && vdev->use_started;
>
> Hmm... the idea is that vdev->started should never be set when
> "use-started" is "off". Instead of checking vdev->use_started
> here, you should rather assign it to vdev->started everywhere
> you currently assign true.
>

Will do it in v2.

Thanks,
Yongji

[Qemu-devel] [PATCH] migration/multifd: sync packet_num after all thread are done

[Wei Yang]

Notification from recv thread is not ordered, which means we may be
notified by one MultiFDRecvParams but adjust packet_num for another.

Move the adjustment after we are sure each recv thread are sync-ed.

Signed-off-by: Wei Yang 
---
 migration/ram.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index ac75e3e30e..a4e7587648 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -1292,15 +1292,15 @@ static void multifd_recv_sync_main(void)
 
 trace_multifd_recv_sync_main_wait(p->id);
 qemu_sem_wait(_recv_state->sem_sync);
+}
+for (i = 0; i < migrate_multifd_channels(); i++) {
+MultiFDRecvParams *p = _recv_state->params[i];
+
 qemu_mutex_lock(>mutex);
 if (multifd_recv_state->packet_num < p->packet_num) {
 multifd_recv_state->packet_num = p->packet_num;
 }
 qemu_mutex_unlock(>mutex);
-}
-for (i = 0; i < migrate_multifd_channels(); i++) {
-MultiFDRecvParams *p = _recv_state->params[i];
-
 trace_multifd_recv_sync_main_signal(p->id);
 qemu_sem_post(>sem_sync);
 }
-- 
2.19.1

Re: [Qemu-devel] [PATCH qemu] aspeed: Add support for the swift-bmc board

[Andrew Jeffery]

On Tue, 4 Jun 2019, at 09:07, Joel Stanley wrote:
> On Mon, 3 Jun 2019 at 19:11, Adriana Kobylak  wrote:
> >
> > From: Adriana Kobylak 
> >
> > The Swift board is an OpenPOWER system hosting POWER processors.
> > Add support for their BMC including the I2C devices as found on HW.
> >
> > Signed-off-by: Adriana Kobylak 
> > Reviewed-by: Cédric Le Goater 
> > ---
> >  hw/arm/aspeed.c | 42 ++
> >  1 file changed, 42 insertions(+)
> >
> > diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> > index 33070a6..cd95b3c 100644
> > --- a/hw/arm/aspeed.c
> > +++ b/hw/arm/aspeed.c
> > @@ -73,6 +73,9 @@ struct AspeedBoardState {
> >  SCU_AST2500_HW_STRAP_ACPI_ENABLE |  \
> >  SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_MASTER))
> >
> > +/* TODO: Swift hardware value: ? (use romulus definition for now) */
> > +#define SWIFT_BMC_HW_STRAP1 ROMULUS_BMC_HW_STRAP1
> 
> I got this from hardware: 0xF11AD206

There are two differences from the value noted in the comment below:

1. Bit 4 is clear in your value
2. Bit 20 is set in your value

Bit 4 is reserved, so not sure if we should care about the difference.

Bit 20 is the SuperIO decode disable bit. I don't think we care much
about it at the moment, but we may as we model more of the LPC
interface in the future.

Andrew

> 
> The rest looks okay.
> 
> Reviewed-by: Joel Stanley 
> 
> > +
> >  /* Witherspoon hardware value: 0xF10AD216 (but use romulus definition) */
> >  #define WITHERSPOON_BMC_HW_STRAP1 ROMULUS_BMC_HW_STRAP1
> >
> > @@ -287,6 +290,35 @@ static void romulus_bmc_i2c_init(AspeedBoardState *bmc)
> >  i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 11), "ds1338", 
> > 0x32);
> >  }
> >
> > +static void swift_bmc_i2c_init(AspeedBoardState *bmc)
> > +{
> > +AspeedSoCState *soc = >soc;
> > +
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 3), "pca9552", 
> > 0x60);
> > +
> > +/* The swift board expects a TMP275 but a TMP105 is compatible */
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 7), "tmp105", 
> > 0x48);
> > +/* The swift board expects a pca9551 but a pca9552 is compatible */
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 7), "pca9552", 
> > 0x60);
> > +
> > +/* The swift board expects an Epson RX8900 RTC but a ds1338 is 
> > compatible */
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 8), "ds1338", 
> > 0x32);
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 8), "pca9552", 
> > 0x60);
> > +
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 9), "tmp423", 
> > 0x4c);
> > +/* The swift board expects a pca9539 but a pca9552 is compatible */
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 9), "pca9552", 
> > 0x74);
> > +
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 10), "tmp423", 
> > 0x4c);
> > +/* The swift board expects a pca9539 but a pca9552 is compatible */
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 10), "pca9552",
> > + 0x74);
> > +
> > +/* The swift board expects a TMP275 but a TMP105 is compatible */
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 12), "tmp105", 
> > 0x48);
> > +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 12), "tmp105", 
> > 0x4a);
> > +}
> > +
> >  static void witherspoon_bmc_i2c_init(AspeedBoardState *bmc)
> >  {
> >  AspeedSoCState *soc = >soc;
> > @@ -378,6 +410,16 @@ static const AspeedBoardConfig aspeed_boards[] = {
> >  .i2c_init  = romulus_bmc_i2c_init,
> >  .ram   = 512 * MiB,
> >  }, {
> > +.name  = MACHINE_TYPE_NAME("swift-bmc"),
> > +.desc  = "OpenPOWER Swift BMC (ARM1176)",
> > +.soc_name  = "ast2500-a1",
> > +.hw_strap1 = SWIFT_BMC_HW_STRAP1,
> > +.fmc_model = "mx66l1g45g",
> > +.spi_model = "mx66l1g45g",
> > +.num_cs= 2,
> > +.i2c_init  = swift_bmc_i2c_init,
> > +.ram   = 512 * MiB,
> > +}, {
> >  .name  = MACHINE_TYPE_NAME("witherspoon-bmc"),
> >  .desc  = "OpenPOWER Witherspoon BMC (ARM1176)",
> >  .soc_name  = "ast2500-a1",
> > --
> > 1.8.3.1
> >
>

Re: [Qemu-devel] [PATCH 0/4] Multifd Cleanup

[Wei Yang]

Hi, David

Do you prefer I resend 3/4 or it is ok for you to pick up here directly?

On Tue, May 28, 2019 at 09:46:59AM +0800, Wei Yang wrote:
>Just found several small places for unused variables.
>
>Wei Yang (4):
>  migration: multifd_save_setup always return 0
>  migration/ram.c: use same type in MultiFDPages_t to define offsest
>  migration/ram.c: MultiFDSendParams.sem_sync is not really used
>  migration/ram.c: multifd_send_state->count is not really used
>
> migration/migration.c |  7 +--
> migration/ram.c   | 11 +--
> 2 files changed, 2 insertions(+), 16 deletions(-)
>
>-- 
>2.19.1

-- 
Wei Yang
Help you, Help me

Re: [Qemu-devel] [PATCH] target/ppc: Use tcg_gen_gvec_bitsel

[David Gibson]

On Mon, Jun 03, 2019 at 11:49:27AM -0500, Richard Henderson wrote:
> Replace the target-specific implementation of XXSEL.

Applied, thanks.

> 
> Signed-off-by: Richard Henderson 
> ---
>  target/ppc/translate/vsx-impl.inc.c | 24 ++--
>  1 file changed, 2 insertions(+), 22 deletions(-)
> 
> diff --git a/target/ppc/translate/vsx-impl.inc.c 
> b/target/ppc/translate/vsx-impl.inc.c
> index 199d22da97..a7a0a88975 100644
> --- a/target/ppc/translate/vsx-impl.inc.c
> +++ b/target/ppc/translate/vsx-impl.inc.c
> @@ -1338,28 +1338,8 @@ static void glue(gen_, name)(DisasContext *ctx)
>  \
>  VSX_XXMRG(xxmrghw, 1)
>  VSX_XXMRG(xxmrglw, 0)
>  
> -static void xxsel_i64(TCGv_i64 t, TCGv_i64 a, TCGv_i64 b, TCGv_i64 c)
> -{
> -tcg_gen_and_i64(b, b, c);
> -tcg_gen_andc_i64(a, a, c);
> -tcg_gen_or_i64(t, a, b);
> -}
> -
> -static void xxsel_vec(unsigned vece, TCGv_vec t, TCGv_vec a,
> -  TCGv_vec b, TCGv_vec c)
> -{
> -tcg_gen_and_vec(vece, b, b, c);
> -tcg_gen_andc_vec(vece, a, a, c);
> -tcg_gen_or_vec(vece, t, a, b);
> -}
> -
>  static void gen_xxsel(DisasContext *ctx)
>  {
> -static const GVecGen4 g = {
> -.fni8 = xxsel_i64,
> -.fniv = xxsel_vec,
> -.vece = MO_64,
> -};
>  int rt = xT(ctx->opcode);
>  int ra = xA(ctx->opcode);
>  int rb = xB(ctx->opcode);
> @@ -1369,8 +1349,8 @@ static void gen_xxsel(DisasContext *ctx)
>  gen_exception(ctx, POWERPC_EXCP_VSXU);
>  return;
>  }
> -tcg_gen_gvec_4(vsr_full_offset(rt), vsr_full_offset(ra),
> -   vsr_full_offset(rb), vsr_full_offset(rc), 16, 16, );
> +tcg_gen_gvec_bitsel(MO_64, vsr_full_offset(rt), vsr_full_offset(rc),
> +vsr_full_offset(rb), vsr_full_offset(ra), 16, 16);
>  }
>  
>  static void gen_xxspltw(DisasContext *ctx)

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [Qemu-devel] [PATCH 2/5] virtio: Migrate the "start_on_kick" flag

[Yongji Xie]

On Tue, 4 Jun 2019 at 04:16, Greg Kurz  wrote:
>
> On Wed, 29 May 2019 15:09:52 +0800
> elohi...@gmail.com wrote:
>
> > From: Xie Yongji 
> >
> > We should migrate the "start_on_kick" flag so that we
> > would not miss starting device on kicking at startup
> > after migration.
> >
>
> Hmm... IIUC "start_on_kick" means "virtio 1.0 transitional device that has
> not been started yet", ie:
>
> !vdev->started &&
> (virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1) &&
>  !virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1))
>
> If so, not sure why you need this extra field in the first place, but
> you probably don't need to migrate it. Just recalculate in a post load
> callback.
>

Good idea! Will recalculate this in virtio_load() in v2. Thank you.

Thanks,
Yongji

Re: [Qemu-devel] [PATCH 1/5] virtio: Set "start_on_kick" on virtio_set_features()

[Yongji Xie]

On Tue, 4 Jun 2019 at 00:53, Greg Kurz  wrote:
>
> On Wed, 29 May 2019 15:09:51 +0800
> elohi...@gmail.com wrote:
>
> > From: Xie Yongji 
> >
> > The guest feature is not set correctly on virtio_reset() and
> > virtio_init(). So we should not use it to set "start_on_kick" at that
> > point. This patch set "start_on_kick" on virtio_set_features() instead.
> >
> > Signed-off-by: Xie Yongji 
> > ---
>
> Maybe add a Fixes: badaf79cfdbd3 ?
>

Will add it in v2. Thanks for review.

Thanks,
Yongji

Re: [Qemu-devel] [PATCH v4 0/2] introduction of migration_version attribute for VFIO live migration

[Yan Zhao]

On Tue, Jun 04, 2019 at 03:29:32AM +0800, Alex Williamson wrote:
> On Thu, 30 May 2019 20:44:38 -0400
> Yan Zhao  wrote:
> 
> > This patchset introduces a migration_version attribute under sysfs of VFIO
> > Mediated devices.
> > 
> > This migration_version attribute is used to check migration compatibility
> > between two mdev devices of the same mdev type.
> > 
> > Patch 1 defines migration_version attribute in
> > Documentation/vfio-mediated-device.txt
> > 
> > Patch 2 uses GVT as an example to show how to expose migration_version
> > attribute and check migration compatibility in vendor driver.
> 
> Thanks for iterating through this, it looks like we've settled on
> something reasonable, but now what?  This is one piece of the puzzle to
> supporting mdev migration, but I don't think it makes sense to commit
> this upstream on its own without also defining the remainder of how we
> actually do migration, preferably with more than one working
> implementation and at least prototyped, if not final, QEMU support.  I
> hope that was the intent, and maybe it's now time to look at the next
> piece of the puzzle.  Thanks,
> 
> Alex

Got it. 
Also thank you and all for discussing and guiding all along:)
We'll move to the next episode now.

Thanks
Yan

[Qemu-devel] [PATCH v2] migratioin/ram: leave RAMBlock->bmap blank on allocating

[Wei Yang]

During migration, we would sync bitmap from ram_list.dirty_memory to
RAMBlock.bmap in cpu_physical_memory_sync_dirty_bitmap().

Since we set RAMBlock.bmap and ram_list.dirty_memory both to all 1, this
means at the first round this sync is meaningless and is a duplicated
work.

Leaving RAMBlock->bmap blank on allocating would have a side effect on
migration_dirty_pages, since it is calculated from the result of
cpu_physical_memory_sync_dirty_bitmap(). To keep it right, we need to
set migration_dirty_pages to 0 in ram_state_init().

Signed-off-by: Wei Yang 
Reviewed-by: Dr. David Alan Gilbert 

---
v2: add a comment explaining why leaving RAMBlock.bmap clear
---
 migration/ram.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 4c60869226..e9a27ea5e6 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -3181,12 +3181,7 @@ static int ram_state_init(RAMState **rsp)
 qemu_mutex_init(&(*rsp)->src_page_req_mutex);
 QSIMPLEQ_INIT(&(*rsp)->src_page_requests);
 
-/*
- * Count the total number of pages used by ram blocks not including any
- * gaps due to alignment or unplugs.
- */
-(*rsp)->migration_dirty_pages = ram_bytes_total() >> TARGET_PAGE_BITS;
-
+(*rsp)->migration_dirty_pages = 0;
 ram_state_reset(*rsp);
 
 return 0;
@@ -3201,8 +3196,15 @@ static void ram_list_init_bitmaps(void)
 if (ram_bytes_total()) {
 RAMBLOCK_FOREACH_NOT_IGNORED(block) {
 pages = block->max_length >> TARGET_PAGE_BITS;
+/*
+ * We leave RAMBlock.bmap clear here and they will be sync from
+ * ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION] in
+ * migration_bitmap_sync_precopy().
+ *
+ * ram_list.dirty_memory[DIRTY_MEMORY_MIGRATION] is set to all 1
+ * in ram_block_add().
+ */
 block->bmap = bitmap_new(pages);
-bitmap_set(block->bmap, 0, pages);
 if (migrate_postcopy_ram()) {
 block->unsentmap = bitmap_new(pages);
 bitmap_set(block->unsentmap, 0, pages);
-- 
2.19.1

Re: [Qemu-devel] [PATCH qemu] aspeed: Add support for the swift-bmc board

[Joel Stanley]

On Mon, 3 Jun 2019 at 19:11, Adriana Kobylak  wrote:
>
> From: Adriana Kobylak 
>
> The Swift board is an OpenPOWER system hosting POWER processors.
> Add support for their BMC including the I2C devices as found on HW.
>
> Signed-off-by: Adriana Kobylak 
> Reviewed-by: Cédric Le Goater 
> ---
>  hw/arm/aspeed.c | 42 ++
>  1 file changed, 42 insertions(+)
>
> diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
> index 33070a6..cd95b3c 100644
> --- a/hw/arm/aspeed.c
> +++ b/hw/arm/aspeed.c
> @@ -73,6 +73,9 @@ struct AspeedBoardState {
>  SCU_AST2500_HW_STRAP_ACPI_ENABLE |  \
>  SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_MASTER))
>
> +/* TODO: Swift hardware value: ? (use romulus definition for now) */
> +#define SWIFT_BMC_HW_STRAP1 ROMULUS_BMC_HW_STRAP1

I got this from hardware: 0xF11AD206

The rest looks okay.

Reviewed-by: Joel Stanley 

> +
>  /* Witherspoon hardware value: 0xF10AD216 (but use romulus definition) */
>  #define WITHERSPOON_BMC_HW_STRAP1 ROMULUS_BMC_HW_STRAP1
>
> @@ -287,6 +290,35 @@ static void romulus_bmc_i2c_init(AspeedBoardState *bmc)
>  i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 11), "ds1338", 
> 0x32);
>  }
>
> +static void swift_bmc_i2c_init(AspeedBoardState *bmc)
> +{
> +AspeedSoCState *soc = >soc;
> +
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 3), "pca9552", 
> 0x60);
> +
> +/* The swift board expects a TMP275 but a TMP105 is compatible */
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 7), "tmp105", 
> 0x48);
> +/* The swift board expects a pca9551 but a pca9552 is compatible */
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 7), "pca9552", 
> 0x60);
> +
> +/* The swift board expects an Epson RX8900 RTC but a ds1338 is 
> compatible */
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 8), "ds1338", 
> 0x32);
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 8), "pca9552", 
> 0x60);
> +
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 9), "tmp423", 
> 0x4c);
> +/* The swift board expects a pca9539 but a pca9552 is compatible */
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 9), "pca9552", 
> 0x74);
> +
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 10), "tmp423", 
> 0x4c);
> +/* The swift board expects a pca9539 but a pca9552 is compatible */
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 10), "pca9552",
> + 0x74);
> +
> +/* The swift board expects a TMP275 but a TMP105 is compatible */
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 12), "tmp105", 
> 0x48);
> +i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 12), "tmp105", 
> 0x4a);
> +}
> +
>  static void witherspoon_bmc_i2c_init(AspeedBoardState *bmc)
>  {
>  AspeedSoCState *soc = >soc;
> @@ -378,6 +410,16 @@ static const AspeedBoardConfig aspeed_boards[] = {
>  .i2c_init  = romulus_bmc_i2c_init,
>  .ram   = 512 * MiB,
>  }, {
> +.name  = MACHINE_TYPE_NAME("swift-bmc"),
> +.desc  = "OpenPOWER Swift BMC (ARM1176)",
> +.soc_name  = "ast2500-a1",
> +.hw_strap1 = SWIFT_BMC_HW_STRAP1,
> +.fmc_model = "mx66l1g45g",
> +.spi_model = "mx66l1g45g",
> +.num_cs= 2,
> +.i2c_init  = swift_bmc_i2c_init,
> +.ram   = 512 * MiB,
> +}, {
>  .name  = MACHINE_TYPE_NAME("witherspoon-bmc"),
>  .desc  = "OpenPOWER Witherspoon BMC (ARM1176)",
>  .soc_name  = "ast2500-a1",
> --
> 1.8.3.1
>

[Qemu-devel] [PATCH v2] target/arm: Vectorize USHL and SSHL

[Richard Henderson]

These instructions shift left or right depending on the sign
of the input, and 7 bits are significant to the shift.  This
requires several masks and selects in addition to the actual
shifts to form the complete answer.

That said, the operation is still a small improvement even for
two 64-bit elements -- 13 vector operations instead of 2 * 7
integer operations.

Signed-off-by: Richard Henderson 
---

Changes in v2:
  * Clarify some commentary.
  * Remove unreachable out-of-line functions.
  * Use more comparisons more favorable to x86_64,
and does not affect other vector hosts.

Example code generation (x86_64 and aarch64):

USHL:

0x564bc522df1b:  c5 e9 ef d2  vpxor%xmm2, %xmm2, %xmm2
0x564bc522df1f:  c5 e9 fa d1  vpsubd   %xmm1, %xmm2, %xmm2
0x564bc522df23:  c5 fa 7e 1d 75 00 00 00  vmovq0x75(%rip), %xmm3
0x564bc522df2b:  c5 f1 db cb  vpand%xmm3, %xmm1, %xmm1
0x564bc522df2f:  c5 e9 db d3  vpand%xmm3, %xmm2, %xmm2
0x564bc522df33:  c4 e2 79 47 d9   vpsllvd  %xmm1, %xmm0, %xmm3
0x564bc522df38:  c4 e2 79 45 c2   vpsrlvd  %xmm2, %xmm0, %xmm0
0x564bc522df3d:  c5 fa 7e 25 63 00 00 00  vmovq0x63(%rip), %xmm4
0x564bc522df45:  c5 d9 66 c9  vpcmpgtd %xmm1, %xmm4, %xmm1
0x564bc522df49:  c5 d9 66 d2  vpcmpgtd %xmm2, %xmm4, %xmm2
0x564bc522df4d:  c5 e1 db c9  vpand%xmm1, %xmm3, %xmm1
0x564bc522df51:  c5 f9 db c2  vpand%xmm2, %xmm0, %xmm0
0x564bc522df55:  c5 f1 eb c0  vpor %xmm0, %xmm1, %xmm0

0xc8a29414:  6ea0b822  neg  v2.4s, v1.4s
0xc8a29418:  6f00e623  movi v3.2d, #0xff00ff
0xc8a2941c:  4e231c21  and  v1.16b, v1.16b, v3.16b
0xc8a29420:  4e231c42  and  v2.16b, v2.16b, v3.16b
0xc8a29424:  6ea14403  ushl v3.4s, v0.4s, v1.4s
0xc8a29428:  6ea0b844  neg  v4.4s, v2.4s
0xc8a2942c:  6ea44400  ushl v0.4s, v0.4s, v4.4s
0xc8a29430:  4f010404  movi v4.4s, #0x20
0xc8a29434:  4ea13481  cmgt v1.4s, v4.4s, v1.4s
0xc8a29438:  4ea23482  cmgt v2.4s, v4.4s, v2.4s
0xc8a2943c:  4e211c61  and  v1.16b, v3.16b, v1.16b
0xc8a29440:  4e221c00  and  v0.16b, v0.16b, v2.16b
0xc8a29444:  4ea01c20  orr  v0.16b, v1.16b, v0.16b

SSHL:

0x55787414385b:  c5 e9 ef d2  vpxor%xmm2, %xmm2, %xmm2
0x55787414385f:  c5 e9 fa d1  vpsubd   %xmm1, %xmm2, %xmm2
0x557874143863:  c4 e2 79 59 1d 7c 00 00  vpbroadcastq 0x7c(%rip), %xmm3
0x55787414386b:  00
0x55787414386c:  c5 f1 db cb  vpand%xmm3, %xmm1, %xmm1
0x557874143870:  c5 e9 db d3  vpand%xmm3, %xmm2, %xmm2
0x557874143874:  c4 e2 79 59 1d 7b 00 00  vpbroadcastq 0x7b(%rip), %xmm3
0x55787414387c:  00
0x55787414387d:  c4 e2 69 3b d3   vpminud  %xmm3, %xmm2, %xmm2
0x557874143882:  c5 f1 66 db  vpcmpgtd %xmm3, %xmm1, %xmm3
0x557874143886:  c4 e2 79 47 e1   vpsllvd  %xmm1, %xmm0, %xmm4
0x55787414388b:  c4 e2 79 46 c2   vpsravd  %xmm2, %xmm0, %xmm0
0x557874143890:  c5 e1 df d4  vpandn   %xmm4, %xmm3, %xmm2
0x557874143894:  c4 e2 79 59 1d 53 00 00  vpbroadcastq 0x53(%rip), %xmm3
0x55787414389c:  00
0x55787414389d:  c5 e1 66 c9  vpcmpgtd %xmm1, %xmm3, %xmm1
0x5578741438a1:  c4 e3 79 4c c2 10vpblendvb %xmm1, %xmm2, %xmm0, %xmm0

0xb5996414:  6ea0b822  neg  v2.4s, v1.4s
0xb5996418:  6f00e623  movi v3.2d, #0xff00ff
0xb599641c:  4e231c21  and  v1.16b, v1.16b, v3.16b
0xb5996420:  4e231c42  and  v2.16b, v2.16b, v3.16b
0xb5996424:  4f0007e3  movi v3.4s, #0x1f
0xb5996428:  6ea36c42  umin v2.4s, v2.4s, v3.4s
0xb599642c:  4ea33423  cmgt v3.4s, v1.4s, v3.4s
0xb5996430:  6ea14404  ushl v4.4s, v0.4s, v1.4s
0xb5996434:  6ea0b842  neg  v2.4s, v2.4s
0xb5996438:  4ea24400  sshl v0.4s, v0.4s, v2.4s
0xb599643c:  4e631c82  bic  v2.16b, v4.16b, v3.16b
0xb5996440:  4f040403  movi v3.4s, #0x80
0xb5996444:  4ea13461  cmgt v1.4s, v3.4s, v1.4s
0xb5996448:  6ea11c40  bit  v0.16b, v2.16b, v1.16b


r~

---
 target/arm/helper.h|  11 +-
 target/arm/translate.h |   6 +
 target/arm/neon_helper.c   |  33 
 target/arm/translate-a64.c |  18 +--
 target/arm/translate.c | 300 +++--
 target/arm/vec_helper.c|  88 +++
 6 files changed, 390 insertions(+), 66 deletions(-)

diff --git a/target/arm/helper.h b/target/arm/helper.h
index 132aa1682e..1ab0fe597a 100644
--- a/target/arm/helper.h
+++ b/target/arm/helper.h
@@ -297,14 +297,8 @@ DEF_HELPER_2(neon_abd_s16, i32, i32, i32)
 DEF_HELPER_2(neon_abd_u32, i32, i32, i32)
 DEF_HELPER_2(neon_abd_s32, i32, i32, i32)
 
-DEF_HELPER_2(neon_shl_u8, i32, i32, i32)
-DEF_HELPER_2(neon_shl_s8, i32, i32, i32)
 DEF_HELPER_2(neon_shl_u16, i32, i32, i32)
 DEF_HELPER_2(neon_shl_s16, i32, i32, i32)
-DEF_HELPER_2(neon_shl_u32, i32, i32, i32)

[Qemu-devel] [PATCH] [RFC] Add a eBPF-capable PCIe device

[Martin Ichilevici de Oliveira]

This RFC adds a PCIe device model that is capable of running machine
code complaint with the extended Berkeley Packet Filter (eBPF) virtual
machine [1]. This machine can then be used to run offloaded code in the
PCIe device against data passed to the PCIe device via DMA. eBPF is a
very well supported “virtual” ISA and has an increasingly level of
support within the Linux kernel. As such, it makes a good choice as a
vendor-agnostic ISA for application acceleration via PCIe offload
engines [2]. This RFC is useful for exploring this idea in an emulated
environment without needing physical PCIe attached eBPF offload engines.

The eBPF device model leverages a userspace eBPF C library (uBPF) [3] in
order to implement the model and this is therefore a dependency when
building QEMU. If this uBPF library is detected at configuration time
and --disable_libubpf is not set then this model will be enabled when
QEMU is built.

Documentation on how to program the eBPF PCIe device is included in
docs/specs/ebpf.txt.

A sample Linux kernel driver can be found in [4]. Note that this driver
also exposes a section of one of the BARs on the eBPF PCIe device as a
p2pdma capable memory [5] and as such requires a 4.20.x or more recent
kernel. This is done to explore the ability of combining the eBPF
offload engine with p2pdma to build more efficient systems.

Note that this RFC is just a starting point for a PCIe eBPF model. The
programming model for the device is not as efficient as it could be
right now. In the future we plan to add more parallelism and the ability
to handle multiple DMA requests. Long term we may add a NVMe controller
interface to this PCIe device to align with work being by SNIA and NVM
Express around NVMe Computational Storage [6]. Suggestions for other
enhancements are very welcome!

A simple “smoke-test” userspace application that utilizes both the
kernel driver and the PCIe model is available [7]. It shows how a C
program can be compiled to eBPF in user-space, pushed to the PCIe device
and be used to operate on data DMA’ed in from an NVMe SSD.

This patch applies to release v4.0.0 of QEMU.

[1]: https://www.kernel.org/doc/Documentation/networking/filter.txt
[2]: https://lkml.org/lkml/2019/2/7/647
[3]: https://github.com/iovisor/ubpf
[4]: https://github.com/iomartin/pci_ubpf_driver
[5]: https://www.kernel.org/doc/Documentation/driver-api/pci/p2pdma.rst
[6]: https://www.snia.org/computational
[7]: https://github.com/iomartin/ebpf-test

Signed-off-by: Martin Ichilevici de Oliveira 
Signed-off-by: Stephen Bates 
---
 configure |  27 +++
 docs/specs/ebpf.txt   | 182 +++
 hw/misc/Makefile.objs |   3 +
 hw/misc/pcie-ebpf.c   | 513 ++
 4 files changed, 725 insertions(+)
 create mode 100644 docs/specs/ebpf.txt
 create mode 100644 hw/misc/pcie-ebpf.c

diff --git a/configure b/configure
index 1c563a7027..41b3b08cfb 100755
--- a/configure
+++ b/configure
@@ -491,6 +491,7 @@ docker="no"
 debug_mutex="no"
 libpmem=""
 default_devices="yes"
+libubpf=""
 
 # cross compilers defaults, can be overridden with --cross-cc-ARCH
 cross_cc_aarch64="aarch64-linux-gnu-gcc"
@@ -1518,6 +1519,10 @@ for opt do
   ;;
   --disable-libpmem) libpmem=no
   ;;
+  --disable-libubpf) libubpf="no"
+  ;;
+  --enable-libubpf) libubpf="yes"
+  ;;
   *)
   echo "ERROR: unknown option $opt"
   echo "Try '$0 --help' for more information"
@@ -3974,6 +3979,24 @@ elif test "$tpm" = "yes"; then
   fi
 fi
 
+##
+# libubpf probe
+
+if test "$libubpf" != "no" ; then
+  cat > $TMPC <
+int main(void) { ubpf_create(); return 0; }
+EOF
+  if compile_prog "" "-lubpf" ; then
+libubpf=yes
+  else
+if test "$libubpf" = "yes" ; then
+  feature_not_found "libubpf" "Install libubpf"
+fi
+libubpf=no
+  fi
+fi
+
 ##
 # attr probe
 
@@ -6438,6 +6461,7 @@ echo "docker$docker"
 echo "libpmem support   $libpmem"
 echo "libudev   $libudev"
 echo "default devices   $default_devices"
+echo "libubpf   $libubpf"
 
 if test "$supported_cpu" = "no"; then
 echo
@@ -6833,6 +6857,9 @@ fi
 if test "$linux_aio" = "yes" ; then
   echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
 fi
+if test "$libubpf" = "yes" ; then
+  echo "CONFIG_LIBUBPF=y" >> $config_host_mak
+fi
 if test "$attr" = "yes" ; then
   echo "CONFIG_ATTR=y" >> $config_host_mak
 fi
diff --git a/docs/specs/ebpf.txt b/docs/specs/ebpf.txt
new file mode 100644
index 00..7aa209f22c
--- /dev/null
+++ b/docs/specs/ebpf.txt
@@ -0,0 +1,182 @@
+
+EBPF device
+===
+
+Copyright (c) 2019 Martin Ichilevici de Oliveira
+
+This document is licensed under the GPLv2 (or later).
+
+eBPF is a Linux kernel instruction set architecture and virtual machine
+specification, which can be used to insert code in the kernel at runtime. One
+of the use-cases is offloading eBPF to external devices. This is an example of
+a PCI device that 

[Qemu-devel] [patch QEMU] kvm: i386: halt poll control MSR support

[Marcelo Tosatti]

(CC'ing qemu devel)

Add support for halt poll control MSR: save/restore, migration
and new feature name.

The purpose of this MSR is to allow the guest to disable
host halt poll.

Signed-off-by: Marcelo Tosatti 

diff --git a/include/standard-headers/asm-x86/kvm_para.h 
b/include/standard-headers/asm-x86/kvm_para.h
index 35cd8d6..e171514 100644
--- a/include/standard-headers/asm-x86/kvm_para.h
+++ b/include/standard-headers/asm-x86/kvm_para.h
@@ -29,6 +29,7 @@
 #define KVM_FEATURE_PV_TLB_FLUSH   9
 #define KVM_FEATURE_ASYNC_PF_VMEXIT10
 #define KVM_FEATURE_PV_SEND_IPI11
+#define KVM_FEATURE_POLL_CONTROL   12
 
 #define KVM_HINTS_REALTIME  0
 
@@ -47,6 +48,7 @@
 #define MSR_KVM_ASYNC_PF_EN 0x4b564d02
 #define MSR_KVM_STEAL_TIME  0x4b564d03
 #define MSR_KVM_PV_EOI_EN  0x4b564d04
+#define MSR_KVM_POLL_CONTROL   0x4b564d05
 
 struct kvm_steal_time {
uint64_t steal;
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index c1ab86d..1ca6944 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -903,7 +903,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = {
 "kvmclock", "kvm-nopiodelay", "kvm-mmu", "kvmclock",
 "kvm-asyncpf", "kvm-steal-time", "kvm-pv-eoi", "kvm-pv-unhalt",
 NULL, "kvm-pv-tlb-flush", NULL, "kvm-pv-ipi",
-NULL, NULL, NULL, NULL,
+"kvm-poll-control", NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
 "kvmclock-stable-bit", NULL, NULL, NULL,
@@ -3001,6 +3001,7 @@ static PropValue kvm_default_props[] = {
 { "kvm-asyncpf", "on" },
 { "kvm-steal-time", "on" },
 { "kvm-pv-eoi", "on" },
+{ "kvm-poll-control", "on" },
 { "kvmclock-stable-bit", "on" },
 { "x2apic", "on" },
 { "acpi", "off" },
@@ -5660,6 +5661,8 @@ static void x86_cpu_initfn(Object *obj)
 object_property_add_alias(obj, "kvm_steal_time", obj, "kvm-steal-time", 
_abort);
 object_property_add_alias(obj, "kvm_pv_eoi", obj, "kvm-pv-eoi", 
_abort);
 object_property_add_alias(obj, "kvm_pv_unhalt", obj, "kvm-pv-unhalt", 
_abort);
+object_property_add_alias(obj, "kvm_poll_control", obj, "kvm-poll-control",
+  _abort);
 object_property_add_alias(obj, "svm_lock", obj, "svm-lock", _abort);
 object_property_add_alias(obj, "nrip_save", obj, "nrip-save", 
_abort);
 object_property_add_alias(obj, "tsc_scale", obj, "tsc-scale", 
_abort);
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index bd06523..21ed2f8 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -1241,6 +1241,7 @@ typedef struct CPUX86State {
 uint64_t steal_time_msr;
 uint64_t async_pf_en_msr;
 uint64_t pv_eoi_en_msr;
+uint64_t poll_control_msr;
 
 /* Partition-wide HV MSRs, will be updated only on the first vcpu */
 uint64_t msr_hv_hypercall;
diff --git a/target/i386/kvm.c b/target/i386/kvm.c
index 3b29ce5..a5e9cdf 100644
--- a/target/i386/kvm.c
+++ b/target/i386/kvm.c
@@ -1369,6 +1369,8 @@ void kvm_arch_reset_vcpu(X86CPU *cpu)
 
 hyperv_x86_synic_reset(cpu);
 }
+/* enabled by default */
+env->poll_control_msr = 1;
 }
 
 void kvm_arch_do_init_vcpu(X86CPU *cpu)
@@ -2059,6 +2061,11 @@ static int kvm_put_msrs(X86CPU *cpu, int level)
 if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_STEAL_TIME)) {
 kvm_msr_entry_add(cpu, MSR_KVM_STEAL_TIME, env->steal_time_msr);
 }
+
+if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_POLL_CONTROL)) {
+kvm_msr_entry_add(cpu, MSR_KVM_POLL_CONTROL, 
env->poll_control_msr);
+}
+
 if (has_architectural_pmu_version > 0) {
 if (has_architectural_pmu_version > 1) {
 /* Stop the counter.  */
@@ -2443,6 +2450,9 @@ static int kvm_get_msrs(X86CPU *cpu)
 if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_STEAL_TIME)) {
 kvm_msr_entry_add(cpu, MSR_KVM_STEAL_TIME, 0);
 }
+if (env->features[FEAT_KVM] & (1 << KVM_FEATURE_POLL_CONTROL)) {
+kvm_msr_entry_add(cpu, MSR_KVM_POLL_CONTROL, 1);
+}
 if (has_architectural_pmu_version > 0) {
 if (has_architectural_pmu_version > 1) {
 kvm_msr_entry_add(cpu, MSR_CORE_PERF_FIXED_CTR_CTRL, 0);
@@ -2677,6 +2687,10 @@ static int kvm_get_msrs(X86CPU *cpu)
 case MSR_KVM_STEAL_TIME:
 env->steal_time_msr = msrs[i].data;
 break;
+case MSR_KVM_POLL_CONTROL: {
+env->poll_control_msr = msrs[i].data;
+break;
+}
 case MSR_CORE_PERF_FIXED_CTR_CTRL:
 env->msr_fixed_ctr_ctrl = msrs[i].data;
 break;
diff --git a/target/i386/machine.c b/target/i386/machine.c
index 225b5d4..1c23e5e 100644
--- a/target/i386/machine.c
+++ b/target/i386/machine.c
@@ -323,6 +323,14 @@ static bool steal_time_msr_needed(void *opaque)
 return cpu->env.steal_time_msr != 0;
 }
 
+/* Poll control MSR enabled by default */
+static bool 

[Qemu-devel] [PATCH] hw: misc: Add Aspeed XDMA device

[Eddie James]

The XDMA engine embedded in the Aspeed SOCs performs PCI DMA operations
between the SOC (acting as a BMC) and a host processor in a server.

The XDMA engine exists on the AST2400, AST2500, and AST2600 SOCs, so
enable it for all of those.

Signed-off-by: Eddie James 
---
 hw/arm/aspeed_soc.c   |  14 
 hw/misc/Makefile.objs |   2 +-
 hw/misc/aspeed_xdma.c | 156 ++
 include/hw/arm/aspeed_soc.h   |   2 +
 include/hw/misc/aspeed_xdma.h |  31 +
 5 files changed, 204 insertions(+), 1 deletion(-)
 create mode 100644 hw/misc/aspeed_xdma.c
 create mode 100644 include/hw/misc/aspeed_xdma.h

diff --git a/hw/arm/aspeed_soc.c b/hw/arm/aspeed_soc.c
index faff42b..b25bb18 100644
--- a/hw/arm/aspeed_soc.c
+++ b/hw/arm/aspeed_soc.c
@@ -31,6 +31,7 @@
 #define ASPEED_SOC_VIC_BASE 0x1E6C
 #define ASPEED_SOC_SDMC_BASE0x1E6E
 #define ASPEED_SOC_SCU_BASE 0x1E6E2000
+#define ASPEED_SOC_XDMA_BASE0x1E6E7000
 #define ASPEED_SOC_SRAM_BASE0x1E72
 #define ASPEED_SOC_TIMER_BASE   0x1E782000
 #define ASPEED_SOC_WDT_BASE 0x1E785000
@@ -159,6 +160,9 @@ static void aspeed_soc_init(Object *obj)
 
 sysbus_init_child_obj(obj, "ftgmac100", OBJECT(>ftgmac100),
   sizeof(s->ftgmac100), TYPE_FTGMAC100);
+
+sysbus_init_child_obj(obj, "xdma", OBJECT(>xdma), sizeof(s->xdma),
+  TYPE_ASPEED_XDMA);
 }
 
 static void aspeed_soc_realize(DeviceState *dev, Error **errp)
@@ -298,6 +302,16 @@ static void aspeed_soc_realize(DeviceState *dev, Error 
**errp)
 sysbus_mmio_map(SYS_BUS_DEVICE(>ftgmac100), 0, ASPEED_SOC_ETH1_BASE);
 sysbus_connect_irq(SYS_BUS_DEVICE(>ftgmac100), 0,
qdev_get_gpio_in(DEVICE(>vic), 2));
+
+/* XDMA */
+object_property_set_bool(OBJECT(>xdma), true, "realized", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+sysbus_mmio_map(SYS_BUS_DEVICE(>xdma), 0, ASPEED_SOC_XDMA_BASE);
+sysbus_connect_irq(SYS_BUS_DEVICE(>xdma), 0,
+   qdev_get_gpio_in(DEVICE(>vic), 6));
 }
 
 static void aspeed_soc_class_init(ObjectClass *oc, void *data)
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index 77b9df9..a4483af 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -74,7 +74,7 @@ obj-$(CONFIG_ARMSSE_MHU) += armsse-mhu.o
 
 obj-$(CONFIG_PVPANIC) += pvpanic.o
 obj-$(CONFIG_AUX) += auxbus.o
-obj-$(CONFIG_ASPEED_SOC) += aspeed_scu.o aspeed_sdmc.o
+obj-$(CONFIG_ASPEED_SOC) += aspeed_scu.o aspeed_sdmc.o aspeed_xdma.o
 obj-$(CONFIG_MSF2) += msf2-sysreg.o
 obj-$(CONFIG_NRF51_SOC) += nrf51_rng.o
 
diff --git a/hw/misc/aspeed_xdma.c b/hw/misc/aspeed_xdma.c
new file mode 100644
index 000..fe3a32e
--- /dev/null
+++ b/hw/misc/aspeed_xdma.c
@@ -0,0 +1,156 @@
+/*
+ * ASPEED XDMA Controller
+ * Eddie James 
+ *
+ * Copyright (C) 2019 IBM Corp
+ * SPDX-License-Identifer: GPL-2.0-or-later
+ */
+
+#include "qemu/osdep.h"
+#include "qemu/log.h"
+#include "qemu/error-report.h"
+#include "hw/misc/aspeed_xdma.h"
+#include "qapi/error.h"
+
+#define XDMA_BMC_CMDQ_ADDR 0x10
+#define XDMA_BMC_CMDQ_ENDP 0x14
+#define XDMA_BMC_CMDQ_WRP  0x18
+#define  XDMA_BMC_CMDQ_W_MASK  0x0003
+#define XDMA_BMC_CMDQ_RDP  0x1C
+#define  XDMA_BMC_CMDQ_RDP_MAGIC   0xEE882266
+#define XDMA_IRQ_ENG_CTRL  0x20
+#define  XDMA_IRQ_ENG_CTRL_US_COMP BIT(4)
+#define  XDMA_IRQ_ENG_CTRL_DS_COMP BIT(5)
+#define  XDMA_IRQ_ENG_CTRL_W_MASK  0xBFEFF07F
+#define XDMA_IRQ_ENG_STAT  0x24
+#define  XDMA_IRQ_ENG_STAT_US_COMP BIT(4)
+#define  XDMA_IRQ_ENG_STAT_DS_COMP BIT(5)
+#define  XDMA_IRQ_ENG_STAT_RESET   0xF800
+
+#define TO_REG(addr) ((addr) / sizeof(uint32_t))
+
+static uint64_t aspeed_xdma_read(void *opaque, hwaddr addr, unsigned int size)
+{
+uint32_t val = 0;
+AspeedXDMAState *xdma = opaque;
+
+if (addr < ASPEED_XDMA_REG_SIZE) {
+val = xdma->regs[TO_REG(addr)];
+}
+
+return (uint64_t)val;
+}
+
+static void aspeed_xdma_write(void *opaque, hwaddr addr, uint64_t val,
+  unsigned int size)
+{
+unsigned int idx;
+uint32_t val32 = (uint32_t)val;
+AspeedXDMAState *xdma = opaque;
+
+if (addr >= ASPEED_XDMA_REG_SIZE) {
+return;
+}
+
+switch (addr) {
+case XDMA_BMC_CMDQ_ENDP:
+xdma->regs[TO_REG(addr)] = val32 & XDMA_BMC_CMDQ_W_MASK;
+break;
+case XDMA_BMC_CMDQ_WRP:
+idx = TO_REG(addr);
+xdma->regs[idx] = val32 & XDMA_BMC_CMDQ_W_MASK;
+xdma->regs[TO_REG(XDMA_BMC_CMDQ_RDP)] = xdma->regs[idx];
+
+if (xdma->bmc_cmdq_readp_set) {
+xdma->bmc_cmdq_readp_set = 0;
+} else {
+xdma->regs[TO_REG(XDMA_IRQ_ENG_STAT)] |=
+XDMA_IRQ_ENG_STAT_US_COMP | XDMA_IRQ_ENG_STAT_DS_COMP;
+
+if (xdma->regs[TO_REG(XDMA_IRQ_ENG_CTRL)] &
+

Re: [Qemu-devel] [Qemu-block] [PATCH v2 1/5] block/nvme: don't flip CQ phase bits

[John Snow]

On 4/17/19 3:53 PM, Maxim Levitsky wrote:
> Phase bits are only set by the hardware to indicate new completions
> and not by the device driver.
> 
> Signed-off-by: Maxim Levitsky 
> ---
>  block/nvme.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/block/nvme.c b/block/nvme.c
> index 0684bbd077..2d208000df 100644
> --- a/block/nvme.c
> +++ b/block/nvme.c
> @@ -340,8 +340,6 @@ static bool nvme_process_completion(BDRVNVMeState *s, 
> NVMeQueuePair *q)
>  qemu_mutex_lock(>lock);
>  c->cid = cpu_to_le16(0);
>  q->inflight--;
> -/* Flip Phase Tag bit. */
> -c->status = cpu_to_le16(le16_to_cpu(c->status) ^ 0x1);
>  progress = true;
>  }
>  if (progress) {
> 

Since you've not got much traction on this and you've pinged a v2, can
you point me to a spec or a reproducer that illustrates the problem?

(Or wait for more NVME knowledgeable people to give you a review...!)

Re: [Qemu-devel] [Qemu-block] [PATCH] qemu-img: Fix options leakage in img_rebase()

[John Snow]

On 5/28/19 3:53 PM, Max Reitz wrote:
> img_rebase() can leak a QDict in two occasions.  Fix it.
> 
> Coverity: CID 1401416
> Fixes: d16699b64671466b42079c45b89127aeea1ca565
> Fixes: 330c72957196e0ae382abcaa97ebf4eb9bc8574f
> Signed-off-by: Max Reitz 
> ---
>  qemu-img.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/qemu-img.c b/qemu-img.c
> index b0535919b1..86e1923acf 100644
> --- a/qemu-img.c
> +++ b/qemu-img.c
> @@ -3347,6 +3347,7 @@ static int img_rebase(int argc, char **argv)
>   out_baseimg,
>   _err);
>  if (local_err) {
> +qobject_unref(options);
>  error_reportf_err(local_err,
>"Could not resolve backing filename: ");
>  ret = -1;
> @@ -3359,7 +3360,9 @@ static int img_rebase(int argc, char **argv)
>   */
>  prefix_chain_bs = bdrv_find_backing_image(bs, out_real_path);
>  if (prefix_chain_bs) {
> +qobject_unref(options);
>  g_free(out_real_path);
> +
>  blk_new_backing = blk_new(BLK_PERM_CONSISTENT_READ,
>BLK_PERM_ALL);
>  ret = blk_insert_bs(blk_new_backing, prefix_chain_bs,
> 

I was going to ask about the other branch after this one, but:
"The reference to the QDict belongs to the block layer after the call
(even on failure)"

"Oh, well... OK."

Reviewed-by: John Snow 

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/2] blockdev: Overlays are not snapshots

[John Snow]

On 6/3/19 4:22 PM, Max Reitz wrote:
> QEMU’s always been confused over what a snapshot is: Is it the overlay?
> Is it the backing image?
> 
> Confusion is rarely a good thing.  I can’t think of any objective reason
> why the overlay would be a snapshot.  A snapshot is something that does
> not change over time; the overlay does.
> 
> (I suppose historically the reason is that “Taking an overlay” makes no
> sense, so the operations are called “Taking a snapshot”.  Somehow, this
> meaning carried over to the new file that is created during that
> operation; if “Creating a snapshot” creates a file, that file must be
> the snapshot, right?  Well, no, it isn’t.)
> 
> Let’s fix this as best as we can.  Better Nate than lever.
> 
> 
> v2:
> - Don’t break the iotests for a change
>   (kept Eric’s R-b, because it felt like the right thing to do)
> 
> 
> git backport-diff against v1:
> 
> Key:
> [] : patches are identical
> [] : number of functional differences between upstream/downstream patch
> [down] : patch is downstream-only
> The flags [FC] indicate (F)unctional and (C)ontextual differences, 
> respectively
> 
> 001/2:[] [--] 'qapi/block-core: Overlays are not snapshots'
> 002/2:[0010] [FC] 'blockdev: Overlays are not snapshots'
> 
> 
> Max Reitz (2):
>   qapi/block-core: Overlays are not snapshots
>   blockdev: Overlays are not snapshots
> 
>  qapi/block-core.json   | 20 ++--
>  blockdev.c | 10 +-
>  tests/qemu-iotests/085.out | 10 +-
>  3 files changed, 20 insertions(+), 20 deletions(-)
> 

Makes good sense to me.

There are only 3,283 things named "snapshot" in QEMU so one less is
probably not the worst.

Reviewed-by: John Snow 

Re: [Qemu-devel] [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load

[Richard Henderson]

On 6/3/19 10:01 AM, Alex Bennée wrote:
> When running on 32 bit TCG backends a wide unaligned load ends up
> truncating data before returning to the guest. We specifically have
> the return type as uint64_t to avoid any premature truncation so we
> should use the same for the interim types.
> 
> Hopefully fixes #1830872
> 
> Signed-off-by: Alex Bennée 
> ---
>  accel/tcg/cputlb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [PATCH] target/s390x: Use tcg_gen_gvec_bitsel

[Richard Henderson]

On 6/3/19 2:41 PM, David Hildenbrand wrote:
>> -static void gen_sel_vec(unsigned vece, TCGv_vec d, TCGv_vec a, TCGv_vec b,
>> -TCGv_vec c)
>> -{
>> -TCGv_vec t = tcg_temp_new_vec_matching(d);
>> -
>> -tcg_gen_andc_vec(vece, t, b, c);
>> -tcg_gen_and_vec(vece, d, a, c);
>> -tcg_gen_or_vec(vece, d, d, t);
>> -tcg_temp_free_vec(t);
>> -}
>> -
> 
> Comparing against tcg_gen_bitsel_i64()
> 
> 1. a and c are switched
> 2. b is _not_ switched (and() and andc() are switched)

Not quite.  {a,b,c} from your s390 implementation becomes {c,a,b} for tcg.

Running tests would show for sure; I guess you have those later in your vx
patch set?

> Should I send this patch with the next s390x/tcg pull request?

Yes please.


r~

Re: [Qemu-devel] [PATCH 2/5] virtio: Migrate the "start_on_kick" flag

[Michael S. Tsirkin]

On Mon, Jun 03, 2019 at 11:25:23PM +0200, Greg Kurz wrote:
> On Mon, 3 Jun 2019 17:03:06 -0400
> "Michael S. Tsirkin"  wrote:
> 
> > On Mon, Jun 03, 2019 at 10:16:39PM +0200, Greg Kurz wrote:
> > > On Wed, 29 May 2019 15:09:52 +0800
> > > elohi...@gmail.com wrote:
> > >   
> > > > From: Xie Yongji 
> > > > 
> > > > We should migrate the "start_on_kick" flag so that we
> > > > would not miss starting device on kicking at startup
> > > > after migration.
> > > >   
> > > 
> > > Hmm... IIUC "start_on_kick" means "virtio 1.0 transitional device that has
> > > not been started yet", ie:
> > > 
> > > !vdev->started &&
> > > (virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1) &&
> > >  !virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1))  
> > 
> > Or a legacy device I guess?
> > 
> 
> Do you mean "start_on_kick" should be set for both legacy
> and virtio 1.0 transitional devices ?

Yes - generally when virtio 1 feature has not
been negotiated.

> > > If so, not sure why you need this extra field in the first place, but
> > > you probably don't need to migrate it. Just recalculate in a post load
> > > callback.
> > >   
> > > > Signed-off-by: Xie Yongji 
> > > > ---
> > > >  hw/virtio/virtio.c | 19 +++
> > > >  1 file changed, 19 insertions(+)
> > > > 
> > > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > > index fc8fca81ad..4d4ff67791 100644
> > > > --- a/hw/virtio/virtio.c
> > > > +++ b/hw/virtio/virtio.c
> > > > @@ -1802,6 +1802,13 @@ static bool virtio_started_needed(void *opaque)
> > > >  return vdev->started;
> > > >  }
> > > >  
> > > > +static bool virtio_start_on_kick_needed(void *opaque)
> > > > +{
> > > > +VirtIODevice *vdev = opaque;
> > > > +
> > > > +return vdev->start_on_kick;
> > > > +}
> > > > +
> > > >  static const VMStateDescription vmstate_virtqueue = {
> > > >  .name = "virtqueue_state",
> > > >  .version_id = 1,
> > > > @@ -1941,6 +1948,17 @@ static const VMStateDescription 
> > > > vmstate_virtio_started = {
> > > >  }
> > > >  };
> > > >  
> > > > +static const VMStateDescription vmstate_virtio_start_on_kick = {
> > > > +.name = "virtio/start_on_kick",
> > > > +.version_id = 1,
> > > > +.minimum_version_id = 1,
> > > > +.needed = _start_on_kick_needed,
> > > > +.fields = (VMStateField[]) {
> > > > +VMSTATE_BOOL(start_on_kick, VirtIODevice),
> > > > +VMSTATE_END_OF_LIST()
> > > > +}
> > > > +};
> > > > +
> > > >  static const VMStateDescription vmstate_virtio = {
> > > >  .name = "virtio",
> > > >  .version_id = 1,
> > > > @@ -1957,6 +1975,7 @@ static const VMStateDescription vmstate_virtio = {
> > > >  _virtio_broken,
> > > >  _virtio_extra_state,
> > > >  _virtio_started,
> > > > +_virtio_start_on_kick,
> > > >  NULL
> > > >  }
> > > >  };  

[Qemu-devel] [PATCH v3 3/3] docs/bitmaps: use QMP lexer instead of json

[John Snow]

The annotated style json we use in QMP documentation is not strict json
and depending on the version of Sphinx (2.0+) or Pygments installed,
might cause the build to fail.

Use the new QMP lexer.

Further, some versions of Sphinx can not apply custom lexers to "code"
directives and require the use of "code-block" directives instead, so
make that change at this time as well.

Tested under:
- Sphinx 1.3.6 and Pygments 2.4
- Sphinx 1.7.6 and Pygments 2.2 (Fedora 29 packages)
- Sphinx 2.0.1 and Pygments 2.4
- Sphinx 3.0.0+/f396b3a783 and Pygments 2.4 (From Sphinx git c4f44bdd)

Reported-by: Aarushi Mehta 
Signed-off-by: John Snow 
Reviewed-by: Eduardo Habkost 
---
 docs/interop/bitmaps.rst | 54 
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/docs/interop/bitmaps.rst b/docs/interop/bitmaps.rst
index c29ac4a854..c20bd37a79 100644
--- a/docs/interop/bitmaps.rst
+++ b/docs/interop/bitmaps.rst
@@ -199,7 +199,7 @@ persistence, and recording state can be adjusted at 
creation time.
 
  to create a new, actively recording persistent bitmap:
 
- .. code:: json
+ .. code-block:: QMP
 
   -> { "execute": "block-dirty-bitmap-add",
"arguments": {
@@ -220,7 +220,7 @@ persistence, and recording state can be adjusted at 
creation time.
  To create a new, disabled (``-recording``), transient bitmap that tracks
  changes in 32KiB segments:
 
- .. code:: json
+ .. code-block:: QMP
 
   -> { "execute": "block-dirty-bitmap-add",
"arguments": {
@@ -254,7 +254,7 @@ Deletes a bitmap. Bitmaps that are ``+busy`` cannot be 
removed.
 
  Remove a bitmap named ``bitmap0`` from node ``drive0``:
 
- .. code:: json
+ .. code-block:: QMP
 
   -> { "execute": "block-dirty-bitmap-remove",
"arguments": {
@@ -280,7 +280,7 @@ Clears all dirty bits from a bitmap. ``+busy`` bitmaps 
cannot be cleared.
 
  Clear all dirty bits from bitmap ``bitmap0`` on node ``drive0``:
 
- .. code:: json
+ .. code-block:: QMP
 
   -> { "execute": "block-dirty-bitmap-clear",
"arguments": {
@@ -309,7 +309,7 @@ begin being recorded. ``+busy`` bitmaps cannot be enabled.
 
  To set ``+recording`` on bitmap ``bitmap0`` on node ``drive0``:
 
- .. code:: json
+ .. code-block:: QMP
 
   -> { "execute": "block-dirty-bitmap-enable",
"arguments": {
@@ -347,7 +347,7 @@ writes to begin being ignored. ``+busy`` bitmaps cannot be 
disabled.
 
  To set ``-recording`` on bitmap ``bitmap0`` on node ``drive0``:
 
- .. code:: json
+ .. code-block:: QMP
 
   -> { "execute": "block-dirty-bitmap-disable",
"arguments": {
@@ -393,7 +393,7 @@ in any one source bitmap, the target bitmap will mark that 
segment dirty.
  ``drive0``. If ``new_bitmap`` was empty prior to this command, this achieves
  a copy.
 
- .. code:: json
+ .. code-block:: QMP
 
   -> { "execute": "block-dirty-bitmap-merge",
"arguments": {
@@ -424,7 +424,7 @@ attached to nodes serving as the root for guest devices.
  API. This result highlights a bitmap ``bitmap0`` attached to the root node of
  device ``drive0``.
 
- .. code:: json
+ .. code-block:: QMP
 
   -> {
"execute": "query-block",
@@ -562,7 +562,7 @@ new, empty bitmap that records writes from this point in 
time forward.
   destination. These writes will be recorded in the bitmap
   accordingly.
 
-.. code:: json
+.. code-block:: QMP
 
   -> {
"execute": "transaction",
@@ -650,7 +650,7 @@ Example: Resetting an Incremental Backup Anchor Point
 If we want to start a new backup chain with an existing bitmap, we can also
 use a transaction to reset the bitmap while making a new full backup:
 
-.. code:: json
+.. code-block:: QMP
 
   -> {
"execute": "transaction",
@@ -730,7 +730,7 @@ Example: First Incremental Backup
 
 #. Issue an incremental backup command:
 
-   .. code:: json
+   .. code-block:: QMP
 
 -> {
  "execute": "drive-backup",
@@ -788,7 +788,7 @@ Example: Second Incremental Backup
 #. Issue a new incremental backup command. The only difference here is that we
have changed the target image below.
 
-   .. code:: json
+   .. code-block:: QMP
 
 -> {
  "execute": "drive-backup",
@@ -869,7 +869,7 @@ image:
 #. Issue a new incremental backup command. Apart from the new destination
image, there is no difference from the last two examples.
 
-   .. code:: json
+   .. code-block:: QMP
 
 -> {
  "execute": "drive-backup",
@@ -932,7 +932,7 @@ point in time.
 
 #. Create a full (anchor) backup for each drive, with accompanying bitmaps:
 
-   .. code:: json
+   .. code-block:: QMP
 
 -> {
  "execute": "transaction",
@@ -1018,7 +1018,7 @@ point in time.
 
 #. Issue a multi-drive incremental push backup transaction:
 
-   .. code:: json
+   .. code-block:: QMP
 
 -> {
  "execute": "transaction",
@@ -1121,7 +1121,7 @@ described above. This example demonstrates the single-job 
failure case:
 
 #. Attempt to create an incremental backup via QMP:
 
-   .. 

[Qemu-devel] [PATCH v3 1/3] docs/interop/bitmaps.rst: Fix typos

[John Snow]

Pygments and Sphinx get pickier all the time; Sphinx 2.1+ now catches
these errors.

Signed-off-by: John Snow 
---
 docs/interop/bitmaps.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/docs/interop/bitmaps.rst b/docs/interop/bitmaps.rst
index 510e8809a9..c29ac4a854 100644
--- a/docs/interop/bitmaps.rst
+++ b/docs/interop/bitmaps.rst
@@ -399,7 +399,7 @@ in any one source bitmap, the target bitmap will mark that 
segment dirty.
"arguments": {
  "node": "drive0",
  "target": "new_bitmap",
- "bitmaps: [ "bitmap0" ]
+ "bitmaps": [ "bitmap0" ]
}
  }
 
@@ -1437,7 +1437,7 @@ applied:
.. code:: json
 
 <- {
- "timestamp": {...}
+ "timestamp": {...},
  "data": {
"device": "drive0",
"type": "backup",
-- 
2.20.1

Re: [Qemu-devel] [PATCH RFC v20 4/8] target-avr: Add instruction decoding

[Richard Henderson]

On 6/3/19 3:13 PM, Michael Rolnik wrote:
> Richard,
> I don't understand what I should do. Do you want me to merge decode files?

Yes, using the mechanisms previously described.


r~

> 
> On Fri, May 31, 2019 at 5:45 PM Richard Henderson 
>  > wrote:
> 
> On 5/30/19 2:07 PM, Michael Rolnik wrote:
> > This includes:
> > - encoding of all 16 bit instructions
> > - encoding of all 32 bit instructions
> >
> > Signed-off-by: Michael Rolnik  >
> > ---
> >  target/avr/insn16.decode | 160 +++
> >  target/avr/insn32.decode |  10 +++
> >  2 files changed, 170 insertions(+)
> >  create mode 100644 target/avr/insn16.decode
> >  create mode 100644 target/avr/insn32.decode
> 
> Two things:
> 
> (1) decodetree can handle variable-width ISA now.
> 
> It's slightly ugly in that the %field numbering is little-endian and thus
> varies for each insn size.  But the in-flight patch set for target/rx 
> shows
> that it works.
> 
> That said, I don't think you need that because,
> 
> (2) The four instructions that are 32-bits do not have
>     any opcode bits in the second 16-bits.
> 
> E.g.
> 
> # The 22-bit immediate is partially in the opcode word,
> # and partially in the next.  Use append_16 to build the
> # complete 22-bit value.
> %imm_call       4:5 0:1                 !function=append_16
> CALL            1001 010.  111.     imm=%imm_call
> JMP             1001 010.  110.     imm=%imm_call
> 
> # The 16-bit immediate is completely in the next word.
> # Fields cannot be defined with no bits, so we cannot play
> # the same trick and append to a zero-bit value.
> # Defer reading the immediate until trans_{LDS,STS}.
> @ldst_s          ... rd:5       imm=0
> LDS             1001 000 .      @ldst_s
> STS             1001 001 .      @ldst_s
> 
> 
> static uint16_t next_word(DisasContext *ctx)
> {
>     return cpu_lduw_code(ctx->env, ctx->npc++ * 2);
> }
> 
> static int append_16(DisasContext *ctx, int x)
> {
>     return x << 16 | next_word(ctx);
> }
> 
> static bool trans_LDS(DisasContext *ctx, arg_ldst_s *a)
> {
>     a->imm = next_word(ctx);
>     // other stuff
> }
> 
> I realize that next_word as written does not fit in to how you currently
> process instructions in the loop, but I also think that's a mistake.  I'll
> respond to that in its place in the next patch.
> 
> That said, next_word *could* be written to use ctx->inst[0].opcode.
> 
> 
> r~
> 
> 
> 
> -- 
> Best Regards,
> Michael Rolnik

[Qemu-devel] [PATCH v3 2/3] sphinx: add qmp_lexer

[John Snow]

Sphinx, through Pygments, does not like annotated json examples very
much. In some versions of Sphinx (1.7), it will render the non-json
portions of code blocks in red, but in newer versions (2.0) it will
throw an exception and not highlight the block at all. Though we can
suppress this warning, it doesn't bring back highlighting on non-strict
json blocks.

We can alleviate this by creating a custom lexer for QMP examples that
allows us to properly highlight these examples in a robust way, keeping
our directionality and elision notations.

Signed-off-by: Eduardo Habkost 
Signed-off-by: John Snow 
---
 docs/conf.py |  4 ++--
 docs/sphinx/qmp_lexer.py | 43 
 2 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100644 docs/sphinx/qmp_lexer.py

diff --git a/docs/conf.py b/docs/conf.py
index befbcc6c3e..e46b299b71 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -41,7 +41,7 @@ except NameError:
 # add these directories to sys.path here. If the directory is relative to the
 # documentation root, use an absolute path starting from qemu_docdir.
 #
-# sys.path.insert(0, os.path.join(qemu_docdir, "my_subdir"))
+sys.path.insert(0, os.path.join(qemu_docdir, "sphinx"))
 
 
 # -- General configuration 
@@ -54,7 +54,7 @@ needs_sphinx = '1.3'
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = []
+extensions = ['qmp_lexer']
 
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']
diff --git a/docs/sphinx/qmp_lexer.py b/docs/sphinx/qmp_lexer.py
new file mode 100644
index 00..f7e4c0e198
--- /dev/null
+++ b/docs/sphinx/qmp_lexer.py
@@ -0,0 +1,43 @@
+# QEMU Monitor Protocol Lexer Extension
+#
+# Copyright (C) 2019, Red Hat Inc.
+#
+# Authors:
+#  Eduardo Habkost 
+#  John Snow 
+#
+# This work is licensed under the terms of the GNU GPLv2 or later.
+# See the COPYING file in the top-level directory.
+"""qmp_lexer is a Sphinx extension that provides a QMP lexer for code 
blocks."""
+
+from pygments.lexer import RegexLexer, DelegatingLexer
+from pygments.lexers.data import JsonLexer
+from pygments import token
+from sphinx import errors
+
+class QMPExampleMarkersLexer(RegexLexer):
+"""
+QMPExampleMarkersLexer lexes QMP example annotations.
+This lexer adds support for directionality flow and elision indicators.
+"""
+tokens = {
+'root': [
+(r'-> ', token.Generic.Prompt),
+(r'<- ', token.Generic.Prompt),
+(r' ?\.{3} ?', token.Generic.Prompt),
+]
+}
+
+class QMPExampleLexer(DelegatingLexer):
+"""QMPExampleLexer lexes annotated QMP examples."""
+def __init__(self, **options):
+super(QMPExampleLexer, self).__init__(JsonLexer, 
QMPExampleMarkersLexer,
+  token.Error, **options)
+
+def setup(sphinx):
+"""For use by the Sphinx extensions API."""
+try:
+sphinx.require_sphinx('2.1')
+sphinx.add_lexer('QMP', QMPExampleLexer)
+except errors.VersionRequirementError:
+sphinx.add_lexer('QMP', QMPExampleLexer())
-- 
2.20.1

[Qemu-devel] [PATCH v3 0/3] Add QMP lexer for annotated JSON to Sphinx

[John Snow]

QMP isn't json. It turns out Pygments cares about this.
Teach Pygments to go with the annotated flow.

V3:
 - Also annotate elision indicators '...', which cause
   problems in Sphinx 2.1+
 - Adjust setup.py to cope with future versions of Sphinx
   that change the add_lexer interface

V2:
 - Change GPL2 to GPLv2+ (Peter Maydell)
 - Change "highlights" to "lexes" in docstrings
 - Fix typo ("Sphinx()" => "Sphinx") in docstring

Reported-by: Aarushi Mehta 

John Snow (3):
  docs/interop/bitmaps.rst: Fix typos
  sphinx: add qmp_lexer
  docs/bitmaps: use QMP lexer instead of json

 docs/conf.py |  4 +--
 docs/interop/bitmaps.rst | 58 
 docs/sphinx/qmp_lexer.py | 43 +
 3 files changed, 74 insertions(+), 31 deletions(-)
 create mode 100644 docs/sphinx/qmp_lexer.py

-- 
2.20.1

Re: [Qemu-devel] [PATCH 2/5] virtio: Migrate the "start_on_kick" flag

[Greg Kurz]

On Mon, 3 Jun 2019 17:03:06 -0400
"Michael S. Tsirkin"  wrote:

> On Mon, Jun 03, 2019 at 10:16:39PM +0200, Greg Kurz wrote:
> > On Wed, 29 May 2019 15:09:52 +0800
> > elohi...@gmail.com wrote:
> >   
> > > From: Xie Yongji 
> > > 
> > > We should migrate the "start_on_kick" flag so that we
> > > would not miss starting device on kicking at startup
> > > after migration.
> > >   
> > 
> > Hmm... IIUC "start_on_kick" means "virtio 1.0 transitional device that has
> > not been started yet", ie:
> > 
> > !vdev->started &&
> > (virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1) &&
> >  !virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1))  
> 
> Or a legacy device I guess?
> 

Do you mean "start_on_kick" should be set for both legacy
and virtio 1.0 transitional devices ?

> > If so, not sure why you need this extra field in the first place, but
> > you probably don't need to migrate it. Just recalculate in a post load
> > callback.
> >   
> > > Signed-off-by: Xie Yongji 
> > > ---
> > >  hw/virtio/virtio.c | 19 +++
> > >  1 file changed, 19 insertions(+)
> > > 
> > > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > > index fc8fca81ad..4d4ff67791 100644
> > > --- a/hw/virtio/virtio.c
> > > +++ b/hw/virtio/virtio.c
> > > @@ -1802,6 +1802,13 @@ static bool virtio_started_needed(void *opaque)
> > >  return vdev->started;
> > >  }
> > >  
> > > +static bool virtio_start_on_kick_needed(void *opaque)
> > > +{
> > > +VirtIODevice *vdev = opaque;
> > > +
> > > +return vdev->start_on_kick;
> > > +}
> > > +
> > >  static const VMStateDescription vmstate_virtqueue = {
> > >  .name = "virtqueue_state",
> > >  .version_id = 1,
> > > @@ -1941,6 +1948,17 @@ static const VMStateDescription 
> > > vmstate_virtio_started = {
> > >  }
> > >  };
> > >  
> > > +static const VMStateDescription vmstate_virtio_start_on_kick = {
> > > +.name = "virtio/start_on_kick",
> > > +.version_id = 1,
> > > +.minimum_version_id = 1,
> > > +.needed = _start_on_kick_needed,
> > > +.fields = (VMStateField[]) {
> > > +VMSTATE_BOOL(start_on_kick, VirtIODevice),
> > > +VMSTATE_END_OF_LIST()
> > > +}
> > > +};
> > > +
> > >  static const VMStateDescription vmstate_virtio = {
> > >  .name = "virtio",
> > >  .version_id = 1,
> > > @@ -1957,6 +1975,7 @@ static const VMStateDescription vmstate_virtio = {
> > >  _virtio_broken,
> > >  _virtio_extra_state,
> > >  _virtio_started,
> > > +_virtio_start_on_kick,
> > >  NULL
> > >  }
> > >  };  

Re: [Qemu-devel] [PATCH 2/5] virtio: Migrate the "start_on_kick" flag

[Michael S. Tsirkin]

On Mon, Jun 03, 2019 at 10:16:39PM +0200, Greg Kurz wrote:
> On Wed, 29 May 2019 15:09:52 +0800
> elohi...@gmail.com wrote:
> 
> > From: Xie Yongji 
> > 
> > We should migrate the "start_on_kick" flag so that we
> > would not miss starting device on kicking at startup
> > after migration.
> > 
> 
> Hmm... IIUC "start_on_kick" means "virtio 1.0 transitional device that has
> not been started yet", ie:
> 
> !vdev->started &&
> (virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1) &&
>  !virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1))

Or a legacy device I guess?

> If so, not sure why you need this extra field in the first place, but
> you probably don't need to migrate it. Just recalculate in a post load
> callback.
> 
> > Signed-off-by: Xie Yongji 
> > ---
> >  hw/virtio/virtio.c | 19 +++
> >  1 file changed, 19 insertions(+)
> > 
> > diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> > index fc8fca81ad..4d4ff67791 100644
> > --- a/hw/virtio/virtio.c
> > +++ b/hw/virtio/virtio.c
> > @@ -1802,6 +1802,13 @@ static bool virtio_started_needed(void *opaque)
> >  return vdev->started;
> >  }
> >  
> > +static bool virtio_start_on_kick_needed(void *opaque)
> > +{
> > +VirtIODevice *vdev = opaque;
> > +
> > +return vdev->start_on_kick;
> > +}
> > +
> >  static const VMStateDescription vmstate_virtqueue = {
> >  .name = "virtqueue_state",
> >  .version_id = 1,
> > @@ -1941,6 +1948,17 @@ static const VMStateDescription 
> > vmstate_virtio_started = {
> >  }
> >  };
> >  
> > +static const VMStateDescription vmstate_virtio_start_on_kick = {
> > +.name = "virtio/start_on_kick",
> > +.version_id = 1,
> > +.minimum_version_id = 1,
> > +.needed = _start_on_kick_needed,
> > +.fields = (VMStateField[]) {
> > +VMSTATE_BOOL(start_on_kick, VirtIODevice),
> > +VMSTATE_END_OF_LIST()
> > +}
> > +};
> > +
> >  static const VMStateDescription vmstate_virtio = {
> >  .name = "virtio",
> >  .version_id = 1,
> > @@ -1957,6 +1975,7 @@ static const VMStateDescription vmstate_virtio = {
> >  _virtio_broken,
> >  _virtio_extra_state,
> >  _virtio_started,
> > +_virtio_start_on_kick,
> >  NULL
> >  }
> >  };

[Qemu-devel] [PATCH qemu] aspeed: Add support for the swift-bmc board

[Adriana Kobylak]

From: Adriana Kobylak 

The Swift board is an OpenPOWER system hosting POWER processors.
Add support for their BMC including the I2C devices as found on HW.

Signed-off-by: Adriana Kobylak 
Reviewed-by: Cédric Le Goater 
---
 hw/arm/aspeed.c | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/hw/arm/aspeed.c b/hw/arm/aspeed.c
index 33070a6..cd95b3c 100644
--- a/hw/arm/aspeed.c
+++ b/hw/arm/aspeed.c
@@ -73,6 +73,9 @@ struct AspeedBoardState {
 SCU_AST2500_HW_STRAP_ACPI_ENABLE |  \
 SCU_HW_STRAP_SPI_MODE(SCU_HW_STRAP_SPI_MASTER))
 
+/* TODO: Swift hardware value: ? (use romulus definition for now) */
+#define SWIFT_BMC_HW_STRAP1 ROMULUS_BMC_HW_STRAP1
+
 /* Witherspoon hardware value: 0xF10AD216 (but use romulus definition) */
 #define WITHERSPOON_BMC_HW_STRAP1 ROMULUS_BMC_HW_STRAP1
 
@@ -287,6 +290,35 @@ static void romulus_bmc_i2c_init(AspeedBoardState *bmc)
 i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 11), "ds1338", 
0x32);
 }
 
+static void swift_bmc_i2c_init(AspeedBoardState *bmc)
+{
+AspeedSoCState *soc = >soc;
+
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 3), "pca9552", 
0x60);
+
+/* The swift board expects a TMP275 but a TMP105 is compatible */
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 7), "tmp105", 0x48);
+/* The swift board expects a pca9551 but a pca9552 is compatible */
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 7), "pca9552", 
0x60);
+
+/* The swift board expects an Epson RX8900 RTC but a ds1338 is compatible 
*/
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 8), "ds1338", 0x32);
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 8), "pca9552", 
0x60);
+
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 9), "tmp423", 0x4c);
+/* The swift board expects a pca9539 but a pca9552 is compatible */
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 9), "pca9552", 
0x74);
+
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 10), "tmp423", 
0x4c);
+/* The swift board expects a pca9539 but a pca9552 is compatible */
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 10), "pca9552",
+ 0x74);
+
+/* The swift board expects a TMP275 but a TMP105 is compatible */
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 12), "tmp105", 
0x48);
+i2c_create_slave(aspeed_i2c_get_bus(DEVICE(>i2c), 12), "tmp105", 
0x4a);
+}
+
 static void witherspoon_bmc_i2c_init(AspeedBoardState *bmc)
 {
 AspeedSoCState *soc = >soc;
@@ -378,6 +410,16 @@ static const AspeedBoardConfig aspeed_boards[] = {
 .i2c_init  = romulus_bmc_i2c_init,
 .ram   = 512 * MiB,
 }, {
+.name  = MACHINE_TYPE_NAME("swift-bmc"),
+.desc  = "OpenPOWER Swift BMC (ARM1176)",
+.soc_name  = "ast2500-a1",
+.hw_strap1 = SWIFT_BMC_HW_STRAP1,
+.fmc_model = "mx66l1g45g",
+.spi_model = "mx66l1g45g",
+.num_cs= 2,
+.i2c_init  = swift_bmc_i2c_init,
+.ram   = 512 * MiB,
+}, {
 .name  = MACHINE_TYPE_NAME("witherspoon-bmc"),
 .desc  = "OpenPOWER Witherspoon BMC (ARM1176)",
 .soc_name  = "ast2500-a1",
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH 5/5] virtio: add "use-started" property

[Greg Kurz]

On Wed, 29 May 2019 15:09:55 +0800
elohi...@gmail.com wrote:

> From: Xie Yongji 
> 
> In order to avoid migration issues, we introduce a "use-started"
> property to the base virtio device to indicate whether "started"
> and "start_on_kick" flag could be used. This property will be
> true by default and set to false when machine type <= 4.0.
> 
> Suggested-by: Greg Kurz 
> Signed-off-by: Xie Yongji 
> ---
>  hw/block/vhost-user-blk.c  |  8 ++--
>  hw/core/machine.c  |  4 +++-
>  hw/virtio/virtio.c |  7 ---
>  include/hw/virtio/virtio.h | 10 ++
>  4 files changed, 23 insertions(+), 6 deletions(-)
> 
> diff --git a/hw/block/vhost-user-blk.c b/hw/block/vhost-user-blk.c
> index 9cb61336a6..520c5d3d4b 100644
> --- a/hw/block/vhost-user-blk.c
> +++ b/hw/block/vhost-user-blk.c
> @@ -191,9 +191,13 @@ static void vhost_user_blk_stop(VirtIODevice *vdev)
>  static void vhost_user_blk_set_status(VirtIODevice *vdev, uint8_t status)
>  {
>  VHostUserBlk *s = VHOST_USER_BLK(vdev);
> -bool should_start = vdev->started;
> +bool should_start = status & VIRTIO_CONFIG_S_DRIVER_OK;

I guess you need the above because the set_status callback is called
before setting vdev->status, and virtio_device_started() thus doesn't
return the expected result for older machine types ?

What about adding a status argument to virtio_device_started() ?

bool should_start = virtio_device_started(vdev, status);

>  int ret;
>  
> +if (virtio_device_started(vdev)) {
> +should_start = true;
> +}
> +
>  if (!vdev->vm_running) {
>  should_start = false;
>  }
> @@ -317,7 +321,7 @@ static int vhost_user_blk_connect(DeviceState *dev)
>  }
>  
>  /* restore vhost state */
> -if (vdev->started) {
> +if (virtio_device_started(vdev)) {

if (virtio_device_started(vdev, vdev->status)) {

and so on...

>  ret = vhost_user_blk_start(vdev);
>  if (ret < 0) {
>  error_report("vhost-user-blk: vhost start failed: %s",
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 934c1bcceb..1730d28c1b 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -24,7 +24,9 @@
>  #include "hw/pci/pci.h"
>  #include "hw/mem/nvdimm.h"
>  
> -GlobalProperty hw_compat_4_0[] = {};
> +GlobalProperty hw_compat_4_0[] = {
> +{ "virtio-device", "use-started", "false" },
> +};
>  const size_t hw_compat_4_0_len = G_N_ELEMENTS(hw_compat_4_0);
>  
>  GlobalProperty hw_compat_3_1[] = {
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index 9e17293d46..4c05a9efe3 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -1803,14 +1803,14 @@ static bool virtio_started_needed(void *opaque)
>  {
>  VirtIODevice *vdev = opaque;
>  
> -return vdev->started;
> +return vdev->started && vdev->use_started;

Hmm... the idea is that vdev->started should never be set when
"use-started" is "off". Instead of checking vdev->use_started
here, you should rather assign it to vdev->started everywhere
you currently assign true.

>  }
>  
>  static bool virtio_start_on_kick_needed(void *opaque)
>  {
>  VirtIODevice *vdev = opaque;
>  
> -return vdev->start_on_kick;
> +return vdev->start_on_kick && vdev->use_started;
>  }
>  
>  static const VMStateDescription vmstate_virtqueue = {
> @@ -2320,7 +2320,7 @@ static void virtio_vmstate_change(void *opaque, int 
> running, RunState state)
>  VirtIODevice *vdev = opaque;
>  BusState *qbus = qdev_get_parent_bus(DEVICE(vdev));
>  VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(qbus);
> -bool backend_run = running && vdev->started;
> +bool backend_run = running && virtio_device_started(vdev);
>  vdev->vm_running = running;
>  
>  if (backend_run) {
> @@ -2698,6 +2698,7 @@ static void virtio_device_instance_finalize(Object *obj)
>  
>  static Property virtio_properties[] = {
>  DEFINE_VIRTIO_COMMON_FEATURES(VirtIODevice, host_features),
> +DEFINE_PROP_BOOL("use-started", VirtIODevice, use_started, true),
>  DEFINE_PROP_END_OF_LIST(),
>  };
>  
> diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
> index 27c0efc3d0..ba4dbd7480 100644
> --- a/include/hw/virtio/virtio.h
> +++ b/include/hw/virtio/virtio.h
> @@ -105,6 +105,7 @@ struct VirtIODevice
>  uint16_t device_id;
>  bool vm_running;
>  bool broken; /* device in invalid state, needs reset */
> +bool use_started;
>  bool started;
>  bool start_on_kick; /* virtio 1.0 transitional devices support that */
>  VMChangeStateEntry *vmstate;
> @@ -351,4 +352,13 @@ static inline bool virtio_is_big_endian(VirtIODevice 
> *vdev)
>  /* Devices conforming to VIRTIO 1.0 or later are always LE. */
>  return false;
>  }
> +
> +static inline bool virtio_device_started(VirtIODevice *vdev)
> +{
> +if (vdev->use_started) {
> +return vdev->started;
> +}
> +
> +return vdev->status & VIRTIO_CONFIG_S_DRIVER_OK;
> +}
>  #endif

[Qemu-devel] [PATCH v2 2/2] blockdev: Overlays are not snapshots

[Max Reitz]

There are error messages which refer to an overlay node as the snapshot.
That is wrong, those are two different things.

Signed-off-by: Max Reitz 
Reviewed-by: Eric Blake 
---
 blockdev.c | 10 +-
 tests/qemu-iotests/085.out | 10 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 6963270108..7de0b04fe7 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1608,13 +1608,13 @@ static void external_snapshot_prepare(BlkActionState 
*common,
 s->has_snapshot_node_name ? s->snapshot_node_name : NULL;
 
 if (node_name && !snapshot_node_name) {
-error_setg(errp, "New snapshot node name missing");
+error_setg(errp, "New overlay node name missing");
 goto out;
 }
 
 if (snapshot_node_name &&
 bdrv_lookup_bs(snapshot_node_name, snapshot_node_name, NULL)) {
-error_setg(errp, "New snapshot node name already in use");
+error_setg(errp, "New overlay node name already in use");
 goto out;
 }
 
@@ -1656,7 +1656,7 @@ static void external_snapshot_prepare(BlkActionState 
*common,
 }
 
 if (bdrv_has_blk(state->new_bs)) {
-error_setg(errp, "The snapshot is already in use");
+error_setg(errp, "The overlay is already in use");
 goto out;
 }
 
@@ -1666,12 +1666,12 @@ static void external_snapshot_prepare(BlkActionState 
*common,
 }
 
 if (state->new_bs->backing != NULL) {
-error_setg(errp, "The snapshot already has a backing image");
+error_setg(errp, "The overlay already has a backing image");
 goto out;
 }
 
 if (!state->new_bs->drv->supports_backing) {
-error_setg(errp, "The snapshot does not support backing images");
+error_setg(errp, "The overlay does not support backing images");
 goto out;
 }
 
diff --git a/tests/qemu-iotests/085.out b/tests/qemu-iotests/085.out
index 6edf107f55..2a5f256cd3 100644
--- a/tests/qemu-iotests/085.out
+++ b/tests/qemu-iotests/085.out
@@ -64,13 +64,13 @@ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 
backing_file=TEST_DIR/
 
 === Invalid command - cannot create a snapshot using a file BDS ===
 
-{"error": {"class": "GenericError", "desc": "The snapshot does not support 
backing images"}}
+{"error": {"class": "GenericError", "desc": "The overlay does not support 
backing images"}}
 
 === Invalid command - snapshot node used as active layer ===
 
-{"error": {"class": "GenericError", "desc": "The snapshot is already in use"}}
-{"error": {"class": "GenericError", "desc": "The snapshot is already in use"}}
-{"error": {"class": "GenericError", "desc": "The snapshot is already in use"}}
+{"error": {"class": "GenericError", "desc": "The overlay is already in use"}}
+{"error": {"class": "GenericError", "desc": "The overlay is already in use"}}
+{"error": {"class": "GenericError", "desc": "The overlay is already in use"}}
 
 === Invalid command - snapshot node used as backing hd ===
 
@@ -81,7 +81,7 @@ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 
backing_file=TEST_DIR/
 Formatting 'TEST_DIR/t.IMGFMT.base', fmt=IMGFMT size=134217728
 Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728 
backing_file=TEST_DIR/t.IMGFMT.base
 {"return": {}}
-{"error": {"class": "GenericError", "desc": "The snapshot already has a 
backing image"}}
+{"error": {"class": "GenericError", "desc": "The overlay already has a backing 
image"}}
 
 === Invalid command - The node does not exist ===
 
-- 
2.21.0

[Qemu-devel] [PATCH v2 0/2] blockdev: Overlays are not snapshots

[Max Reitz]

QEMU’s always been confused over what a snapshot is: Is it the overlay?
Is it the backing image?

Confusion is rarely a good thing.  I can’t think of any objective reason
why the overlay would be a snapshot.  A snapshot is something that does
not change over time; the overlay does.

(I suppose historically the reason is that “Taking an overlay” makes no
sense, so the operations are called “Taking a snapshot”.  Somehow, this
meaning carried over to the new file that is created during that
operation; if “Creating a snapshot” creates a file, that file must be
the snapshot, right?  Well, no, it isn’t.)

Let’s fix this as best as we can.  Better Nate than lever.


v2:
- Don’t break the iotests for a change
  (kept Eric’s R-b, because it felt like the right thing to do)


git backport-diff against v1:

Key:
[] : patches are identical
[] : number of functional differences between upstream/downstream patch
[down] : patch is downstream-only
The flags [FC] indicate (F)unctional and (C)ontextual differences, respectively

001/2:[] [--] 'qapi/block-core: Overlays are not snapshots'
002/2:[0010] [FC] 'blockdev: Overlays are not snapshots'


Max Reitz (2):
  qapi/block-core: Overlays are not snapshots
  blockdev: Overlays are not snapshots

 qapi/block-core.json   | 20 ++--
 blockdev.c | 10 +-
 tests/qemu-iotests/085.out | 10 +-
 3 files changed, 20 insertions(+), 20 deletions(-)

-- 
2.21.0

[Qemu-devel] [PATCH v2 1/2] qapi/block-core: Overlays are not snapshots

[Max Reitz]

A snapshot is something that reflects the state of something at a
certain point in time.  It does not change.

The file our snapshot commands create (or the node they install) is not
a snapshot, as it does change over time.  It is an overlay.  We cannot
do anything about the parameter names, but we can at least adjust the
descriptions to reflect that fact.

Signed-off-by: Max Reitz 
Reviewed-by: Eric Blake 
---
 qapi/block-core.json | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/qapi/block-core.json b/qapi/block-core.json
index 1defcde048..df52a90736 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -1279,17 +1279,17 @@
 #
 # Either @device or @node-name must be set but not both.
 #
-# @device: the name of the device to generate the snapshot from.
+# @device: the name of the device to take a snapshot of.
 #
 # @node-name: graph node name to generate the snapshot from (Since 2.0)
 #
-# @snapshot-file: the target of the new image. If the file exists, or
-# if it is a device, the snapshot will be created in the existing
-# file/device. Otherwise, a new file will be created.
+# @snapshot-file: the target of the new overlay image. If the file
+# exists, or if it is a device, the overlay will be created in the
+# existing file/device. Otherwise, a new file will be created.
 #
 # @snapshot-node-name: the graph node name of the new image (Since 2.0)
 #
-# @format: the format of the snapshot image, default is 'qcow2'.
+# @format: the format of the overlay image, default is 'qcow2'.
 #
 # @mode: whether and how QEMU should create a new image, default is
 #'absolute-paths'.
@@ -1302,10 +1302,10 @@
 ##
 # @BlockdevSnapshot:
 #
-# @node: device or node name that will have a snapshot created.
+# @node: device or node name that will have a snapshot taken.
 #
 # @overlay: reference to the existing block device that will become
-#   the overlay of @node, as part of creating the snapshot.
+#   the overlay of @node, as part of taking the snapshot.
 #   It must not have a current backing file (this can be
 #   achieved by passing "backing": null to blockdev-add).
 #
@@ -1443,7 +1443,7 @@
 ##
 # @blockdev-snapshot-sync:
 #
-# Generates a synchronous snapshot of a block device.
+# Takes a synchronous snapshot of a block device.
 #
 # For the arguments, see the documentation of BlockdevSnapshotSync.
 #
@@ -1469,9 +1469,9 @@
 ##
 # @blockdev-snapshot:
 #
-# Generates a snapshot of a block device.
+# Takes a snapshot of a block device.
 #
-# Create a snapshot, by installing 'node' as the backing image of
+# Take a snapshot, by installing 'node' as the backing image of
 # 'overlay'. Additionally, if 'node' is associated with a block
 # device, the block device changes to using 'overlay' as its new active
 # image.
-- 
2.21.0

Re: [Qemu-devel] [PATCH 2/5] virtio: Migrate the "start_on_kick" flag

[Greg Kurz]

On Wed, 29 May 2019 15:09:52 +0800
elohi...@gmail.com wrote:

> From: Xie Yongji 
> 
> We should migrate the "start_on_kick" flag so that we
> would not miss starting device on kicking at startup
> after migration.
> 

Hmm... IIUC "start_on_kick" means "virtio 1.0 transitional device that has
not been started yet", ie:

!vdev->started &&
(virtio_host_has_feature(vdev, VIRTIO_F_VERSION_1) &&
 !virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1))

If so, not sure why you need this extra field in the first place, but
you probably don't need to migrate it. Just recalculate in a post load
callback.

> Signed-off-by: Xie Yongji 
> ---
>  hw/virtio/virtio.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
> index fc8fca81ad..4d4ff67791 100644
> --- a/hw/virtio/virtio.c
> +++ b/hw/virtio/virtio.c
> @@ -1802,6 +1802,13 @@ static bool virtio_started_needed(void *opaque)
>  return vdev->started;
>  }
>  
> +static bool virtio_start_on_kick_needed(void *opaque)
> +{
> +VirtIODevice *vdev = opaque;
> +
> +return vdev->start_on_kick;
> +}
> +
>  static const VMStateDescription vmstate_virtqueue = {
>  .name = "virtqueue_state",
>  .version_id = 1,
> @@ -1941,6 +1948,17 @@ static const VMStateDescription vmstate_virtio_started 
> = {
>  }
>  };
>  
> +static const VMStateDescription vmstate_virtio_start_on_kick = {
> +.name = "virtio/start_on_kick",
> +.version_id = 1,
> +.minimum_version_id = 1,
> +.needed = _start_on_kick_needed,
> +.fields = (VMStateField[]) {
> +VMSTATE_BOOL(start_on_kick, VirtIODevice),
> +VMSTATE_END_OF_LIST()
> +}
> +};
> +
>  static const VMStateDescription vmstate_virtio = {
>  .name = "virtio",
>  .version_id = 1,
> @@ -1957,6 +1975,7 @@ static const VMStateDescription vmstate_virtio = {
>  _virtio_broken,
>  _virtio_extra_state,
>  _virtio_started,
> +_virtio_start_on_kick,
>  NULL
>  }
>  };

Re: [Qemu-devel] [PATCH RFC v20 4/8] target-avr: Add instruction decoding

[Michael Rolnik]

Richard,
I don't understand what I should do. Do you want me to merge decode files?

On Fri, May 31, 2019 at 5:45 PM Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 5/30/19 2:07 PM, Michael Rolnik wrote:
> > This includes:
> > - encoding of all 16 bit instructions
> > - encoding of all 32 bit instructions
> >
> > Signed-off-by: Michael Rolnik 
> > ---
> >  target/avr/insn16.decode | 160 +++
> >  target/avr/insn32.decode |  10 +++
> >  2 files changed, 170 insertions(+)
> >  create mode 100644 target/avr/insn16.decode
> >  create mode 100644 target/avr/insn32.decode
>
> Two things:
>
> (1) decodetree can handle variable-width ISA now.
>
> It's slightly ugly in that the %field numbering is little-endian and thus
> varies for each insn size.  But the in-flight patch set for target/rx shows
> that it works.
>
> That said, I don't think you need that because,
>
> (2) The four instructions that are 32-bits do not have
> any opcode bits in the second 16-bits.
>
> E.g.
>
> # The 22-bit immediate is partially in the opcode word,
> # and partially in the next.  Use append_16 to build the
> # complete 22-bit value.
> %imm_call   4:5 0:1 !function=append_16
> CALL1001 010.  111. imm=%imm_call
> JMP 1001 010.  110. imm=%imm_call
>
> # The 16-bit immediate is completely in the next word.
> # Fields cannot be defined with no bits, so we cannot play
> # the same trick and append to a zero-bit value.
> # Defer reading the immediate until trans_{LDS,STS}.
> @ldst_s  ... rd:5   imm=0
> LDS 1001 000 .  @ldst_s
> STS 1001 001 .  @ldst_s
>
>
> static uint16_t next_word(DisasContext *ctx)
> {
> return cpu_lduw_code(ctx->env, ctx->npc++ * 2);
> }
>
> static int append_16(DisasContext *ctx, int x)
> {
> return x << 16 | next_word(ctx);
> }
>
> static bool trans_LDS(DisasContext *ctx, arg_ldst_s *a)
> {
> a->imm = next_word(ctx);
> // other stuff
> }
>
> I realize that next_word as written does not fit in to how you currently
> process instructions in the loop, but I also think that's a mistake.  I'll
> respond to that in its place in the next patch.
>
> That said, next_word *could* be written to use ctx->inst[0].opcode.
>
>
> r~
>


-- 
Best Regards,
Michael Rolnik

Re: [Qemu-devel] [PATCH 2/2] blockdev: Overlays are not snapshots

[Max Reitz]

On 03.06.19 18:25, Max Reitz wrote:
> There are error messages which refer to an overlay node as the snapshot.
> That is wrong, those are two different things.
> 
> Signed-off-by: Max Reitz 
> ---
>  blockdev.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Oops.  I remember I wanted to run the iotests and see what fails, but
then I forgot to do so.  Of course something fails, so I’ll send a v2.

Max



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v2] vfio/common: Introduce vfio_set_irq_signaling helper

[Alex Williamson]

On Mon, 3 Jun 2019 20:51:50 +0200
Auger Eric  wrote:

> Hi Alex,
> 
> On 6/3/19 8:31 PM, Alex Williamson wrote:
> > On Mon, 27 May 2019 11:59:04 +0200
> > Eric Auger  wrote:
> >   
> >> The code used to assign an interrupt index/subindex to an
> >> eventfd is duplicated many times. Let's introduce an helper that
> >> allows to set/unset the signaling for an ACTION_TRIGGER,
> >> ACTION_MASK or ACTION_UNMASK action.
> >>
> >> Signed-off-by: Eric Auger 
> >>
> >> ---
> >>
> >> v1 -> v2:
> >> - don't call GET_IRQ_INFO in vfio_set_irq_signaling()
> >>   and restore quiet check in vfio_register_req_notifier.
> >>   Nicer display of the IRQ name.  
> > 
> > Hi Eric,
> > 
> > On this last item, it looks like irq_to_str() is now PCI specific, but
> > used generically.  Do you really want error messages with PCI interrupt
> > names on platform devices?  If we were to include PCI specific names,
> > we'd need to test the device is PCI or else default to simply printing
> > the index as you has previously.  Thanks,  
> 
> Yes I noticed that as well but thought this was not a big deal as the
> VFIO-PLATFORM device practically uses index 0 = VFIO_PCI_INTX_IRQ_INDEX
> for PLATFORM interrupts. If you consider we should care I will respin.

It needs to be done at some point, referring to a platform interrupt as
INTX might only induce a little cringe now, but that would reach a
tipping point as soon as more vectors are used by other bus drivers.
If I don't make it your problem now, it becomes someone else's problem
later, maybe even mine ;)  Thanks,

Alex

> >> This is a follow-up to
> >> [PATCH v2 0/2] vfio-pci: Introduce vfio_set_event_handler().
> >> It looks to me that introducing vfio_set_irq_signaling() has more
> >> benefits in term of code reduction and the helper abstraction
> >> looks cleaner.
> >> ---
> >>  hw/vfio/common.c  |  78 
> >>  hw/vfio/pci.c | 217 --
> >>  hw/vfio/platform.c|  54 +++--
> >>  include/hw/vfio/vfio-common.h |   2 +
> >>  4 files changed, 150 insertions(+), 201 deletions(-)
> >>
> >> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> >> index 4374cc6176..1f1deff360 100644
> >> --- a/hw/vfio/common.c
> >> +++ b/hw/vfio/common.c
> >> @@ -95,6 +95,84 @@ void vfio_mask_single_irqindex(VFIODevice *vbasedev, 
> >> int index)
> >>  ioctl(vbasedev->fd, VFIO_DEVICE_SET_IRQS, _set);
> >>  }
> >>  
> >> +static inline const char *action_to_str(int action)
> >> +{
> >> +switch (action) {
> >> +case VFIO_IRQ_SET_ACTION_MASK:
> >> +return "MASK";
> >> +case VFIO_IRQ_SET_ACTION_UNMASK:
> >> +return "UNMASK";
> >> +case VFIO_IRQ_SET_ACTION_TRIGGER:
> >> +return "TRIGGER";
> >> +default:
> >> +return "UNKNOWN ACTION";
> >> +}
> >> +}
> >> +
> >> +static char *irq_to_str(int index, int subindex)
> >> +{
> >> +char *str;
> >> +
> >> +switch (index) {
> >> +case VFIO_PCI_INTX_IRQ_INDEX:
> >> +str = g_strdup_printf("INTX-%d", subindex);
> >> +break;
> >> +case VFIO_PCI_MSI_IRQ_INDEX:
> >> +str = g_strdup_printf("MSI-%d", subindex);
> >> +break;
> >> +case VFIO_PCI_MSIX_IRQ_INDEX:
> >> +str = g_strdup_printf("MSIX-%d", subindex);
> >> +break;
> >> +case VFIO_PCI_ERR_IRQ_INDEX:
> >> +str = g_strdup_printf("ERR-%d", subindex);
> >> +break;
> >> +case VFIO_PCI_REQ_IRQ_INDEX:
> >> +str = g_strdup_printf("REQ-%d", subindex);
> >> +break;
> >> +default:
> >> +str = g_strdup_printf("index %d (unknown)", index);
> >> +break;
> >> +}
> >> +return str;
> >> +}
> >> +
> >> +int vfio_set_irq_signaling(VFIODevice *vbasedev, int index, int subindex,
> >> +   int action, int fd, Error **errp)
> >> +{
> >> +struct vfio_irq_set *irq_set;
> >> +int argsz, ret = 0;
> >> +int32_t *pfd;
> >> +char *irq_name;
> >> +
> >> +argsz = sizeof(*irq_set) + sizeof(*pfd);
> >> +
> >> +irq_set = g_malloc0(argsz);
> >> +irq_set->argsz = argsz;
> >> +irq_set->flags = VFIO_IRQ_SET_DATA_EVENTFD | action;
> >> +irq_set->index = index;
> >> +irq_set->start = subindex;
> >> +irq_set->count = 1;
> >> +pfd = (int32_t *)_set->data;
> >> +*pfd = fd;
> >> +
> >> +ret = ioctl(vbasedev->fd, VFIO_DEVICE_SET_IRQS, irq_set);
> >> +
> >> +g_free(irq_set);
> >> +
> >> +if (!ret) {
> >> +return 0;
> >> +}
> >> +
> >> +error_setg_errno(errp, -ret, "VFIO_DEVICE_SET_IRQS failure");
> >> +irq_name = irq_to_str(index, subindex);
> >> +error_prepend(errp,
> >> +  "Failed to %s %s eventfd signaling for interrupt %s: ",
> >> +  fd < 0 ? "tear down" : "set up", action_to_str(action),
> >> +  irq_name);
> >> +g_free(irq_name);
> >> +return ret;
> >> +}
> >> +
> >>  /*
> >>   * IO Port/MMIO - Beware of the endians, VFIO is always 

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support

[Eduardo Habkost]

On Mon, Jun 03, 2019 at 10:24:56AM +0200, Jens Freimann wrote:
> On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote:
> > On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote:
> > > On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote:
> > > > On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan Gilbert wrote:
> > > > > * Jens Freimann (jfreim...@redhat.com) wrote:
> > [...]
> > > > > > +}
> > > > > > +if (migration_in_setup(s) && !should_be_hidden && 
> > > > > > n->primary_dev) {
> > > > > > +qdev_unplug(n->primary_dev, );
> > > > >
> > > > > Not knowing unplug well; can you just explain - is that device hard
> > > > > unplugged and it's gone by the time this function returns or is it 
> > > > > still
> > > > > hanging around for some indeterminate time?
> > > 
> > > Qemu will trigger an unplug request via pcie attention button in which 
> > > case
> > > there could be a delay by the guest operating system. We could give it 
> > > some
> > > amount of time and if nothing happens try surpise removal or handle the
> > > error otherwise.
> > 
> > I'm missing something here:
> > 
> > Isn't the whole point of the new device-hiding infrastructure to
> > prevent QEMU from closing the VFIO until migration ended
> > successfully?
> 
> No. The point of hiding it is to only add the VFIO (that is configured
> with the same MAC as the virtio-net device) until the
> VIRTIO_NET_F_STANDBY feature is negotiated. We don't want to expose to
> devices with the same MAC to guests who can't handle it.
> 
> > What exactly is preventing QEMU from closing the host VFIO device
> > after the guest OS has handled the unplug request?
> 
> We qdev_unplug() the VFIO device and want the virtio-net standby device to
> take over. If something goes wrong with unplug or
> migration in general we have to qdev_plug() the device back.
> 
> This series does not try to implement new functionality to close a
> device without freeing the resources.
> 
> From the discussion in this thread I understand that is what libvirt
> needs though. Something that will trigger the unplug from the
> guest but not free the devices resources in the host system (which is
> what qdev_unplug() does). Correct?

This is what I understand we need, but this is not what
qdev_unplug() does.

> 
> Why is it bad to fully re-create the device in case of a failed migration?

Bad or not, I thought the whole point of doing it inside QEMU was
to do something libvirt wouldn't be able to do (namely,
unplugging the device while not freeing resources).  If we are
doing something that management software is already capable of
doing, what's the point?

Quoting a previous message from this thread:

On Thu, May 30, 2019 at 02:09:42PM -0400, Michael S. Tsirkin wrote:
| > On Thu, May 30, 2019 at 07:00:23PM +0100, Dr. David Alan Gilbert wrote:
| > >  This patch series is very
| > > odd precisely because it's trying to do the unplug itself in the
| > > migration phase rather than let the management layer do it - so unless
| > > it's nailed down how to make sure that's really really bullet proof
| > > then we've got to go back and ask the question about whether we should
| > > really fix it so it can be done by the management layer.
| > > 
| > > Dave
| > 
| > management already said they can't because files get closed and
| > resources freed on unplug and so they might not be able to re-add device
| > on migration failure. We do it in migration because that is
| > where failures can happen and we can recover.


-- 
Eduardo

Re: [Qemu-devel] [PATCH v2] vfio/common: Introduce vfio_set_irq_signaling helper

[Auger Eric]

Hi Alex,

On 6/3/19 9:36 PM, Alex Williamson wrote:
> On Mon, 3 Jun 2019 20:51:50 +0200
> Auger Eric  wrote:
> 
>> Hi Alex,
>>
>> On 6/3/19 8:31 PM, Alex Williamson wrote:
>>> On Mon, 27 May 2019 11:59:04 +0200
>>> Eric Auger  wrote:
>>>   
 The code used to assign an interrupt index/subindex to an
 eventfd is duplicated many times. Let's introduce an helper that
 allows to set/unset the signaling for an ACTION_TRIGGER,
 ACTION_MASK or ACTION_UNMASK action.

 Signed-off-by: Eric Auger 

 ---

 v1 -> v2:
 - don't call GET_IRQ_INFO in vfio_set_irq_signaling()
   and restore quiet check in vfio_register_req_notifier.
   Nicer display of the IRQ name.  
>>>
>>> Hi Eric,
>>>
>>> On this last item, it looks like irq_to_str() is now PCI specific, but
>>> used generically.  Do you really want error messages with PCI interrupt
>>> names on platform devices?  If we were to include PCI specific names,
>>> we'd need to test the device is PCI or else default to simply printing
>>> the index as you has previously.  Thanks,  
>>
>> Yes I noticed that as well but thought this was not a big deal as the
>> VFIO-PLATFORM device practically uses index 0 = VFIO_PCI_INTX_IRQ_INDEX
>> for PLATFORM interrupts. If you consider we should care I will respin.
> 
> It needs to be done at some point, referring to a platform interrupt as
> INTX might only induce a little cringe now, but that would reach a
> tipping point as soon as more vectors are used by other bus drivers.
> If I don't make it your problem now, it becomes someone else's problem
> later, maybe even mine ;)  Thanks,
Sure, I understand ;-)

Thanks

Eric
> 
> Alex
> 
 This is a follow-up to
 [PATCH v2 0/2] vfio-pci: Introduce vfio_set_event_handler().
 It looks to me that introducing vfio_set_irq_signaling() has more
 benefits in term of code reduction and the helper abstraction
 looks cleaner.
 ---
  hw/vfio/common.c  |  78 
  hw/vfio/pci.c | 217 --
  hw/vfio/platform.c|  54 +++--
  include/hw/vfio/vfio-common.h |   2 +
  4 files changed, 150 insertions(+), 201 deletions(-)

 diff --git a/hw/vfio/common.c b/hw/vfio/common.c
 index 4374cc6176..1f1deff360 100644
 --- a/hw/vfio/common.c
 +++ b/hw/vfio/common.c
 @@ -95,6 +95,84 @@ void vfio_mask_single_irqindex(VFIODevice *vbasedev, 
 int index)
  ioctl(vbasedev->fd, VFIO_DEVICE_SET_IRQS, _set);
  }
  
 +static inline const char *action_to_str(int action)
 +{
 +switch (action) {
 +case VFIO_IRQ_SET_ACTION_MASK:
 +return "MASK";
 +case VFIO_IRQ_SET_ACTION_UNMASK:
 +return "UNMASK";
 +case VFIO_IRQ_SET_ACTION_TRIGGER:
 +return "TRIGGER";
 +default:
 +return "UNKNOWN ACTION";
 +}
 +}
 +
 +static char *irq_to_str(int index, int subindex)
 +{
 +char *str;
 +
 +switch (index) {
 +case VFIO_PCI_INTX_IRQ_INDEX:
 +str = g_strdup_printf("INTX-%d", subindex);
 +break;
 +case VFIO_PCI_MSI_IRQ_INDEX:
 +str = g_strdup_printf("MSI-%d", subindex);
 +break;
 +case VFIO_PCI_MSIX_IRQ_INDEX:
 +str = g_strdup_printf("MSIX-%d", subindex);
 +break;
 +case VFIO_PCI_ERR_IRQ_INDEX:
 +str = g_strdup_printf("ERR-%d", subindex);
 +break;
 +case VFIO_PCI_REQ_IRQ_INDEX:
 +str = g_strdup_printf("REQ-%d", subindex);
 +break;
 +default:
 +str = g_strdup_printf("index %d (unknown)", index);
 +break;
 +}
 +return str;
 +}
 +
 +int vfio_set_irq_signaling(VFIODevice *vbasedev, int index, int subindex,
 +   int action, int fd, Error **errp)
 +{
 +struct vfio_irq_set *irq_set;
 +int argsz, ret = 0;
 +int32_t *pfd;
 +char *irq_name;
 +
 +argsz = sizeof(*irq_set) + sizeof(*pfd);
 +
 +irq_set = g_malloc0(argsz);
 +irq_set->argsz = argsz;
 +irq_set->flags = VFIO_IRQ_SET_DATA_EVENTFD | action;
 +irq_set->index = index;
 +irq_set->start = subindex;
 +irq_set->count = 1;
 +pfd = (int32_t *)_set->data;
 +*pfd = fd;
 +
 +ret = ioctl(vbasedev->fd, VFIO_DEVICE_SET_IRQS, irq_set);
 +
 +g_free(irq_set);
 +
 +if (!ret) {
 +return 0;
 +}
 +
 +error_setg_errno(errp, -ret, "VFIO_DEVICE_SET_IRQS failure");
 +irq_name = irq_to_str(index, subindex);
 +error_prepend(errp,
 +  "Failed to %s %s eventfd signaling for interrupt %s: ",
 +  fd < 0 ? "tear down" : "set up", action_to_str(action),
 +  irq_name);
 +

Re: [Qemu-devel] [PATCH 1/2] qapi/block-core: Overlays are not snapshots

[Eric Blake]

On 6/3/19 11:25 AM, Max Reitz wrote:
> A snapshot is something that reflects the state of something at a
> certain point in time.  It does not change.
> 
> The file our snapshot commands create (or the node they install) is not
> a snapshot, as it does change over time.  It is an overlay.  We cannot
> do anything about the parameter names, but we can at least adjust the
> descriptions to reflect that fact.
> 
> Signed-off-by: Max Reitz 
> ---
>  qapi/block-core.json | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH RFC v20 8/8] target/avr: Register AVR support with the rest of QEMU, the build system, and the MAINTAINERS file

[Michael Rolnik]

Thanks!

On Mon, Jun 3, 2019 at 10:47 PM Eric Blake  wrote:

> On 6/1/19 4:20 PM, Michael Rolnik wrote:
> > Hi Eric.
> >
> > please explain what should I do or point to an example or documentation.
> >
>
> >>>  # Since: 3.0
> >>>  ##
> >>>  { 'enum' : 'SysEmuTarget',
> >>> -  'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386',
> 'lm32',
> >>> +  'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'cris', 'hppa', 'i386',
> >> 'lm32',
> >>>   'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
> >>>   'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
> >>>   'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
> >>
> >> Missing documentation that 'avr' is (since 4.1).
>
> Look above a few lines, where it says:
>
> # ppcemb: dropped in 3.1
> #
> # Since: 3.0
> ##
> { 'enum' : 'SysEmuTarget',
>
> You'll add a new line, right after ppcemb, which states
>
> # avr: since 4.1
>
> --
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.   +1-919-301-3226
> Virtualization:  qemu.org | libvirt.org
>
>

-- 
Best Regards,
Michael Rolnik

Re: [Qemu-devel] [PATCH] target/s390x: Use tcg_gen_gvec_bitsel

[David Hildenbrand]

On 03.06.19 18:57, Richard Henderson wrote:
> This replaces the target-specific implementations for VSEL.
> 
> Signed-off-by: Richard Henderson 
> ---
>  target/s390x/translate_vx.inc.c | 38 ++---
>  1 file changed, 6 insertions(+), 32 deletions(-)
> 
> diff --git a/target/s390x/translate_vx.inc.c b/target/s390x/translate_vx.inc.c
> index 7e0bfcb190..a8603cbfd6 100644
> --- a/target/s390x/translate_vx.inc.c
> +++ b/target/s390x/translate_vx.inc.c
> @@ -233,6 +233,9 @@ static void get_vec_element_ptr_i64(TCGv_ptr ptr, uint8_t 
> reg, TCGv_i64 enr,
>  #define gen_gvec_fn_3(fn, es, v1, v2, v3) \
>  tcg_gen_gvec_##fn(es, vec_full_reg_offset(v1), vec_full_reg_offset(v2), \
>vec_full_reg_offset(v3), 16, 16)
> +#define gen_gvec_fn_4(fn, es, v1, v2, v3, v4) \
> +tcg_gen_gvec_##fn(es, vec_full_reg_offset(v1), vec_full_reg_offset(v2), \
> +  vec_full_reg_offset(v3), vec_full_reg_offset(v4), 16, 
> 16)
>  
>  /*
>   * Helper to carry out a 128 bit vector computation using 2 i64 values per
> @@ -903,40 +906,11 @@ static DisasJumpType op_vsce(DisasContext *s, DisasOps 
> *o)
>  return DISAS_NEXT;
>  }
>  
> -static void gen_sel_i64(TCGv_i64 d, TCGv_i64 a, TCGv_i64 b, TCGv_i64 c)
> -{
> -TCGv_i64 t = tcg_temp_new_i64();
> -
> -/* bit in c not set -> copy bit from b */
> -tcg_gen_andc_i64(t, b, c);
> -/* bit in c set -> copy bit from a */
> -tcg_gen_and_i64(d, a, c);
> -/* merge the results */
> -tcg_gen_or_i64(d, d, t);
> -tcg_temp_free_i64(t);
> -}
> -
> -static void gen_sel_vec(unsigned vece, TCGv_vec d, TCGv_vec a, TCGv_vec b,
> -TCGv_vec c)
> -{
> -TCGv_vec t = tcg_temp_new_vec_matching(d);
> -
> -tcg_gen_andc_vec(vece, t, b, c);
> -tcg_gen_and_vec(vece, d, a, c);
> -tcg_gen_or_vec(vece, d, d, t);
> -tcg_temp_free_vec(t);
> -}
> -

Comparing against tcg_gen_bitsel_i64()

1. a and c are switched
2. b is _not_ switched (and() and andc() are switched)

Shouldn't this be

gen_gvec_fn_4(bitsel, ES_8, get_field(s->fields, v1),
  get_field(s->fields, v4), get_field(s->fields, v3),
  get_field(s->fields, v2));

?

Maybe I am missing something. It was a long day :)

Should I send this patch with the next s390x/tcg pull request?

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 2/2] blockdev: Overlays are not snapshots

[Eric Blake]

On 6/3/19 11:25 AM, Max Reitz wrote:
> There are error messages which refer to an overlay node as the snapshot.
> That is wrong, those are two different things.
> 
> Signed-off-by: Max Reitz 
> ---
>  blockdev.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

Reviewed-by: Eric Blake 

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] Deprecation policy and build dependencies

[Eduardo Habkost]

On Mon, Jun 03, 2019 at 08:16:29PM +0200, Cornelia Huck wrote:
> On Mon, 3 Jun 2019 14:02:16 -0400
> John Snow  wrote:
> 
> > On 6/3/19 8:26 AM, Markus Armbruster wrote:
> > > John Snow  writes:
> > >   
> > >> On 5/31/19 3:24 PM, Eduardo Habkost wrote:  
> > >>> Long story short: I would really like to drop support for Python
> > >>> 2 in QEMU 4.1.  
> > > 
> > > The sooner, the better, as far as I'm concerned.
> > >   
> > >>> What exactly prevents us from doing this?  Does our deprecation
> > >>> policy really apply to build dependencies?
> > >>>  
> > >>
> > >> Normally I'd say it's only nice to also follow the depreciation policy
> > >> for tooling as well to give people a chance to switch away, but with
> > >> regards to Python2, I feel like we're in the clear to drop it for the
> > >> first release that will happen after the Python2 doomsday clock.
> > >>
> > >> (So, probably 4.2.)  
> > > 
> > > In addition to our feature deprecation policity, we have a "Supported
> > > build platforms" policy (commit 45b47130f4b).  The most common holdback
> > > is this one:
> > > 
> > > For distributions with long-lifetime releases, the project will aim
> > > to support the most recent major version at all times. Support for
> > > the previous major version will be dropped 2 years after the new
> > > major version is released. For the purposes of identifying supported
> > > software versions, the project will look at RHEL, Debian, Ubuntu
> > > LTS, and SLES distros. Other long-lifetime distros will be assumed
> > > to ship similar software versions.
> > > 
> > > RHEL-7 has Python 3 only in EPEL.  RHEL-8 came out last month.  Unless
> > > we interpret our policy to include EPEL, this means supporting Python 2
> > > for some 16 months after upstream Python retires it.  My personal
> > > opinion: nuts.
> > >   
> > 
> > I would rather not support Python2 a day after the clock expires.

Me neither.

> > 
> > > I didn't bother checking Debian, Ubuntu LTS and SLES.
> > > 
> > > For hosts other than Linux, we're less ambitious.
> > >   
> > 
> > That policy strikes me as weird, because RHEL7 is not going to be, in
> > general, using the latest and greatest QEMU. Usually stable versions of
> > distros stick with the versions of the programs that came out at the time.
> 
> I think the idea was that folks might actually develop on a 'stable'
> distro (in a previous life, I used to complain quite often that
> building QEMU on a stable distro broke... it was one of my main
> development machines, but not controlled by me).

Good point.

> 
> > 
> > What's the benefit of making sure that stable platforms can continue to
> > run the *newest* QEMU? Is this even a reasonable restriction? If you are
> > running RHEL7, how many projects do you expect to be able to git clone
> > and build and have that work with the rest of your legacy/stable
> > dependencies?
> > 
> > RHEL7 uses a 1.5.3 based version. I don't think it matters if we update
> > 4.2 to be Python3 only, really.
> 
> It depends on how old the distro is and what update policy it
> uses... if parts of it are regularly updated, it might actually be
> usable. In this case, I think we really need to interpret our policy
> to include EPEL, or it is completely nuts.

Let's do that, please.  If we simply include EPEL in our policy
we don't need to treat Python as special.

-- 
Eduardo

Re: [Qemu-devel] [PATCH RFC v20 8/8] target/avr: Register AVR support with the rest of QEMU, the build system, and the MAINTAINERS file

[Eric Blake]

On 6/1/19 4:20 PM, Michael Rolnik wrote:
> Hi Eric.
> 
> please explain what should I do or point to an example or documentation.
> 

>>>  # Since: 3.0
>>>  ##
>>>  { 'enum' : 'SysEmuTarget',
>>> -  'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32',
>>> +  'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'cris', 'hppa', 'i386',
>> 'lm32',
>>>   'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
>>>   'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
>>>   'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
>>
>> Missing documentation that 'avr' is (since 4.1).

Look above a few lines, where it says:

# ppcemb: dropped in 3.1
#
# Since: 3.0
##
{ 'enum' : 'SysEmuTarget',

You'll add a new line, right after ppcemb, which states

# avr: since 4.1

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



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v4 0/2] introduction of migration_version attribute for VFIO live migration

[Alex Williamson]

On Thu, 30 May 2019 20:44:38 -0400
Yan Zhao  wrote:

> This patchset introduces a migration_version attribute under sysfs of VFIO
> Mediated devices.
> 
> This migration_version attribute is used to check migration compatibility
> between two mdev devices of the same mdev type.
> 
> Patch 1 defines migration_version attribute in
> Documentation/vfio-mediated-device.txt
> 
> Patch 2 uses GVT as an example to show how to expose migration_version
> attribute and check migration compatibility in vendor driver.

Thanks for iterating through this, it looks like we've settled on
something reasonable, but now what?  This is one piece of the puzzle to
supporting mdev migration, but I don't think it makes sense to commit
this upstream on its own without also defining the remainder of how we
actually do migration, preferably with more than one working
implementation and at least prototyped, if not final, QEMU support.  I
hope that was the intent, and maybe it's now time to look at the next
piece of the puzzle.  Thanks,

Alex

Re: [Qemu-devel] [PATCH v2 09/10] hw/vfio/pci: Use the QOM DEVICE() macro to access DeviceState.qdev

[Alex Williamson]

On Tue, 28 May 2019 18:40:19 +0200
Philippe Mathieu-Daudé  wrote:

> Rather than looking inside the definition of a DeviceState with
> "s->qdev", use the QOM prefered style: "DEVICE(s)".
> 
> This patch was generated using the following Coccinelle script:
> 
> // Use DEVICE() macros to access DeviceState.qdev
> @use_device_macro_to_access_qdev@
> expression obj;
> identifier dev;
> @@
> ->dev.qdev
> +DEVICE(obj)
> 
> Suggested-by: Peter Maydell 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/vfio/pci.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)


Acked-by: Alex Williamson 


> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 8e555db12e..2a4091d216 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -2717,7 +2717,7 @@ static void vfio_req_notifier_handler(void *opaque)
>  return;
>  }
>  
> -qdev_unplug(>pdev.qdev, );
> +qdev_unplug(DEVICE(vdev), );
>  if (err) {
>  warn_reportf_err(err, VFIO_MSG_PREFIX, vdev->vbasedev.name);
>  }
> @@ -2839,7 +2839,7 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
>  vdev->vbasedev.name = g_path_get_basename(vdev->vbasedev.sysfsdev);
>  vdev->vbasedev.ops = _pci_ops;
>  vdev->vbasedev.type = VFIO_DEVICE_TYPE_PCI;
> -vdev->vbasedev.dev = >pdev.qdev;
> +vdev->vbasedev.dev = DEVICE(vdev);
>  
>  tmp = g_strdup_printf("%s/iommu_group", vdev->vbasedev.sysfsdev);
>  len = readlink(tmp, group_path, sizeof(group_path));

Re: [Qemu-devel] [PATCH v2] vfio/common: Introduce vfio_set_irq_signaling helper

[Auger Eric]

Hi Alex,

On 6/3/19 8:31 PM, Alex Williamson wrote:
> On Mon, 27 May 2019 11:59:04 +0200
> Eric Auger  wrote:
> 
>> The code used to assign an interrupt index/subindex to an
>> eventfd is duplicated many times. Let's introduce an helper that
>> allows to set/unset the signaling for an ACTION_TRIGGER,
>> ACTION_MASK or ACTION_UNMASK action.
>>
>> Signed-off-by: Eric Auger 
>>
>> ---
>>
>> v1 -> v2:
>> - don't call GET_IRQ_INFO in vfio_set_irq_signaling()
>>   and restore quiet check in vfio_register_req_notifier.
>>   Nicer display of the IRQ name.
> 
> Hi Eric,
> 
> On this last item, it looks like irq_to_str() is now PCI specific, but
> used generically.  Do you really want error messages with PCI interrupt
> names on platform devices?  If we were to include PCI specific names,
> we'd need to test the device is PCI or else default to simply printing
> the index as you has previously.  Thanks,

Yes I noticed that as well but thought this was not a big deal as the
VFIO-PLATFORM device practically uses index 0 = VFIO_PCI_INTX_IRQ_INDEX
for PLATFORM interrupts. If you consider we should care I will respin.

thanks

Eric
> 
> Alex
> 
>> This is a follow-up to
>> [PATCH v2 0/2] vfio-pci: Introduce vfio_set_event_handler().
>> It looks to me that introducing vfio_set_irq_signaling() has more
>> benefits in term of code reduction and the helper abstraction
>> looks cleaner.
>> ---
>>  hw/vfio/common.c  |  78 
>>  hw/vfio/pci.c | 217 --
>>  hw/vfio/platform.c|  54 +++--
>>  include/hw/vfio/vfio-common.h |   2 +
>>  4 files changed, 150 insertions(+), 201 deletions(-)
>>
>> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
>> index 4374cc6176..1f1deff360 100644
>> --- a/hw/vfio/common.c
>> +++ b/hw/vfio/common.c
>> @@ -95,6 +95,84 @@ void vfio_mask_single_irqindex(VFIODevice *vbasedev, int 
>> index)
>>  ioctl(vbasedev->fd, VFIO_DEVICE_SET_IRQS, _set);
>>  }
>>  
>> +static inline const char *action_to_str(int action)
>> +{
>> +switch (action) {
>> +case VFIO_IRQ_SET_ACTION_MASK:
>> +return "MASK";
>> +case VFIO_IRQ_SET_ACTION_UNMASK:
>> +return "UNMASK";
>> +case VFIO_IRQ_SET_ACTION_TRIGGER:
>> +return "TRIGGER";
>> +default:
>> +return "UNKNOWN ACTION";
>> +}
>> +}
>> +
>> +static char *irq_to_str(int index, int subindex)
>> +{
>> +char *str;
>> +
>> +switch (index) {
>> +case VFIO_PCI_INTX_IRQ_INDEX:
>> +str = g_strdup_printf("INTX-%d", subindex);
>> +break;
>> +case VFIO_PCI_MSI_IRQ_INDEX:
>> +str = g_strdup_printf("MSI-%d", subindex);
>> +break;
>> +case VFIO_PCI_MSIX_IRQ_INDEX:
>> +str = g_strdup_printf("MSIX-%d", subindex);
>> +break;
>> +case VFIO_PCI_ERR_IRQ_INDEX:
>> +str = g_strdup_printf("ERR-%d", subindex);
>> +break;
>> +case VFIO_PCI_REQ_IRQ_INDEX:
>> +str = g_strdup_printf("REQ-%d", subindex);
>> +break;
>> +default:
>> +str = g_strdup_printf("index %d (unknown)", index);
>> +break;
>> +}
>> +return str;
>> +}
>> +
>> +int vfio_set_irq_signaling(VFIODevice *vbasedev, int index, int subindex,
>> +   int action, int fd, Error **errp)
>> +{
>> +struct vfio_irq_set *irq_set;
>> +int argsz, ret = 0;
>> +int32_t *pfd;
>> +char *irq_name;
>> +
>> +argsz = sizeof(*irq_set) + sizeof(*pfd);
>> +
>> +irq_set = g_malloc0(argsz);
>> +irq_set->argsz = argsz;
>> +irq_set->flags = VFIO_IRQ_SET_DATA_EVENTFD | action;
>> +irq_set->index = index;
>> +irq_set->start = subindex;
>> +irq_set->count = 1;
>> +pfd = (int32_t *)_set->data;
>> +*pfd = fd;
>> +
>> +ret = ioctl(vbasedev->fd, VFIO_DEVICE_SET_IRQS, irq_set);
>> +
>> +g_free(irq_set);
>> +
>> +if (!ret) {
>> +return 0;
>> +}
>> +
>> +error_setg_errno(errp, -ret, "VFIO_DEVICE_SET_IRQS failure");
>> +irq_name = irq_to_str(index, subindex);
>> +error_prepend(errp,
>> +  "Failed to %s %s eventfd signaling for interrupt %s: ",
>> +  fd < 0 ? "tear down" : "set up", action_to_str(action),
>> +  irq_name);
>> +g_free(irq_name);
>> +return ret;
>> +}
>> +
>>  /*
>>   * IO Port/MMIO - Beware of the endians, VFIO is always little endian
>>   */
>> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
>> index 8cecb53d5c..e42901bd66 100644
>> --- a/hw/vfio/pci.c
>> +++ b/hw/vfio/pci.c
>> @@ -113,9 +113,7 @@ static void vfio_intx_enable_kvm(VFIOPCIDevice *vdev, 
>> Error **errp)
>>  .gsi = vdev->intx.route.irq,
>>  .flags = KVM_IRQFD_FLAG_RESAMPLE,
>>  };
>> -struct vfio_irq_set *irq_set;
>> -int ret, argsz;
>> -int32_t *pfd;
>> +Error *err = NULL;
>>  
>>  if (vdev->no_kvm_intx || !kvm_irqfds_enabled() ||
>>  vdev->intx.route.mode != PCI_INTX_ENABLED ||
>> @@ -143,22 +141,10 @@ static void 

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support

[Alex Williamson]

On Mon, 3 Jun 2019 14:10:52 -0400
Laine Stump  wrote:

> On 6/3/19 4:24 AM, Jens Freimann wrote:
> > On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote:  
> >> On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote:  
> >>> On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote:  
> >>> > On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan Gilbert   
> >>> wrote:  
> >>> > > * Jens Freimann (jfreim...@redhat.com) wrote:  
> >> [...]  
> >>> > > > +    }
> >>> > > > +    if (migration_in_setup(s) && !should_be_hidden &&   
> >>> n->primary_dev) {  
> >>> > > > +    qdev_unplug(n->primary_dev, );  
> >>> > >
> >>> > > Not knowing unplug well; can you just explain - is that device hard
> >>> > > unplugged and it's gone by the time this function returns or is   
> >>> it still  
> >>> > > hanging around for some indeterminate time?  
> >>>
> >>> Qemu will trigger an unplug request via pcie attention button in 
> >>> which case
> >>> there could be a delay by the guest operating system. We could give 
> >>> it some
> >>> amount of time and if nothing happens try surpise removal or handle the
> >>> error otherwise.  
> >>
> >> I'm missing something here:
> >>
> >> Isn't the whole point of the new device-hiding infrastructure to
> >> prevent QEMU from closing the VFIO until migration ended
> >> successfully?  
> > 
> > No. The point of hiding it is to only add the VFIO (that is configured
> > with the same MAC as the virtio-net device) until the
> > VIRTIO_NET_F_STANDBY feature is negotiated. We don't want to expose to
> > devices with the same MAC to guests who can't handle it.
> >   
> >> What exactly is preventing QEMU from closing the host VFIO device
> >> after the guest OS has handled the unplug request?  
> > 
> > We qdev_unplug() the VFIO device and want the virtio-net standby device to
> > take over. If something goes wrong with unplug or
> > migration in general we have to qdev_plug() the device back.
> > 
> > This series does not try to implement new functionality to close a
> > device without freeing the resources.
> > 
> >  From the discussion in this thread I understand that is what libvirt
> > needs though. Something that will trigger the unplug from the
> > guest but not free the devices resources in the host system (which is
> > what qdev_unplug() does). Correct?
> > Why is it bad to fully re-create the device in case of a failed migration?  
> 
> I think the concern is that if the device was fully released by qemu 
> during migration, it might have already been given to some other/new 
> guest during the time that migration is trying to complete. If migration 
> then fails, you may be unable to restore the guest to the previous state.

Yep, plus I think the memory pinning and IOMMU resources could be a
variable as well.  Essentially, there's no guaranteed reservation to
the device or any of the additional resources that the device implies
once it's released, so we want to keep as much of that on hot-standby
as we can in case the migration fails.  Unfortunately even just
unmapping the BARs for a guest-only hot-unplug unmaps those regions
from the IOMMU, but aside from catastrophic resource issues on the
host, we can essentially guarantee being able to remap those.  Thanks,

Alex

Re: [Qemu-devel] Deprecation policy and build dependencies

[Peter Maydell]

On Mon, 3 Jun 2019 at 19:21, John Snow  wrote:
> I get it, we don't want to require Python 3.8 because some dev wanted
> assignment conditionals -- but we're talking about Python 2 here, which
> suffers its EOL by the end of this calendar year.
>
> So do we think it's reasonable to drop support for Python2 for the
> release that comes out after Python2's EOL, or do we insist on 2x3
> simultaneous support for years more?

I don't have a strong opinion on Python in particular, but
I think it would be nicer to avoid the "python is a special
snowflake" effect. Would it really be so bad for it to just
be "drop it when it falls off the last LTS distro" like the
rest of our dependencies ?

thanks
-- PMM

[Qemu-devel] [Bug 1830872] Re: [RFC PATCH] cputlb: use uint64_t for interim values for unaligned load

[Laszlo Ersek (Red Hat)]

(+Igor)

On 06/03/19 17:01, Alex Bennée wrote:
> When running on 32 bit TCG backends a wide unaligned load ends up
> truncating data before returning to the guest. We specifically have
> the return type as uint64_t to avoid any premature truncation so we
> should use the same for the interim types.
> 
> Hopefully fixes #1830872
> 
> Signed-off-by: Alex Bennée 
> ---
>  accel/tcg/cputlb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/accel/tcg/cputlb.c b/accel/tcg/cputlb.c
> index cdcc3771020..b796ab1cbea 100644
> --- a/accel/tcg/cputlb.c
> +++ b/accel/tcg/cputlb.c
> @@ -1303,7 +1303,7 @@ load_helper(CPUArchState *env, target_ulong addr, 
> TCGMemOpIdx oi,
>  && unlikely((addr & ~TARGET_PAGE_MASK) + size - 1
>  >= TARGET_PAGE_SIZE)) {
>  target_ulong addr1, addr2;
> -tcg_target_ulong r1, r2;
> +uint64_t r1, r2;
>  unsigned shift;
>  do_unaligned_access:
>  addr1 = addr & ~(size - 1);
> 

Applied on top of commit ad88e4252f09c2956b99c90de39e95bab2e8e7af:

Tested-by: Laszlo Ersek 

Thanks!
Laszlo

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

Title:
  AARCH64 to ARMv7 mistranslation in TCG

Status in QEMU:
  New

Bug description:
  The following guest code:

  
https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S

  implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI
  Development Kit II) library function. (CopyMem() basically has memmove()
  semantics, to provide a standard C analog here.) The relevant functions
  are InternalMemCopyMem() and __memcpy().

  When TCG translates this aarch64 code to x86_64, everything works
  fine.

  When TCG translates this aarch64 code to ARMv7, the destination area of
  the translated CopyMem() function becomes corrupted -- it differs from
  the intended source contents. Namely, in every 4096 byte block, the
  8-byte word at offset 4032 (0xFC0) is zeroed out in the destination,
  instead of receiving the intended source value.

  I'm attaching two hexdumps of the same destination area:

  - "good.txt" is a hexdump of the destination area when CopyMem() was
translated to x86_64,

  - "bad.txt" is a hexdump of the destination area when CopyMem() was
translated to ARMv7.

  In order to assist with the analysis of this issue, I disassembled the
  aarch64 binary with "objdump". Please find the listing in
  "DxeCore.objdump", attached. The InternalMemCopyMem() function starts at
  hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180.

  And, I ran the guest on the ARMv7 host with "-d
  in_asm,op,op_opt,op_ind,out_asm". Please find the log in
  "tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached.

  The TBs that correspond to (parts of) the InternalMemCopyMem() and
  __memcpy() functions are scattered over the TCG log file, but the offset
  between the "nice" disassembly from "DxeCore.objdump", and the in-RAM
  TBs in the TCG log, can be determined from the fact that there is a
  single prfm instruction in the entire binary. The instruction's offset
  is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy()
  function --, and its RAM address is 0x472d2180 in the TCG log. Thus the
  difference (= the load address of DxeCore.efi) is 0x472a7000.

  QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch
  'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21).

  The reproducer command line is (on an ARMv7 host):

qemu-system-aarch64 \
  -display none \
  -machine virt,accel=tcg \
  -nodefaults \
  -nographic \
  -drive 
if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \
  -drive 
if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \
  -cpu cortex-a57 \
  -chardev stdio,signal=off,mux=on,id=char0 \
  -mon chardev=char0,mode=readline \
  -serial chardev:char0

  The apparent symptom is an assertion failure *in the guest*, such as

  > ASSERT [DxeCore]
  > 
/home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090):
  > Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength

  but that is only a (distant) consequence of the CopyMem()
  mistranslation, and resultant destination area corruption.

  Originally reported in the following two mailing list messages:
  - 9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com">http://mid.mail-archive.com/9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com
  - f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com">http://mid.mail-archive.com/f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com

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

Re: [Qemu-devel] [PATCH v2] vfio/common: Introduce vfio_set_irq_signaling helper

[Alex Williamson]

On Mon, 27 May 2019 11:59:04 +0200
Eric Auger  wrote:

> The code used to assign an interrupt index/subindex to an
> eventfd is duplicated many times. Let's introduce an helper that
> allows to set/unset the signaling for an ACTION_TRIGGER,
> ACTION_MASK or ACTION_UNMASK action.
> 
> Signed-off-by: Eric Auger 
> 
> ---
> 
> v1 -> v2:
> - don't call GET_IRQ_INFO in vfio_set_irq_signaling()
>   and restore quiet check in vfio_register_req_notifier.
>   Nicer display of the IRQ name.

Hi Eric,

On this last item, it looks like irq_to_str() is now PCI specific, but
used generically.  Do you really want error messages with PCI interrupt
names on platform devices?  If we were to include PCI specific names,
we'd need to test the device is PCI or else default to simply printing
the index as you has previously.  Thanks,

Alex

> This is a follow-up to
> [PATCH v2 0/2] vfio-pci: Introduce vfio_set_event_handler().
> It looks to me that introducing vfio_set_irq_signaling() has more
> benefits in term of code reduction and the helper abstraction
> looks cleaner.
> ---
>  hw/vfio/common.c  |  78 
>  hw/vfio/pci.c | 217 --
>  hw/vfio/platform.c|  54 +++--
>  include/hw/vfio/vfio-common.h |   2 +
>  4 files changed, 150 insertions(+), 201 deletions(-)
> 
> diff --git a/hw/vfio/common.c b/hw/vfio/common.c
> index 4374cc6176..1f1deff360 100644
> --- a/hw/vfio/common.c
> +++ b/hw/vfio/common.c
> @@ -95,6 +95,84 @@ void vfio_mask_single_irqindex(VFIODevice *vbasedev, int 
> index)
>  ioctl(vbasedev->fd, VFIO_DEVICE_SET_IRQS, _set);
>  }
>  
> +static inline const char *action_to_str(int action)
> +{
> +switch (action) {
> +case VFIO_IRQ_SET_ACTION_MASK:
> +return "MASK";
> +case VFIO_IRQ_SET_ACTION_UNMASK:
> +return "UNMASK";
> +case VFIO_IRQ_SET_ACTION_TRIGGER:
> +return "TRIGGER";
> +default:
> +return "UNKNOWN ACTION";
> +}
> +}
> +
> +static char *irq_to_str(int index, int subindex)
> +{
> +char *str;
> +
> +switch (index) {
> +case VFIO_PCI_INTX_IRQ_INDEX:
> +str = g_strdup_printf("INTX-%d", subindex);
> +break;
> +case VFIO_PCI_MSI_IRQ_INDEX:
> +str = g_strdup_printf("MSI-%d", subindex);
> +break;
> +case VFIO_PCI_MSIX_IRQ_INDEX:
> +str = g_strdup_printf("MSIX-%d", subindex);
> +break;
> +case VFIO_PCI_ERR_IRQ_INDEX:
> +str = g_strdup_printf("ERR-%d", subindex);
> +break;
> +case VFIO_PCI_REQ_IRQ_INDEX:
> +str = g_strdup_printf("REQ-%d", subindex);
> +break;
> +default:
> +str = g_strdup_printf("index %d (unknown)", index);
> +break;
> +}
> +return str;
> +}
> +
> +int vfio_set_irq_signaling(VFIODevice *vbasedev, int index, int subindex,
> +   int action, int fd, Error **errp)
> +{
> +struct vfio_irq_set *irq_set;
> +int argsz, ret = 0;
> +int32_t *pfd;
> +char *irq_name;
> +
> +argsz = sizeof(*irq_set) + sizeof(*pfd);
> +
> +irq_set = g_malloc0(argsz);
> +irq_set->argsz = argsz;
> +irq_set->flags = VFIO_IRQ_SET_DATA_EVENTFD | action;
> +irq_set->index = index;
> +irq_set->start = subindex;
> +irq_set->count = 1;
> +pfd = (int32_t *)_set->data;
> +*pfd = fd;
> +
> +ret = ioctl(vbasedev->fd, VFIO_DEVICE_SET_IRQS, irq_set);
> +
> +g_free(irq_set);
> +
> +if (!ret) {
> +return 0;
> +}
> +
> +error_setg_errno(errp, -ret, "VFIO_DEVICE_SET_IRQS failure");
> +irq_name = irq_to_str(index, subindex);
> +error_prepend(errp,
> +  "Failed to %s %s eventfd signaling for interrupt %s: ",
> +  fd < 0 ? "tear down" : "set up", action_to_str(action),
> +  irq_name);
> +g_free(irq_name);
> +return ret;
> +}
> +
>  /*
>   * IO Port/MMIO - Beware of the endians, VFIO is always little endian
>   */
> diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> index 8cecb53d5c..e42901bd66 100644
> --- a/hw/vfio/pci.c
> +++ b/hw/vfio/pci.c
> @@ -113,9 +113,7 @@ static void vfio_intx_enable_kvm(VFIOPCIDevice *vdev, 
> Error **errp)
>  .gsi = vdev->intx.route.irq,
>  .flags = KVM_IRQFD_FLAG_RESAMPLE,
>  };
> -struct vfio_irq_set *irq_set;
> -int ret, argsz;
> -int32_t *pfd;
> +Error *err = NULL;
>  
>  if (vdev->no_kvm_intx || !kvm_irqfds_enabled() ||
>  vdev->intx.route.mode != PCI_INTX_ENABLED ||
> @@ -143,22 +141,10 @@ static void vfio_intx_enable_kvm(VFIOPCIDevice *vdev, 
> Error **errp)
>  goto fail_irqfd;
>  }
>  
> -argsz = sizeof(*irq_set) + sizeof(*pfd);
> -
> -irq_set = g_malloc0(argsz);
> -irq_set->argsz = argsz;
> -irq_set->flags = VFIO_IRQ_SET_DATA_EVENTFD | VFIO_IRQ_SET_ACTION_UNMASK;
> -irq_set->index = VFIO_PCI_INTX_IRQ_INDEX;
> -irq_set->start = 0;
> -irq_set->count = 1;
> -pfd = (int32_t *)_set->data;
> -

[Qemu-devel] [Bug 1831486] [NEW] qmp monitor deadlock (with spice events for ex)

[elmarco]

Public bug reported:

If an event is emitted during monitor_flush_locked() it will deadlock.

Thread 1 (Thread 0x7f14f1854000 (LWP 7245)):
#0  0x7f14fc30592d in __lll_lock_wait () at /lib64/libpthread.so.0
#1  0x7f14fc2fedc9 in pthread_mutex_lock () at /lib64/libpthread.so.0
#2  0x55de60e19327 in qemu_mutex_lock_impl (mutex=0x55de61859e58, 
file=0x55de60f1a640 "/home/elmarco/src/qq/monitor.c", line=438) at 
/home/elmarco/src/qq/util/qemu-thread-posix.c:66
#3  0x55de6085c5af in monitor_puts (mon=0x55de61859d30, str=0x55de62a61d30 
"{\"timestamp\": {\"seconds\": 1559585795, \"microseconds\": 508720}, 
\"event\": \"SPICE_DISCONNECTED\", \"data\": {\"server\": {\"port\": 
\"/tmp/.9IW52Z/spice.sock\", \"family\": \"unix\", \"host\": \"localhost\"}, 
\"client\": {"...) at /home/elmarco/src/qq/monitor.c:438
#4  0x55de6085c85a in qmp_send_response (mon=0x55de61859d30, 
rsp=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:493
#5  0x55de6085c8ee in monitor_qapi_event_emit 
(event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at 
/home/elmarco/src/qq/monitor.c:521
#6  0x55de6085c9ea in monitor_qapi_event_queue_no_reenter 
(event=QAPI_EVENT_SPICE_DISCONNECTED, qdict=0x55de61ed19a0) at 
/home/elmarco/src/qq/monitor.c:546
#7  0x55de6085cd7a in qapi_event_emit (event=QAPI_EVENT_SPICE_DISCONNECTED, 
qdict=0x55de61ed19a0) at /home/elmarco/src/qq/monitor.c:621
#8  0x55de60e04bc3 in qapi_event_send_spice_disconnected 
(server=0x55de61ee7b30, client=0x55de620c9090) at qapi/qapi-events-ui.c:101
#9  0x55de60c84381 in channel_event (event=3, info=0x55de6222f4c0) at 
/home/elmarco/src/qq/ui/spice-core.c:234
#10 0x7f14fc70ba3b in reds_handle_channel_event (reds=, 
event=3, info=0x55de6222f4c0) at reds.c:318
#11 0x7f14fc6f407b in main_dispatcher_self_handle_channel_event 
(info=0x55de6222f4c0, event=3, self=0x55de61a5b0b0) at main-dispatcher.c:191
#12 0x7f14fc6f407b in main_dispatcher_channel_event (self=0x55de61a5b0b0, 
event=event@entry=3, info=0x55de6222f4c0) at main-dispatcher.c:191
#13 0x7f14fc713cf3 in red_stream_push_channel_event 
(s=s@entry=0x55de6222f400, event=event@entry=3) at red-stream.c:416
#14 0x7f14fc713d2b in red_stream_free (s=0x55de6222f400) at red-stream.c:390
#15 0x7f14fc6fa67c in red_channel_client_finalize (object=0x55de62511360) 
at red-channel-client.c:347
#16 0x7f14fe4cfcf0 in g_object_unref () at /lib64/libgobject-2.0.so.0
#17 0x7f14fc6fca12 in red_channel_client_push (rcc=0x55de62511360) at 
red-channel-client.c:1340
#18 0x7f14fc6fca12 in red_channel_client_push (rcc=0x55de62511360) at 
red-channel-client.c:1303
#19 0x7f14fc6cd479 in red_char_device_send_msg_to_client (client=, msg=0x55de62512c00, dev=0x55de61a5b3b0) at char-device.c:307
#20 0x7f14fc6cd479 in red_char_device_send_msg_to_clients 
(msg=0x55de62512c00, dev=0x55de61a5b3b0) at char-device.c:307
#21 0x7f14fc6cd479 in red_char_device_read_from_device (dev=0x55de61a5b3b0) 
at char-device.c:355
#22 0x55de60a27dba in spice_chr_write (chr=0x55de61924c00, 
buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25) at 
/home/elmarco/src/qq/chardev/spice.c:201
#23 0x55de60d89e29 in qemu_chr_write_buffer (s=0x55de61924c00, 
buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25, 
offset=0x7ffcd5e1a860, write_all=false) at 
/home/elmarco/src/qq/chardev/char.c:113
#24 0x55de60d89f96 in qemu_chr_write (s=0x55de61924c00, buf=0x55de6236c070 
"{\"return\": {}, \"id\": 2}\r\n", len=25, write_all=false) at 
/home/elmarco/src/qq/chardev/char.c:148
#25 0x55de60d8cf78 in qemu_chr_fe_write (be=0x55de61859d30, 
buf=0x55de6236c070 "{\"return\": {}, \"id\": 2}\r\n", len=25) at 
/home/elmarco/src/qq/chardev/char-fe.c:42
#26 0x55de6085c40f in monitor_flush_locked (mon=0x55de61859d30) at 
/home/elmarco/src/qq/monitor.c:404
#27 0x55de6085c614 in monitor_puts (mon=0x55de61859d30, str=0x55de622f6a40 
"{\"return\": {}, \"id\": 2}\n") at /home/elmarco/src/qq/monitor.c:446
#28 0x55de6085c85a in qmp_send_response (mon=0x55de61859d30, 
rsp=0x55de61ecf960) at /home/elmarco/src/qq/monitor.c:493
#29 0x55de60865902 in monitor_qmp_respond (mon=0x55de61859d30, 
rsp=0x55de61ecf960) at /home/elmarco/src/qq/monitor.c:4128
#30 0x55de60865a19 in monitor_qmp_dispatch (mon=0x55de61859d30, 
req=0x55de622ec000) at /home/elmarco/src/qq/monitor.c:4157
#31 0x55de60865ce2 in monitor_qmp_bh_dispatcher (data=0x0) at 
/home/elmarco/src/qq/monitor.c:4224

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

Title:
  qmp monitor deadlock (with spice events for ex)

Status in QEMU:
  New

Bug description:
  If an event is emitted during monitor_flush_locked() it will deadlock.

  Thread 1 (Thread 0x7f14f1854000 (LWP 7245)):
  #0  0x7f14fc30592d in __lll_lock_wait () at /lib64/libpthread.so.0

Re: [Qemu-devel] Deprecation policy and build dependencies

[John Snow]

On 6/3/19 2:27 PM, Peter Maydell wrote:
> On Mon, 3 Jun 2019 at 19:21, John Snow  wrote:
>> I get it, we don't want to require Python 3.8 because some dev wanted
>> assignment conditionals -- but we're talking about Python 2 here, which
>> suffers its EOL by the end of this calendar year.
>>
>> So do we think it's reasonable to drop support for Python2 for the
>> release that comes out after Python2's EOL, or do we insist on 2x3
>> simultaneous support for years more?
> 
> I don't have a strong opinion on Python in particular, but
> I think it would be nicer to avoid the "python is a special
> snowflake" effect. Would it really be so bad for it to just
> be "drop it when it falls off the last LTS distro" like the
> rest of our dependencies ?
> 
> thanks
> -- PMM
> 

When it comes to supporting both 2 and 3 simultaneously yes; it's in my
opinion not trivial to maintain a growing testing and utility
infrastructure that works in versions as disparate as 2.7 and 3.7 from
RHEL7 all the way to Fedora 30. It's not going to get easier, either.
(Especially not after EOL.)

For comparison, at least when we target different versions of compilers,
we are at least targeting the same version of the language...

If you are running a stable or outdated distro and you want to build
bleeding edge QEMU and you cannot somehow find out how to get Python3 on
your machine after the official EOL of python2, I am not sure that
should become the developer's burden. I don't think we are being too
unreasonably avant-garde about adopting technologies that are too new.

--js

Re: [Qemu-devel] Deprecation policy and build dependencies

[John Snow]

On 6/3/19 2:17 PM, Peter Maydell wrote:
> On Mon, 3 Jun 2019 at 19:02, John Snow  wrote:
>> That policy strikes me as weird, because RHEL7 is not going to be, in
>> general, using the latest and greatest QEMU. Usually stable versions of
>> distros stick with the versions of the programs that came out at the time.
>>
>> What's the benefit of making sure that stable platforms can continue to
>> run the *newest* QEMU? Is this even a reasonable restriction? If you are
>> running RHEL7, how many projects do you expect to be able to git clone
>> and build and have that work with the rest of your legacy/stable
>> dependencies?
> 
> The benefit is that in general people who want to build QEMU
> from source can do so. I don't want us to be the kind of
> project that needs latest-and-greatest-foo for everything
> to build, because that sort of project is pretty infuriating
> to try to work with if you're an occasional contributor.
> "Builds on LTS distros" is an easy-to-express way to keep
> things from getting out of hand.
> 
> Plus a bunch of the build machines we do testing on are
> not running bleeding edge distros, and as Connie says plenty
> of developers do QEMU development on non-bleeding-edge versions
> (my primary dev box run an LTS Ubuntu).
> 

I get it, we don't want to require Python 3.8 because some dev wanted
assignment conditionals -- but we're talking about Python 2 here, which
suffers its EOL by the end of this calendar year.

So do we think it's reasonable to drop support for Python2 for the
release that comes out after Python2's EOL, or do we insist on 2x3
simultaneous support for years more?

--js

Re: [Qemu-devel] Deprecation policy and build dependencies

[Peter Maydell]

On Mon, 3 Jun 2019 at 19:02, John Snow  wrote:
> That policy strikes me as weird, because RHEL7 is not going to be, in
> general, using the latest and greatest QEMU. Usually stable versions of
> distros stick with the versions of the programs that came out at the time.
>
> What's the benefit of making sure that stable platforms can continue to
> run the *newest* QEMU? Is this even a reasonable restriction? If you are
> running RHEL7, how many projects do you expect to be able to git clone
> and build and have that work with the rest of your legacy/stable
> dependencies?

The benefit is that in general people who want to build QEMU
from source can do so. I don't want us to be the kind of
project that needs latest-and-greatest-foo for everything
to build, because that sort of project is pretty infuriating
to try to work with if you're an occasional contributor.
"Builds on LTS distros" is an easy-to-express way to keep
things from getting out of hand.

Plus a bunch of the build machines we do testing on are
not running bleeding edge distros, and as Connie says plenty
of developers do QEMU development on non-bleeding-edge versions
(my primary dev box run an LTS Ubuntu).

thanks
-- PMM

Re: [Qemu-devel] Deprecation policy and build dependencies

[Cornelia Huck]

On Mon, 3 Jun 2019 14:02:16 -0400
John Snow  wrote:

> On 6/3/19 8:26 AM, Markus Armbruster wrote:
> > John Snow  writes:
> >   
> >> On 5/31/19 3:24 PM, Eduardo Habkost wrote:  
> >>> Long story short: I would really like to drop support for Python
> >>> 2 in QEMU 4.1.  
> > 
> > The sooner, the better, as far as I'm concerned.
> >   
> >>> What exactly prevents us from doing this?  Does our deprecation
> >>> policy really apply to build dependencies?
> >>>  
> >>
> >> Normally I'd say it's only nice to also follow the depreciation policy
> >> for tooling as well to give people a chance to switch away, but with
> >> regards to Python2, I feel like we're in the clear to drop it for the
> >> first release that will happen after the Python2 doomsday clock.
> >>
> >> (So, probably 4.2.)  
> > 
> > In addition to our feature deprecation policity, we have a "Supported
> > build platforms" policy (commit 45b47130f4b).  The most common holdback
> > is this one:
> > 
> > For distributions with long-lifetime releases, the project will aim
> > to support the most recent major version at all times. Support for
> > the previous major version will be dropped 2 years after the new
> > major version is released. For the purposes of identifying supported
> > software versions, the project will look at RHEL, Debian, Ubuntu
> > LTS, and SLES distros. Other long-lifetime distros will be assumed
> > to ship similar software versions.
> > 
> > RHEL-7 has Python 3 only in EPEL.  RHEL-8 came out last month.  Unless
> > we interpret our policy to include EPEL, this means supporting Python 2
> > for some 16 months after upstream Python retires it.  My personal
> > opinion: nuts.
> >   
> 
> I would rather not support Python2 a day after the clock expires.
> 
> > I didn't bother checking Debian, Ubuntu LTS and SLES.
> > 
> > For hosts other than Linux, we're less ambitious.
> >   
> 
> That policy strikes me as weird, because RHEL7 is not going to be, in
> general, using the latest and greatest QEMU. Usually stable versions of
> distros stick with the versions of the programs that came out at the time.

I think the idea was that folks might actually develop on a 'stable'
distro (in a previous life, I used to complain quite often that
building QEMU on a stable distro broke... it was one of my main
development machines, but not controlled by me).

> 
> What's the benefit of making sure that stable platforms can continue to
> run the *newest* QEMU? Is this even a reasonable restriction? If you are
> running RHEL7, how many projects do you expect to be able to git clone
> and build and have that work with the rest of your legacy/stable
> dependencies?
> 
> RHEL7 uses a 1.5.3 based version. I don't think it matters if we update
> 4.2 to be Python3 only, really.

It depends on how old the distro is and what update policy it
uses... if parts of it are regularly updated, it might actually be
usable. In this case, I think we really need to interpret our policy
to include EPEL, or it is completely nuts.

Re: [Qemu-devel] [PATCH 2/2] target/arm: Use tcg_gen_gvec_bitsel

[Richard Henderson]

On 5/23/19 8:30 AM, Peter Maydell wrote:
> On Thu, 23 May 2019 at 14:16, Richard Henderson
>  wrote:
>>
>> On 5/23/19 9:08 AM, Peter Maydell wrote:
 Because the three different instructions perform the same operation with
 reshuffled register arguments.
>>>
>>> Ah, so they do. Next question, how do I find out what the
>>> order of arguments in the above code means so I can compare
>>> it against the pseudocode expression we're implementing?
>>
>> >From tcg/README:
>>
>> * bitsel_vec v0, v1, v2, v3
>>
>>   Bitwise select, v0 = (v2 & v1) | (v3 & ~v1), across the entire vector.
>>
>> The "selector" is second, the first input operand.
> 
> Oh, this series is based on another patchset.
> 
> Reviewed-by: Peter Maydell 

The prerequisite for this patch is now in master.


r~

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

[Laine Stump]

On 6/3/19 2:12 PM, Michael S. Tsirkin wrote:

On Mon, Jun 03, 2019 at 02:06:47PM -0400, Laine Stump wrote:

On 5/28/19 10:54 PM, Michael S. Tsirkin wrote:

On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote:



On 5/21/2019 11:49 AM, Jens Freimann wrote:

On Tue, May 21, 2019 at 07:37:19AM -0400, Michael S. Tsirkin wrote:

On Tue, May 21, 2019 at 09:21:57AM +0200, Jens Freimann wrote:

On Mon, May 20, 2019 at 04:56:57PM -0600, Alex Williamson wrote:



Actually is there a list of devices for which this has been tested
besides mlx5? I think someone said some old intel cards
don't support this well, we might need to blacklist these ...


So far I've tested mlx5 and XL710 which both worked, but I'm
working on testing with more devices. But of course help with testing
is greatly appreciated.


It won't work on Intel ixgbe and Broadcom bnxt_en, which requires toggling
the state of tap backing the virtio-net in order to release/reprogram MAC
filter. Actually, it's very few NICs that could work with this - even some
works by chance the behavior is undefined. Instead of blacklisting it makes
more sense to whitelist the NIC that supports it - with some new sysfs
attribute claiming the support presumably.

-Siwei


I agree for many cards we won't know how they behave until we try.  One
can consider this a bug in Linux that cards don't behave in a consistent
way.  The best thing to do IMHO would be to write a tool that people can
run to test the behaviour.


Is the "bad behavior" something due to the hardware of the cards, or their
drivers? If it's the latter, then at least initially having a whitelist
would be counterproductive, since it would make it difficult for relative
outsiders to test and report success/failure of various cards.


We can add an "ignore whitelist" flag. Would that address the issue?


It would be better than requiring a kernel/qemu recompile :-)


Where would the whilelist live? In qemu or in the kernel? It would be 
problematic to have the whitelist in qemu if kernel driver changes could 
fix a particular card.


Beyond that, what about *always* just issuing some sort of warning 
rather than completely forbidding a card that wasn't whitelisted? 
(Haven't decided if I like that better or not (and it probably doesn't 
matter, since I'm not a "real" user, but I thought I would mention it).

Re: [Qemu-devel] [PATCH 3/4] net/virtio: add failover support

[Laine Stump]

On 6/3/19 4:24 AM, Jens Freimann wrote:

On Fri, May 31, 2019 at 06:47:48PM -0300, Eduardo Habkost wrote:

On Thu, May 30, 2019 at 04:56:45PM +0200, Jens Freimann wrote:

On Tue, May 28, 2019 at 11:04:15AM -0400, Michael S. Tsirkin wrote:
> On Tue, May 21, 2019 at 10:45:05AM +0100, Dr. David Alan Gilbert 
wrote:

> > * Jens Freimann (jfreim...@redhat.com) wrote:

[...]

> > > +    }
> > > +    if (migration_in_setup(s) && !should_be_hidden && 
n->primary_dev) {

> > > +    qdev_unplug(n->primary_dev, );
> >
> > Not knowing unplug well; can you just explain - is that device hard
> > unplugged and it's gone by the time this function returns or is 
it still

> > hanging around for some indeterminate time?

Qemu will trigger an unplug request via pcie attention button in 
which case
there could be a delay by the guest operating system. We could give 
it some

amount of time and if nothing happens try surpise removal or handle the
error otherwise.


I'm missing something here:

Isn't the whole point of the new device-hiding infrastructure to
prevent QEMU from closing the VFIO until migration ended
successfully?


No. The point of hiding it is to only add the VFIO (that is configured
with the same MAC as the virtio-net device) until the
VIRTIO_NET_F_STANDBY feature is negotiated. We don't want to expose to
devices with the same MAC to guests who can't handle it.


What exactly is preventing QEMU from closing the host VFIO device
after the guest OS has handled the unplug request?


We qdev_unplug() the VFIO device and want the virtio-net standby device to
take over. If something goes wrong with unplug or
migration in general we have to qdev_plug() the device back.

This series does not try to implement new functionality to close a
device without freeing the resources.

 From the discussion in this thread I understand that is what libvirt
needs though. Something that will trigger the unplug from the
guest but not free the devices resources in the host system (which is
what qdev_unplug() does). Correct?
Why is it bad to fully re-create the device in case of a failed migration?


I think the concern is that if the device was fully released by qemu 
during migration, it might have already been given to some other/new 
guest during the time that migration is trying to complete. If migration 
then fails, you may be unable to restore the guest to the previous state.

Re: [Qemu-devel] [PULL 00/24] Misc patches for 2019-06-03

[Peter Maydell]

On Mon, 3 Jun 2019 at 18:12, Paolo Bonzini  wrote:
>
> The following changes since commit ad88e4252f09c2956b99c90de39e95bab2e8e7af:
>
>   Merge remote-tracking branch 'remotes/amarkovic/tags/mips-queue-jun-1-2019' 
> into staging (2019-06-03 10:25:12 +0100)
>
> are available in the git repository at:
>
>
>   git://github.com/bonzini/qemu.git tags/for-upstream
>
> for you to fetch changes up to c87759ce876a7a0b17c2bf4f0b964bd51f0ee871:
>
>   q35: Revert to kernel irqchip (2019-06-03 14:03:03 +0200)
>
> 
> * Revert q35 to kernel irqchip (Alex)
> * edu device fixes (Li Qiang)
> * cleanups (Marc-André, Peter)
> * Improvements to -accel help
> * Better support for IA32_MISC_ENABLE MSR (Wanpeng)
> * I2C test conversion to qgraph (Paolo)
>
> 


Applied, thanks.

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

-- PMM

Re: [Qemu-devel] [PATCH v2 0/2] Add QMP lexer for annotated JSON to Sphinx

[John Snow]

Peter: I think this one would be through your tree if anyone's, yes? Any
thoughts?

--js

On 5/23/19 8:12 AM, John Snow wrote:
> QMP isn't json. It turns out Pygments cares about this.
> Teach Pygments to go with the annotated flow.
> 
> V2:
>  - Change GPL2 to GPLv2+ (Peter Maydell)
>  - Change "highlights" to "lexes" in docstrings
>  - Fix typo ("Sphinx()" => "Sphinx") in docstring
> 
> Reported-by: Aarushi Mehta 
> 
> John Snow (2):
>   sphinx: add qmp_lexer
>   docs/bitmaps: use QMP lexer instead of json
> 
>  docs/conf.py |  4 +--
>  docs/interop/bitmaps.rst | 54 
>  docs/sphinx/qmp_lexer.py | 34 +
>  3 files changed, 63 insertions(+), 29 deletions(-)
>  create mode 100644 docs/sphinx/qmp_lexer.py
> 

[Qemu-devel] [PULL v2 14/14] bios-tables-test: list all tables that differ

[Michael S. Tsirkin]

Fail after comparing all tables: this way
user gets the full list of tables that need
to be updated or whitelisted.

Signed-off-by: Michael S. Tsirkin 
---
 tests/bios-tables-test.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 28d7d427e0..70895e1014 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -364,7 +364,7 @@ static void test_acpi_asl(test_data *data)
 int i;
 AcpiSdtTable *sdt, *exp_sdt;
 test_data exp_data;
-gboolean exp_err, err;
+gboolean exp_err, err, all_tables_match = true;
 
 memset(_data, 0, sizeof(exp_data));
 exp_data.tables = load_expected_aml(data);
@@ -413,11 +413,13 @@ static void test_acpi_asl(test_data *data)
 }
 }
 }
-g_assert(test_acpi_find_diff_allowed(exp_sdt));
+all_tables_match = all_tables_match &&
+test_acpi_find_diff_allowed(exp_sdt);
 }
 g_string_free(asl, true);
 g_string_free(exp_asl, true);
 }
+g_assert(all_tables_match);
 
 free_test_data(_data);
 }
-- 
MST

[Qemu-devel] [PULL v2 13/14] vhost-scsi: Allow user to enable migration

[Michael S. Tsirkin]

From: Liran Alon 

In order to perform a valid migration of a vhost-scsi device,
the following requirements must be met:
(1) The virtio-scsi device state needs to be saved & loaded.
(2) The vhost backend must be stopped before virtio-scsi device state
is saved:
  (2.1) Sync vhost backend state to virtio-scsi device state.
  (2.2) No further I/O requests are made by vhost backend to target
SCSI device.
  (2.3) No further guest memory access takes place after VM is stopped.
(3) Requests in-flight to target SCSI device are completed before
migration handover.
(4) Target SCSI device state needs to be saved & loaded into the
destination host target SCSI device.

Previous commit ("vhost-scsi: Add VMState descriptor")
add support to save & load the device state using VMState.
This meets requirement (1).

When VM is stopped by migration thread (On Pre-Copy complete), the
following code path is executed:
migration_completion() -> vm_stop_force_state() -> vm_stop() ->
do_vm_stop().

do_vm_stop() calls first pause_all_vcpus() which pause all guest
vCPUs and then call vm_state_notify().
In case of vhost-scsi device, this will lead to the following code path
to be executed:
vm_state_notify() -> virtio_vmstate_change() ->
virtio_set_status() -> vhost_scsi_set_status() -> vhost_scsi_stop().
vhost_scsi_stop() then calls vhost_scsi_clear_endpoint() and
vhost_scsi_common_stop().

vhost_scsi_clear_endpoint() sends VHOST_SCSI_CLEAR_ENDPOINT ioctl to
vhost backend which will reach kernel's vhost_scsi_clear_endpoint()
which process all pending I/O requests and wait for them to complete
(vhost_scsi_flush()). This meets requirement (3).

vhost_scsi_common_stop() will stop the vhost backend.
As part of this stop, dirty-bitmap is synced and vhost backend state is
synced with virtio-scsi device state. As at this point guest vCPUs are
already paused, this meets requirement (2).

At this point we are left with requirement (4) which is target SCSI
device specific and therefore cannot be done by QEMU. Which is the main
reason why vhost-scsi adds a migration blocker.
However, as this can be handled either by an external orchestrator or
by using shared-storage (i.e. iSCSI), there is no reason to limit the
orchestrator from being able to explictly specify it wish to enable
migration even when VM have a vhost-scsi device.

Considering all the above, this commit allows orchestrator to explictly
specify that it is responsbile for taking care of requirement (4) and
therefore vhost-scsi should not add a migration blocker.

Reviewed-by: Nir Weiner 
Reviewed-by: Bijan Mottahedeh 
Signed-off-by: Liran Alon 
Message-Id: <20190416125912.44001-4-liran.a...@oracle.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Stefan Hajnoczi 
---
 include/hw/virtio/vhost-scsi-common.h |  1 +
 hw/scsi/vhost-scsi.c  | 30 ++-
 2 files changed, 21 insertions(+), 10 deletions(-)

diff --git a/include/hw/virtio/vhost-scsi-common.h 
b/include/hw/virtio/vhost-scsi-common.h
index 57fb1d87b5..4eab767ee8 100644
--- a/include/hw/virtio/vhost-scsi-common.h
+++ b/include/hw/virtio/vhost-scsi-common.h
@@ -36,6 +36,7 @@ typedef struct VHostSCSICommon {
 int target;
 int lun;
 uint64_t host_features;
+bool migratable;
 } VHostSCSICommon;
 
 int vhost_scsi_common_start(VHostSCSICommon *vsc);
diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index eb0cf9e131..6b01accf61 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -199,13 +199,18 @@ static void vhost_scsi_realize(DeviceState *dev, Error 
**errp)
 goto close_fd;
 }
 
-error_setg(>migration_blocker,
-   "vhost-scsi does not support migration");
-migrate_add_blocker(vsc->migration_blocker, );
-if (err) {
-error_propagate(errp, err);
-error_free(vsc->migration_blocker);
-goto close_fd;
+if (!vsc->migratable) {
+error_setg(>migration_blocker,
+"vhost-scsi does not support migration in all cases. "
+"When external environment supports it (Orchestrator migrates "
+"target SCSI device state or use shared storage over network), 
"
+"set 'migratable' property to true to enable migration.");
+migrate_add_blocker(vsc->migration_blocker, );
+if (err) {
+error_propagate(errp, err);
+error_free(vsc->migration_blocker);
+goto close_fd;
+}
 }
 
 vsc->dev.nvqs = VHOST_SCSI_VQ_NUM_FIXED + vs->conf.num_queues;
@@ -230,7 +235,9 @@ static void vhost_scsi_realize(DeviceState *dev, Error 
**errp)
 return;
 
  free_vqs:
-migrate_del_blocker(vsc->migration_blocker);
+if (!vsc->migratable) {
+migrate_del_blocker(vsc->migration_blocker);
+}
 g_free(vsc->dev.vqs);
  close_fd:
 close(vhostfd);
@@ -243,8 +250,10 @@ static void vhost_scsi_unrealize(DeviceState *dev, Error 
**errp)
 

[Qemu-devel] [PULL v2 11/14] vhost-scsi: The vhost backend should be stopped when the VM is not running

[Michael S. Tsirkin]

From: Nir Weiner 

vhost-scsi doesn’t takes into account whether the VM is running or not in
order to decide if it should start/stop vhost backend.
This would lead to vhost backend still being active when VM's RunState
suddenly change to stopped.

An example of when this issue is encountered is when Live-Migration Pre-Copy
phase completes. As in this case, VM state will be changed to stopped (while
vhost backend is still active), which will result in
virtio_vmstate_change() -> virtio_set_status() -> vhost_scsi_set_status()
executed but vhost_scsi_set_status() will just return without stopping
vhost backend.

To handle this, change code to consider that vhost processing should be
stopped when VM is not running. Similar to how it is done in vhost-vsock
device at vhost_vsock_set_status().

Fixes: 5e9be92d7752 ("vhost-scsi: new device supporting the tcm_vhost Linux 
kernel module”)
Reviewed-by: Bijan Mottahedeh 
Reviewed-by: Liran Alon 
Signed-off-by: Nir Weiner 
Message-Id: <20190416125912.44001-2-liran.a...@oracle.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Stefan Hajnoczi 
---
 hw/scsi/vhost-scsi.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index 61e2e57da9..ca42cff1b9 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -114,6 +114,10 @@ static void vhost_scsi_set_status(VirtIODevice *vdev, 
uint8_t val)
 VHostSCSICommon *vsc = VHOST_SCSI_COMMON(s);
 bool start = (val & VIRTIO_CONFIG_S_DRIVER_OK);
 
+if (!vdev->vm_running) {
+start = false;
+}
+
 if (vsc->dev.started == start) {
 return;
 }
-- 
MST

[Qemu-devel] [PULL v2 12/14] vhost-scsi: Add VMState descriptor

[Michael S. Tsirkin]

From: Nir Weiner 

As preparation of enabling migration of vhost-scsi device,
define it’s VMState. Note, we keep the convention of
verifying in the pre_save() method that the vhost backend
must be stopped before attempting to save the device
state. Similar to how it is done for vhost-vsock.

Reviewed-by: Bijan Mottahedeh 
Reviewed-by: Liran Alon 
Signed-off-by: Nir Weiner 
Message-Id: <20190416125912.44001-3-liran.a...@oracle.com>
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 
Reviewed-by: Stefan Hajnoczi 
---
 hw/scsi/vhost-scsi.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/hw/scsi/vhost-scsi.c b/hw/scsi/vhost-scsi.c
index ca42cff1b9..eb0cf9e131 100644
--- a/hw/scsi/vhost-scsi.c
+++ b/hw/scsi/vhost-scsi.c
@@ -139,6 +139,28 @@ static void vhost_dummy_handle_output(VirtIODevice *vdev, 
VirtQueue *vq)
 {
 }
 
+static int vhost_scsi_pre_save(void *opaque)
+{
+VHostSCSICommon *vsc = opaque;
+
+/* At this point, backend must be stopped, otherwise
+ * it might keep writing to memory. */
+assert(!vsc->dev.started);
+
+return 0;
+}
+
+static const VMStateDescription vmstate_virtio_vhost_scsi = {
+.name = "virtio-vhost_scsi",
+.minimum_version_id = 1,
+.version_id = 1,
+.fields = (VMStateField[]) {
+VMSTATE_VIRTIO_DEVICE,
+VMSTATE_END_OF_LIST()
+},
+.pre_save = vhost_scsi_pre_save,
+};
+
 static void vhost_scsi_realize(DeviceState *dev, Error **errp)
 {
 VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(dev);
@@ -256,6 +278,7 @@ static void vhost_scsi_class_init(ObjectClass *klass, void 
*data)
 FWPathProviderClass *fwc = FW_PATH_PROVIDER_CLASS(klass);
 
 dc->props = vhost_scsi_properties;
+dc->vmsd = _virtio_vhost_scsi;
 set_bit(DEVICE_CATEGORY_STORAGE, dc->categories);
 vdc->realize = vhost_scsi_realize;
 vdc->unrealize = vhost_scsi_unrealize;
-- 
MST

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

[Michael S. Tsirkin]

On Mon, Jun 03, 2019 at 02:06:47PM -0400, Laine Stump wrote:
> On 5/28/19 10:54 PM, Michael S. Tsirkin wrote:
> > On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote:
> > > 
> > > 
> > > On 5/21/2019 11:49 AM, Jens Freimann wrote:
> > > > On Tue, May 21, 2019 at 07:37:19AM -0400, Michael S. Tsirkin wrote:
> > > > > On Tue, May 21, 2019 at 09:21:57AM +0200, Jens Freimann wrote:
> > > > > > On Mon, May 20, 2019 at 04:56:57PM -0600, Alex Williamson wrote:
> 
> > > > > Actually is there a list of devices for which this has been tested
> > > > > besides mlx5? I think someone said some old intel cards
> > > > > don't support this well, we might need to blacklist these ...
> > > > 
> > > > So far I've tested mlx5 and XL710 which both worked, but I'm
> > > > working on testing with more devices. But of course help with testing
> > > > is greatly appreciated.
> >>
> > > It won't work on Intel ixgbe and Broadcom bnxt_en, which requires toggling
> > > the state of tap backing the virtio-net in order to release/reprogram MAC
> > > filter. Actually, it's very few NICs that could work with this - even some
> > > works by chance the behavior is undefined. Instead of blacklisting it 
> > > makes
> > > more sense to whitelist the NIC that supports it - with some new sysfs
> > > attribute claiming the support presumably.
> > > 
> > > -Siwei
> > 
> > I agree for many cards we won't know how they behave until we try.  One
> > can consider this a bug in Linux that cards don't behave in a consistent
> > way.  The best thing to do IMHO would be to write a tool that people can
> > run to test the behaviour.
> 
> Is the "bad behavior" something due to the hardware of the cards, or their
> drivers? If it's the latter, then at least initially having a whitelist
> would be counterproductive, since it would make it difficult for relative
> outsiders to test and report success/failure of various cards.

We can add an "ignore whitelist" flag. Would that address the issue?

> (It's probably just a pipe dream, but it would be nice if it eventually
> could work with old igb cards - I have several of them that I use for SRIOV
> testing, and would rather avoid having to buy new hardware.)

I think it generally can be worked around in the driver.
Most host drivers do get a notification when guest driver
loads/unloads and can use that to manipulate the on-device
switch.

-- 
MST

[Qemu-devel] [PULL v2 10/14] bios-tables-test: add diff allowed list

[Michael S. Tsirkin]

Expected table change is then handled like this:
1. add table to diff allowed list
2. change generating code (can be combined with 1)
3. maintainer runs a script to update expected +
   blows away allowed diff list

Signed-off-by: Michael S. Tsirkin 
---
 tests/bios-tables-test-allowed-diff.h |  1 +
 tests/bios-tables-test.c  | 19 ++-
 2 files changed, 19 insertions(+), 1 deletion(-)
 create mode 100644 tests/bios-tables-test-allowed-diff.h

diff --git a/tests/bios-tables-test-allowed-diff.h 
b/tests/bios-tables-test-allowed-diff.h
new file mode 100644
index 00..dfb8523c8b
--- /dev/null
+++ b/tests/bios-tables-test-allowed-diff.h
@@ -0,0 +1 @@
+/* List of comma-separated changed AML files to ignore */
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 11e07be093..28d7d427e0 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -342,6 +342,22 @@ try_again:
 return exp_tables;
 }
 
+static bool test_acpi_find_diff_allowed(AcpiSdtTable *sdt)
+{
+const gchar *allowed_diff_file[] = {
+#include "bios-tables-test-allowed-diff.h"
+NULL
+};
+const gchar **f;
+
+for (f = allowed_diff_file; *f; ++f) {
+if (!g_strcmp0(sdt->aml_file, *f)) {
+return true;
+}
+}
+return false;
+}
+
 /* test the list of tables in @data->tables against reference tables */
 static void test_acpi_asl(test_data *data)
 {
@@ -396,7 +412,8 @@ static void test_acpi_asl(test_data *data)
 "see ASL difference.");
 }
 }
-  }
+}
+g_assert(test_acpi_find_diff_allowed(exp_sdt));
 }
 g_string_free(asl, true);
 g_string_free(exp_asl, true);
-- 
MST

[Qemu-devel] [PULL v2 00/14] virtio, pci, pc: cleanups, features

[Michael S. Tsirkin]

The following changes since commit 8c1ecb590497b0349c550607db923972b37f6963:

  Merge remote-tracking branch 
'remotes/stsquad/tags/pull-testing-next-280519-2' into staging (2019-05-28 
17:38:32 +0100)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream

for you to fetch changes up to df7cafdeb68b6572fa81d2be9a1910547c4dfafc:

  bios-tables-test: list all tables that differ (2019-06-03 08:05:43 -0400)


virtio, pci, pc: cleanups, features

stricter rules for acpi tables: we now fail
on any difference that isn't whitelisted.

vhost-scsi migration.

some cleanups all over the place

Signed-off-by: Michael S. Tsirkin 


David Gibson (3):
  pcie: Simplify pci_adjust_config_limit()
  pci: Make is_bridge a bool
  pci: Fold pci_get_bus_devfn() into its sole caller

Igor Mammedov (1):
  docs: smbios: remove family=x from type2 entry description

Jie Wang (3):
  vhost: remove the dead code
  vhost: fix incorrect print type
  vhost: fix memory leak in vhost_user_scsi_realize

Liran Alon (1):
  vhost-scsi: Allow user to enable migration

Michael S. Tsirkin (2):
  bios-tables-test: add diff allowed list
  bios-tables-test: list all tables that differ

Nir Weiner (2):
  vhost-scsi: The vhost backend should be stopped when the VM is not running
  vhost-scsi: Add VMState descriptor

Wei Yang (2):
  hw/acpi: Consolidate build_mcfg to pci.c
  acpi: pci: use build_append_foo() API to construct MCFG

 default-configs/i386-softmmu.mak  |   1 +
 include/hw/acpi/acpi-defs.h   |  18 --
 include/hw/acpi/pci.h |   1 +
 include/hw/pci/pci.h  |   3 +-
 include/hw/pci/pci_bus.h  |   8 ++-
 include/hw/virtio/vhost-scsi-common.h |   1 +
 tests/bios-tables-test-allowed-diff.h |   1 +
 hw/acpi/pci.c |  61 
 hw/arm/virt-acpi-build.c  |  17 --
 hw/i386/acpi-build.c  |  18 +-
 hw/pci-bridge/dec.c   |   4 +-
 hw/pci-bridge/i82801b11.c |   2 +-
 hw/pci-bridge/pci_bridge_dev.c|   2 +-
 hw/pci-bridge/pcie_pci_bridge.c   |   2 +-
 hw/pci-bridge/pcie_root_port.c|   2 +-
 hw/pci-bridge/simba.c |   2 +-
 hw/pci-bridge/xio3130_downstream.c|   2 +-
 hw/pci-bridge/xio3130_upstream.c  |   2 +-
 hw/pci/pci.c  | 101 +-
 hw/pci/pci_host.c |  13 +
 hw/ppc/spapr_pci.c|  34 
 hw/scsi/vhost-scsi.c  |  57 +++
 hw/scsi/vhost-user-scsi.c |   3 +
 hw/virtio/vhost.c |   3 +-
 tests/bios-tables-test.c  |  23 +++-
 hw/acpi/Kconfig   |   4 ++
 hw/acpi/Makefile.objs |   1 +
 hw/arm/Kconfig|   1 +
 qemu-options.hx   |   2 +-
 29 files changed, 226 insertions(+), 163 deletions(-)
 create mode 100644 tests/bios-tables-test-allowed-diff.h
 create mode 100644 hw/acpi/pci.c

Re: [Qemu-devel] [PATCH 0/4] add failover feature for assigned network devices

[Laine Stump]

On 5/28/19 10:54 PM, Michael S. Tsirkin wrote:

On Tue, May 28, 2019 at 05:14:22PM -0700, si-wei liu wrote:



On 5/21/2019 11:49 AM, Jens Freimann wrote:

On Tue, May 21, 2019 at 07:37:19AM -0400, Michael S. Tsirkin wrote:

On Tue, May 21, 2019 at 09:21:57AM +0200, Jens Freimann wrote:

On Mon, May 20, 2019 at 04:56:57PM -0600, Alex Williamson wrote:



Actually is there a list of devices for which this has been tested
besides mlx5? I think someone said some old intel cards
don't support this well, we might need to blacklist these ...


So far I've tested mlx5 and XL710 which both worked, but I'm
working on testing with more devices. But of course help with testing
is greatly appreciated.

>>

It won't work on Intel ixgbe and Broadcom bnxt_en, which requires toggling
the state of tap backing the virtio-net in order to release/reprogram MAC
filter. Actually, it's very few NICs that could work with this - even some
works by chance the behavior is undefined. Instead of blacklisting it makes
more sense to whitelist the NIC that supports it - with some new sysfs
attribute claiming the support presumably.

-Siwei


I agree for many cards we won't know how they behave until we try.  One
can consider this a bug in Linux that cards don't behave in a consistent
way.  The best thing to do IMHO would be to write a tool that people can
run to test the behaviour.


Is the "bad behavior" something due to the hardware of the cards, or 
their drivers? If it's the latter, then at least initially having a 
whitelist would be counterproductive, since it would make it difficult 
for relative outsiders to test and report success/failure of various cards.


(It's probably just a pipe dream, but it would be nice if it eventually 
could work with old igb cards - I have several of them that I use for 
SRIOV testing, and would rather avoid having to buy new hardware.)

Re: [Qemu-devel] Deprecation policy and build dependencies

[John Snow]

On 6/3/19 8:26 AM, Markus Armbruster wrote:
> John Snow  writes:
> 
>> On 5/31/19 3:24 PM, Eduardo Habkost wrote:
>>> Long story short: I would really like to drop support for Python
>>> 2 in QEMU 4.1.
> 
> The sooner, the better, as far as I'm concerned.
> 
>>> What exactly prevents us from doing this?  Does our deprecation
>>> policy really apply to build dependencies?
>>>
>>
>> Normally I'd say it's only nice to also follow the depreciation policy
>> for tooling as well to give people a chance to switch away, but with
>> regards to Python2, I feel like we're in the clear to drop it for the
>> first release that will happen after the Python2 doomsday clock.
>>
>> (So, probably 4.2.)
> 
> In addition to our feature deprecation policity, we have a "Supported
> build platforms" policy (commit 45b47130f4b).  The most common holdback
> is this one:
> 
> For distributions with long-lifetime releases, the project will aim
> to support the most recent major version at all times. Support for
> the previous major version will be dropped 2 years after the new
> major version is released. For the purposes of identifying supported
> software versions, the project will look at RHEL, Debian, Ubuntu
> LTS, and SLES distros. Other long-lifetime distros will be assumed
> to ship similar software versions.
> 
> RHEL-7 has Python 3 only in EPEL.  RHEL-8 came out last month.  Unless
> we interpret our policy to include EPEL, this means supporting Python 2
> for some 16 months after upstream Python retires it.  My personal
> opinion: nuts.
> 

I would rather not support Python2 a day after the clock expires.

> I didn't bother checking Debian, Ubuntu LTS and SLES.
> 
> For hosts other than Linux, we're less ambitious.
> 

That policy strikes me as weird, because RHEL7 is not going to be, in
general, using the latest and greatest QEMU. Usually stable versions of
distros stick with the versions of the programs that came out at the time.

What's the benefit of making sure that stable platforms can continue to
run the *newest* QEMU? Is this even a reasonable restriction? If you are
running RHEL7, how many projects do you expect to be able to git clone
and build and have that work with the rest of your legacy/stable
dependencies?

RHEL7 uses a 1.5.3 based version. I don't think it matters if we update
4.2 to be Python3 only, really.

Re: [Qemu-devel] [PULL 22/27] vl: Create block backends before setting machine properties

[Markus Armbruster]

I apologize for the delay, got distracted.

Michal Privoznik  writes:

> On 5/16/19 1:43 PM, Markus Armbruster wrote:
> 
>
>>> Actually, there is more problems with this. Trying to run a guest with
>>> persistent reservations fails after this patch is applied (git bisect
>>> points me to this commit). My command line is:
>>>
>>> qemu.git $ ./x86_64-softmmu/qemu-system-x86_64 \
>>> -monitor stdio \
>>> -object pr-manager-helper,id=pr-helper0,path=/tmp/pr-helper0.sock
>>> -drive
>>> file=/dev/mapper/crypt,file.pr-manager=pr-helper0,format=raw,if=none,id=drive-scsi0-0-0-2
>>> \
>>> -device
>>> scsi-block,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2
>>>
>>> Honestly, I have no idea how to fix it, so I'm just raising this issue
>>> here. Do you want me to open a bug or something?
>>
>> Let's skip the bug filing bureaucracy and go straight to debugging.
>
> Agreed.
>
>>
>> Actual and expected behavior of your reproducer, please :)
>>
>
> Actual is that qemu fails to parse cmd line:
>
>
> qemu-system-x86_64: -drive
> file=/dev/mapper/crypt,file.pr-manager=pr-helper0,format=raw,if=none,id=drive-scsi0-0-0-2:
> No persistent reservation manager with id 'pr-helper0'
>
>
> Which obviously is not correct, because pr-helper0 is specified.
> Expected result is that qemu suceeds in parsing the cmd line and
> starts the guest. To test it you don't need /dev/mapper/* really, I
> mean, if qemu fails with a different error message (e.g. it can't open
> the disk or EPERM or whatever), it's a sign it got past the cmd line
> parsing successfuly.

Reproduced, thanks!

Here's what happens.  Our general problem is that qemu-system-FOO's
main() acts on command line arguments in its own idiosyncratic order.
There's not much method to its madness.  Whenever we find a case where
one kind of command line argument needs to refer to something created
for another kind later, we rejigger the order.

Some time back, Dan Berrangé ran into an "impossible" instance of this
general problem: some kinds of -object get referenced by certain
character devices (therefore, -object must be acted on before character
devices), but other kinds of -object reference other character devices
(therefore, -object must be acted on after character devices).  He
solved the problem by sorting the -object into two buckets (commit
f08f9271bfe):

* Normal ones are created pretty early, so they can be referenced by
  (most) other things.

* Delayed ones are created pretty late, so they can reference (most)
  other things.

The pr-manager-helper object is a delayed one (commit 7c9e527659c).

Worked because block backends got created even after delayed objects:

qemu_opts_foreach(qemu_find_opts("object"),
  user_creatable_add_opts_foreach,
  object_create_initial, _fatal);
[...]
qemu_opts_foreach(qemu_find_opts("object"),
  user_creatable_add_opts_foreach,
  object_create_delayed, _fatal);
[...]
configure_blockdev(_queue, machine_class, snapshot);

Commit cda4aa9a5a0 moved the configure_blockdev() up:

qemu_opts_foreach(qemu_find_opts("object"),
  user_creatable_add_opts_foreach,
  object_create_initial, _fatal);
[...]
/*
 * Note: we need to create block backends before
 * machine_set_property(), so machine properties can refer to
 * them.
 */
configure_blockdev(_queue, machine_class, snapshot);
[...]
qemu_opts_foreach(qemu_find_opts("object"),
  user_creatable_add_opts_foreach,
  object_create_delayed, _fatal);

Now file-posix property "pr-manager" can no longer reference a
pr-manager-helper object.  Regression.

If I make pr-manager-helper a normal object, it again can reference it.

Paolo, why is pr-manager-helper a delayed object?  Why this hunk of
commit 7c9e527659c:

diff --git a/vl.c b/vl.c
index 9bb5058c3a..a121a65731 100644
--- a/vl.c
+++ b/vl.c
@@ -2893,7 +2893,8 @@ static int machine_set_property(void *opaque,
  */
 static bool object_create_initial(const char *type)
 {
-if (g_str_equal(type, "rng-egd")) {
+if (g_str_equal(type, "rng-egd") ||
+g_str_has_prefix(type, "pr-manager-")) {
 return false;
 }

[Qemu-devel] qemu build error with latest kernel headers due to net: socket: implement 64-bit timestamps

[Christian Borntraeger]

Arnd,

with kernel headers from the latest kernel QEMU fails to build if the user run
configure with --target-list=s390x-linux-user:

when the kernel has commit 0768e17073dc527ccd18ed5f96ce85f9985e9115
net: socket: implement 64-bit timestamps 



/root/rpmbuild/BUILD/qemu-4.0.50/linux-user/ioctls.h:222:9: error: 'SIOCGSTAMP' 
undeclared here (not in a function); did you mean 'SIOCSRARP'?
  222 |   IOCTL(SIOCGSTAMP, IOC_R, MK_PTR(MK_STRUCT(STRUCT_timeval)))
  | ^~

It seems that qemu build relies on SIOCGSTAMP to be present via sys/socket.h.

Adding this patch to qemu helps.

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index efa3ec2837..7332be9b06 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

But it is also a change in behavior of the kernel headers. (but only for 
programs that
use sys/socket.h instead of linux/sockios.h.

[Qemu-devel] [Bug 1830872] Re: AARCH64 to ARMv7 mistranslation in TCG

[Andrew Randrianasulu]

** Attachment added: "bzImage-4.12.0-x64"
   
https://bugs.launchpad.net/bugs/1830872/+attachment/5268560/+files/bzImage-4.12.0-x64

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

Title:
  AARCH64 to ARMv7 mistranslation in TCG

Status in QEMU:
  New

Bug description:
  The following guest code:

  
https://github.com/tianocore/edk2/blob/3604174718e2afc950c3cc64c64ba5165c8692bd/MdePkg/Library/BaseMemoryLibOptDxe/AArch64/CopyMem.S

  implements, in hand-optimized aarch64 assembly, the CopyMem() edk2 (EFI
  Development Kit II) library function. (CopyMem() basically has memmove()
  semantics, to provide a standard C analog here.) The relevant functions
  are InternalMemCopyMem() and __memcpy().

  When TCG translates this aarch64 code to x86_64, everything works
  fine.

  When TCG translates this aarch64 code to ARMv7, the destination area of
  the translated CopyMem() function becomes corrupted -- it differs from
  the intended source contents. Namely, in every 4096 byte block, the
  8-byte word at offset 4032 (0xFC0) is zeroed out in the destination,
  instead of receiving the intended source value.

  I'm attaching two hexdumps of the same destination area:

  - "good.txt" is a hexdump of the destination area when CopyMem() was
translated to x86_64,

  - "bad.txt" is a hexdump of the destination area when CopyMem() was
translated to ARMv7.

  In order to assist with the analysis of this issue, I disassembled the
  aarch64 binary with "objdump". Please find the listing in
  "DxeCore.objdump", attached. The InternalMemCopyMem() function starts at
  hex offset 2b2ec. The __memcpy() function starts at hex offset 2b180.

  And, I ran the guest on the ARMv7 host with "-d
  in_asm,op,op_opt,op_ind,out_asm". Please find the log in
  "tcg.in_asm.op.op_opt.op_ind.out_asm.log", attached.

  The TBs that correspond to (parts of) the InternalMemCopyMem() and
  __memcpy() functions are scattered over the TCG log file, but the offset
  between the "nice" disassembly from "DxeCore.objdump", and the in-RAM
  TBs in the TCG log, can be determined from the fact that there is a
  single prfm instruction in the entire binary. The instruction's offset
  is 0x2b180 in "DxeCore.objdump" -- at the beginning of the __memcpy()
  function --, and its RAM address is 0x472d2180 in the TCG log. Thus the
  difference (= the load address of DxeCore.efi) is 0x472a7000.

  QEMU was built at commit a4f667b67149 ("Merge remote-tracking branch
  'remotes/cohuck/tags/s390x-20190521-3' into staging", 2019-05-21).

  The reproducer command line is (on an ARMv7 host):

qemu-system-aarch64 \
  -display none \
  -machine virt,accel=tcg \
  -nodefaults \
  -nographic \
  -drive 
if=pflash,format=raw,file=$prefix/share/qemu/edk2-aarch64-code.fd,readonly \
  -drive 
if=pflash,format=raw,file=$prefix/share/qemu/edk2-arm-vars.fd,snapshot=on \
  -cpu cortex-a57 \
  -chardev stdio,signal=off,mux=on,id=char0 \
  -mon chardev=char0,mode=readline \
  -serial chardev:char0

  The apparent symptom is an assertion failure *in the guest*, such as

  > ASSERT [DxeCore]
  > 
/home/lacos/src/upstream/qemu/roms/edk2/MdePkg/Library/BaseLib/String.c(1090):
  > Length < _gPcd_FixedAtBuild_PcdMaximumAsciiStringLength

  but that is only a (distant) consequence of the CopyMem()
  mistranslation, and resultant destination area corruption.

  Originally reported in the following two mailing list messages:
  - 9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com">http://mid.mail-archive.com/9d2e260c-c491-03d2-9b8b-b57b72083f77@redhat.com
  - f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com">http://mid.mail-archive.com/f1cec8c0-1a9b-f5bb-f951-ea0ba9d276ee@redhat.com

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

[Qemu-devel] [PULL 22/24] ci: store Patchew configuration in the tree

[Paolo Bonzini]

Patchew cannot yet retrieve the configuration from the QEMU Git tree, but
this is planned.  In the meanwhile, let's start storing it as YAML
so that the Patchew configuration (currently accessible only to administrators)
is public and documented.

Signed-off-by: Paolo Bonzini 
---
 .patchew.yml | 302 +++
 1 file changed, 302 insertions(+)
 create mode 100644 .patchew.yml

diff --git a/.patchew.yml b/.patchew.yml
new file mode 100644
index 000..988c292
--- /dev/null
+++ b/.patchew.yml
@@ -0,0 +1,302 @@
+---
+# Note: this file is still unused.  It serves as a documentation for the
+# Patchew configuration in case patchew.org disappears or has to be
+# reinstalled.
+#
+# Patchew configuration is available to project administrators at
+# https://patchew.org/api/v1/projects/1/config/ and can be configured
+# to YAML using the following Python script:
+#
+# import json
+# import sys
+# import ruamel.yaml
+#
+# json_str = sys.stdin.read()
+# yaml = ruamel.yaml.YAML()
+# yaml.explicit_start = True
+# data = json.loads(json_str, 
object_pairs_hook=ruamel.yaml.comments.CommentedMap)
+# ruamel.yaml.scalarstring.walk_tree(data)
+# yaml.dump(data, sys.stdout)
+
+email:
+  notifications:
+timeouts:
+  event: TestingReport
+  enabled: true
+  to_user: false
+  reply_subject: true
+  set_reply_to: true
+  in_reply_to: true
+  reply_to_all: false
+  subject_template: none
+  to: f...@euphon.net
+  cc: ''
+  body_template: |
+{% if not is_timeout %} {{ cancel }} {% endif %}
+
+Test '{{ test }}' timeout, log:
+
+{{ log }}
+ENOSPC:
+  event: TestingReport
+  enabled: true
+  to_user: false
+  reply_subject: false
+  set_reply_to: false
+  in_reply_to: true
+  reply_to_all: false
+  subject_template: Out of space error
+  to: f...@euphon.net
+  cc: ''
+  body_template: |
+{% if passed %}
+  {{ cancel }}
+{% endif %}
+
+{% if 'No space left on device' in log %}
+Tester {{ tester }} out of space when running {{ test }}
+
+  {{ log }}
+{% else %}
+  {{ cancel }}
+{% endif %}
+FailureShort:
+  event: TestingReport
+  enabled: true
+  to_user: false
+  reply_subject: true
+  set_reply_to: true
+  in_reply_to: true
+  reply_to_all: true
+  subject_template: Testing failed
+  to: ''
+  cc: ''
+  body_template: |
+{% if passed or not obj.message_id or is_timeout %}
+  {{ cancel }}
+{% endif %}
+{% if 'No space left on device' in log %}
+  {{ cancel }}
+{% endif %}
+Patchew URL: https://patchew.org/QEMU/{{ obj.message_id }}/
+
+{% ansi2text log as logtext %}
+{% if test == "checkpatch" %}
+Hi,
+
+This series seems to have some coding style problems. See output below 
for
+more information:
+
+{{ logtext }}
+{% elif test == "docker-mingw@fedora" or test == 
"docker-quick@centos7" or test == "asan" %}
+Hi,
+
+This series failed the {{ test }} build test. Please find the testing 
commands and
+their output below. If you have Docker installed, you can probably 
reproduce it
+locally.
+
+{% lines_between logtext start="^=== TEST SCRIPT BEGIN ===$" 
stop="^=== TEST SCRIPT END ===$" %}
+{% lines_between logtext start="^=== OUTPUT BEGIN ===$" stop="=== 
OUTPUT END ===$" as output %}
+{% grep_C output regex="\b(FAIL|XPASS|ERROR|WARN|error:|warning:)" n=3 
%}
+{% elif test == "s390x" or test == "FreeBSD" or test == "ppcle" or 
test == "ppcbe" %}
+Hi,
+
+This series failed build test on {{test}} host. Please find the 
details below.
+
+{% lines_between logtext start="^=== TEST SCRIPT BEGIN ===$" 
stop="^=== TEST SCRIPT END ===$" %}
+{% lines_between logtext start="^=== OUTPUT BEGIN ===$" stop="=== 
OUTPUT END ===$" as output %}
+{% grep_C output regex="\b(FAIL|XPASS|ERROR|WARN|error:|warning:)" n=3 
%}
+{% else %}
+{{ cancel }}
+{% endif %}
+
+The full log is available at
+{{ log_url }}.
+---
+Email generated automatically by Patchew [https://patchew.org/].
+Please send your feedback to patchew-de...@redhat.com
+testing:
+  tests:
+asan:
+  enabled: true
+  requirements: docker
+  timeout: 3600
+  script: |
+#!/bin/bash
+time make docker-test-debug@fedora TARGET_LIST=x86_64-softmmu J=14 
NETWORK=1
+docker-quick@centos7:
+  enabled: false
+  requirements: docker,x86_64
+  timeout: 3600
+  script: |
+#!/bin/bash
+time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
+checkpatch:
+  enabled: true
+  requirements: ''
+  timeout: 600
+  script: |
+ 

[Qemu-devel] [PULL 06/24] edu: mmio: allow 64-bit access

[Paolo Bonzini]

From: Li Qiang 

The edu spec says the MMIO area can be accessed by 64-bit.
However currently the 'max_access_size' is not so the MMIO
access dispatch can only access 32-bit one time. This patch fixes
this to respect the spec.

Signed-off-by: Li Qiang 
Reviewed-by: Philippe Mathieu-Daude 
Message-Id: <20190510164349.81507-2-liq...@163.com>
Signed-off-by: Paolo Bonzini 
---
 hw/misc/edu.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/hw/misc/edu.c b/hw/misc/edu.c
index 91af452..65fc32b 100644
--- a/hw/misc/edu.c
+++ b/hw/misc/edu.c
@@ -289,6 +289,15 @@ static const MemoryRegionOps edu_mmio_ops = {
 .read = edu_mmio_read,
 .write = edu_mmio_write,
 .endianness = DEVICE_NATIVE_ENDIAN,
+.valid = {
+.min_access_size = 4,
+.max_access_size = 8,
+},
+.impl = {
+.min_access_size = 4,
+.max_access_size = 8,
+},
+
 };
 
 /*
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH 1/2] target/arm: Vectorize USHL and SSHL

[Richard Henderson]

On 5/23/19 8:03 AM, Peter Maydell wrote:
> On Thu, 23 May 2019 at 13:44, Peter Maydell  wrote:
>>
>> On Sat, 18 May 2019 at 20:19, Richard Henderson
>>  wrote:
>>>
>>> These instructions shift left or right depending on the sign
>>> of the input, and 7 bits are significant to the shift.  This
>>> requires several masks and selects in addition to the actual
>>> shifts to form the complete answer.
>>>
>>> That said, the operation is still a small improvement even for
>>> two 64-bit elements -- 13 vector operations instead of 2 * 7
>>> integer operations.
>>>
>>> +void gen_ushl_i32(TCGv_i32 d, TCGv_i32 a, TCGv_i32 b)
>>> +{
>>> +TCGv_i32 lval = tcg_temp_new_i32();
>>> +TCGv_i32 rval = tcg_temp_new_i32();
>>> +TCGv_i32 lsh = tcg_temp_new_i32();
>>> +TCGv_i32 rsh = tcg_temp_new_i32();
>>> +TCGv_i32 zero = tcg_const_i32(0);
>>> +TCGv_i32 max = tcg_const_i32(32);
>>> +
>>> +/*
>>> + * Perform possibly out of range shifts, trusting that the operation
>>> + * does not trap.  Discard unused results after the fact.
>>> + */
>>
>> This comment reads to me like we're relying on a guarantee
>> that TCG doesn't make, but in fact the readme says it does:
>> out-of-range shifts are "unspecified behavior" which may give
>> bogus results but won't crash. Perhaps phrasing the comment
>> as "relying on the TCG guarantee that these are only
>> 'unspecified behavior' and not 'undefined behavior' and so
>> won't crash" would be clearer ?

I've adjusted the comment along these lines.

> I had a look through the rest of the patch, but there is
> too much code here and I don't have enough context to
> figure out how all the various new gvec helpers are
> called and what jobs they are doing compared to the
> actual instruction operation. Maybe I'll have another try later.
If the host supports vectors, then the .fniv expander will be called.
Otherwise, .fni4 or .fni8 will be used to expand with 32-bit or 64-bit
integers.  Finally, the .fno expander calls an out-of-line helper.

Not strictly kosher perhaps, but in some places we Know that MAX_UNROLL is set
to 4 in tcg/tcg-op-gvec.c, and that since AdvSIMD uses 128-bit vectors, 4 *
32-bit will always be expanded inline, and so omit the out-of-line helper.

I'm not sure why I didn't do this here, since this is not one of the cases in
which we could share helpers with SVE.  (SVE dropped the right-shift as
negative shift count thing.)

> Why can we get rid of the 8-bit, 32-bit and 64-bit old shift
> helpers, but not 16-bit ?

It's still used by gen_neon_shift_narrow.


r~

[Qemu-devel] [PULL 13/24] pca9552-test: do not rely on state across tests

[Paolo Bonzini]

receive_autoinc is relying on the LED state that is set by
send_and_receive.  Stop doing that, because qgraph resets the
machine between tests.

Reviewed-by: Thomas Huth 
Signed-off-by: Paolo Bonzini 
---
 tests/pca9552-test.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/tests/pca9552-test.c b/tests/pca9552-test.c
index 06359b7..89b4445 100644
--- a/tests/pca9552-test.c
+++ b/tests/pca9552-test.c
@@ -18,11 +18,20 @@
 
 static I2CAdapter *i2c;
 
+static void pca9552_init(I2CAdapter *i2c)
+{
+/* Switch on LEDs 0 and 12 */
+i2c_set8(i2c, PCA9552_TEST_ADDR, PCA9552_LS0, 0x54);
+i2c_set8(i2c, PCA9552_TEST_ADDR, PCA9552_LS3, 0x54);
+}
+
 static void receive_autoinc(void)
 {
 uint8_t resp;
 uint8_t reg = PCA9552_LS0 | PCA9552_AUTOINC;
 
+pca9552_init(i2cdev);
+
 i2c_send(i2c, PCA9552_TEST_ADDR, , 1);
 
 /* PCA9552_LS0 */
@@ -52,16 +61,14 @@ static void send_and_receive(void)
 value = i2c_get8(i2c, PCA9552_TEST_ADDR, PCA9552_INPUT0);
 g_assert_cmphex(value, ==, 0x0);
 
-/* Switch on LED 0 */
-i2c_set8(i2c, PCA9552_TEST_ADDR, PCA9552_LS0, 0x54);
+pca9552_init(i2cdev);
+
 value = i2c_get8(i2c, PCA9552_TEST_ADDR, PCA9552_LS0);
 g_assert_cmphex(value, ==, 0x54);
 
 value = i2c_get8(i2c, PCA9552_TEST_ADDR, PCA9552_INPUT0);
 g_assert_cmphex(value, ==, 0x01);
 
-/* Switch on LED 12 */
-i2c_set8(i2c, PCA9552_TEST_ADDR, PCA9552_LS3, 0x54);
 value = i2c_get8(i2c, PCA9552_TEST_ADDR, PCA9552_LS3);
 g_assert_cmphex(value, ==, 0x54);
 
-- 
1.8.3.1

[Qemu-devel] [PULL 15/24] libqos: split I2CAdapter initialization and allocation

[Paolo Bonzini]

Provide *_init functions that populate an I2CAdapter struct without
allocating one, and make the existing *_create functions wrap them.

Because in the new setup *_create might return a pointer inside the
IMXI2C or OMAPI2C struct, create companion *_free functions to go
back to the outer pointer.

All this is temporary until allocation will be handled entirely by
qgraph.

Signed-off-by: Paolo Bonzini 
---
 tests/libqos/i2c-imx.c  | 37 ++---
 tests/libqos/i2c-omap.c | 32 +---
 tests/libqos/i2c.h  | 20 ++--
 tests/pca9552-test.c|  2 +-
 tests/tmp105-test.c |  2 +-
 5 files changed, 63 insertions(+), 30 deletions(-)

diff --git a/tests/libqos/i2c-imx.c b/tests/libqos/i2c-imx.c
index 0945f2e..28289c5 100644
--- a/tests/libqos/i2c-imx.c
+++ b/tests/libqos/i2c-imx.c
@@ -30,13 +30,6 @@ enum IMXI2CDirection {
 IMX_I2C_WRITE,
 };
 
-typedef struct IMXI2C {
-I2CAdapter parent;
-
-uint64_t addr;
-} IMXI2C;
-
-
 static void imx_i2c_set_slave_addr(IMXI2C *s, uint8_t addr,
enum IMXI2CDirection direction)
 {
@@ -47,7 +40,7 @@ static void imx_i2c_set_slave_addr(IMXI2C *s, uint8_t addr,
 static void imx_i2c_send(I2CAdapter *i2c, uint8_t addr,
  const uint8_t *buf, uint16_t len)
 {
-IMXI2C *s = (IMXI2C *)i2c;
+IMXI2C *s = container_of(i2c, IMXI2C, parent);
 uint8_t data;
 uint8_t status;
 uint16_t size = 0;
@@ -107,7 +100,7 @@ static void imx_i2c_send(I2CAdapter *i2c, uint8_t addr,
 static void imx_i2c_recv(I2CAdapter *i2c, uint8_t addr,
  uint8_t *buf, uint16_t len)
 {
-IMXI2C *s = (IMXI2C *)i2c;
+IMXI2C *s = container_of(i2c, IMXI2C, parent);
 uint8_t data;
 uint8_t status;
 uint16_t size = 0;
@@ -193,16 +186,30 @@ static void imx_i2c_recv(I2CAdapter *i2c, uint8_t addr,
 g_assert((status & I2SR_IBB) == 0);
 }
 
+void imx_i2c_init(IMXI2C *s, QTestState *qts, uint64_t addr)
+{
+s->addr = addr;
+
+s->parent.send = imx_i2c_send;
+s->parent.recv = imx_i2c_recv;
+s->parent.qts = qts;
+}
+
 I2CAdapter *imx_i2c_create(QTestState *qts, uint64_t addr)
 {
 IMXI2C *s = g_malloc0(sizeof(*s));
-I2CAdapter *i2c = (I2CAdapter *)s;
 
-s->addr = addr;
+imx_i2c_init(s, qts, addr);
+return >parent;
+}
 
-i2c->send = imx_i2c_send;
-i2c->recv = imx_i2c_recv;
-i2c->qts = qts;
+void imx_i2c_free(I2CAdapter *i2c)
+{
+IMXI2C *s;
 
-return i2c;
+if (!i2c) {
+return;
+}
+s = container_of(i2c, IMXI2C, parent);
+g_free(s);
 }
diff --git a/tests/libqos/i2c-omap.c b/tests/libqos/i2c-omap.c
index bb65336..c7cbb9e 100644
--- a/tests/libqos/i2c-omap.c
+++ b/tests/libqos/i2c-omap.c
@@ -40,12 +40,6 @@ enum OMAPI2CCONBits {
 OMAP_I2C_CON_I2C_EN = 1 << 15,
 };
 
-typedef struct OMAPI2C {
-I2CAdapter parent;
-
-uint64_t addr;
-} OMAPI2C;
-
 
 static void omap_i2c_set_slave_addr(OMAPI2C *s, uint8_t addr)
 {
@@ -59,7 +53,7 @@ static void omap_i2c_set_slave_addr(OMAPI2C *s, uint8_t addr)
 static void omap_i2c_send(I2CAdapter *i2c, uint8_t addr,
   const uint8_t *buf, uint16_t len)
 {
-OMAPI2C *s = (OMAPI2C *)i2c;
+OMAPI2C *s = container_of(i2c, OMAPI2C, parent);
 uint16_t data;
 
 omap_i2c_set_slave_addr(s, addr);
@@ -103,7 +97,7 @@ static void omap_i2c_send(I2CAdapter *i2c, uint8_t addr,
 static void omap_i2c_recv(I2CAdapter *i2c, uint8_t addr,
   uint8_t *buf, uint16_t len)
 {
-OMAPI2C *s = (OMAPI2C *)i2c;
+OMAPI2C *s = container_of(i2c, OMAPI2C, parent);
 uint16_t data, stat;
 uint16_t orig_len = len;
 
@@ -161,9 +155,8 @@ static void omap_i2c_recv(I2CAdapter *i2c, uint8_t addr,
 g_assert((data & OMAP_I2C_CON_STP) == 0);
 }
 
-I2CAdapter *omap_i2c_create(QTestState *qts, uint64_t addr)
+void omap_i2c_init(OMAPI2C *s, QTestState *qts, uint64_t addr)
 {
-OMAPI2C *s = g_malloc0(sizeof(*s));
 I2CAdapter *i2c = (I2CAdapter *)s;
 uint16_t data;
 
@@ -176,6 +169,23 @@ I2CAdapter *omap_i2c_create(QTestState *qts, uint64_t addr)
 /* verify the mmio address by looking for a known signature */
 data = qtest_readw(qts, addr + OMAP_I2C_REV);
 g_assert_cmphex(data, ==, 0x34);
+}
+
+I2CAdapter *omap_i2c_create(QTestState *qts, uint64_t addr)
+{
+OMAPI2C *s = g_malloc0(sizeof(*s));
+
+omap_i2c_init(s, qts, addr);
+return >parent;
+}
 
-return i2c;
+void omap_i2c_free(I2CAdapter *i2c)
+{
+OMAPI2C *s;
+
+if (!i2c) {
+return;
+}
+s = container_of(i2c, OMAPI2C, parent);
+g_free(s);
 }
diff --git a/tests/libqos/i2c.h b/tests/libqos/i2c.h
index a462114..877d2ab 100644
--- a/tests/libqos/i2c.h
+++ b/tests/libqos/i2c.h
@@ -39,10 +39,26 @@ void i2c_set8(I2CAdapter *i2c, uint8_t addr, uint8_t reg,
 void i2c_set16(I2CAdapter *i2c, uint8_t addr, uint8_t reg,
uint16_t value);
 
-/* libi2c-omap.c */
+/* 

[Qemu-devel] [PULL 23/24] configure: remove tpm_passthrough & tpm_emulator

[Paolo Bonzini]

From: Marc-André Lureau 

This is a left-over from commit 7aaa6a16373 "tpm: express dependencies
with Kconfig".

Signed-off-by: Marc-André Lureau 
Message-Id: <20190524181411.8599-1-marcandre.lur...@redhat.com>
Signed-off-by: Paolo Bonzini 
---
 configure | 10 --
 1 file changed, 10 deletions(-)

diff --git a/configure b/configure
index 6cdcfb2..b091b82 100755
--- a/configure
+++ b/configure
@@ -6452,8 +6452,6 @@ echo "gcov  $gcov_tool"
 echo "gcov enabled  $gcov"
 echo "TPM support   $tpm"
 echo "libssh2 support   $libssh2"
-echo "TPM passthrough   $tpm_passthrough"
-echo "TPM emulator  $tpm_emulator"
 echo "QOM debugging $qom_cast_debug"
 echo "Live block migration $live_block_migration"
 echo "lzo support   $lzo"
@@ -7158,14 +7156,6 @@ fi
 
 if test "$tpm" = "yes"; then
   echo 'CONFIG_TPM=$(CONFIG_SOFTMMU)' >> $config_host_mak
-  # TPM passthrough support?
-  if test "$tpm_passthrough" = "yes"; then
-echo "CONFIG_TPM_PASSTHROUGH=y" >> $config_host_mak
-  fi
-  # TPM emulator support?
-  if test "$tpm_emulator" = "yes"; then
-echo "CONFIG_TPM_EMULATOR=y" >> $config_host_mak
-  fi
 fi
 
 echo "TRACE_BACKENDS=$trace_backends" >> $config_host_mak
-- 
1.8.3.1

[Qemu-devel] [PULL 12/24] libqos: fix omap-i2c receiving more than 4 bytes

[Paolo Bonzini]

If more than 4 bytes are received, the FIFO cannot host the entire
contents of the transfer and STP will be nonzero before entering
the transfer loop.  Also, CNT will contain the number of bytes
left to be transferred instead of the total number of bytes in
the transfer.

(Reverse engineered from the omap_i2c.c source code; no available
datasheet).

This will fix ds1338-test for omap-i2c.

Signed-off-by: Paolo Bonzini 
---
 tests/libqos/i2c-omap.c | 19 ++-
 1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/tests/libqos/i2c-omap.c b/tests/libqos/i2c-omap.c
index 1ef6e7b..bb65336 100644
--- a/tests/libqos/i2c-omap.c
+++ b/tests/libqos/i2c-omap.c
@@ -105,6 +105,7 @@ static void omap_i2c_recv(I2CAdapter *i2c, uint8_t addr,
 {
 OMAPI2C *s = (OMAPI2C *)i2c;
 uint16_t data, stat;
+uint16_t orig_len = len;
 
 omap_i2c_set_slave_addr(s, addr);
 
@@ -116,16 +117,24 @@ static void omap_i2c_recv(I2CAdapter *i2c, uint8_t addr,
OMAP_I2C_CON_STT |
OMAP_I2C_CON_STP;
 qtest_writew(i2c->qts, s->addr + OMAP_I2C_CON, data);
-data = qtest_readw(i2c->qts, s->addr + OMAP_I2C_CON);
-g_assert((data & OMAP_I2C_CON_STP) == 0);
 
 data = qtest_readw(i2c->qts, s->addr + OMAP_I2C_STAT);
 g_assert((data & OMAP_I2C_STAT_NACK) == 0);
 
-data = qtest_readw(i2c->qts, s->addr + OMAP_I2C_CNT);
-g_assert_cmpuint(data, ==, len);
-
 while (len > 0) {
+data = qtest_readw(i2c->qts, s->addr + OMAP_I2C_CON);
+if (len <= 4) {
+g_assert((data & OMAP_I2C_CON_STP) == 0);
+
+data = qtest_readw(i2c->qts, s->addr + OMAP_I2C_CNT);
+g_assert_cmpuint(data, ==, orig_len);
+} else {
+g_assert((data & OMAP_I2C_CON_STP) != 0);
+
+data = qtest_readw(i2c->qts, s->addr + OMAP_I2C_CNT);
+g_assert_cmpuint(data, ==, len - 4);
+}
+
 data = qtest_readw(i2c->qts, s->addr + OMAP_I2C_STAT);
 g_assert((data & OMAP_I2C_STAT_RRDY) != 0);
 g_assert((data & OMAP_I2C_STAT_ROVR) == 0);
-- 
1.8.3.1

[Qemu-devel] [PULL 17/24] libqos: add ARM n800 machine object

[Paolo Bonzini]

This is used to test omap_i2c.

Signed-off-by: Paolo Bonzini 
---
 tests/Makefile.include  |  1 +
 tests/libqos/arm-n800-machine.c | 92 +
 2 files changed, 93 insertions(+)
 create mode 100644 tests/libqos/arm-n800-machine.c

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 63f646a..03a6483 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -711,6 +711,7 @@ qos-test-obj-y += tests/libqos/virtio-serial.o
 
 # Machines
 qos-test-obj-y += tests/libqos/aarch64-xlnx-zcu102-machine.o
+qos-test-obj-y += tests/libqos/arm-n800-machine.o
 qos-test-obj-y += tests/libqos/arm-raspi2-machine.o
 qos-test-obj-y += tests/libqos/arm-sabrelite-machine.o
 qos-test-obj-y += tests/libqos/arm-smdkc210-machine.o
diff --git a/tests/libqos/arm-n800-machine.c b/tests/libqos/arm-n800-machine.c
new file mode 100644
index 000..87279bd
--- /dev/null
+++ b/tests/libqos/arm-n800-machine.c
@@ -0,0 +1,92 @@
+/*
+ * libqos driver framework
+ *
+ * Copyright (c) 2019 Red Hat, Inc.
+ *
+ * Author: Paolo Bonzini 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License version 2 as published by the Free Software Foundation.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see 
+ */
+
+#include "qemu/osdep.h"
+#include "libqtest.h"
+#include "libqos/malloc.h"
+#include "libqos/qgraph.h"
+#include "libqos/i2c.h"
+
+#define ARM_PAGE_SIZE4096
+#define N800_RAM_START  0x8000
+#define N800_RAM_END0x8800
+
+typedef struct QN800Machine QN800Machine;
+
+struct QN800Machine {
+QOSGraphObject obj;
+QGuestAllocator alloc;
+OMAPI2C i2c_1;
+};
+
+static void *n800_get_driver(void *object, const char *interface)
+{
+QN800Machine *machine = object;
+if (!g_strcmp0(interface, "memory")) {
+return >alloc;
+}
+
+fprintf(stderr, "%s not present in arm/n800\n", interface);
+g_assert_not_reached();
+}
+
+static QOSGraphObject *n800_get_device(void *obj, const char *device)
+{
+QN800Machine *machine = obj;
+if (!g_strcmp0(device, "omap_i2c")) {
+return >i2c_1.obj;
+}
+
+fprintf(stderr, "%s not present in arm/n800\n", device);
+g_assert_not_reached();
+}
+
+static void n800_destructor(QOSGraphObject *obj)
+{
+QN800Machine *machine = (QN800Machine *) obj;
+alloc_destroy(>alloc);
+}
+
+static void *qos_create_machine_arm_n800(QTestState *qts)
+{
+QN800Machine *machine = g_new0(QN800Machine, 1);
+
+alloc_init(>alloc, 0,
+   N800_RAM_START,
+   N800_RAM_END,
+   ARM_PAGE_SIZE);
+machine->obj.get_device = n800_get_device;
+machine->obj.get_driver = n800_get_driver;
+machine->obj.destructor = n800_destructor;
+
+omap_i2c_init(>i2c_1, qts, 0x4807);
+return >obj;
+}
+
+static void n800_register_nodes(void)
+{
+QOSGraphEdgeOptions edge = {
+.extra_device_opts = "bus=i2c-bus.0"
+};
+qos_node_create_machine("arm/n800", qos_create_machine_arm_n800);
+qos_node_contains("arm/n800", "omap_i2c", , NULL);
+}
+
+libqos_init(n800_register_nodes);
-- 
1.8.3.1

[Qemu-devel] [PULL 24/24] q35: Revert to kernel irqchip

[Paolo Bonzini]

From: Alex Williamson 

Commit b2fc91db8447 ("q35: set split kernel irqchip as default") changed
the default for the pc-q35-4.0 machine type to use split irqchip, which
turned out to have disasterous effects on vfio-pci INTx support.  KVM
resampling irqfds are registered for handling these interrupts, but
these are non-functional in split irqchip mode.  We can't simply test
for split irqchip in QEMU as userspace handling of this interrupt is a
significant performance regression versus KVM handling (GeForce GPUs
assigned to Windows VMs are non-functional without forcing MSI mode or
re-enabling kernel irqchip).

The resolution is to revert the change in default irqchip mode in the
pc-q35-4.1 machine and create a pc-q35-4.0.1 machine for the 4.0-stable
branch.  The qemu-q35-4.0 machine type should not be used in vfio-pci
configurations for devices requiring legacy INTx support without
explicitly modifying the VM configuration to use kernel irqchip.

Link: https://bugs.launchpad.net/qemu/+bug/1826422
Fixes: b2fc91db8447 ("q35: set split kernel irqchip as default")
Signed-off-by: Alex Williamson 
Reviewed-by: Peter Xu 
Message-Id: <155786484688.13873.6037015630912983760.st...@gimli.home>
Signed-off-by: Paolo Bonzini 
---
 hw/core/machine.c|  3 +++
 hw/i386/pc.c |  3 +++
 hw/i386/pc_q35.c | 16 ++--
 include/hw/boards.h  |  3 +++
 include/hw/i386/pc.h |  3 +++
 5 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 16ba667..f1a0f45 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -24,6 +24,9 @@
 #include "hw/pci/pci.h"
 #include "hw/mem/nvdimm.h"
 
+GlobalProperty hw_compat_4_0_1[] = {};
+const size_t hw_compat_4_0_1_len = G_N_ELEMENTS(hw_compat_4_0_1);
+
 GlobalProperty hw_compat_4_0[] = {};
 const size_t hw_compat_4_0_len = G_N_ELEMENTS(hw_compat_4_0);
 
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 2632b73..edc240b 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -110,6 +110,9 @@ struct hpet_fw_config hpet_cfg = {.count = UINT8_MAX};
 /* Physical Address of PVH entry point read from kernel ELF NOTE */
 static size_t pvh_start_addr;
 
+GlobalProperty pc_compat_4_0_1[] = {};
+const size_t pc_compat_4_0_1_len = G_N_ELEMENTS(pc_compat_4_0_1);
+
 GlobalProperty pc_compat_4_0[] = {};
 const size_t pc_compat_4_0_len = G_N_ELEMENTS(pc_compat_4_0);
 
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 37dd350..dcddc64 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -357,7 +357,7 @@ static void pc_q35_machine_options(MachineClass *m)
 m->units_per_default_bus = 1;
 m->default_machine_opts = "firmware=bios-256k.bin";
 m->default_display = "std";
-m->default_kernel_irqchip_split = true;
+m->default_kernel_irqchip_split = false;
 m->no_floppy = 1;
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_AMD_IOMMU_DEVICE);
 machine_class_allow_dynamic_sysbus_dev(m, TYPE_INTEL_IOMMU_DEVICE);
@@ -374,10 +374,22 @@ static void pc_q35_4_1_machine_options(MachineClass *m)
 DEFINE_Q35_MACHINE(v4_1, "pc-q35-4.1", NULL,
pc_q35_4_1_machine_options);
 
-static void pc_q35_4_0_machine_options(MachineClass *m)
+static void pc_q35_4_0_1_machine_options(MachineClass *m)
 {
 pc_q35_4_1_machine_options(m);
 m->alias = NULL;
+compat_props_add(m->compat_props, hw_compat_4_0_1, hw_compat_4_0_1_len);
+compat_props_add(m->compat_props, pc_compat_4_0_1, pc_compat_4_0_1_len);
+}
+
+DEFINE_Q35_MACHINE(v4_0_1, "pc-q35-4.0.1", NULL,
+   pc_q35_4_0_1_machine_options);
+
+static void pc_q35_4_0_machine_options(MachineClass *m)
+{
+pc_q35_4_0_1_machine_options(m);
+m->default_kernel_irqchip_split = true;
+m->alias = NULL;
 compat_props_add(m->compat_props, hw_compat_4_0, hw_compat_4_0_len);
 compat_props_add(m->compat_props, pc_compat_4_0, pc_compat_4_0_len);
 }
diff --git a/include/hw/boards.h b/include/hw/boards.h
index 6f7916f..6ff02bf 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -292,6 +292,9 @@ struct MachineState {
 } \
 type_init(machine_initfn##_register_types)
 
+extern GlobalProperty hw_compat_4_0_1[];
+extern const size_t hw_compat_4_0_1_len;
+
 extern GlobalProperty hw_compat_4_0[];
 extern const size_t hw_compat_4_0_len;
 
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 43df723..5d56362 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -293,6 +293,9 @@ int e820_add_entry(uint64_t, uint64_t, uint32_t);
 int e820_get_num_entries(void);
 bool e820_get_entry(int, uint32_t, uint64_t *, uint64_t *);
 
+extern GlobalProperty pc_compat_4_0_1[];
+extern const size_t pc_compat_4_0_1_len;
+
 extern GlobalProperty pc_compat_4_0[];
 extern const size_t pc_compat_4_0_len;
 
-- 
1.8.3.1

[Qemu-devel] [PULL 16/24] libqos: convert I2C to qgraph

[Paolo Bonzini]

Create an i2c-bus interface, corresponding to the I2CAdapter struct.
Wrap IMXI2C and OMAPI2C with a QOSGraphObject, and add the get_driver
function to retrieve the I2CAdapter.

The conversion is still not complete; for simplicity, i2c_recv and
i2c_send (along with their wrappers) still take an adapter/address
pair.  Fixing that would be complicated until the tests are converted
to qgraph, so it is left for after the conversion.

Signed-off-by: Paolo Bonzini 
---
 tests/Makefile.include  |  2 ++
 tests/libqos/i2c-imx.c  | 20 
 tests/libqos/i2c-omap.c | 40 
 tests/libqos/i2c.c  |  8 
 tests/libqos/i2c.h  | 21 +
 5 files changed, 83 insertions(+), 8 deletions(-)

diff --git a/tests/Makefile.include b/tests/Makefile.include
index 1865f6b..63f646a 100644
--- a/tests/Makefile.include
+++ b/tests/Makefile.include
@@ -694,6 +694,8 @@ libqos-usb-obj-y = $(libqos-spapr-obj-y) $(libqos-pc-obj-y) 
tests/libqos/usb.o
 qos-test-obj-y = tests/qos-test.o $(libqgraph-obj-y)
 qos-test-obj-y += $(libqos-pc-obj-y) $(libqos-spapr-obj-y)
 qos-test-obj-y += tests/libqos/e1000e.o
+qos-test-obj-y += $(libqos-imx-obj-y)
+qos-test-obj-y += $(libqos-omap-obj-y)
 qos-test-obj-y += tests/libqos/sdhci.o
 qos-test-obj-y += tests/libqos/tpci200.o
 qos-test-obj-y += tests/libqos/virtio.o
diff --git a/tests/libqos/i2c-imx.c b/tests/libqos/i2c-imx.c
index 28289c5..86d84a7 100644
--- a/tests/libqos/i2c-imx.c
+++ b/tests/libqos/i2c-imx.c
@@ -186,10 +186,22 @@ static void imx_i2c_recv(I2CAdapter *i2c, uint8_t addr,
 g_assert((status & I2SR_IBB) == 0);
 }
 
+static void *imx_i2c_get_driver(void *obj, const char *interface)
+{
+IMXI2C *s = obj;
+if (!g_strcmp0(interface, "i2c-bus")) {
+return >parent;
+}
+fprintf(stderr, "%s not present in imx-i2c\n", interface);
+g_assert_not_reached();
+}
+
 void imx_i2c_init(IMXI2C *s, QTestState *qts, uint64_t addr)
 {
 s->addr = addr;
 
+s->obj.get_driver = imx_i2c_get_driver;
+
 s->parent.send = imx_i2c_send;
 s->parent.recv = imx_i2c_recv;
 s->parent.qts = qts;
@@ -213,3 +225,11 @@ void imx_i2c_free(I2CAdapter *i2c)
 s = container_of(i2c, IMXI2C, parent);
 g_free(s);
 }
+
+static void imx_i2c_register_nodes(void)
+{
+qos_node_create_driver("imx.i2c", NULL);
+qos_node_produces("imx.i2c", "i2c-bus");
+}
+
+libqos_init(imx_i2c_register_nodes);
diff --git a/tests/libqos/i2c-omap.c b/tests/libqos/i2c-omap.c
index c7cbb9e..f949564 100644
--- a/tests/libqos/i2c-omap.c
+++ b/tests/libqos/i2c-omap.c
@@ -155,20 +155,36 @@ static void omap_i2c_recv(I2CAdapter *i2c, uint8_t addr,
 g_assert((data & OMAP_I2C_CON_STP) == 0);
 }
 
-void omap_i2c_init(OMAPI2C *s, QTestState *qts, uint64_t addr)
+static void *omap_i2c_get_driver(void *obj, const char *interface)
+{
+OMAPI2C *s = obj;
+if (!g_strcmp0(interface, "i2c-bus")) {
+return >parent;
+}
+fprintf(stderr, "%s not present in omap_i2c\n", interface);
+g_assert_not_reached();
+}
+
+static void omap_i2c_start_hw(QOSGraphObject *object)
 {
-I2CAdapter *i2c = (I2CAdapter *)s;
+OMAPI2C *s = (OMAPI2C *) object;
 uint16_t data;
 
+/* verify the mmio address by looking for a known signature */
+data = qtest_readw(s->parent.qts, s->addr + OMAP_I2C_REV);
+g_assert_cmphex(data, ==, 0x34);
+}
+
+void omap_i2c_init(OMAPI2C *s, QTestState *qts, uint64_t addr)
+{
 s->addr = addr;
 
-i2c->send = omap_i2c_send;
-i2c->recv = omap_i2c_recv;
-i2c->qts = qts;
+s->obj.get_driver = omap_i2c_get_driver;
+s->obj.start_hw = omap_i2c_start_hw;
 
-/* verify the mmio address by looking for a known signature */
-data = qtest_readw(qts, addr + OMAP_I2C_REV);
-g_assert_cmphex(data, ==, 0x34);
+s->parent.send = omap_i2c_send;
+s->parent.recv = omap_i2c_recv;
+s->parent.qts = qts;
 }
 
 I2CAdapter *omap_i2c_create(QTestState *qts, uint64_t addr)
@@ -189,3 +205,11 @@ void omap_i2c_free(I2CAdapter *i2c)
 s = container_of(i2c, OMAPI2C, parent);
 g_free(s);
 }
+
+static void omap_i2c_register_nodes(void)
+{
+qos_node_create_driver("omap_i2c", NULL);
+qos_node_produces("omap_i2c", "i2c-bus");
+}
+
+libqos_init(omap_i2c_register_nodes);
diff --git a/tests/libqos/i2c.c b/tests/libqos/i2c.c
index daf9a96..8117d13 100644
--- a/tests/libqos/i2c.c
+++ b/tests/libqos/i2c.c
@@ -68,3 +68,11 @@ void i2c_set16(I2CAdapter *i2c, uint8_t addr, uint8_t reg,
 data[1] = value & 255;
 i2c_write_block(i2c, addr, reg, data, sizeof(data));
 }
+
+void *i2c_device_create(void *i2c_bus, QGuestAllocator *alloc, void *addr)
+{
+QI2CDevice *i2cdev = g_new0(QI2CDevice, 1);
+
+i2cdev->bus = i2c_bus;
+return >obj;
+}
diff --git a/tests/libqos/i2c.h b/tests/libqos/i2c.h
index 877d2ab..0107cfc 100644
--- a/tests/libqos/i2c.h
+++ b/tests/libqos/i2c.h
@@ -10,6 +10,7 @@
 #define LIBQOS_I2C_H
 
 #include "libqtest.h"
+#include "libqos/qgraph.h"