Re: [RFC PATCH 5/6] i386/sev: add support to encrypt BIOS when SEV-SNP is enabled

[Dov Murik]

On 14/07/2021 21:52, Brijesh Singh wrote:
> 
> 
> On 7/14/21 12:08 PM, Connor Kuehl wrote:
>> On 7/9/21 3:55 PM, Brijesh Singh wrote:
>>> The KVM_SEV_SNP_LAUNCH_UPDATE command is used for encrypting the bios
>>> image used for booting the SEV-SNP guest.
>>>
>>> Signed-off-by: Brijesh Singh 
>>> ---
>>>   target/i386/sev.c    | 33 -
>>>   target/i386/trace-events |  1 +
>>>   2 files changed, 33 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/target/i386/sev.c b/target/i386/sev.c
>>> index 259408a8f1..41dcb084d1 100644
>>> --- a/target/i386/sev.c
>>> +++ b/target/i386/sev.c
>>> @@ -883,6 +883,30 @@ out:
>>>   return ret;
>>>   }
>>>   +static int
>>> +sev_snp_launch_update(SevGuestState *sev, uint8_t *addr, uint64_t
>>> len, int type)
>>> +{
>>> +    int ret, fw_error;
>>> +    struct kvm_sev_snp_launch_update update = {};
>>> +
>>> +    if (!addr || !len) {
>>> +    return 1;
>>
>> Should this be a -1? It looks like the caller checks if this function
>> returns < 0, but doesn't check for res == 1.
> 
> Ah, it should be -1.
> 
>>
>> Alternatively, invoking error_report might provide more useful
>> information that the preconditions to this function were violated.
>>
> 
> Sure, I will add error_report.

Maybe even simpler:

  assert(addr);
  assert(len > 0);

The assertion failure will show the developer what is wrong. This should
not happen for the end-user (unless I'm missing something).

-Dov

Re: About two-dimensional page translation (e.g., Intel EPT) and shadow page table in Linux QEMU/KVM

[harry harry]

Hi Sean,

> No, each vCPU has its own MMU instance, where an "MMU instance" is (mostly) a 
> KVM
> construct.  Per-vCPU MMU instances are necessary because each vCPU has its own
> relevant state, e.g. CR0, CR4, EFER, etc..., that affects the MMU instance in
> some way.  E.g. the MMU instance is used to walk guest page tables when
> translating GVA->GPA for emulation, so per-vCPU MMUs are necessary even when
> using TDP.
>
> However, shadow/TDP PTEs are shared between compatible MMU instances.  E.g. in
> the common case where all vCPUs in a VM use identical settings, there will
> effectively be a single set of TDP page tables shared by all vCPUs.

What do you mean by "MMU instance"? Do you mean VMCS? MMU is hardware.
Could you please share me the code of the MMU instance in KVM? Thanks!

Re: [PATCH v2 10/21] contrib/gitdm: add domain-map/group-map mappings for Samsung

[Klaus Jensen]

On Jul 14 19:20, Alex Bennée wrote:
> Minwoo's work from their personal address are treated as personal
> contributions.
> 
> Signed-off-by: Alex Bennée 
> Acked-by: Klaus Jensen 
> Cc: Gollu Appalanaidu 
> Cc: Minwoo Im 
> Message-Id: <220210714093719.21429-11-alex.ben...@linaro.org>
> ---
>  contrib/gitdm/domain-map| 1 +
>  contrib/gitdm/group-map-individuals | 1 +
>  contrib/gitdm/group-map-samsung | 5 +
>  gitdm.config| 1 +
>  4 files changed, 8 insertions(+)
>  create mode 100644 contrib/gitdm/group-map-samsung
> 
> diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
> index efbbb15643..beeb24341e 100644
> --- a/contrib/gitdm/domain-map
> +++ b/contrib/gitdm/domain-map
> @@ -26,6 +26,7 @@ proxmox.com Proxmox
>  quicinc.com Qualcomm Innovation Center
>  redhat.com  Red Hat
>  rt-rk.com   RT-RK
> +samsung.com Samsung
>  siemens.com Siemens
>  sifive.com  SiFive
>  suse.comSUSE
> diff --git a/contrib/gitdm/group-map-individuals 
> b/contrib/gitdm/group-map-individuals
> index 36bbb77c39..4ac2f98823 100644
> --- a/contrib/gitdm/group-map-individuals
> +++ b/contrib/gitdm/group-map-individuals
> @@ -29,3 +29,4 @@ mrol...@gmail.com
>  h...@tuxfamily.org
>  jho...@kernel.org
>  atar4q...@gmail.com
> +minwoo.im@gmail.com
> diff --git a/contrib/gitdm/group-map-samsung b/contrib/gitdm/group-map-samsung
> new file mode 100644
> index 00..e38c7eeeac
> --- /dev/null
> +++ b/contrib/gitdm/group-map-samsung
> @@ -0,0 +1,5 @@
> +#
> +# Some Samsung contributors submit via another domain
> +#
> +
> +minwoo.im@gmail.com

I'm not sure how this groupmap works, but was it intentional that you
left Minwoo in the Samsung group map?

> diff --git a/gitdm.config b/gitdm.config
> index a3542d2fc7..e7a744146e 100644
> --- a/gitdm.config
> +++ b/gitdm.config
> @@ -36,6 +36,7 @@ GroupMap contrib/gitdm/group-map-codeweavers CodeWeavers
>  GroupMap contrib/gitdm/group-map-ibm IBM
>  GroupMap contrib/gitdm/group-map-janustech Janus Technologies
>  GroupMap contrib/gitdm/group-map-redhat Red Hat +GroupMap
>  contrib/gitdm/group-map-samsung Samsung GroupMap
>  contrib/gitdm/group-map-wavecomp Wave Computing
>  


signature.asc
Description: PGP signature

Re: [PATCH v3 0/9] tests: Add test cases for TPM 1.2 ACPI tables

[Markus Armbruster]

Philippe Mathieu-Daudé  writes:

> On 7/14/21 4:43 PM, Markus Armbruster wrote:
>> Philippe Mathieu-Daudé  writes:
>> 
>>> +Markus

[...]

>>> IMO the "right" solution is to check via QMP if TMP is supported
>>> or not. This is now doable since commit caff255a546 ("tpm: Return
>>> QMP error when TPM is disabled in build").
>>>
>>> Long term we'd like to decouple the tests/ build from the various
>>> QEMU configurations, and build the tests once.
>> 
>> This argument applies only to macros from target-specific headers like
>> $TARGET-config-target.h, not to macros from config-host.h.  #ifdef
>> CONFIG_TPM should be fine, shouldn't it?
>
> Some definitions depend on the host (OS, libraries installed, ...),
> others depend on the --enable/--disable ./configure options.
>
> IMO it would be nice if we could get qtests independent of the latter.

Why?

> I suppose config-host.h holds both kinds.

Yes.

Re: [PATCH 17/17] target/riscv: Remove gen_get_gpr

[Alistair Francis]

On Fri, Jul 9, 2021 at 2:48 PM Richard Henderson
 wrote:
>
> This function is now unused.
> The corresponding gen_set_gpr function is still in use.
>
> Signed-off-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/translate.c | 17 +
>  1 file changed, 5 insertions(+), 12 deletions(-)
>
> diff --git a/target/riscv/translate.c b/target/riscv/translate.c
> index 8ff75a5798..a6c850e9d3 100644
> --- a/target/riscv/translate.c
> +++ b/target/riscv/translate.c
> @@ -195,15 +195,6 @@ static void gen_goto_tb(DisasContext *ctx, int n, 
> target_ulong dest)
>  /* Wrapper for getting reg values - need to check of reg is zero since
>   * cpu_gpr[0] is not actually allocated
>   */
> -static inline void gen_get_gpr(TCGv t, int reg_num)
> -{
> -if (reg_num == 0) {
> -tcg_gen_movi_tl(t, 0);
> -} else {
> -tcg_gen_mov_tl(t, cpu_gpr[reg_num]);
> -}
> -}
> -
>  static TCGv gpr_src(DisasContext *ctx, int reg_num)
>  {
>  if (reg_num == 0) {
> @@ -1046,9 +1037,11 @@ void riscv_translate_init(void)
>  {
>  int i;
>
> -/* cpu_gpr[0] is a placeholder for the zero register. Do not use it. */
> -/* Use the gen_set_gpr and gen_get_gpr helper functions when accessing */
> -/* registers, unless you specifically block reads/writes to reg 0 */
> +/*
> + * cpu_gpr[0] is a placeholder for the zero register. Do not use it.
> + * Use the gpr_src and gpr_dst helper functions when accessing regs,
> + * unless you specifically block reads/writes to reg 0.
> + */
>  cpu_gpr[0] = NULL;
>
>  for (i = 1; i < 32; i++) {
> --
> 2.25.1
>
>

Re: [PATCH 16/17] target/riscv: Use gpr_{src,dst} for RVV

[Alistair Francis]

On Fri, Jul 9, 2021 at 2:43 PM Richard Henderson
 wrote:
>
> Signed-off-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/insn_trans/trans_rvv.c.inc | 79 +++--
>  1 file changed, 20 insertions(+), 59 deletions(-)
>
> diff --git a/target/riscv/insn_trans/trans_rvv.c.inc 
> b/target/riscv/insn_trans/trans_rvv.c.inc
> index a8e7272487..84a45fac38 100644
> --- a/target/riscv/insn_trans/trans_rvv.c.inc
> +++ b/target/riscv/insn_trans/trans_rvv.c.inc
> @@ -27,27 +27,21 @@ static bool trans_vsetvl(DisasContext *ctx, arg_vsetvl *a)
>  return false;
>  }
>
> -s2 = tcg_temp_new();
> -dst = tcg_temp_new();
> +s2 = gpr_src(ctx, a->rs2);
> +dst = gpr_dst(ctx, a->rd);
>
>  /* Using x0 as the rs1 register specifier, encodes an infinite AVL */
>  if (a->rs1 == 0) {
>  /* As the mask is at least one bit, RV_VLEN_MAX is >= VLMAX */
>  s1 = tcg_constant_tl(RV_VLEN_MAX);
>  } else {
> -s1 = tcg_temp_new();
> -gen_get_gpr(s1, a->rs1);
> +s1 = gpr_src(ctx, a->rs1);
>  }
> -gen_get_gpr(s2, a->rs2);
>  gen_helper_vsetvl(dst, cpu_env, s1, s2);
> -gen_set_gpr(a->rd, dst);
> +
>  tcg_gen_movi_tl(cpu_pc, ctx->pc_succ_insn);
>  lookup_and_goto_ptr(ctx);
>  ctx->base.is_jmp = DISAS_NORETURN;
> -
> -tcg_temp_free(s1);
> -tcg_temp_free(s2);
> -tcg_temp_free(dst);
>  return true;
>  }
>
> @@ -60,23 +54,19 @@ static bool trans_vsetvli(DisasContext *ctx, arg_vsetvli 
> *a)
>  }
>
>  s2 = tcg_constant_tl(a->zimm);
> -dst = tcg_temp_new();
> +dst = gpr_dst(ctx, a->rd);
>
>  /* Using x0 as the rs1 register specifier, encodes an infinite AVL */
>  if (a->rs1 == 0) {
>  /* As the mask is at least one bit, RV_VLEN_MAX is >= VLMAX */
>  s1 = tcg_constant_tl(RV_VLEN_MAX);
>  } else {
> -s1 = tcg_temp_new();
> -gen_get_gpr(s1, a->rs1);
> +s1 = gpr_src(ctx, a->rs1);
>  }
>  gen_helper_vsetvl(dst, cpu_env, s1, s2);
> -gen_set_gpr(a->rd, dst);
> +
>  gen_goto_tb(ctx, 0, ctx->pc_succ_insn);
>  ctx->base.is_jmp = DISAS_NORETURN;
> -
> -tcg_temp_free(s1);
> -tcg_temp_free(dst);
>  return true;
>  }
>
> @@ -173,7 +163,7 @@ static bool ldst_us_trans(uint32_t vd, uint32_t rs1, 
> uint32_t data,
>
>  dest = tcg_temp_new_ptr();
>  mask = tcg_temp_new_ptr();
> -base = tcg_temp_new();
> +base = gpr_src(s, rs1);
>
>  /*
>   * As simd_desc supports at most 256 bytes, and in this implementation,
> @@ -184,7 +174,6 @@ static bool ldst_us_trans(uint32_t vd, uint32_t rs1, 
> uint32_t data,
>   */
>  desc = tcg_constant_i32(simd_desc(s->vlen / 8, s->vlen / 8, data));
>
> -gen_get_gpr(base, rs1);
>  tcg_gen_addi_ptr(dest, cpu_env, vreg_ofs(s, vd));
>  tcg_gen_addi_ptr(mask, cpu_env, vreg_ofs(s, 0));
>
> @@ -192,7 +181,6 @@ static bool ldst_us_trans(uint32_t vd, uint32_t rs1, 
> uint32_t data,
>
>  tcg_temp_free_ptr(dest);
>  tcg_temp_free_ptr(mask);
> -tcg_temp_free(base);
>  gen_set_label(over);
>  return true;
>  }
> @@ -330,12 +318,10 @@ static bool ldst_stride_trans(uint32_t vd, uint32_t 
> rs1, uint32_t rs2,
>
>  dest = tcg_temp_new_ptr();
>  mask = tcg_temp_new_ptr();
> -base = tcg_temp_new();
> -stride = tcg_temp_new();
> +base = gpr_src(s, rs1);
> +stride = gpr_src(s, rs2);
>  desc = tcg_constant_i32(simd_desc(s->vlen / 8, s->vlen / 8, data));
>
> -gen_get_gpr(base, rs1);
> -gen_get_gpr(stride, rs2);
>  tcg_gen_addi_ptr(dest, cpu_env, vreg_ofs(s, vd));
>  tcg_gen_addi_ptr(mask, cpu_env, vreg_ofs(s, 0));
>
> @@ -343,8 +329,6 @@ static bool ldst_stride_trans(uint32_t vd, uint32_t rs1, 
> uint32_t rs2,
>
>  tcg_temp_free_ptr(dest);
>  tcg_temp_free_ptr(mask);
> -tcg_temp_free(base);
> -tcg_temp_free(stride);
>  gen_set_label(over);
>  return true;
>  }
> @@ -458,10 +442,9 @@ static bool ldst_index_trans(uint32_t vd, uint32_t rs1, 
> uint32_t vs2,
>  dest = tcg_temp_new_ptr();
>  mask = tcg_temp_new_ptr();
>  index = tcg_temp_new_ptr();
> -base = tcg_temp_new();
> +base = gpr_src(s, rs1);
>  desc = tcg_constant_i32(simd_desc(s->vlen / 8, s->vlen / 8, data));
>
> -gen_get_gpr(base, rs1);
>  tcg_gen_addi_ptr(dest, cpu_env, vreg_ofs(s, vd));
>  tcg_gen_addi_ptr(index, cpu_env, vreg_ofs(s, vs2));
>  tcg_gen_addi_ptr(mask, cpu_env, vreg_ofs(s, 0));
> @@ -471,7 +454,6 @@ static bool ldst_index_trans(uint32_t vd, uint32_t rs1, 
> uint32_t vs2,
>  tcg_temp_free_ptr(dest);
>  tcg_temp_free_ptr(mask);
>  tcg_temp_free_ptr(index);
> -tcg_temp_free(base);
>  gen_set_label(over);
>  return true;
>  }
> @@ -589,10 +571,9 @@ static bool ldff_trans(uint32_t vd, uint32_t rs1, 
> uint32_t data,
>
>  dest = tcg_temp_new_ptr();
>  mask = tcg_temp_new_ptr();
> -base = tcg_temp_new();
> +base = 

Re: [PATCH 15/17] target/riscv: Use gen_arith for mulh and mulhu

[Alistair Francis]

On Fri, Jul 9, 2021 at 2:40 PM Richard Henderson
 wrote:
>
> Split out gen_mulh and gen_mulhu and use the common helper.
>
> Signed-off-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/translate.c| 16 
>  target/riscv/insn_trans/trans_rvm.c.inc | 24 ++--
>  2 files changed, 18 insertions(+), 22 deletions(-)
>
> diff --git a/target/riscv/translate.c b/target/riscv/translate.c
> index 6ad40e43b0..8ff75a5798 100644
> --- a/target/riscv/translate.c
> +++ b/target/riscv/translate.c
> @@ -235,6 +235,22 @@ static TCGv gpr_dst(DisasContext *ctx, int reg_num)
>  return cpu_gpr[reg_num];
>  }
>
> +static void gen_mulh(TCGv ret, TCGv s1, TCGv s2)
> +{
> +TCGv discard = tcg_temp_new();
> +
> +tcg_gen_muls2_tl(discard, ret, s1, s2);
> +tcg_temp_free(discard);
> +}
> +
> +static void gen_mulhu(TCGv ret, TCGv s1, TCGv s2)
> +{
> +TCGv discard = tcg_temp_new();
> +
> +tcg_gen_mulu2_tl(discard, ret, s1, s2);
> +tcg_temp_free(discard);
> +}
> +
>  static void gen_mulhsu(TCGv ret, TCGv arg1, TCGv arg2)
>  {
>  TCGv rl = tcg_temp_new();
> diff --git a/target/riscv/insn_trans/trans_rvm.c.inc 
> b/target/riscv/insn_trans/trans_rvm.c.inc
> index 10ecc456fc..34220b824d 100644
> --- a/target/riscv/insn_trans/trans_rvm.c.inc
> +++ b/target/riscv/insn_trans/trans_rvm.c.inc
> @@ -28,17 +28,7 @@ static bool trans_mul(DisasContext *ctx, arg_mul *a)
>  static bool trans_mulh(DisasContext *ctx, arg_mulh *a)
>  {
>  REQUIRE_EXT(ctx, RVM);
> -TCGv source1 = tcg_temp_new();
> -TCGv source2 = tcg_temp_new();
> -gen_get_gpr(source1, a->rs1);
> -gen_get_gpr(source2, a->rs2);
> -
> -tcg_gen_muls2_tl(source2, source1, source1, source2);
> -
> -gen_set_gpr(a->rd, source1);
> -tcg_temp_free(source1);
> -tcg_temp_free(source2);
> -return true;
> +return gen_arith(ctx, a, gen_mulh);
>  }
>
>  static bool trans_mulhsu(DisasContext *ctx, arg_mulhsu *a)
> @@ -50,17 +40,7 @@ static bool trans_mulhsu(DisasContext *ctx, arg_mulhsu *a)
>  static bool trans_mulhu(DisasContext *ctx, arg_mulhu *a)
>  {
>  REQUIRE_EXT(ctx, RVM);
> -TCGv source1 = tcg_temp_new();
> -TCGv source2 = tcg_temp_new();
> -gen_get_gpr(source1, a->rs1);
> -gen_get_gpr(source2, a->rs2);
> -
> -tcg_gen_mulu2_tl(source2, source1, source1, source2);
> -
> -gen_set_gpr(a->rd, source1);
> -tcg_temp_free(source1);
> -tcg_temp_free(source2);
> -return true;
> +return gen_arith(ctx, a, gen_mulhu);
>  }
>
>  static bool trans_div(DisasContext *ctx, arg_div *a)
> --
> 2.25.1
>
>

Re: [PATCH 13/17] target/riscv: Use gpr_{src,dst} for RVD

[Alistair Francis]

On Fri, Jul 9, 2021 at 2:42 PM Richard Henderson
 wrote:
>
> Signed-off-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/insn_trans/trans_rvd.c.inc | 116 +---
>  1 file changed, 44 insertions(+), 72 deletions(-)
>
> diff --git a/target/riscv/insn_trans/trans_rvd.c.inc 
> b/target/riscv/insn_trans/trans_rvd.c.inc
> index 7e45538ae0..9bb15fdc12 100644
> --- a/target/riscv/insn_trans/trans_rvd.c.inc
> +++ b/target/riscv/insn_trans/trans_rvd.c.inc
> @@ -22,14 +22,22 @@ static bool trans_fld(DisasContext *ctx, arg_fld *a)
>  {
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVD);
> -TCGv t0 = tcg_temp_new();
> -gen_get_gpr(t0, a->rs1);
> -tcg_gen_addi_tl(t0, t0, a->imm);
>
> -tcg_gen_qemu_ld_i64(cpu_fpr[a->rd], t0, ctx->mem_idx, MO_TEQ);
> +TCGv addr = gpr_src(ctx, a->rs1);
> +TCGv temp = NULL;
>
> +if (a->imm) {
> +temp = tcg_temp_new();
> +tcg_gen_addi_tl(temp, addr, a->imm);
> +addr = temp;
> +}
> +
> +tcg_gen_qemu_ld_i64(cpu_fpr[a->rd], addr, ctx->mem_idx, MO_TEQ);
> +
> +if (temp) {
> +tcg_temp_free(temp);
> +}
>  mark_fs_dirty(ctx);
> -tcg_temp_free(t0);
>  return true;
>  }
>
> @@ -37,13 +45,21 @@ static bool trans_fsd(DisasContext *ctx, arg_fsd *a)
>  {
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVD);
> -TCGv t0 = tcg_temp_new();
> -gen_get_gpr(t0, a->rs1);
> -tcg_gen_addi_tl(t0, t0, a->imm);
>
> -tcg_gen_qemu_st_i64(cpu_fpr[a->rs2], t0, ctx->mem_idx, MO_TEQ);
> +TCGv addr = gpr_src(ctx, a->rs1);
> +TCGv temp = NULL;
>
> -tcg_temp_free(t0);
> +if (a->imm) {
> +temp = tcg_temp_new();
> +tcg_gen_addi_tl(temp, addr, a->imm);
> +addr = temp;
> +}
> +
> +tcg_gen_qemu_st_i64(cpu_fpr[a->rs2], addr, ctx->mem_idx, MO_TEQ);
> +
> +if (temp) {
> +tcg_temp_free(temp);
> +}
>  return true;
>  }
>
> @@ -252,11 +268,8 @@ static bool trans_feq_d(DisasContext *ctx, arg_feq_d *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVD);
>
> -TCGv t0 = tcg_temp_new();
> -gen_helper_feq_d(t0, cpu_env, cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> -
> +gen_helper_feq_d(gpr_dst(ctx, a->rd), cpu_env,
> + cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
>  return true;
>  }
>
> @@ -265,11 +278,8 @@ static bool trans_flt_d(DisasContext *ctx, arg_flt_d *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVD);
>
> -TCGv t0 = tcg_temp_new();
> -gen_helper_flt_d(t0, cpu_env, cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> -
> +gen_helper_flt_d(gpr_dst(ctx, a->rd), cpu_env,
> + cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
>  return true;
>  }
>
> @@ -278,11 +288,8 @@ static bool trans_fle_d(DisasContext *ctx, arg_fle_d *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVD);
>
> -TCGv t0 = tcg_temp_new();
> -gen_helper_fle_d(t0, cpu_env, cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> -
> +gen_helper_fle_d(gpr_dst(ctx, a->rd), cpu_env,
> + cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
>  return true;
>  }
>
> @@ -291,10 +298,7 @@ static bool trans_fclass_d(DisasContext *ctx, 
> arg_fclass_d *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVD);
>
> -TCGv t0 = tcg_temp_new();
> -gen_helper_fclass_d(t0, cpu_fpr[a->rs1]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> +gen_helper_fclass_d(gpr_dst(ctx, a->rd), cpu_fpr[a->rs1]);
>  return true;
>  }
>
> @@ -303,12 +307,8 @@ static bool trans_fcvt_w_d(DisasContext *ctx, 
> arg_fcvt_w_d *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVD);
>
> -TCGv t0 = tcg_temp_new();
>  gen_set_rm(ctx, a->rm);
> -gen_helper_fcvt_w_d(t0, cpu_env, cpu_fpr[a->rs1]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> -
> +gen_helper_fcvt_w_d(gpr_dst(ctx, a->rd), cpu_env, cpu_fpr[a->rs1]);
>  return true;
>  }
>
> @@ -317,12 +317,8 @@ static bool trans_fcvt_wu_d(DisasContext *ctx, 
> arg_fcvt_wu_d *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVD);
>
> -TCGv t0 = tcg_temp_new();
>  gen_set_rm(ctx, a->rm);
> -gen_helper_fcvt_wu_d(t0, cpu_env, cpu_fpr[a->rs1]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> -
> +gen_helper_fcvt_wu_d(gpr_dst(ctx, a->rd), cpu_env, cpu_fpr[a->rs1]);
>  return true;
>  }
>
> @@ -331,12 +327,8 @@ static bool trans_fcvt_d_w(DisasContext *ctx, 
> arg_fcvt_d_w *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVD);
>
> -TCGv t0 = tcg_temp_new();
> -gen_get_gpr(t0, a->rs1);
> -
>  gen_set_rm(ctx, a->rm);
> -gen_helper_fcvt_d_w(cpu_fpr[a->rd], cpu_env, t0);
> -tcg_temp_free(t0);
> +gen_helper_fcvt_d_w(cpu_fpr[a->rd], cpu_env, gpr_src(ctx, a->rs1));
>
>  mark_fs_dirty(ctx);
>  return true;
> @@ -347,12 +339,8 @@ static bool trans_fcvt_d_wu(DisasContext 

Re: [PATCH 12/17] target/riscv: Use gpr_{src,dst} for RVF

[Alistair Francis]

On Fri, Jul 9, 2021 at 2:49 PM Richard Henderson
 wrote:
>
> Signed-off-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/insn_trans/trans_rvf.c.inc | 131 +---
>  1 file changed, 49 insertions(+), 82 deletions(-)
>
> diff --git a/target/riscv/insn_trans/trans_rvf.c.inc 
> b/target/riscv/insn_trans/trans_rvf.c.inc
> index 89f78701e7..ff8e942199 100644
> --- a/target/riscv/insn_trans/trans_rvf.c.inc
> +++ b/target/riscv/insn_trans/trans_rvf.c.inc
> @@ -27,14 +27,23 @@ static bool trans_flw(DisasContext *ctx, arg_flw *a)
>  {
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVF);
> -TCGv t0 = tcg_temp_new();
> -gen_get_gpr(t0, a->rs1);
> -tcg_gen_addi_tl(t0, t0, a->imm);
>
> -tcg_gen_qemu_ld_i64(cpu_fpr[a->rd], t0, ctx->mem_idx, MO_TEUL);
> -gen_nanbox_s(cpu_fpr[a->rd], cpu_fpr[a->rd]);
> +TCGv addr = gpr_src(ctx, a->rs1);
> +TCGv temp = NULL;
>
> -tcg_temp_free(t0);
> +if (a->imm) {
> +temp = tcg_temp_new();
> +tcg_gen_addi_tl(temp, addr, a->imm);
> +addr = temp;
> +}
> +
> +TCGv_i64 dest = cpu_fpr[a->rd];
> +tcg_gen_qemu_ld_i64(dest, addr, ctx->mem_idx, MO_TEUL);
> +gen_nanbox_s(dest, dest);
> +
> +if (temp) {
> +tcg_temp_free(temp);
> +}
>  mark_fs_dirty(ctx);
>  return true;
>  }
> @@ -43,14 +52,21 @@ static bool trans_fsw(DisasContext *ctx, arg_fsw *a)
>  {
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVF);
> -TCGv t0 = tcg_temp_new();
> -gen_get_gpr(t0, a->rs1);
>
> -tcg_gen_addi_tl(t0, t0, a->imm);
> +TCGv addr = gpr_src(ctx, a->rs1);
> +TCGv temp = NULL;
>
> -tcg_gen_qemu_st_i64(cpu_fpr[a->rs2], t0, ctx->mem_idx, MO_TEUL);
> +if (a->imm) {
> +temp = tcg_temp_new();
> +tcg_gen_addi_tl(temp, addr, a->imm);
> +addr = temp;
> +}
>
> -tcg_temp_free(t0);
> +tcg_gen_qemu_st_i64(cpu_fpr[a->rs2], addr, ctx->mem_idx, MO_TEUL);
> +
> +if (temp) {
> +tcg_temp_free(temp);
> +}
>  return true;
>  }
>
> @@ -271,12 +287,8 @@ static bool trans_fcvt_w_s(DisasContext *ctx, 
> arg_fcvt_w_s *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVF);
>
> -TCGv t0 = tcg_temp_new();
>  gen_set_rm(ctx, a->rm);
> -gen_helper_fcvt_w_s(t0, cpu_env, cpu_fpr[a->rs1]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> -
> +gen_helper_fcvt_w_s(gpr_dst(ctx, a->rd), cpu_env, cpu_fpr[a->rs1]);
>  return true;
>  }
>
> @@ -285,12 +297,8 @@ static bool trans_fcvt_wu_s(DisasContext *ctx, 
> arg_fcvt_wu_s *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVF);
>
> -TCGv t0 = tcg_temp_new();
>  gen_set_rm(ctx, a->rm);
> -gen_helper_fcvt_wu_s(t0, cpu_env, cpu_fpr[a->rs1]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> -
> +gen_helper_fcvt_wu_s(gpr_dst(ctx, a->rd), cpu_env, cpu_fpr[a->rs1]);
>  return true;
>  }
>
> @@ -300,17 +308,14 @@ static bool trans_fmv_x_w(DisasContext *ctx, 
> arg_fmv_x_w *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVF);
>
> -TCGv t0 = tcg_temp_new();
> +TCGv dest = gpr_dst(ctx, a->rd);
>
>  #if defined(TARGET_RISCV64)
> -tcg_gen_ext32s_tl(t0, cpu_fpr[a->rs1]);
> +tcg_gen_ext32s_tl(dest, cpu_fpr[a->rs1]);
>  #else
> -tcg_gen_extrl_i64_i32(t0, cpu_fpr[a->rs1]);
> +tcg_gen_extrl_i64_i32(dest, cpu_fpr[a->rs1]);
>  #endif
>
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> -
>  return true;
>  }
>
> @@ -318,10 +323,9 @@ static bool trans_feq_s(DisasContext *ctx, arg_feq_s *a)
>  {
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVF);
> -TCGv t0 = tcg_temp_new();
> -gen_helper_feq_s(t0, cpu_env, cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> +
> +gen_helper_feq_s(gpr_dst(ctx, a->rd), cpu_env,
> + cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
>  return true;
>  }
>
> @@ -329,10 +333,9 @@ static bool trans_flt_s(DisasContext *ctx, arg_flt_s *a)
>  {
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVF);
> -TCGv t0 = tcg_temp_new();
> -gen_helper_flt_s(t0, cpu_env, cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> +
> +gen_helper_flt_s(gpr_dst(ctx, a->rd), cpu_env,
> + cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
>  return true;
>  }
>
> @@ -340,10 +343,9 @@ static bool trans_fle_s(DisasContext *ctx, arg_fle_s *a)
>  {
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVF);
> -TCGv t0 = tcg_temp_new();
> -gen_helper_fle_s(t0, cpu_env, cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
> -gen_set_gpr(a->rd, t0);
> -tcg_temp_free(t0);
> +
> +gen_helper_fle_s(gpr_dst(ctx, a->rd), cpu_env,
> + cpu_fpr[a->rs1], cpu_fpr[a->rs2]);
>  return true;
>  }
>
> @@ -352,13 +354,7 @@ static bool trans_fclass_s(DisasContext *ctx, 
> arg_fclass_s *a)
>  REQUIRE_FPU;
>  REQUIRE_EXT(ctx, RVF);
>
> -TCGv t0 = tcg_temp_new();
> -
> -

Re: [PATCH 11/17] target/riscv: Use gpr_{src,dst} for RVB

[Alistair Francis]

On Fri, Jul 9, 2021 at 2:37 PM Richard Henderson
 wrote:
>
> Signed-off-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/insn_trans/trans_rvb.c.inc | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
> b/target/riscv/insn_trans/trans_rvb.c.inc
> index 9e81f6e3de..58921f3224 100644
> --- a/target/riscv/insn_trans/trans_rvb.c.inc
> +++ b/target/riscv/insn_trans/trans_rvb.c.inc
> @@ -423,16 +423,13 @@ static bool trans_slli_uw(DisasContext *ctx, 
> arg_slli_uw *a)
>  REQUIRE_64BIT(ctx);
>  REQUIRE_EXT(ctx, RVB);
>
> -TCGv source1 = tcg_temp_new();
> -gen_get_gpr(source1, a->rs1);
> +TCGv dest = gpr_dst(ctx, a->rd);
> +TCGv src1 = gpr_src(ctx, a->rs1);
>
>  if (a->shamt < 32) {
> -tcg_gen_deposit_z_tl(source1, source1, a->shamt, 32);
> +tcg_gen_deposit_z_tl(dest, src1, a->shamt, 32);
>  } else {
> -tcg_gen_shli_tl(source1, source1, a->shamt);
> +tcg_gen_shli_tl(dest, src1, a->shamt);
>  }
> -
> -gen_set_gpr(a->rd, source1);
> -tcg_temp_free(source1);
>  return true;
>  }
> --
> 2.25.1
>
>

Re: [PATCH 10/17] target/riscv: Use gpr_{src,dst} for RVA

[Alistair Francis]

On Fri, Jul 9, 2021 at 2:39 PM Richard Henderson
 wrote:
>
> Signed-off-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/insn_trans/trans_rva.c.inc | 42 +
>  1 file changed, 14 insertions(+), 28 deletions(-)
>
> diff --git a/target/riscv/insn_trans/trans_rva.c.inc 
> b/target/riscv/insn_trans/trans_rva.c.inc
> index ab2ec4f0a5..5bb5bbd09c 100644
> --- a/target/riscv/insn_trans/trans_rva.c.inc
> +++ b/target/riscv/insn_trans/trans_rva.c.inc
> @@ -18,11 +18,11 @@
>   * this program.  If not, see .
>   */
>
> -static inline bool gen_lr(DisasContext *ctx, arg_atomic *a, MemOp mop)
> +static bool gen_lr(DisasContext *ctx, arg_atomic *a, MemOp mop)
>  {
> -TCGv src1 = tcg_temp_new();
> +TCGv src1 = gpr_src(ctx, a->rs1);
> +
>  /* Put addr in load_res, data in load_val.  */
> -gen_get_gpr(src1, a->rs1);
>  if (a->rl) {
>  tcg_gen_mb(TCG_MO_ALL | TCG_BAR_STRL);
>  }
> @@ -33,30 +33,26 @@ static inline bool gen_lr(DisasContext *ctx, arg_atomic 
> *a, MemOp mop)
>  tcg_gen_mov_tl(load_res, src1);
>  gen_set_gpr(a->rd, load_val);
>
> -tcg_temp_free(src1);
>  return true;
>  }
>
> -static inline bool gen_sc(DisasContext *ctx, arg_atomic *a, MemOp mop)
> +static bool gen_sc(DisasContext *ctx, arg_atomic *a, MemOp mop)
>  {
> -TCGv src1 = tcg_temp_new();
> -TCGv src2 = tcg_temp_new();
> -TCGv dat = tcg_temp_new();
> +TCGv dest = gpr_dst(ctx, a->rd);
> +TCGv src1 = gpr_src(ctx, a->rs1);
> +TCGv src2 = gpr_src(ctx, a->rs2);
>  TCGLabel *l1 = gen_new_label();
>  TCGLabel *l2 = gen_new_label();
>
> -gen_get_gpr(src1, a->rs1);
>  tcg_gen_brcond_tl(TCG_COND_NE, load_res, src1, l1);
>
> -gen_get_gpr(src2, a->rs2);
>  /*
>   * Note that the TCG atomic primitives are SC,
>   * so we can ignore AQ/RL along this path.
>   */
> -tcg_gen_atomic_cmpxchg_tl(src1, load_res, load_val, src2,
> +tcg_gen_atomic_cmpxchg_tl(dest, load_res, load_val, src2,
>ctx->mem_idx, mop);
> -tcg_gen_setcond_tl(TCG_COND_NE, dat, src1, load_val);
> -gen_set_gpr(a->rd, dat);
> +tcg_gen_setcond_tl(TCG_COND_NE, dest, dest, load_val);
>  tcg_gen_br(l2);
>
>  gen_set_label(l1);
> @@ -65,8 +61,7 @@ static inline bool gen_sc(DisasContext *ctx, arg_atomic *a, 
> MemOp mop)
>   * provide the memory barrier implied by AQ/RL.
>   */
>  tcg_gen_mb(TCG_MO_ALL + a->aq * TCG_BAR_LDAQ + a->rl * TCG_BAR_STRL);
> -tcg_gen_movi_tl(dat, 1);
> -gen_set_gpr(a->rd, dat);
> +tcg_gen_movi_tl(dest, 1);
>
>  gen_set_label(l2);
>  /*
> @@ -75,9 +70,6 @@ static inline bool gen_sc(DisasContext *ctx, arg_atomic *a, 
> MemOp mop)
>   */
>  tcg_gen_movi_tl(load_res, -1);
>
> -tcg_temp_free(dat);
> -tcg_temp_free(src1);
> -tcg_temp_free(src2);
>  return true;
>  }
>
> @@ -85,17 +77,11 @@ static bool gen_amo(DisasContext *ctx, arg_atomic *a,
>  void(*func)(TCGv, TCGv, TCGv, TCGArg, MemOp),
>  MemOp mop)
>  {
> -TCGv src1 = tcg_temp_new();
> -TCGv src2 = tcg_temp_new();
> +TCGv dest = gpr_dst(ctx, a->rd);
> +TCGv src1 = gpr_src(ctx, a->rs1);
> +TCGv src2 = gpr_src(ctx, a->rs2);
>
> -gen_get_gpr(src1, a->rs1);
> -gen_get_gpr(src2, a->rs2);
> -
> -(*func)(src2, src1, src2, ctx->mem_idx, mop);
> -
> -gen_set_gpr(a->rd, src2);
> -tcg_temp_free(src1);
> -tcg_temp_free(src2);
> +(*func)(dest, src1, src2, ctx->mem_idx, mop);
>  return true;
>  }
>
> --
> 2.25.1
>
>

Re: [PATCH 08/17] target/riscv: Use gpr_{src, dst} for word shift operations

[Alistair Francis]

On Fri, Jul 9, 2021 at 2:35 PM Richard Henderson
 wrote:
>
> For trans_sllw, we can just use gen_shiftw.  The others use
> various tricks to reduce the tcg operation count.
>
> Signed-off-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/insn_trans/trans_rvi.c.inc | 82 ++---
>  1 file changed, 31 insertions(+), 51 deletions(-)
>
> diff --git a/target/riscv/insn_trans/trans_rvi.c.inc 
> b/target/riscv/insn_trans/trans_rvi.c.inc
> index a422dc9ef4..840187a4d6 100644
> --- a/target/riscv/insn_trans/trans_rvi.c.inc
> +++ b/target/riscv/insn_trans/trans_rvi.c.inc
> @@ -352,24 +352,23 @@ static bool trans_slliw(DisasContext *ctx, arg_slliw *a)
>  static bool trans_srliw(DisasContext *ctx, arg_srliw *a)
>  {
>  REQUIRE_64BIT(ctx);
> -TCGv t = tcg_temp_new();
> -gen_get_gpr(t, a->rs1);
> -tcg_gen_extract_tl(t, t, a->shamt, 32 - a->shamt);
> -/* sign-extend for W instructions */
> -tcg_gen_ext32s_tl(t, t);
> -gen_set_gpr(a->rd, t);
> -tcg_temp_free(t);
> +
> +TCGv dest = gpr_dst(ctx, a->rd);
> +TCGv src1 = gpr_src(ctx, a->rs1);
> +
> +tcg_gen_extract_tl(dest, src1, a->shamt, 32 - a->shamt);
> +tcg_gen_ext32s_tl(dest, dest);
>  return true;
>  }
>
>  static bool trans_sraiw(DisasContext *ctx, arg_sraiw *a)
>  {
>  REQUIRE_64BIT(ctx);
> -TCGv t = tcg_temp_new();
> -gen_get_gpr(t, a->rs1);
> -tcg_gen_sextract_tl(t, t, a->shamt, 32 - a->shamt);
> -gen_set_gpr(a->rd, t);
> -tcg_temp_free(t);
> +
> +TCGv dest = gpr_dst(ctx, a->rd);
> +TCGv src1 = gpr_src(ctx, a->rs1);
> +
> +tcg_gen_sextract_tl(dest, src1, a->shamt, 32 - a->shamt);
>  return true;
>  }
>
> @@ -388,64 +387,45 @@ static bool trans_subw(DisasContext *ctx, arg_subw *a)
>  static bool trans_sllw(DisasContext *ctx, arg_sllw *a)
>  {
>  REQUIRE_64BIT(ctx);
> -TCGv source1 = tcg_temp_new();
> -TCGv source2 = tcg_temp_new();
> -
> -gen_get_gpr(source1, a->rs1);
> -gen_get_gpr(source2, a->rs2);
> -
> -tcg_gen_andi_tl(source2, source2, 0x1F);
> -tcg_gen_shl_tl(source1, source1, source2);
> -
> -tcg_gen_ext32s_tl(source1, source1);
> -gen_set_gpr(a->rd, source1);
> -tcg_temp_free(source1);
> -tcg_temp_free(source2);
> -return true;
> +return gen_shiftw(ctx, a, tcg_gen_shl_tl);
>  }
>
>  static bool trans_srlw(DisasContext *ctx, arg_srlw *a)
>  {
>  REQUIRE_64BIT(ctx);
> -TCGv source1 = tcg_temp_new();
> -TCGv source2 = tcg_temp_new();
>
> -gen_get_gpr(source1, a->rs1);
> -gen_get_gpr(source2, a->rs2);
> +TCGv dest = gpr_dst(ctx, a->rd);
> +TCGv src1 = gpr_src(ctx, a->rs1);
> +TCGv src2 = gpr_src(ctx, a->rs2);
> +TCGv ext2 = tcg_temp_new();
>
> -/* clear upper 32 */
> -tcg_gen_ext32u_tl(source1, source1);
> -tcg_gen_andi_tl(source2, source2, 0x1F);
> -tcg_gen_shr_tl(source1, source1, source2);
> +tcg_gen_andi_tl(ext2, src2, 31);
> +tcg_gen_ext32u_tl(dest, src1);
> +tcg_gen_shr_tl(dest, dest, ext2);
> +tcg_gen_ext32s_tl(dest, dest);
>
> -tcg_gen_ext32s_tl(source1, source1);
> -gen_set_gpr(a->rd, source1);
> -tcg_temp_free(source1);
> -tcg_temp_free(source2);
> +tcg_temp_free(ext2);
>  return true;
>  }
>
>  static bool trans_sraw(DisasContext *ctx, arg_sraw *a)
>  {
>  REQUIRE_64BIT(ctx);
> -TCGv source1 = tcg_temp_new();
> -TCGv source2 = tcg_temp_new();
>
> -gen_get_gpr(source1, a->rs1);
> -gen_get_gpr(source2, a->rs2);
> +TCGv dest = gpr_dst(ctx, a->rd);
> +TCGv src1 = gpr_src(ctx, a->rs1);
> +TCGv src2 = gpr_src(ctx, a->rs2);
> +TCGv ext2 = tcg_temp_new();
>
> +tcg_gen_andi_tl(ext2, src2, 31);
>  /*
> - * first, trick to get it to act like working on 32 bits (get rid of
> - * upper 32, sign extend to fill space)
> + * First, trick to get it to act like working on 32 bits
> + * (get rid of upper 32, sign extend to fill space)
>   */
> -tcg_gen_ext32s_tl(source1, source1);
> -tcg_gen_andi_tl(source2, source2, 0x1F);
> -tcg_gen_sar_tl(source1, source1, source2);
> -
> -gen_set_gpr(a->rd, source1);
> -tcg_temp_free(source1);
> -tcg_temp_free(source2);
> +tcg_gen_ext32s_tl(dest, src1);
> +tcg_gen_sar_tl(dest, dest, ext2);
>
> +tcg_temp_free(ext2);
>  return true;
>  }
>
> --
> 2.25.1
>
>

[Bug 1924914] Re: Running sway in a QEMU VM results in a GPU hang of the guest (virtio-gpu driver)

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Running sway in a QEMU VM results in a GPU hang of the guest (virtio-
  gpu driver)

Status in QEMU:
  Expired

Bug description:
  System is Arch Linux (guest and host OS).

  Problem:

  Basically, when using sway on a guest and running certain applications
  via Xwayland (on the guest), the GUI will freeze and won't be usable
  anymore, I can still ssh to the guest and run commands.

  This is the command I use to run my guest:

  qemu-system-x86_64 -enable-kvm -cdrom
  ~/Downloads/linux/archlinux/archlinux-2021.04.01-x86_64.iso -m 4G -vga
  virtio -nic user,hostfwd=tcp::10022-:22

  This doesn't happen when I use X with i3-wm.

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

[Bug 1924987] Re: Storage | Two decimal digits precision

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Storage | Two decimal digits precision

Status in QEMU:
  Expired

Bug description:
  Tested on: Fedora 34; Component: qemu-img-5.2.0-5.fc34.1.x86_64

  Hello. A two decimal digits precision is most appropriated on systems
  whose storage capacities have to be saved. That is one of the reason
  why such precision is supported in the context of creation of virtual
  machines in several Unix/Linux virtualization platforms; virt-manager
  is one of them. That last exhibits virtual disks size values with such
  precision – 128.00 GiB – nevertheless it lacks yet a mention
  illustrating physical disks size values.

  Storage values exhibited in qemu-img and virt-manager are already
  according to a clear format; thus, values are not attached to their
  measure units (#value# #units#).

  $ qemu-img info ~/.local/share/libvirt/images/fedora_default.img | sed -n 
'2,4p'
  file format: qcow2
  virtual size: 128 GiB (137438953472 bytes)
  disk size: 147 MiB

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

[Bug 1925094] Re: DISCARD support for Crypto Block Devices

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  DISCARD support for Crypto Block Devices

Status in QEMU:
  Expired

Bug description:
  It appears that running `fstrim` or similar is useless when the VM is
  on a LUKS-encrypted device using QEMU's native LUKS support.

  Looking at the source, it seems that block/crypto.c lacks an
  implementation for bdrv_co_pdiscard, which probably needs to delegate
  to a per-crypto type discard helper.

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

[Bug 1920934] Re: Heap-use-after-free in io_writex / cputlb.c results in Linux kernel crashes

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Heap-use-after-free in io_writex / cputlb.c results in Linux kernel
  crashes

Status in QEMU:
  Expired

Bug description:
  qemu version: git 5ca634afcf83215a9a54ca6e66032325b5ffb5f6; 5.2.0

  We've encountered that booting the Linux kernel in TCG mode, results
  in a racy heap-use-after-free. The bug can be detected by ASan [A],
  but in the majority of runs results in a crashing kernel [B].

  To reproduce, the following command line was used:

  $> while ./qemu-system-x86_64 -no-reboot -smp 10 -m 2G -kernel
  arch/x86/boot/bzImage -nographic -append "oops=panic panic_on_warn=1
  panic=1 kfence.sample_interval=1 nokaslr"; do sleep 0.5s; done

  The crashes in the kernel [B] appear to receive an interrupt in a code
  location where the instructions are periodically patched (via the
  jump_label infrastructure).

  [A]:
  = 


 
  ==3552508==ERROR: AddressSanitizer: heap-use-after-free on address 
0x6190007fef50 at pc 0x55885b0b4d1b bp 0x7f83baffb800 sp 0x7f83baffb7f8 


  READ of size 8 at 0x6190007fef50 thread T4


 
  [4.616506][T1] pci :00:02.0: reg 0x18: [mem 
0xfebf-0xfebf0fff]  

   
  [4.670567][T1] pci :00:02.0: reg 0x30: [mem 0xfebe-0xfebe 
pref]   

 
  [4.691345][T1] pci :00:03.0: [8086:100e] type 00 class 0x02   


 
  [4.701540][T1] pci :00:03.0: reg 0x10: [mem 
0xfebc-0xfebd]  

   
  [4.711076][T1] pci :00:03.0: reg 0x14: [io  0xc000-0xc03f]


 
  [4.746869][T1] pci :00:03.0: reg 0x30: [mem 0xfeb8-0xfebb 
pref]   

 
  [4.813612][T1] ACPI: PCI Interrupt Link [LNKA] (IRQs 5 *10 11)


 
  #0 0x55885b0b4d1a in io_writex ../accel/tcg/cputlb.c:1408 


 
  #1 0x55885b0d3b9f in store_helper ../accel/tcg/cputlb.c:2444  


 
  #2 0x55885b0d3b9f in helper_le_stl_mmu ../accel/tcg/cputlb.c:2510 


 
  [4.820927][T1] ACPI: PCI Interrupt Link [LNKB] (IRQs 5 *10 11)


 
  #3 0x7f843cedf8dc  () 

  

[Bug 1925109] Re: usbredirparser: bulk transfer length exceeds limits

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  usbredirparser: bulk transfer length exceeds limits

Status in QEMU:
  Expired

Bug description:
  2021-04-20T01:26:36.662244Z qemu-system-x86_64: usbredirparser: bulk transfer 
length exceeds limits 131072 > 65536
  2021-04-20T01:26:36.662276Z qemu-system-x86_64: usbredirparser: error 
usbredirparser_send_* call invalid params, please report!!
  2021-04-20T01:26:57.670412Z qemu-system-x86_64: usbredirparser: bulk transfer 
length exceeds limits 131072 > 65536
  2021-04-20T01:26:57.670445Z qemu-system-x86_64: usbredirparser: error 
usbredirparser_send_* call invalid params, please report!!
  2021-04-20T01:37:01.920613Z qemu-system-x86_64: usbredirparser: bulk transfer 
length exceeds limits 131072 > 65536
  2021-04-20T01:37:01.920624Z qemu-system-x86_64: usbredirparser: error 
usbredirparser_send_* call invalid params, please report!!
  host:
  Linux version 5.11.15-arch1-2 (linux@archlinux) (gcc (GCC) 10.2.0, GNU ld 
(GNU Binutils) 2.36.1) #1 SMP PREEMPT Sat, 17 Apr 2021 00:22:30 +
  guest:
  win10 20H2
  usb device:
  Bus 002 Device 007: ID 0781:55ab SanDisk Corp.  SanDisk 3.2Gen1
  size 250G

  
https://gitlab.freedesktop.org/spice/usbredir/-/blob/master/usbredirparser/usbredirparser.c#L32

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

[Bug 1926202] Re: qemu-user can't run some ppc binaries

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  qemu-user can't run some ppc binaries

Status in QEMU:
  Expired

Bug description:
  qemu-user v6.0.0-rc5, built in static mode, will crash for certain ppc
  binaries.  It seems to have something to do with glibc for some Centos
  versions.  The problem is easiest to see with statically-linked
  binaries.

  The attached Dockerfile shows how to produce a ppc binary that will
  crash qemu-user.  Here is how to reproduce the problem:

  $ uname -m
  x86_64

  $ docker run --rm --privileged multiarch/qemu-user-static --reset -p
  yes

  $ docker build -t qemu-bug:centos -f Dockerfile.centos .

  $ docker run --rm -it -v$PWD:$PWD -w$PWD qemu-bug:centos cp
  /helloworld-centos.static.ppc .

  $ qemu-ppc-static --version
  qemu-ppc version 5.2.95 (v6.0.0-rc5)
  Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers

  $ qemu-ppc-static ./helloworld-centos.static.ppc
  emu: uncaught target signal 4 (Illegal instruction) - core dumped
  [1]16678 illegal hardware instruction (core dumped)  qemu-ppc-static 
./helloworld-centos.static.ppc

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

[Bug 1925966] Re: Win10 guest freezes randomly

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Win10 guest freezes randomly

Status in QEMU:
  Expired

Bug description:
  In addition to bug #1916775, my Win10 Home guest freezes randomly and
  infrequently. Unlike bug ​#1916775, this is unrecoverable and I see on
  the host (Debian 4.19.171-2) via iotop that all disk IO has stopped.
  My only recourse is a hard reset of the guest.

  My setup uses PCI-pass-through graphics (GTX 1650), host cpu (Ryzen 7
  3800XT). It seems to occur more frequently (every few hours) after
  switching from "kvm=off,vendor=GenuineIntel" to "kvm=on" and maybe
  using 3 monitors rather than 2 on the pass-through graphics card
  further increases frequency. The switch to "kvm=on" was necessary to
  enable nested virtualization, which now works. It occurs whether or
  not I use the qcow disk drive.

  qemu-system-x86_64
    -cpu 
host,kvm=on,l3-cache=on,hv_relaxed,hv_vapic,hv_time,hv_spinlocks=0x1fff,hv_vendor_id=hv_dummy
    -smp 8
    -rtc clock=host,base=localtime
    -machine type=q35,accel=kvm,kernel_irqchip=on
    -enable-kvm
    -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd
    -drive if=pflash,format=raw,file=/tmp/OVMF_VARS.fd
    -m 32G
    -usb
    -device usb-tablet
    -vga none
    -serial none
    -parallel none
    -boot cd
    -nographic
    -device usb-host,vendorid=0x045e,productid=0x00db
    -device usb-host,vendorid=0x1bcf,productid=0x0005
    -drive 
id=disk0,index=0,format=qcow2,if=virtio,cache=off,file=./win10_boot_priv.qcow2
    -drive 
id=disk2,index=2,aio=native,cache.direct=on,if=virtio,cache=off,format=raw,discard=unmap,detect-zeroes=unmap,file=/dev/vg0/win10_hdpriv
    -device vfio-pci,host=09:00.0,addr=0x02.0x0,multifunction=on
    -device vfio-pci,host=09:00.1,addr=0x02.0x1
    -device vfio-pci,host=09:00.2,addr=0x02.0x2
    -device vfio-pci,host=09:00.3,addr=0x02.0x3
    -netdev tap,id=netid,ifname=taplan,script=no,downscript=no
    -device e1000,netdev=netid,mac=52:54:00:01:02:03

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

[Bug 1926596] Re: qemu-monitor-event command gets stuck randomly

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  qemu-monitor-event command gets stuck randomly

Status in QEMU:
  Expired

Bug description:
  We are using kvm virtualization on our servers, We use 
"qemu-monitor-command"(drive-backup) to take qcow2 backups and to monitor them 
we use "qemu-monitor-event" command 
  For eg:-
  /usr/bin/virsh qemu-monitor-event VPSNAME --event 
"BLOCK_JOB_COMPLETED\|BLOCK_JOB_ERROR" --regex

  the above command stucks randomly (backup completes but still it is
  waiting) and because of which other vms backup are stucked until we
  kill that process.

  Can you suggest how can we debug this further to find the actual
  issue.

  
  /usr/bin/virsh version

  Compiled against library: libvirt 4.5.0
  Using library: libvirt 4.5.0
  Using API: QEMU 4.5.0
  Running hypervisor: QEMU 2.0.0

  cat /etc/os-release
  NAME="CentOS Linux"
  VERSION="7 (Core)"
  ID="centos"
  ID_LIKE="rhel fedora"
  VERSION_ID="7"
  PRETTY_NAME="CentOS Linux 7 (Core)"
  ANSI_COLOR="0;31"
  CPE_NAME="cpe:/o:centos:centos:7"
  HOME_URL="https://www.centos.org/;
  BUG_REPORT_URL="https://bugs.centos.org/;

  CENTOS_MANTISBT_PROJECT="CentOS-7"
  CENTOS_MANTISBT_PROJECT_VERSION="7"
  REDHAT_SUPPORT_PRODUCT="centos"
  REDHAT_SUPPORT_PRODUCT_VERSION="7"

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

[Bug 1926231] Re: SCSI passthrough of SATA cdrom -> errors & performance issues

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  SCSI passthrough of SATA cdrom -> errors & performance issues

Status in QEMU:
  Expired

Bug description:
  qemu 5.0, compiled from git

  I am passing through a SATA cdrom via SCSI passthrough, with this
  libvirt XML:

  

  
  



  

  It seems to mostly work, I have written discs with it, except I am
  getting errors that cause reads to take about 5x as long as they
  should, under certain circumstances.  It appears to be based on the
  guest's read block size.

  I found that if on the guest I run, say `dd if=$some_large_file
  bs=262144|pv > /dev/null`, `iostat` and `pv` disagree about how much
  is being read by a factor of about 2.  Also many kernel messages like
  this happen on the guest:

  [  190.919684] sr 0:0:0:0: [sr0] tag#160 FAILED Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE cmd_age=0s
  [  190.919687] sr 0:0:0:0: [sr0] tag#160 Sense Key : Aborted Command 
[current] 
  [  190.919689] sr 0:0:0:0: [sr0] tag#160 Add. Sense: I/O process terminated
  [  190.919691] sr 0:0:0:0: [sr0] tag#160 CDB: Read(10) 28 00 00 18 a5 5a 00 
00 80 00
  [  190.919694] blk_update_request: I/O error, dev sr0, sector 6460776 op 
0x0:(READ) flags 0x80700 phys_seg 5 prio class 0

  If I change to bs=131072 the errors stop and performance is normal.

  (262144 happens to be the block size ultimately used by md5sum, which
  is how I got here)

  I also ran strace on the qemu process while it was happening, and
  noticed SG_IO calls like this:

  21748 10:06:29.330910 ioctl(22, SG_IO, {interface_id='S', 
dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, 
cmdp="\x28\x00\x00\x12\x95\x5a\x00\x00\x80\x00", mx_sb_len=252, iovec_count=0, 
dxfer_len=262144, timeout=4294967295, flags=SG_FLAG_DIRECT_IO 
  21751 10:06:29.330976 ioctl(22, SG_IO, {interface_id='S', 
dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, 
cmdp="\x28\x00\x00\x12\x94\xda\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, 
dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO 
  21749 10:06:29.331586 ioctl(22, SG_IO, {interface_id='S', 
dxfer_direction=SG_DXFER_FROM_DEV, cmd_len=10, 
cmdp="\x28\x00\x00\x12\x94\xdc\x00\x00\x02\x00", mx_sb_len=252, iovec_count=0, 
dxfer_len=4096, timeout=4294967295, flags=SG_FLAG_DIRECT_IO 
  [etc]

  I suspect qemu is the culprit because I have tried a 4.19 guest kernel
  as well as a 5.9 one, with the same result.

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

[Bug 1922773] Re: RISCV32 illegal instruction exception

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  RISCV32 illegal instruction exception

Status in QEMU:
  Expired

Bug description:
  I'm running a machine learning model on qemu riscv32 and I ran into
  illegal instruction exception for some reason. I wasn't sure if this
  is a bug and if so whether it is related to zephyr or qemu, however
  I'll try to provide as much as information to get a better
  understanding.

  Here is the assembly code that I'm running:

  0x8000bd74 <+0>:  lw  a4,0(a0)
 0x8000bd76 <+2>:   lw  a5,8(a0)
 0x8000bd78 <+4>:   lw  a0,0(a4)
 0x8000bd7a <+6>:   lw  a1,0(a5)
 0x8000bd7c <+8>:   li  a3,0
 0x8000bd7e <+10>:  j   0x8000bda4 
 0x8000bd80 <+12>:  addia5,a3,-2
 0x8000bd84 <+16>:  li  a2,27
 0x8000bd86 <+18>:  bgeua2,a5,0x8000bdae 

  => 0x8000bd8a <+22>:  fmv.w.x fa5,zero
 0x8000bd8e <+26>:  sllia5,a3,0x5
 0x8000bd92 <+30>:  add a5,a5,a4
 0x8000bd94 <+32>:  sllia5,a5,0x2
 0x8000bd96 <+34>:  add a5,a5,a1
 0x8000bd98 <+36>:  fsw fa5,0(a5)
 0x8000bd9a <+38>:  addia4,a4,1
 0x8000bd9c <+40>:  li  a5,31
 0x8000bd9e <+42>:  bge a5,a4,0x8000bd80 

 0x8000bda2 <+46>:  addia3,a3,1
 0x8000bda4 <+48>:  li  a5,31
 0x8000bda6 <+50>:  blt a5,a3,0x8000bde0 

 0x8000bdaa <+54>:  li  a4,0
 0x8000bdac <+56>:  j   0x8000bd9c 
 0x8000bdae <+58>:  li  a5,1
 0x8000bdb0 <+60>:  bge a5,a4,0x8000bdd4 

 0x8000bdb4 <+64>:  li  a5,29
 0x8000bdb6 <+66>:  blt a5,a4,0x8000bdda 

 0x8000bdba <+70>:  li  a5,28
 0x8000bdbc <+72>:  mul a5,a3,a5
 0x8000bdc0 <+76>:  add a5,a5,a4
 0x8000bdc2 <+78>:  lui a2,0x4
 0x8000bdc6 <+82>:  addia2,a2,-58 # 0x3fc6
 0x8000bdca <+86>:  add a5,a5,a2
 0x8000bdcc <+88>:  sllia5,a5,0x2
 0x8000bdce <+90>:  add a5,a5,a0
 0x8000bdd0 <+92>:  flw fa5,0(a5)
 0x8000bdd2 <+94>:  j   0x8000bd8e 
 0x8000bdd4 <+96>:  fmv.w.x fa5,zero
 0x8000bdd8 <+100>: j   0x8000bd8e 
 0x8000bdda <+102>: fmv.w.x fa5,zero
 0x8000bdde <+106>: j   0x8000bd8e 
 0x8000bde0 <+108>: li  a0,0
 0x8000bde2 <+110>: ret

  My code breaks on line 0x8000bd8a and then the mcause register is
  loaded with value 0x02 which translates to illegal instruction. Please
  let me know if you need more information about this.

  I also posted this on ZephyrProject in case it is related to the
  Zephyr: https://github.com/zephyrproject-rtos/zephyr/issues/34026

  I have tested on both QEMU 5.1.0 and 5.2.0 versions. I ran the same
  code on qemu riscv64 and didn't have the same problem. Here is the
  assembly code that is generated for the same operation:

  => 0x8000b446 <+0>:   ld  a4,0(a0)
 0x8000b448 <+2>:   ld  a5,8(a0)
 0x8000b44a <+4>:   ld  a0,0(a4)
 0x8000b44c <+6>:   ld  a1,0(a5)
 0x8000b44e <+8>:   li  a3,0
 0x8000b450 <+10>:  j   0x8000b476 

 0x8000b452 <+12>:  addiw   a5,a3,-2
 0x8000b456 <+16>:  li  a2,27
 0x8000b458 <+18>:  bgeua2,a5,0x8000b480 

 0x8000b45c <+22>:  li  a2,0
 0x8000b460 <+26>:  slliw   a5,a3,0x5
 0x8000b464 <+30>:  addwa5,a5,a4
 0x8000b466 <+32>:  sllia5,a5,0x2
 0x8000b468 <+34>:  add a5,a5,a1
 0x8000b46a <+36>:  sw  a2,0(a5)
 0x8000b46c <+38>:  addiw   a4,a4,1
 0x8000b46e <+40>:  li  a5,31
 0x8000b470 <+42>:  bge a5,a4,0x8000b452 

 0x8000b474 <+46>:  addiw   a3,a3,1
 0x8000b476 <+48>:  li  a5,31
 0x8000b478 <+50>:  blt a5,a3,0x8000b4ac 

 0x8000b47c <+54>:  li  a4,0
 0x8000b47e <+56>:  j   0x8000b46e 

 0x8000b480 <+58>:  li  a5,1
 0x8000b482 <+60>:  bge a5,a4,0x8000b4a0 

 0x8000b486 <+64>:  li  a5,29
 0x8000b488 <+66>:  blt a5,a4,0x8000b4a6 

 0x8000b48c <+70>:  li  a5,28
 0x8000b48e <+72>:  mulwa5,a5,a3
 0x8000b492 <+76>:  addwa5,a5,a4
 0x8000b494 <+78>:  addiw   a5,a5,-58
 0x8000b498 <+82>:  sllia5,a5,0x2
 0x8000b49a <+84>:  add a5,a5,a0
 0x8000b49c <+86>:  lw  a2,0(a5)
 0x8000b49e <+88>:  j   0x8000b460 

 0x8000b4a0 <+90>:  li  a2,0
 0x8000b4a4 <+94>:  j   0x8000b460 

 0x8000b4a6 <+96>:  li  a2,0
 0x8000b4aa <+100>: j   0x8000b460 

 

[Bug 1926782] Re: configure script --extra-cflags not passed to config-meson.cross

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  configure script --extra-cflags not passed to config-meson.cross

Status in QEMU:
  Expired

Bug description:
  Since qemu 5.2, when building, the configure would not finish, but
  would return this error instead:

 qemu ../meson.build:852:2: ERROR: C header 'sasl/sasl.h' not found

  This is for a cross build, and I invoke qemu with the --extra-cflags
  and --extra-ldflags containing all the proper paths to the headers,
  libraries etc. It worked properly with qemu 3.1 to 5.1.

  After looking into the configure script, it seems that meson is passed
  the CFLAGS environment variable instead of QEMU_CFLAGS, and only the
  latter contains the --extra-cflags argument:

  echo "c_args = [${CFLAGS:+$(meson_quote $CFLAGS)}]" >> $cross

  Using the CFLAGS and LDFLAGS environment variable instead of --extra-
  cflags and --extra-ldflags fixes the issue.

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

[Bug 1926952] Re: SPICE support broken with 6.0

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  SPICE support broken with 6.0

Status in QEMU:
  Expired

Bug description:
  Using latest relase 6.0.0 while using Intel GVT-G DMA-BUF and SPICE
  for usb redirection Qemu won't start:

  qemu-system-x86_64: The console requires display DMABUF support.

  However just patching ui/console.c:

  if (flags & GRAPHIC_FLAGS_DMABUF &&
  !displaychangelistener_has_dmabuf(dcl)) {
  error_setg(errp, "The console requires display DMABUF support.");
  return false;
  }

  to always return true for dmabuf part works just fine:

  if (flags & GRAPHIC_FLAGS_DMABUF &&
  !displaychangelistener_has_dmabuf(dcl)) {
  error_setg(errp, "The console requires display DMABUF support.");
  return true;
  }

  This behavior wasn't in qemu 5.x version.

  To reproduce this bug need to use:

  /usr/bin/qemu-system-x86_64 \
  -machine q35 \
  -enable-kvm \
  -no-user-config \
  -nodefaults \
  -no-hpet \
  -display gtk,gl=on \
  -device 
pcie-root-port,port=0x0,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1 
\
  -device 
vfio-pci,id=hostdev2,driver=vfio-pci-nohotplug,romfile=/sys/devices/pci:00/:00:02.0/gvt_firmware,sysfsdev=/sys/bus/mdev/devices/1ae40c36-b180-4af0-8fab-c27de21f597d,x-igd-opregion=on,ramfb=on,display=on,xres=1920,yres=1080,bus=pcie.0,multifunction=on,addr=0x2
 \
  -spice port=5900,addr=127.0.0.1,disable-ticketing=on

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

[Bug 1926174] Re: Laggy and/or displaced mouse input on CloudReady (Chrome OS) VM

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  Laggy and/or displaced mouse input on CloudReady (Chrome OS) VM

Status in QEMU:
  Expired

Bug description:
  This weekend I tried to get a CloudReady (Chrome OS) VM running on
  qemu 5.2. This seems to wok quite well, performance seems to be great
  in fact. Only problem is mouse input.

  Using SDL display, there is no visible mouse unless I set "show-
  cursor=on". After that the mouse pointer flickers a bit and most of
  the time is displaced so I need to press below a button in order to
  hit it. After switching to fullscreen and back using ctrl-alt-f this
  effect seems to be fixed for a while but the mouse pointer does not
  reach all parts of the emulated screen anymore.

  Using SPICE instead the mouse pointer is drawn, but it is *very*
  laggy. In fact it is only drawn every few seconds so it is unusable
  but placement seems to be correct. Text input is instant, so general
  emulation speed is not an issue here.

  To reproduce, download the free image from
  https://www.neverware.com/freedownload#home-edition-install

  Then run one of the following commands:

  qemu-system-x86_64 -drive driver=raw,file=cloudready-
  free-89.3.3-64bit.bin -machine pc,accel=kvm -m 2048 -device virtio-
  vga,virgl=on -display sdl,gl=on,show-cursor=on -usb -device usb-mouse
  -device intel-hda -device hda-duplex

  qemu-system-x86_64 -drive driver=raw,file=cloudready-
  free-89.3.3-64bit.bin -machine pc,accel=kvm -m 2048 -device virtio-
  vga,virgl=on -display spice-app,gl=on -usb -device usb-mouse -device
  intel-hda -device hda-duplex

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

[Bug 1926497] Re: dp83932 stops working after a short while

[Launchpad Bug Tracker]

[Expired for QEMU because there has been no activity for 60 days.]

** Changed in: qemu
   Status: Incomplete => Expired

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

Title:
  dp83932 stops working after a short while

Status in QEMU:
  Expired

Bug description:
  Following the instructions here
  https://wiki.qemu.org/Documentation/Platforms/m68k I was able to
  successfully install debian. However, running apt-get update stalls
  after the first 1-2MB.

  root@debian:~# apt-get update
  Get:1 http://ftp.ports.debian.org/debian-ports sid InRelease [55.3 kB]
  Ign:1 http://ftp.ports.debian.org/debian-ports sid InRelease
  Get:2 http://ftp.ports.debian.org/debian-ports sid/main all Packages [8,735 
kB]
  18% [2 Packages 2,155 kB/8,735 kB 25%]

  After running apt-get update. I don't seem to be able to send any
  packets anymore. ping host lookups fail and a subsequent apt-get
  update makes no progress.

  I'm launching qemu with:

qemu-system-m68k -boot c \
   -M q800 -serial none -serial mon:stdio -m 1000M \
   -net nic,model=dp83932 -net user \
   -append "root=/dev/sda2 rw console=ttyS0 console=tty" \
   -kernel vmlinux-4.16.0-1-m68k \
   -initrd initrd.img-4.16.0-1-m68k \
   -drive file=m68k-deb10.qcow2,format=qcow2 \
   -nographic

  I see this with qemu v6.0.0-rc5

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

Re: [PATCH V2 00/18] vhost-vDPA multiqueue

[Jason Wang]

在 2021/7/12 下午1:44, Jason Wang 写道:


在 2021/7/6 下午4:26, Jason Wang 写道:

Hi All:

This patch implements the multiqueue support for vhost-vDPA. The most
important requirement the control virtqueue support. The virtio-net
and vhost-net core are tweak to support control virtqueue as if what
data queue pairs are done: a dedicated vhost_net device which is
coupled with the NetClientState is intrdouced so most of the existing
vhost codes could be reused with minor changes. With the control
virtqueue, vhost-vDPA are extend to support creating and destroying
multiqueue queue pairs plus the control virtqueue.

Tests are done via the vp_vdpa driver in L1 guest plus vdpa simulator
on L0.

Please reivew.



If no objection, I will queue this for 6.1.



Hi Michael:

So we miss the soft freeze, want to know if the series is fine from your 
side, and if you'd like to merge them (for 6.2 probably?).


Thanks

Re: [PULL V2 3/6] hmp-commands: Add new HMP command for filter passthrough

[Jason Wang]

在 2021/7/15 上午11:07, Zhang, Chen 写道:

Oh, good idea. I will quick update it.
By the way,  please review or tag other patches in this series.
Maybe we can catch up 6.1 merge window.

Thanks
Chen



Note that we probably miss the soft-freeze since it's actually a new 
feature.


It could only be done for 6.2.

Thanks

RE: [PULL V2 3/6] hmp-commands: Add new HMP command for filter passthrough

[Zhang, Chen]

> -Original Message-
> From: Dr. David Alan Gilbert 
> Sent: Thursday, July 15, 2021 2:48 AM
> To: Zhang, Chen 
> Cc: Jason Wang ; qemu-dev  de...@nongnu.org>; Eric Blake ; Markus Armbruster
> ; Daniel P. Berrangé ; Gerd
> Hoffmann ; Li Zhijian ; Lukas
> Straub 
> Subject: Re: [PULL V2 3/6] hmp-commands: Add new HMP command for
> filter passthrough
> 
> * Zhang Chen (chen.zh...@intel.com) wrote:
> > Add hmp_passthrough_filter_add and hmp_passthrough_filter_del make
> > user can maintain object network passthrough list in human monitor
> >
> > Signed-off-by: Zhang Chen 
> > ---
> >  hmp-commands.hx   | 26 +
> >  include/monitor/hmp.h |  2 ++
> >  monitor/hmp-cmds.c| 67
> +++
> >  3 files changed, 95 insertions(+)
> >
> > diff --git a/hmp-commands.hx b/hmp-commands.hx index
> > 8e45bce2cd..426a7d6cda 100644
> > --- a/hmp-commands.hx
> > +++ b/hmp-commands.hx
> > @@ -1292,6 +1292,32 @@ SRST
> >Remove host network device.
> >  ERST
> >
> > +{
> > +.name   = "passthrough_filter_add",
> > +.args_type  = "protocol:s?,object-name:s,src:s?,dst:s?",
> > +.params = "[protocol] object-name [src] [dst]",
> > +.help   = "Add network passthrough rule to object passthrough 
> > list",
> > +.cmd= hmp_passthrough_filter_add,
> > +},
> > +
> > +SRST
> > +``passthrough_filter_add``
> > +  Add network stream to object passthrough list.
> > +ERST
> > +
> > +{
> > +.name   = "passthrough_filter_del",
> > +.args_type  = "protocol:s?,object-name:s,src:s?,dst:s?",
> > +.params = "[protocol] object-name [src] [dst]",
> > +.help   = "Delete network passthrough rule from object 
> > passthrough
> list",
> > +.cmd= hmp_passthrough_filter_del,
> > +},
> > +
> > +SRST
> > +``passthrough_filter_del``
> > +  Delete network stream from object passthrough list.
> > +ERST
> > +
> >  {
> >  .name   = "object_add",
> >  .args_type  = "object:S",
> > diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h index
> > 3baa1058e2..ba6987e552 100644
> > --- a/include/monitor/hmp.h
> > +++ b/include/monitor/hmp.h
> > @@ -77,6 +77,8 @@ void hmp_device_del(Monitor *mon, const QDict
> > *qdict);  void hmp_dump_guest_memory(Monitor *mon, const QDict
> > *qdict);  void hmp_netdev_add(Monitor *mon, const QDict *qdict);  void
> > hmp_netdev_del(Monitor *mon, const QDict *qdict);
> > +void hmp_passthrough_filter_add(Monitor *mon, const QDict *qdict);
> > +void hmp_passthrough_filter_del(Monitor *mon, const QDict *qdict);
> >  void hmp_getfd(Monitor *mon, const QDict *qdict);  void
> > hmp_closefd(Monitor *mon, const QDict *qdict);  void
> > hmp_sendkey(Monitor *mon, const QDict *qdict); diff --git
> > a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c index
> 0942027208..b47a2e4850
> > 100644
> > --- a/monitor/hmp-cmds.c
> > +++ b/monitor/hmp-cmds.c
> > @@ -1638,6 +1638,73 @@ void hmp_netdev_del(Monitor *mon, const
> QDict *qdict)
> >  hmp_handle_error(mon, err);
> >  }
> >
> > +IPFlowSpec *hmp_parse_IPFlowSpec(Monitor *mon, const QDict *qdict)
> {
> > +IPFlowSpec *spec = g_new0(IPFlowSpec, 1);
> > +char *src, *dst;
> > +
> > +spec->protocol = g_strdup(qdict_get_try_str(qdict, "protocol"));
> > +spec->object_name = g_strdup(qdict_get_try_str(qdict, "object-
> name"));
> > +src = g_strdup(qdict_get_try_str(qdict, "src"));
> > +dst = g_strdup(qdict_get_try_str(qdict, "dst"));
> > +
> > +if (src) {
> > +spec->source = g_new0(InetSocketAddressBase, 1);
> > +
> > +if (inet_parse_base(spec->source, src, NULL)) {
> > +monitor_printf(mon, "Incorrect passthrough src address\n");
> > +g_free(spec->source);
> > +g_free(src);
> > +goto err;
> 
> That leaks dst if dst is set.
> 
> > +}
> > +g_free(src);
> > +}
> > +
> > +if (dst) {
> > +spec->destination = g_new0(InetSocketAddressBase, 1);
> > +
> > +if (inet_parse_base(spec->destination, dst, NULL)) {
> > +monitor_printf(mon, "Incorrect passthrough dst address\n");
> > +g_free(spec->destination);
> > +g_free(dst);
> 
> That leaks src, and spec->source
> 
> Perhaps the easiest thing would be:
>   g_autofree *src = NULL;
>   g_autofree *dst = NULL;
> 
> and then they'll get free'd up automatically.
> Then in err:  you can do a g_free() of spec->source and
> spec->destination and finally spec.
> 

Oh, good idea. I will quick update it.
By the way,  please review or tag other patches in this series.
Maybe we can catch up 6.1 merge window.

Thanks
Chen

> Dave
> 
> > +goto err;
> > +}
> > +g_free(dst);
> > +}
> > +
> > +return spec;
> > +
> > +err:
> > +g_free(spec);
> > +return NULL;
> > +}
> > +
> > +void hmp_passthrough_filter_add(Monitor *mon, const QDict *qdict) {
> > +

tests/acceptance/multiprocess.py test failure

[Cleber Rosa]

Hi everyone,

The tests/acceptance/multiprocess.py:Multiprocess.test_multiprocess_x86_64
is currently failing (as of a9649a719a44894b81f38dc1c5c1888ee684acef).
Unfortunately CI was unable to catch this issue earlier, because tests
that require KVM are not yet running (but this should change soon).
The relevant part of the test logs is:

VM launch command: './qemu-system-x86_64 -display none -vga none
-chardev 
socket,id=mon,path=/var/tmp/avo_qemu_sock_5g22rvrp/qemu-427815-monitor.sock
-mon chardev=mon,mode=control -chardev
socket,id=console,path=/var/tmp/avo_qemu_sock_5g22rvrp/qemu-427815-console.sock,server=on,wait=off
-serial chardev:console -machine pc -accel kvm -cpu host -object
memory-backend-memfd,id=sysmem-file,size=2G --numa
node,memdev=sysmem-file -m 2048 -kernel
/home/cleber/avocado/data/cache/by_location/b4c64f15a75b083966d39d9246dd8db177736bb4/vmlinuz
-initrd 
/home/cleber/avocado/data/cache/by_location/b4c64f15a75b083966d39d9246dd8db177736bb4/initrd.img
-append printk.time=0 console=ttyS0 rdinit=/bin/bash -device
x-pci-proxy-dev,id=lsi1,fd=16'
>>> {'execute': 'qmp_capabilities'}

The test remains stuck here for as long as the test is allowed to run.
Because there's currently no timeout in the test, it can remain stuck
forever.  But, with a timeout, we end up getting:

Error launching VM
Command: './qemu-system-x86_64 -display none -vga none -chardev
socket,id=mon,path=/var/tmp/avo_qemu_sock_5g22rvrp/qemu-427815-monitor.sock
-mon chardev=mon,mode=control -chardev
socket,id=console,path=/var/tmp/avo_qemu_sock_5g22rvrp/qemu-427815-console.sock,server=on,wait=off
-serial chardev:console -machine pc -accel kvm -cpu host -object
memory-backend-memfd,id=sysmem-file,size=2G --numa
node,memdev=sysmem-file -m 2048 -kernel
/home/cleber/avocado/data/cache/by_location/b4c64f15a75b083966d39d9246dd8db177736bb4/vmlinuz
-initrd 
/home/cleber/avocado/data/cache/by_location/b4c64f15a75b083966d39d9246dd8db177736bb4/initrd.img
-append printk.time=0 console=ttyS0 rdinit=/bin/bash -device
x-pci-proxy-dev,id=lsi1,fd=16'
Output: "qemu-system-x86_64: ../../src/qemu/softmmu/physmem.c:2055:
qemu_ram_alloc_from_fd: Assertion `(ram_flags & ~(RAM_SHARED |
RAM_PMEM | RAM_NORESERVE)) == 0' failed.\n"

I've bisected it to:

---

d5015b80134047013eeec1df5ce2014ee114 is the first bad commit
commit d5015b80134047013eeec1df5ce2014ee114
Author: David Hildenbrand 
Date:   Mon May 10 13:43:17 2021 +0200

softmmu/memory: Pass ram_flags to qemu_ram_alloc_from_fd()

Let's pass in ram flags just like we do with qemu_ram_alloc_from_file(),
to clean up and prepare for more flags.

Simplify the documentation of passed ram flags: Looking at our
documentation of RAM_SHARED and RAM_PMEM is sufficient, no need to be
repetitive.

Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Peter Xu 
Acked-by: Eduardo Habkost  for memory backend
and machine core
Signed-off-by: David Hildenbrand 
Message-Id: <20210510114328.21835-5-da...@redhat.com>
Signed-off-by: Paolo Bonzini 

 backends/hostmem-memfd.c | 7 ---
 hw/misc/ivshmem.c| 5 ++---
 include/exec/memory.h| 9 +++--
 include/exec/ram_addr.h  | 6 +-
 softmmu/memory.c | 7 +++
 5 files changed, 13 insertions(+), 21 deletions(-)

---

To reproduce it:

1. configure --target-list=x86_64-softmmu
2. meson compile
3. make check-venv
4. ./tests/venv/bin/avocado --show=test run --job-timeout=20s
tests/acceptance/multiprocess.py:Multiprocess.test_multiprocess_x86_64

It'd be helpful to know if anyone else is experiencing the same failure.

Thanks,
- Cleber.

Re: [PATCH for-6.2 04/34] target/arm: Fix signed VADDV

[Richard Henderson]

On 7/13/21 6:36 AM, Peter Maydell wrote:

A cut-and-paste error meant we handled signed VADDV like
unsigned VADDV; fix the type used.

Signed-off-by: Peter Maydell
---
  target/arm/mve_helper.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH for-6.2 02/34] target/arm: Print MVE VPR in CPU dumps

[Richard Henderson]

On 7/13/21 6:36 AM, Peter Maydell wrote:

Include the MVE VPR register value in the CPU dumps produced by
arm_cpu_dump_state() if we are printing FPU information. This
makes it easier to interpret debug logs when predication is
active.

Signed-off-by: Peter Maydell
---
  target/arm/cpu.c | 3 +++
  1 file changed, 3 insertions(+)


Reviewed-by: Richard Henderson 

r~

Re: [PATCH v2 1/2] Hexagon (target/hexagon) remove put_user_*/get_user_*

[Richard Henderson]

On 7/14/21 3:55 PM, Taylor Simpson wrote:

+target_ulong pc = env->gpr[HEX_REG_PC];
+uint8_t width = env->mem_log_stores[slot_num].width;
+target_ulong va = env->mem_log_stores[slot_num].va;
+
+switch (width) {
  case 1:
-put_user_u8(env->mem_log_stores[slot_num].data32,
-env->mem_log_stores[slot_num].va);
+cpu_stb_data_ra(env, va, env->mem_log_stores[slot_num].data32, pc);


No, you need to pass the host return address, not the guest.
This should be

uintptr_t ra = GETPC();


r~

[PATCH v2 1/1] hw/riscv/boot: Check the error of fdt_pack()

[Alistair Francis]

Coverity reports that we don't check the error result of fdt_pack(), so
let's save the result and assert that it is 0.

Fixes: Coverity CID 1458136
Signed-off-by: Alistair Francis 
Reviewed-by: Bin Meng 
---
 hw/riscv/boot.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index 0d38bb7426..993bf89064 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -182,7 +182,7 @@ uint32_t riscv_load_fdt(hwaddr dram_base, uint64_t 
mem_size, void *fdt)
 {
 uint32_t temp, fdt_addr;
 hwaddr dram_end = dram_base + mem_size;
-int fdtsize = fdt_totalsize(fdt);
+int ret, fdtsize = fdt_totalsize(fdt);
 
 if (fdtsize <= 0) {
 error_report("invalid device-tree");
@@ -198,7 +198,9 @@ uint32_t riscv_load_fdt(hwaddr dram_base, uint64_t 
mem_size, void *fdt)
 temp = MIN(dram_end, 3072 * MiB);
 fdt_addr = QEMU_ALIGN_DOWN(temp - fdtsize, 16 * MiB);
 
-fdt_pack(fdt);
+ret = fdt_pack(fdt);
+/* Should only fail if we've built a corrupted tree */
+g_assert(ret == 0);
 /* copy in the device tree */
 qemu_fdt_dumpdtb(fdt, fdtsize);
 
-- 
2.31.1

[PATCH v2 2/2] linux-test (tests/tcg/multiarch/linux-test.c) add check

[Taylor Simpson]

Add a check that the SIGSEGV handler is called

Reviewed-by: Richard Henderson 
Signed-off-by: Taylor Simpson 
---
 tests/tcg/multiarch/linux-test.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tests/tcg/multiarch/linux-test.c b/tests/tcg/multiarch/linux-test.c
index c8c6aed..e2d88f8 100644
--- a/tests/tcg/multiarch/linux-test.c
+++ b/tests/tcg/multiarch/linux-test.c
@@ -439,10 +439,14 @@ static void sig_alarm(int sig)
 alarm_count++;
 }
 
+/* Count the number of times handler is called */
+static int sig_segv_called;
+
 static void sig_segv(int sig, siginfo_t *info, void *puc)
 {
 if (sig != SIGSEGV)
 error("signal");
+sig_segv_called++;
 longjmp(jmp_env, 1);
 }
 
@@ -492,6 +496,10 @@ static void test_signal(void)
 *(volatile uint8_t *)0 = 0;
 }
 
+if (sig_segv_called == 0) {
+error("SIGSEGV handler not called");
+}
+
 act.sa_handler = SIG_DFL;
 sigemptyset(_mask);
 act.sa_flags = 0;
-- 
2.7.4

[PATCH v2 0/2] SIGSEGV fixes

[Taylor Simpson]

The Hexagon target was silently failing the SIGSEGV test because
the signal handler was not called.

Patch 1/2 fixes the Hexagon target
Patch 2/2 adds a check that the signal handler is called

 Changes in v2 
Address feedback from Richard Henderson 
- Replace put_user_* with cpu_st*_data_ra
- Replace get_user_* with cpu_ld*_data_ra
- Treat sig_segv_called as a counter


Taylor Simpson (2):
  Hexagon (target/hexagon) remove put_user_*/get_user_*
  linux-test (tests/tcg/multiarch/linux-test.c) add check

 target/hexagon/op_helper.c   | 39 ++-
 tests/tcg/multiarch/linux-test.c |  8 
 target/hexagon/hex_common.py |  2 ++
 3 files changed, 28 insertions(+), 21 deletions(-)

-- 
2.7.4

[PATCH v2 1/2] Hexagon (target/hexagon) remove put_user_*/get_user_*

[Taylor Simpson]

Replace put_user_* with cpu_st*_data_ra
Replace get_user_* with cpu_ld*_data_ra

Since these functions need the PC, we mark load/store instructions
with the A_IMPLICIT_READS_PC attribute in hex_common.py

Suggested-by: Richard Henderson 
Signed-off-by: Taylor Simpson 
---
 target/hexagon/op_helper.c   | 39 ++-
 target/hexagon/hex_common.py |  2 ++
 2 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/target/hexagon/op_helper.c b/target/hexagon/op_helper.c
index 4595559..c5b708d 100644
--- a/target/hexagon/op_helper.c
+++ b/target/hexagon/op_helper.c
@@ -17,6 +17,7 @@
 
 #include "qemu/osdep.h"
 #include "qemu.h"
+#include "exec/cpu_ldst.h"
 #include "exec/helper-proto.h"
 #include "fpu/softfloat.h"
 #include "cpu.h"
@@ -140,22 +141,22 @@ void HELPER(debug_check_store_width)(CPUHexagonState 
*env, int slot, int check)
 
 void HELPER(commit_store)(CPUHexagonState *env, int slot_num)
 {
-switch (env->mem_log_stores[slot_num].width) {
+target_ulong pc = env->gpr[HEX_REG_PC];
+uint8_t width = env->mem_log_stores[slot_num].width;
+target_ulong va = env->mem_log_stores[slot_num].va;
+
+switch (width) {
 case 1:
-put_user_u8(env->mem_log_stores[slot_num].data32,
-env->mem_log_stores[slot_num].va);
+cpu_stb_data_ra(env, va, env->mem_log_stores[slot_num].data32, pc);
 break;
 case 2:
-put_user_u16(env->mem_log_stores[slot_num].data32,
- env->mem_log_stores[slot_num].va);
+cpu_stw_data_ra(env, va, env->mem_log_stores[slot_num].data32, pc);
 break;
 case 4:
-put_user_u32(env->mem_log_stores[slot_num].data32,
- env->mem_log_stores[slot_num].va);
+cpu_stl_data_ra(env, va, env->mem_log_stores[slot_num].data32, pc);
 break;
 case 8:
-put_user_u64(env->mem_log_stores[slot_num].data64,
- env->mem_log_stores[slot_num].va);
+cpu_stq_data_ra(env, va, env->mem_log_stores[slot_num].data64, pc);
 break;
 default:
 g_assert_not_reached();
@@ -393,37 +394,33 @@ static void check_noshuf(CPUHexagonState *env, uint32_t 
slot)
 static uint8_t mem_load1(CPUHexagonState *env, uint32_t slot,
  target_ulong vaddr)
 {
-uint8_t retval;
+target_ulong pc = env->gpr[HEX_REG_PC];
 check_noshuf(env, slot);
-get_user_u8(retval, vaddr);
-return retval;
+return cpu_ldub_data_ra(env, vaddr, pc);
 }
 
 static uint16_t mem_load2(CPUHexagonState *env, uint32_t slot,
   target_ulong vaddr)
 {
-uint16_t retval;
+target_ulong pc = env->gpr[HEX_REG_PC];
 check_noshuf(env, slot);
-get_user_u16(retval, vaddr);
-return retval;
+return cpu_lduw_data_ra(env, vaddr, pc);
 }
 
 static uint32_t mem_load4(CPUHexagonState *env, uint32_t slot,
   target_ulong vaddr)
 {
-uint32_t retval;
+target_ulong pc = env->gpr[HEX_REG_PC];
 check_noshuf(env, slot);
-get_user_u32(retval, vaddr);
-return retval;
+return cpu_ldl_data_ra(env, vaddr, pc);
 }
 
 static uint64_t mem_load8(CPUHexagonState *env, uint32_t slot,
   target_ulong vaddr)
 {
-uint64_t retval;
+target_ulong pc = env->gpr[HEX_REG_PC];
 check_noshuf(env, slot);
-get_user_u64(retval, vaddr);
-return retval;
+return cpu_ldq_data_ra(env, vaddr, pc);
 }
 
 /* Floating point */
diff --git a/target/hexagon/hex_common.py b/target/hexagon/hex_common.py
index b3b5340..16872a2 100755
--- a/target/hexagon/hex_common.py
+++ b/target/hexagon/hex_common.py
@@ -69,6 +69,8 @@ def add_qemu_macro_attrib(name, attrib):
 def calculate_attribs():
 add_qemu_macro_attrib('fREAD_PC', 'A_IMPLICIT_READS_PC')
 add_qemu_macro_attrib('fTRAP', 'A_IMPLICIT_READS_PC')
+add_qemu_macro_attrib('fLOAD', 'A_IMPLICIT_READS_PC')
+add_qemu_macro_attrib('fSTORE', 'A_IMPLICIT_READS_PC')
 add_qemu_macro_attrib('fWRITE_P0', 'A_WRITES_PRED_REG')
 add_qemu_macro_attrib('fWRITE_P1', 'A_WRITES_PRED_REG')
 add_qemu_macro_attrib('fWRITE_P2', 'A_WRITES_PRED_REG')
-- 
2.7.4

[PATCH 1/1] acpi: Consolidate the handling of OEM ID and OEM Table ID fields

[Marian Postevca]

Introduces structure AcpiBuildOem to hold the value of OEM fields and
uses dedicated helper functions to initialize/set the values.
Unnecessary dynamically allocated OEM fields are re-factored to static
allocation.

Signed-off-by: Marian Postevca 
---
 hw/acpi/hmat.h   |  2 +-
 hw/i386/acpi-common.h|  2 +-
 include/hw/acpi/acpi-build-oem.h | 61 +
 include/hw/acpi/aml-build.h  | 15 +++---
 include/hw/acpi/ghes.h   |  2 +-
 include/hw/acpi/pci.h|  2 +-
 include/hw/acpi/vmgenid.h|  2 +-
 include/hw/arm/virt.h|  4 +-
 include/hw/i386/x86.h|  4 +-
 include/hw/mem/nvdimm.h  |  4 +-
 hw/acpi/aml-build.c  | 26 +--
 hw/acpi/ghes-stub.c  |  1 +
 hw/acpi/ghes.c   |  5 +-
 hw/acpi/hmat.c   |  4 +-
 hw/acpi/nvdimm.c | 22 +
 hw/acpi/pci.c|  4 +-
 hw/acpi/vmgenid.c|  6 ++-
 hw/arm/virt-acpi-build.c | 40 ++--
 hw/arm/virt.c| 16 +++
 hw/i386/acpi-build.c | 78 +++-
 hw/i386/acpi-common.c|  4 +-
 hw/i386/acpi-microvm.c   | 13 ++
 hw/i386/x86.c| 19 
 23 files changed, 189 insertions(+), 147 deletions(-)
 create mode 100644 include/hw/acpi/acpi-build-oem.h

diff --git a/hw/acpi/hmat.h b/hw/acpi/hmat.h
index b57f0e7e80..c1ce9aaa48 100644
--- a/hw/acpi/hmat.h
+++ b/hw/acpi/hmat.h
@@ -38,6 +38,6 @@
 #define HMAT_PROXIMITY_INITIATOR_VALID  0x1
 
 void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState *numa_state,
-const char *oem_id, const char *oem_table_id);
+AcpiBuildOem *bld_oem);
 
 #endif
diff --git a/hw/i386/acpi-common.h b/hw/i386/acpi-common.h
index a68825acf5..f5e793a950 100644
--- a/hw/i386/acpi-common.h
+++ b/hw/i386/acpi-common.h
@@ -10,6 +10,6 @@
 
 void acpi_build_madt(GArray *table_data, BIOSLinker *linker,
  X86MachineState *x86ms, AcpiDeviceIf *adev,
- const char *oem_id, const char *oem_table_id);
+ AcpiBuildOem *bld_oem);
 
 #endif
diff --git a/include/hw/acpi/acpi-build-oem.h b/include/hw/acpi/acpi-build-oem.h
new file mode 100644
index 00..410ebbb9c5
--- /dev/null
+++ b/include/hw/acpi/acpi-build-oem.h
@@ -0,0 +1,61 @@
+#ifndef QEMU_HW_ACPI_BUILD_OEM_H
+#define QEMU_HW_ACPI_BUILD_OEM_H
+
+/*
+ * Utilities for working with ACPI OEM ID and OEM TABLE ID fields
+ *
+ * Copyright (c) 2021 Marian Postevca
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+#include "qemu/cutils.h"
+
+#define ACPI_BUILD_APPNAME6 "BOCHS "
+#define ACPI_BUILD_APPNAME8 "BXPC"
+
+#define ACPI_BUILD_OEM_ID_SIZE 6
+#define ACPI_BUILD_OEM_TABLE_ID_SIZE 8
+
+typedef struct AcpiBuildOem {
+char oem_id[ACPI_BUILD_OEM_ID_SIZE + 1];
+char oem_table_id[ACPI_BUILD_OEM_TABLE_ID_SIZE + 1];
+} AcpiBuildOem;
+
+static inline void ACPI_BUILD_OEM_SET_ID(AcpiBuildOem *bld_oem,
+ const char *oem_id)
+{
+pstrcpy(bld_oem->oem_id, sizeof bld_oem->oem_id, oem_id);
+}
+
+static inline void ACPI_BUILD_OEM_SET_TABLE_ID(AcpiBuildOem *bld_oem,
+   const char *oem_table_id)
+{
+pstrcpy(bld_oem->oem_table_id,
+sizeof bld_oem->oem_table_id, oem_table_id);
+}
+
+static inline void ACPI_BUILD_OEM_INIT(AcpiBuildOem *bld_oem,
+   const char *oem_id,
+   const char *oem_table_id)
+{
+ACPI_BUILD_OEM_SET_ID(bld_oem, oem_id);
+ACPI_BUILD_OEM_SET_TABLE_ID(bld_oem, oem_table_id);
+}
+
+static inline void ACPI_BUILD_OEM_INIT_DEFAULT(AcpiBuildOem *bld_oem)
+{
+ACPI_BUILD_OEM_INIT(bld_oem, ACPI_BUILD_APPNAME6, ACPI_BUILD_APPNAME8);
+}
+
+#endif /* QEMU_HW_ACPI_BUILD_OEM_H */
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index 471266d739..c19621a29c 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -3,9 +3,8 @@
 
 #include "hw/acpi/acpi-defs.h"
 #include "hw/acpi/bios-linker-loader.h"
+#include "hw/acpi/acpi-build-oem.h"
 
-#define ACPI_BUILD_APPNAME6 "BOCHS "
-#define ACPI_BUILD_APPNAME8 "BXPC"
 
 #define ACPI_BUILD_TABLE_FILE "etc/acpi/tables"
 

[PATCH v6 0/1] Rework ACPI OEM fields handling to simplify code (was: acpi: Remove duplicated code handling OEM ID and OEM table ID fields)

[Marian Postevca]

This patch consolidates ACPI OEM fields handling
by:
- Moving common code in PC and MICROVM to X86.
- Changes unnecessary dynamic memory allocation to static allocation
- Uses dedicated structure to keep values of fields instead of two
  separate strings
- Adds helper functions to initialize the structure

v2:
- Move the setters/getters of OEM fields to X86MachineState to
  remove duplication
- Change commit message to make it clear the second commit is
  a re-factor

v3:
- Rebase "acpi: Consolidate the handling of OEM ID and OEM
  Table ID fields to latest" to latest HEAD
- Dropped "acpi: Move setters/getters of oem fields to
   X86MachineState" since it was accepted already

v4:
- Drop helper macros and use static inline functions instead
- Removed variables starting with __
- Used consistent naming for helper functions that start with ACPI_BUILD_OEM_*
- Didn't drop the defines ACPI_BUILD_APPNAME6 and ACPI_BUILD_APPNAME8 since
  ACPI_BUILD_APPNAME8 is still used in build_header() in aml-build.c and it
  feels better to keep them defined together. But if others prefer to drop the
  ACPI_BUILD_APPNAME6 define, will resend the patch.

v5:
- Rebase on mst tree latest HEAD

v6:
- Rebase on mst tree latest HEAD
- Fixed compilation error in hw/acpi/ghes-stub.c
- Fixed coding style error by typedefing struct AcpiBuildOem

Marian Postevca (1):
  acpi: Consolidate the handling of OEM ID and OEM Table ID fields

 hw/acpi/hmat.h   |  2 +-
 hw/i386/acpi-common.h|  2 +-
 include/hw/acpi/acpi-build-oem.h | 61 +
 include/hw/acpi/aml-build.h  | 15 +++---
 include/hw/acpi/ghes.h   |  2 +-
 include/hw/acpi/pci.h|  2 +-
 include/hw/acpi/vmgenid.h|  2 +-
 include/hw/arm/virt.h|  4 +-
 include/hw/i386/x86.h|  4 +-
 include/hw/mem/nvdimm.h  |  4 +-
 hw/acpi/aml-build.c  | 26 +--
 hw/acpi/ghes-stub.c  |  1 +
 hw/acpi/ghes.c   |  5 +-
 hw/acpi/hmat.c   |  4 +-
 hw/acpi/nvdimm.c | 22 +
 hw/acpi/pci.c|  4 +-
 hw/acpi/vmgenid.c|  6 ++-
 hw/arm/virt-acpi-build.c | 40 ++--
 hw/arm/virt.c| 16 +++
 hw/i386/acpi-build.c | 78 +++-
 hw/i386/acpi-common.c|  4 +-
 hw/i386/acpi-microvm.c   | 13 ++
 hw/i386/x86.c| 19 
 23 files changed, 189 insertions(+), 147 deletions(-)
 create mode 100644 include/hw/acpi/acpi-build-oem.h

-- 
2.31.1

Re: [PULL 36/40] vl: switch -M parsing to keyval

[Alex Williamson]

On Wed, 14 Jul 2021 07:16:43 +0100
Mark Cave-Ayland  wrote:

> On 14/07/2021 00:10, Alex Williamson wrote:
> 
> > On Tue, 13 Jul 2021 13:43:47 -0600
> > Alex Williamson  wrote:
> >   
> >> On Tue,  6 Jul 2021 12:01:37 +0200
> >> Paolo Bonzini  wrote:
> >>  
> >>> Switch from QemuOpts to keyval.  This enables the introduction
> >>> of non-scalar machine properties, and JSON syntax in the future.
> >>>
> >>> For JSON syntax to be supported right now, we would have to
> >>> consider what would happen if string-based dictionaries (produced by
> >>> -M key=val) were to be merged with strongly-typed dictionaries
> >>> (produced by -M {'key': 123}).
> >>>
> >>> The simplest way out is to never enter the situation, and only allow one
> >>> -M option when JSON syntax is in use.  However, we want options such as
> >>> -smp to become syntactic sugar for -M, and this is a problem; as soon
> >>> as -smp becomes a shortcut for -M, QEMU would forbid using -M '{}'
> >>> together with -smp.  Therefore, allowing JSON syntax right now for -M
> >>> would be a forward-compatibility nightmare and it would be impossible
> >>> anyway to introduce -M incrementally in tools.
> >>>
> >>> Instead, support for JSON syntax is delayed until after the main
> >>> options are converted to QOM compound properties.  These include -boot,
> >>> -acpitable, -smbios, -m, -semihosting-config, -rtc and -fw_cfg.  Once JSON
> >>> syntax is introduced, these options will _also_ be forbidden together
> >>> with -M '{...}'.
> >>>
> >>> Signed-off-by: Paolo Bonzini 
> >>> ---
> >>>   softmmu/vl.c | 315 ---
> >>>   1 file changed, 146 insertions(+), 169 deletions(-)  
> >>
> >> This breaks the below long standing test VM.  libvirt log and xml
> >> provided below.  I'm using libvirt version 7.3.0.  
> > 
> > A trivial reproducer:
> > 
> > qemu-system-x86_64 -blockdev 
> > '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.fd","node-name":"pflash0-storage","auto-read-only":true,"discard":"unmap"}'
> >  -blockdev 
> > '{"node-name":"pflash0-format","read-only":true,"driver":"raw","file":"pflash0-storage"}'
> >  -machine pc,pflash0=pflash0-format
> > 
> > backtrace:
> > 
> > #0  error_setg_internal
> >  (errp=0x7fffd6c8, src=0x5618bc10 
> > "../../home/alwillia/Work/qemu.git/qapi/qobject-input-visitor.c", line=172, 
> > func=0x5618bf20 <__func__.27> "qobject_input_get_object", 
> > fmt=0x5618bc98 "Parameter '%s' is missing") at 
> > ../../home/alwillia/Work/qemu.git/util/error.c:93
> > #1  0x55f8d255 in qobject_input_get_object (qiv=0x569c59b0, 
> > name=0x56920ef0 "drive", consume=true, errp=0x7fffd6c8) at 
> > ../../home/alwillia/Work/qemu.git/qapi/qobject-input-visitor.c:172
> > #2  0x55f8d28b in qobject_input_get_keyval (qiv=0x569c59b0, 
> > name=0x56920ef0 "drive", errp=0x7fffd6c8) at 
> > ../../home/alwillia/Work/qemu.git/qapi/qobject-input-visitor.c:184
> > #3  0x55f8e3a9 in qobject_input_type_str_keyval (v=0x569c59b0, 
> > name=0x56920ef0 "drive", obj=0x7fffd5a8, errp=0x7fffd6c8)
> >  at ../../home/alwillia/Work/qemu.git/qapi/qobject-input-visitor.c:551
> > #4  0x55f59e51 in visit_type_str (v=0x569c59b0, 
> > name=0x56920ef0 "drive", obj=0x7fffd5a8, errp=0x7fffd6c8) at 
> > ../../home/alwillia/Work/qemu.git/qapi/qapi-visit-core.c:337
> > #5  0x558c3b70 in set_drive_helper (obj=0x569208a0, 
> > v=0x569c59b0, name=0x56920ef0 "drive", opaque=0x564c8300 
> > , iothread=false, errp=0x7fffd6c8)
> >  at 
> > ../../home/alwillia/Work/qemu.git/hw/core/qdev-properties-system.c:97
> > #6  0x558c3e0b in set_drive (obj=0x569208a0, v=0x569c59b0, 
> > name=0x56920ef0 "drive", opaque=0x564c8300 
> > , errp=0x7fffd6c8)
> >  at 
> > ../../home/alwillia/Work/qemu.git/hw/core/qdev-properties-system.c:171
> > #7  0x55edb821 in field_prop_set (obj=0x569208a0, 
> > v=0x569c59b0, name=0x56920ef0 "drive", opaque=0x564c8300 
> > , errp=0x7fffd6c8)
> >  at ../../home/alwillia/Work/qemu.git/hw/core/qdev-properties.c:86
> > #8  0x55eb7f15 in object_property_set (obj=0x569208a0, 
> > name=0x56920ef0 "drive", v=0x569c59b0, errp=0x7fffd768) at 
> > ../../home/alwillia/Work/qemu.git/qom/object.c:1402
> > #9  0x55ebad9e in property_set_alias (obj=0x5683dde0, 
> > v=0x569c59b0, name=0x566fc8a0 "pflash0", opaque=0x56920ed0, 
> > errp=0x7fffd768)
> >  at ../../home/alwillia/Work/qemu.git/qom/object.c:2695
> > #10 0x55eb7f15 in object_property_set (obj=0x5683dde0, 
> > name=0x566fc8a0 "pflash0", v=0x569c59b0, errp=0x7fffd7b8) at 
> > ../../home/alwillia/Work/qemu.git/qom/object.c:1402
> > #11 0x55eb3aa3 in object_set_properties_from_qdict 
> > (obj=0x5683dde0, qdict=0x566fa5b0, v=0x569c59b0, 
> > errp=0x565d9308 )
> >   

[PATCH 1/1] acpi: Consolidate the handling of OEM ID and OEM Table ID fields

[Marian Postevca]

Introduces structure AcpiBuildOem to hold the value of OEM fields and
uses dedicated helper functions to initialize/set the values.
Unnecessary dynamically allocated OEM fields are re-factored to static
allocation.

Signed-off-by: Marian Postevca 
---
 hw/acpi/hmat.h   |  2 +-
 hw/i386/acpi-common.h|  2 +-
 include/hw/acpi/acpi-build-oem.h | 61 +
 include/hw/acpi/aml-build.h  | 15 +++---
 include/hw/acpi/ghes.h   |  2 +-
 include/hw/acpi/pci.h|  2 +-
 include/hw/acpi/vmgenid.h|  2 +-
 include/hw/arm/virt.h|  4 +-
 include/hw/i386/x86.h|  4 +-
 include/hw/mem/nvdimm.h  |  4 +-
 hw/acpi/aml-build.c  | 26 +--
 hw/acpi/ghes-stub.c  |  1 +
 hw/acpi/ghes.c   |  5 +-
 hw/acpi/hmat.c   |  4 +-
 hw/acpi/nvdimm.c | 22 +
 hw/acpi/pci.c|  4 +-
 hw/acpi/vmgenid.c|  6 ++-
 hw/arm/virt-acpi-build.c | 40 ++--
 hw/arm/virt.c| 16 +++
 hw/i386/acpi-build.c | 78 +++-
 hw/i386/acpi-common.c|  4 +-
 hw/i386/acpi-microvm.c   | 13 ++
 hw/i386/x86.c| 19 
 23 files changed, 189 insertions(+), 147 deletions(-)
 create mode 100644 include/hw/acpi/acpi-build-oem.h

diff --git a/hw/acpi/hmat.h b/hw/acpi/hmat.h
index b57f0e7e80..c1ce9aaa48 100644
--- a/hw/acpi/hmat.h
+++ b/hw/acpi/hmat.h
@@ -38,6 +38,6 @@
 #define HMAT_PROXIMITY_INITIATOR_VALID  0x1
 
 void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState *numa_state,
-const char *oem_id, const char *oem_table_id);
+AcpiBuildOem *bld_oem);
 
 #endif
diff --git a/hw/i386/acpi-common.h b/hw/i386/acpi-common.h
index a68825acf5..f5e793a950 100644
--- a/hw/i386/acpi-common.h
+++ b/hw/i386/acpi-common.h
@@ -10,6 +10,6 @@
 
 void acpi_build_madt(GArray *table_data, BIOSLinker *linker,
  X86MachineState *x86ms, AcpiDeviceIf *adev,
- const char *oem_id, const char *oem_table_id);
+ AcpiBuildOem *bld_oem);
 
 #endif
diff --git a/include/hw/acpi/acpi-build-oem.h b/include/hw/acpi/acpi-build-oem.h
new file mode 100644
index 00..410ebbb9c5
--- /dev/null
+++ b/include/hw/acpi/acpi-build-oem.h
@@ -0,0 +1,61 @@
+#ifndef QEMU_HW_ACPI_BUILD_OEM_H
+#define QEMU_HW_ACPI_BUILD_OEM_H
+
+/*
+ * Utilities for working with ACPI OEM ID and OEM TABLE ID fields
+ *
+ * Copyright (c) 2021 Marian Postevca
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see .
+ */
+#include "qemu/cutils.h"
+
+#define ACPI_BUILD_APPNAME6 "BOCHS "
+#define ACPI_BUILD_APPNAME8 "BXPC"
+
+#define ACPI_BUILD_OEM_ID_SIZE 6
+#define ACPI_BUILD_OEM_TABLE_ID_SIZE 8
+
+typedef struct AcpiBuildOem {
+char oem_id[ACPI_BUILD_OEM_ID_SIZE + 1];
+char oem_table_id[ACPI_BUILD_OEM_TABLE_ID_SIZE + 1];
+} AcpiBuildOem;
+
+static inline void ACPI_BUILD_OEM_SET_ID(AcpiBuildOem *bld_oem,
+ const char *oem_id)
+{
+pstrcpy(bld_oem->oem_id, sizeof bld_oem->oem_id, oem_id);
+}
+
+static inline void ACPI_BUILD_OEM_SET_TABLE_ID(AcpiBuildOem *bld_oem,
+   const char *oem_table_id)
+{
+pstrcpy(bld_oem->oem_table_id,
+sizeof bld_oem->oem_table_id, oem_table_id);
+}
+
+static inline void ACPI_BUILD_OEM_INIT(AcpiBuildOem *bld_oem,
+   const char *oem_id,
+   const char *oem_table_id)
+{
+ACPI_BUILD_OEM_SET_ID(bld_oem, oem_id);
+ACPI_BUILD_OEM_SET_TABLE_ID(bld_oem, oem_table_id);
+}
+
+static inline void ACPI_BUILD_OEM_INIT_DEFAULT(AcpiBuildOem *bld_oem)
+{
+ACPI_BUILD_OEM_INIT(bld_oem, ACPI_BUILD_APPNAME6, ACPI_BUILD_APPNAME8);
+}
+
+#endif /* QEMU_HW_ACPI_BUILD_OEM_H */
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index 471266d739..c19621a29c 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -3,9 +3,8 @@
 
 #include "hw/acpi/acpi-defs.h"
 #include "hw/acpi/bios-linker-loader.h"
+#include "hw/acpi/acpi-build-oem.h"
 
-#define ACPI_BUILD_APPNAME6 "BOCHS "
-#define ACPI_BUILD_APPNAME8 "BXPC"
 
 #define ACPI_BUILD_TABLE_FILE "etc/acpi/tables"
 

Re: [PATCH 6/6] tests/acceptance/virtio-gpu.py: provide kernel and initrd hashes

[Willian Rampazzo]

On Wed, Jul 14, 2021 at 2:41 PM Cleber Rosa  wrote:
>
> By providing kernel and initrd hashes, the test guarantees the
> integrity of the images used and avoids the warnings set by
> fetch_asset() when hashes are lacking.
>
> Signed-off-by: Cleber Rosa 
> ---
>  tests/acceptance/virtio-gpu.py | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>

Reviewed-by: Willian Rampazzo 

Re: [PATCH 5/6] tests/acceptance/virtio-gpu.py: use virtio-vga-gl

[Willian Rampazzo]

On Wed, Jul 14, 2021 at 2:41 PM Cleber Rosa  wrote:
>
> Since 49afbca3b, the use of an optional virgl renderer is not
> available anymore, and since b36eb8860f, the way to choose a GL based
> rendered is to use the "virtio-vga-gl" device.
>
> Signed-off-by: Cleber Rosa 
> ---
>  tests/acceptance/virtio-gpu.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

Reviewed-by: Willian Rampazzo 

Re: [PATCH 4/6] tests/acceptance/virtio-gpu.py: combine kernel command line

[Willian Rampazzo]

On Wed, Jul 14, 2021 at 2:41 PM Cleber Rosa  wrote:
>
> Both tests use the same kernel command line arguments, so there's no
> need to have a common and then an additional set of arguments.
>
> Signed-off-by: Cleber Rosa 
> ---
>  tests/acceptance/virtio-gpu.py | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
>

Reviewed-by: Willian Rampazzo 

Re: [PATCH 3/6] tests/acceptance/virtio-gpu.py: combine CPU tags

[Willian Rampazzo]

On Wed, Jul 14, 2021 at 2:41 PM Cleber Rosa  wrote:
>
> Like previously done with the arch tags, all tests use the same CPU
> value so it's possible to combine them at the class level.
>
> Signed-off-by: Cleber Rosa 
> ---
>  tests/acceptance/virtio-gpu.py | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>

Reviewed-by: Willian Rampazzo 

Re: [PATCH 2/6] tests/acceptance/virtio-gpu.py: combine x86_64 arch tags

[Willian Rampazzo]

On Wed, Jul 14, 2021 at 2:41 PM Cleber Rosa  wrote:
>
> The test class in question is x86_64 specific, so it's possible to set
> the tags at the class level.
>
> Signed-off-by: Cleber Rosa 
> ---
>  tests/acceptance/virtio-gpu.py | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>

Reviewed-by: Willian Rampazzo 

Re: [PATCH 1/6] tests/acceptance/virtio-gpu.py: use require_accelerator()

[Willian Rampazzo]

On Wed, Jul 14, 2021 at 2:41 PM Cleber Rosa  wrote:
>
> Since efe30d501 there's a shorthand for requiring specific
> accelerators, and canceling the test if it's not available.
>
> Signed-off-by: Cleber Rosa 
> ---
>  tests/acceptance/virtio-gpu.py | 10 ++
>  1 file changed, 2 insertions(+), 8 deletions(-)
>

Reviewed-by: Willian Rampazzo 

[PULL v2 3/3] vfio/pci: Add pba_offset PCI quirk for BAIDU KUNLUN AI processor

[Alex Williamson]

From: Cai Huoqing 

Fix pba_offset initialization value for BAIDU KUNLUN Virtual
Function device. The KUNLUN hardware returns an incorrect
value for the VF PBA offset, and add a quirk to instead
return a hardcoded value of 0xb400.

Signed-off-by: Cai Huoqing 
Link: https://lore.kernel.org/r/20210713093743.942-1-caihuoq...@baidu.com
[aw: comment & whitespace tuning]
Signed-off-by: Alex Williamson 
---
 hw/vfio/pci.c|8 
 include/hw/pci/pci_ids.h |3 +++
 2 files changed, 11 insertions(+)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index 971273fd458b..e1ea1d8a23b5 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -1499,6 +1499,14 @@ static void vfio_msix_early_setup(VFIOPCIDevice *vdev, 
Error **errp)
 if (vdev->vendor_id == PCI_VENDOR_ID_CHELSIO &&
 (vdev->device_id & 0xff00) == 0x5800) {
 msix->pba_offset = 0x1000;
+/*
+ * BAIDU KUNLUN Virtual Function devices for KUNLUN AI processor
+ * return an incorrect value of 0x46 for the VF PBA offset while
+ * the BAR itself is only 0x1.  The correct value is 0xb400.
+ */
+} else if (vfio_pci_is(vdev, PCI_VENDOR_ID_BAIDU,
+   PCI_DEVICE_ID_KUNLUN_VF)) {
+msix->pba_offset = 0xb400;
 } else if (vdev->msix_relo == OFF_AUTOPCIBAR_OFF) {
 error_setg(errp, "hardware reports invalid configuration, "
"MSIX PBA outside of specified BAR");
diff --git a/include/hw/pci/pci_ids.h b/include/hw/pci/pci_ids.h
index 5c14681b82eb..11abe22d4604 100644
--- a/include/hw/pci/pci_ids.h
+++ b/include/hw/pci/pci_ids.h
@@ -227,6 +227,9 @@
 #define PCI_VENDOR_ID_FREESCALE  0x1957
 #define PCI_DEVICE_ID_MPC8533E   0x0030
 
+#define PCI_VENDOR_ID_BAIDU  0x1d22
+#define PCI_DEVICE_ID_KUNLUN_VF  0x3685
+
 #define PCI_VENDOR_ID_INTEL  0x8086
 #define PCI_DEVICE_ID_INTEL_823780x0484
 #define PCI_DEVICE_ID_INTEL_824410x1237

[PULL v2 2/3] vfio/pci: Change to use vfio_pci_is()

[Alex Williamson]

From: Cai Huoqing 

Make use of vfio_pci_is() helper function.

Signed-off-by: Cai Huoqing 
Link: https://lore.kernel.org/r/20210713014831.742-1-caihuoq...@baidu.com
[aw: commit log wording]
Signed-off-by: Alex Williamson 
---
 hw/vfio/pci.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
index ab4077aad23e..971273fd458b 100644
--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
@@ -3058,14 +3058,14 @@ static void vfio_realize(PCIDevice *pdev, Error **errp)
 }
 }
 
-if (vdev->vendor_id == PCI_VENDOR_ID_NVIDIA) {
+if (vfio_pci_is(vdev, PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID)) {
 ret = vfio_pci_nvidia_v100_ram_init(vdev, errp);
 if (ret && ret != -ENODEV) {
 error_report("Failed to setup NVIDIA V100 GPU RAM");
 }
 }
 
-if (vdev->vendor_id == PCI_VENDOR_ID_IBM) {
+if (vfio_pci_is(vdev, PCI_VENDOR_ID_IBM, PCI_ANY_ID)) {
 ret = vfio_pci_nvlink2_init(vdev, errp);
 if (ret && ret != -ENODEV) {
 error_report("Failed to setup NVlink2 bridge");

[PULL v2 1/3] vfio: Fix CID 1458134 in vfio_register_ram_discard_listener()

[Alex Williamson]

From: David Hildenbrand 

  CID 1458134:  Integer handling issues  (BAD_SHIFT)
In expression "1 << ctz64(container->pgsizes)", left shifting by more
than 31 bits has undefined behavior.  The shift amount,
"ctz64(container->pgsizes)", is 64.

Commit 5e3b981c330c ("vfio: Support for RamDiscardManager in the !vIOMMU
case") added an assertion that our granularity is at least as big as the
page size.

Although unlikely, we could have a page size that does not fit into
32 bit. In that case, we'd try shifting by more than 31 bit.

Let's use 1ULL instead and make sure we're not shifting by more than 63
bit by asserting that any bit in container->pgsizes is set.

Fixes: CID 1458134
Cc: Alex Williamson 
Cc: Eduardo Habkost 
Cc: "Michael S. Tsirkin" 
Cc: Paolo Bonzini 
Cc: Dr. David Alan Gilbert 
Cc: Igor Mammedov 
Cc: Pankaj Gupta 
Cc: Peter Xu 
Cc: Auger Eric 
Cc: Wei Yang 
Cc: teawater 
Cc: Marek Kedzierski 
Signed-off-by: David Hildenbrand 
Reviewed-by: Igor Mammedov 
Reviewed-by: Pankaj Gupta 
Link: https://lore.kernel.org/r/20210712083135.15755-1-da...@redhat.com
Signed-off-by: Alex Williamson 
---
 hw/vfio/common.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/vfio/common.c b/hw/vfio/common.c
index 3f0d11136081..8728d4d5c2e2 100644
--- a/hw/vfio/common.c
+++ b/hw/vfio/common.c
@@ -783,7 +783,8 @@ static void 
vfio_register_ram_discard_listener(VFIOContainer *container,
 section->mr);
 
 g_assert(vrdl->granularity && is_power_of_2(vrdl->granularity));
-g_assert(vrdl->granularity >= 1 << ctz64(container->pgsizes));
+g_assert(container->pgsizes &&
+ vrdl->granularity >= 1ULL << ctz64(container->pgsizes));
 
 ram_discard_listener_init(>listener,
   vfio_ram_discard_notify_populate,

[PULL v2 0/3] VFIO update 2021-07-14 (for v6.1)

[Alex Williamson]

The following changes since commit a9649a719a44894b81f38dc1c5c1888ee684acef:

  Merge remote-tracking branch 
'remotes/cleber-gitlab/tags/python-next-pull-request' into staging (2021-07-14 
18:09:09 +0100)

are available in the Git repository at:

  git://github.com/awilliam/qemu-vfio.git tags/vfio-update-20210714.0

for you to fetch changes up to 1bd9f1b14d1e9c1498bb03faf4e2bb945cf6542d:

  vfio/pci: Add pba_offset PCI quirk for BAIDU KUNLUN AI processor (2021-07-14 
13:47:17 -0600)


VFIO update 2021-07-14

 * Coverity fix to discard listener (David Hildenbrand)

 * MSI-X PBA quirk for BAIDU VFs, additional helper use cases (Cai Huoqing)


Cai Huoqing (2):
  vfio/pci: Change to use vfio_pci_is()
  vfio/pci: Add pba_offset PCI quirk for BAIDU KUNLUN AI processor

David Hildenbrand (1):
  vfio: Fix CID 1458134 in vfio_register_ram_discard_listener()

 hw/vfio/common.c |  3 ++-
 hw/vfio/pci.c| 12 ++--
 include/hw/pci/pci_ids.h |  3 +++
 3 files changed, 15 insertions(+), 3 deletions(-)

Re: Host folder sharing via USB issue

[Programmingkid]

> On Jul 14, 2021, at 6:35 AM, Vladimir Sementsov-Ogievskiy 
>  wrote:
> 
> 14.07.2021 00:04, Programmingkid wrote:
>> Hi I have noticed that host folder sharing via USB has recently stopped 
>> working. After doing some git bisecting I found this as the patch that seems 
>> to be the issue:
>> 25f78d9e2de528473d52acfcf7acdfb64e3453d4 is the first bad commit
>> commit 25f78d9e2de528473d52acfcf7acdfb64e3453d4
>> Author: Vladimir Sementsov-Ogievskiy 
>> Date:   Thu Jun 10 15:05:34 2021 +0300
>> block: move supports_backing check to bdrv_set_file_or_backing_noperm()
>>  Move supports_backing check of bdrv_reopen_parse_backing to called
>> (through bdrv_set_backing_noperm()) bdrv_set_file_or_backing_noperm()
>> function. The check applies to general case, so it's appropriate for
>> bdrv_set_file_or_backing_noperm().
>>  We have to declare backing support for two test drivers, otherwise 
>> new
>> check fails.
>>  Signed-off-by: Vladimir Sementsov-Ogievskiy 
>> 
>> Message-Id: <20210610120537.196183-7-vsement...@virtuozzo.com>
>> Signed-off-by: Kevin Wolf 
>>  block.c  | 29 +++--
>>  tests/unit/test-bdrv-drain.c |  1 +
>>  tests/unit/test-bdrv-graph-mod.c |  1 +
>>  3 files changed, 17 insertions(+), 14 deletions(-)
>> To reproduce this issue run this command:
>> qemu-system-i386 -usb -device usb-storage,drive=fat16 -drive 
>> file=fat:rw:fat-type=16:"",id=fat16,format=raw,if=none
>> Results:
>> Unexpected error in bdrv_set_file_or_backing_noperm() at ../block.c:3159:
>> qemu-system-i386: -drive file=fat:rw:fat-type=16:> path>,id=fat16,format=raw,if=none: Driver 'vvfat' of node '#block057' does 
>> not support backing files
>> Abort trap: 6
>> Expected results:
>> QEMU start running normally.
>> Please let me know if you need more information.
>> Thank you.
> 
> Hi!
> 
> Look at bt:
> 
> #0  0x7fd34f6939d5 in raise () at /lib64/libc.so.6
> #1  0x7fd34f67c8a4 in abort () at /lib64/libc.so.6
> #2  0x55e446d967aa in error_handle_fatal (errp=0x55e447652680 
> , err=0x55e448d17a20) at ../util/error.c:40
> #3  0x55e446d968da in error_setv
>(errp=0x55e447652680 , src=0x55e446f8755b "../block.c", 
> line=3158, func=0x55e446f89c20 <__func__.64> 
> "bdrv_set_file_or_backing_noperm", err_class=ERROR_CLASS_GENERIC_ERROR, 
> fmt=0x55e446f88458 "Driver '%s' of node '%s' does not support backing files", 
> ap=0x7ffc31aba090, suffix=0x0) at ../util/error.c:73
> #4  0x55e446d96ab8 in error_setg_internal
>(errp=0x55e447652680 , src=0x55e446f8755b "../block.c", 
> line=3158, func=0x55e446f89c20 <__func__.64> 
> "bdrv_set_file_or_backing_noperm", fmt=0x55e446f88458 "Driver '%s' of node 
> '%s' does not support backing files") at ../util/error.c:97
> #5  0x55e446c411cf in bdrv_set_file_or_backing_noperm 
> (parent_bs=0x55e448ceebe0, child_bs=0x55e448d21e40, is_backing=true, 
> tran=0x55e448d16c20, errp=0x55e447652680 ) at ../block.c:3158
> #6  0x55e446c41377 in bdrv_set_backing_noperm (bs=0x55e448ceebe0, 
> backing_hd=0x55e448d21e40, tran=0x55e448d16c20, errp=0x55e447652680 
> ) at ../block.c:3218
> #7  0x55e446c413ae in bdrv_set_backing_hd (bs=0x55e448ceebe0, 
> backing_hd=0x55e448d21e40, errp=0x55e447652680 ) at 
> ../block.c:3227
> #8  0x55e446c1bd37 in enable_write_target (bs=0x55e448ceebe0, 
> errp=0x7ffc31aba360) at ../block/vvfat.c:3191
> #9  0x55e446c16fe8 in vvfat_open (bs=0x55e448ceebe0, 
> options=0x55e448cf4330, flags=155650, errp=0x7ffc31aba360) at 
> ../block/vvfat.c:1236
> #10 0x55e446c3df37 in bdrv_open_driver (bs=0x55e448ceebe0, 
> drv=0x55e4475e9760 , node_name=0x0, options=0x55e448cf4330, 
> open_flags=155650, errp=0x7ffc31aba470) at ../block.c:1550
> #11 0x55e446c3e8ee in bdrv_open_common (bs=0x55e448ceebe0, file=0x0, 
> options=0x55e448cf4330, errp=0x7ffc31aba470) at ../block.c:1827
> #12 0x55e446c427b6 in bdrv_open_inherit
>(filename=0x55e448ce4300 "fat:rw:fat-type=16:/tmp", reference=0x0, 
> options=0x55e448cf4330, flags=40962, parent=0x55e448ce75a0, 
> child_class=0x55e4475099c0 , child_role=19, errp=0x7ffc31aba670)
>at ../block.c:3747
> #13 0x55e446c419f5 in bdrv_open_child_bs
>(filename=0x55e448ce4300 "fat:rw:fat-type=16:/tmp", 
> options=0x55e448cec9f0, bdref_key=0x55e446f884d0 "file", 
> parent=0x55e448ce75a0, child_class=0x55e4475099c0 , 
> child_role=19, allow_none=true, errp=0x7ffc31aba670) at ../block.c:3387
> #14 0x55e446c42568 in bdrv_open_inherit
>(filename=0x55e448ce4300 "fat:rw:fat-type=16:/tmp", reference=0x0, 
> options=0x55e448cec9f0, flags=8194, parent=0x0, child_class=0x0, 
> child_role=0, errp=0x55e447652688 ) at ../block.c:3694
> #15 0x55e446c42cf6 in bdrv_open (filename=0x55e448ce4300 
> "fat:rw:fat-type=16:/tmp", reference=0x0, options=0x55e448ce4f00, flags=0, 
> errp=0x55e447652688 ) at ../block.c:3840
> #16 0x55e446c5fcaf in blk_new_open (filename=0x55e448ce4300 
> 

[PULL 0/5] OVMF patches for 2021-07-14

[Philippe Mathieu-Daudé]

The following changes since commit a9649a719a44894b81f38dc1c5c1888ee684acef:

  Merge remote-tracking branch 
'remotes/cleber-gitlab/tags/python-next-pull-request' into staging (2021-07-14 
18:09:09 +0100)

are available in the Git repository at:

  https://github.com/philmd/qemu.git tags/fw-edk2-20210714

for you to fetch changes up to 2669350db2c3df33f4e68c518e9f31f91502a83d:

  MAINTAINERS: remove Laszlo Ersek's entries (2021-07-14 22:28:59 +0200)


Patches related to EDK2/OVMF

- MAINTAINERS: remove Laszlo Ersek's entries
- Introduce X86_FW_OVMF Kconfig symbol
- pc_system_ovmf_table_find: Assert that flash was parsed, document
- gitlab-ci: Fix the jobs building EDK2 blobs



Dov Murik (2):
  hw/i386/pc: pc_system_ovmf_table_find: Assert that flash was parsed
  hw/i386/pc: Document pc_system_ovmf_table_find

Laszlo Ersek (1):
  MAINTAINERS: remove Laszlo Ersek's entries

Philippe Mathieu-Daudé (2):
  gitlab-ci: Extract EDK2 job rules to reusable section
  hw/i386: Introduce X86_FW_OVMF Kconfig symbol

 include/hw/i386/pc.h  |   1 +
 hw/i386/pc_sysfw.c| 107 
 hw/i386/pc_sysfw_ovmf-stubs.c |  26 ++
 hw/i386/pc_sysfw_ovmf.c   | 151 ++
 .gitlab-ci.d/edk2.yml |  27 +++---
 MAINTAINERS   |   4 +-
 hw/i386/Kconfig   |   4 +
 hw/i386/meson.build   |   2 +
 8 files changed, 201 insertions(+), 121 deletions(-)
 create mode 100644 hw/i386/pc_sysfw_ovmf-stubs.c
 create mode 100644 hw/i386/pc_sysfw_ovmf.c

-- 
2.31.1

[PULL 1/5] gitlab-ci: Extract EDK2 job rules to reusable section

[Philippe Mathieu-Daudé]

All jobs depending on 'docker-edk2' job must use at most all
the rules that triggers it. The simplest way to ensure that
is to always use the same rules. Extract all the rules to a
reusable section, and include this section (with the 'extends'
keyword) in both 'docker-edk2' and 'build-edk2' jobs.

The problem was introduced in commit 71920809cea ("gitlab-ci.yml:
Add jobs to build EDK2 firmware binaries"), but was revealed in
commit 1925468ddbf ("docker: EDK2 build job depends on EDK2
container") and eventually failed on CI:
https://gitlab.com/qemu-project/qemu/-/pipelines/335995843

Reported-by: Daniel P. Berrangé 
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: Daniel P. Berrangé 
Reviewed-by: Willian Rampazzo 
Message-Id: <20210714101003.3113726-1-phi...@redhat.com>
---
 .gitlab-ci.d/edk2.yml | 27 ---
 1 file changed, 16 insertions(+), 11 deletions(-)

diff --git a/.gitlab-ci.d/edk2.yml b/.gitlab-ci.d/edk2.yml
index ba7280605c4..aae2f7ad880 100644
--- a/.gitlab-ci.d/edk2.yml
+++ b/.gitlab-ci.d/edk2.yml
@@ -1,10 +1,22 @@
-docker-edk2:
- stage: containers
- rules: # Only run this job when the Dockerfile is modified
+# All jobs needing docker-edk2 must use the same rules it uses.
+.edk2_job_rules:
+ rules: # Only run this job when ...
  - changes:
+   # this file is modified
- .gitlab-ci.d/edk2.yml
+   # or the Dockerfile is modified
- .gitlab-ci.d/edk2/Dockerfile
+   # or roms/edk2/ is modified (submodule updated)
+   - roms/edk2/*
when: always
+ - if: '$CI_COMMIT_REF_NAME =~ /^edk2/' # or the branch/tag starts with 'edk2'
+   when: always
+ - if: '$CI_COMMIT_MESSAGE =~ /edk2/i' # or last commit description contains 
'EDK2'
+   when: always
+
+docker-edk2:
+ extends: .edk2_job_rules
+ stage: containers
  image: docker:19.03.1
  services:
  - docker:19.03.1-dind
@@ -24,16 +36,9 @@ docker-edk2:
  - docker push $IMAGE_TAG
 
 build-edk2:
+ extends: .edk2_job_rules
  stage: build
  needs: ['docker-edk2']
- rules: # Only run this job when ...
- - changes: # ... roms/edk2/ is modified (submodule updated)
-   - roms/edk2/*
-   when: always
- - if: '$CI_COMMIT_REF_NAME =~ /^edk2/' # or the branch/tag starts with 'edk2'
-   when: always
- - if: '$CI_COMMIT_MESSAGE =~ /edk2/i' # or last commit description contains 
'EDK2'
-   when: always
  artifacts:
paths: # 'artifacts.zip' will contains the following files:
- pc-bios/edk2*bz2
-- 
2.31.1

Re: [PULL 0/3] VFIO update 2021-07-13 (for v6.1)

[Alex Williamson]

On Wed, 14 Jul 2021 20:45:40 +0100
Peter Maydell  wrote:

> On Tue, 13 Jul 2021 at 22:42, Alex Williamson
>  wrote:
> >
> > The following changes since commit 961fef0ace0b2a997544deec2f01981b9c9c96e3:
> >
> >   Merge remote-tracking branch 
> > 'remotes/alistair/tags/pull-riscv-to-apply-20210712' into staging 
> > (2021-07-13 17:51:50 +0100)
> >
...
> 
> Something seems to have gone wrong with your pullrequest. Specifically,
> it appears to be based on commit 961fef0ace0b2a997 "Merge remote-tracking
> branch 'remotes/alistair/tags/pull-riscv-to-apply-20210712' into staging",
> which is not a commit that has ever been in master and indeed does not
> compile on all systems. (This is lucky, because if it had compiled
> I might not have noticed the mistake...)
> 
> Pull requests should always be based only on commits in master.

Sorry about that, Peter.  I'm glad you caught it.  I'll respin against
current master.  Thanks,

Alex

Re: [PATCH-for-6.1] gitlab-ci: Extract EDK2 job rules to reusable section

[Philippe Mathieu-Daudé]

On 7/14/21 12:10 PM, Philippe Mathieu-Daudé wrote:
> All jobs depending on 'docker-edk2' job must use at most all
> the rules that triggers it. The simplest way to ensure that
> is to always use the same rules. Extract all the rules to a
> reusable section, and include this section (with the 'extends'
> keyword) in both 'docker-edk2' and 'build-edk2' jobs.
> 
> The problem was introduced in commit 71920809cea ("gitlab-ci.yml:
> Add jobs to build EDK2 firmware binaries"), but was revealed in
> commit 1925468ddbf ("docker: EDK2 build job depends on EDK2
> container") and eventually failed on CI:
> https://gitlab.com/qemu-project/qemu/-/pipelines/335995843
> 
> Reported-by: Daniel P. Berrangé 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> If this is a correct fix, I'll send a similar fix for the
> OpenSBI jobs.
> ---
>  .gitlab-ci.d/edk2.yml | 27 ---
>  1 file changed, 16 insertions(+), 11 deletions(-)

Queued to fw-edk2 tree.

Re: [PULL 00/23] pc,pci,virtio: lots of new features

[Peter Maydell]

On Tue, 13 Jul 2021 at 23:10, Michael S. Tsirkin  wrote:
>
> The following changes since commit 708f50199b59476ec4b45ebcdf171550086d6292:
>
>   Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2021-07-09-v2' 
> into staging (2021-07-13 14:32:20 +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 cf171f90d5e41730ad3e0ce23f1990f34b7e63ef:
>
>   vhost-vsock: SOCK_SEQPACKET feature bit support (2021-07-13 16:59:12 -0400)
>
> 
> pc,pci,virtio: lots of new features
>
> Lots of last minute stuff.
>
> vhost-user-rng.
> vhost-user-i2c.
> vhost-vsock SOCK_SEQPACKET support.
> IOMMU bypass.
> ACPI based pci hotplug.
>
> Signed-off-by: Michael S. Tsirkin 

This seems to produce a new meson warning:

Configuring 50-qemu-gpu.json using configuration
Configuring 50-qemu-virtiofsd.json using configuration
Configuring 50-qemu-rng.json using configuration
../../tools/vhost-user-rng/meson.build:7: WARNING: The variable(s)
'libexecdir' in the input file
'tools/vhost-user-rng/50-qemu-rng.json.in' are not present in the
given configuration data.
Configuring 50-edk2-i386-secure.json using configuration
Configuring 50-edk2-x86_64-secure.json using configuration
Configuring 60-edk2-aarch64.json using configuration

(the build then seems to go on to complete OK).

-- PMM

Re: [PATCH-for-6.1] gitlab-ci: Extract EDK2 job rules to reusable section

[Philippe Mathieu-Daudé]

On 7/14/21 8:14 PM, Cleber Rosa wrote:
> 
> Philippe Mathieu-Daudé writes:
> 
>> All jobs depending on 'docker-edk2' job must use at most all
>> the rules that triggers it. The simplest way to ensure that
>> is to always use the same rules. Extract all the rules to a
>> reusable section, and include this section (with the 'extends'
>> keyword) in both 'docker-edk2' and 'build-edk2' jobs.
>>
>> The problem was introduced in commit 71920809cea ("gitlab-ci.yml:
>> Add jobs to build EDK2 firmware binaries"), but was revealed in
>> commit 1925468ddbf ("docker: EDK2 build job depends on EDK2
>> container") and eventually failed on CI:
>> https://gitlab.com/qemu-project/qemu/-/pipelines/335995843
>>
>> Reported-by: Daniel P. Berrangé 
>> Signed-off-by: Philippe Mathieu-Daudé 
>> ---
>> If this is a correct fix, I'll send a similar fix for the
>> OpenSBI jobs.
>> ---
>>  .gitlab-ci.d/edk2.yml | 27 ---
>>  1 file changed, 16 insertions(+), 11 deletions(-)
>>
>> diff --git a/.gitlab-ci.d/edk2.yml b/.gitlab-ci.d/edk2.yml
>> index ba7280605c4..aae2f7ad880 100644
>> --- a/.gitlab-ci.d/edk2.yml
>> +++ b/.gitlab-ci.d/edk2.yml
>> @@ -1,10 +1,22 @@
>> -docker-edk2:
>> - stage: containers
>> - rules: # Only run this job when the Dockerfile is modified
>> +# All jobs needing docker-edk2 must use the same rules it uses.
>> +.edk2_job_rules:
>> + rules: # Only run this job when ...
>>   - changes:
>> +   # this file is modified
>> - .gitlab-ci.d/edk2.yml
>> +   # or the Dockerfile is modified
>> - .gitlab-ci.d/edk2/Dockerfile
>> +   # or roms/edk2/ is modified (submodule updated)
>> +   - roms/edk2/*
>> when: always
>> + - if: '$CI_COMMIT_REF_NAME =~ /^edk2/' # or the branch/tag starts with 
>> 'edk2'
>> +   when: always
>> + - if: '$CI_COMMIT_MESSAGE =~ /edk2/i' # or last commit description 
>> contains 'EDK2'
>> +   when: always
>> +
>> +docker-edk2:
>> + extends: .edk2_job_rules
>> + stage: containers
>>   image: docker:19.03.1
>>   services:
>>   - docker:19.03.1-dind
>> @@ -24,16 +36,9 @@ docker-edk2:
>>   - docker push $IMAGE_TAG
>>  
>>  build-edk2:
>> + extends: .edk2_job_rules
>>   stage: build
>>   needs: ['docker-edk2']
>> - rules: # Only run this job when ...
>> - - changes: # ... roms/edk2/ is modified (submodule updated)
>> -   - roms/edk2/*
>> -   when: always
>> - - if: '$CI_COMMIT_REF_NAME =~ /^edk2/' # or the branch/tag starts with 
>> 'edk2'
>> -   when: always
>> - - if: '$CI_COMMIT_MESSAGE =~ /edk2/i' # or last commit description 
>> contains 'EDK2'
>> -   when: always
>>   artifacts:
>> paths: # 'artifacts.zip' will contains the following files:
>> - pc-bios/edk2*bz2
> 
> 
> Hi Phil,
> 
> This looks good, but have you triggered a pipeline with these changes?
> It'd be helpful for an extra level of assurance for the intended results.

Yes, before sending this patch ;)

https://gitlab.com/philmd_rh/qemu/-/pipelines/336800660

Re: [PATCH v3 0/9] tests: Add test cases for TPM 1.2 ACPI tables

[Philippe Mathieu-Daudé]

On 7/14/21 4:43 PM, Markus Armbruster wrote:
> Philippe Mathieu-Daudé  writes:
> 
>> +Markus
>>
>> On 7/12/21 5:47 PM, Stefan Berger wrote:
>>>
>>> On 7/12/21 11:29 AM, Philippe Mathieu-Daudé wrote:
 Hi Stefan,

 On 7/12/21 5:09 PM, Stefan Berger wrote:
> This series of patches adds test case for TPM 1.2 ACPI tables.
>
>    Stefan
>
> v3:
>    - Define enum TPMVersion for when CONFIG_TPM is not defined
>  affected patches 2 and 6
 I think in 11fb99e6f48..e542b71805d we missed an extra patch
 for qtests. Probably (untested):
>>>
>>> Shouldn't we have seen test compilation errors already?
>>>
>>> I didn't go down this route for the build system (as you show below)
>>> because in this series we are testing ACPI tables and I introduce the
>>> reference to enum TPMVersion here, which wasn't needed before. The
>>> alternative may be to go into 8/9 and eliminate all TPM code if
>>> CONFIG_TPM is not set. The introduction of the enum now passes the tests
>>> with --enable-tpm and --disable-tpm.
>>>
>>> Otherwise the BIOS test are skipped due to this here:
>>>
>>>
>>> static void test_acpi_tcg_tpm(const char *machine, const char *tpm_if,
>>>   uint64_t base, enum TPMVersion tpm_version)
>>> {
>>> #ifdef CONFIG_TPM
>>> [...]
>>>
>>> #else
>>>     g_test_skip("TPM disabled");
>>> #endif
>>> }
>>>
>>> So I didn't want to clutter this code with more #ifdef CONFIG_TPM but
>>> maybe that would be the right solution.
>>
>> IMO the "right" solution is to check via QMP if TMP is supported
>> or not. This is now doable since commit caff255a546 ("tpm: Return
>> QMP error when TPM is disabled in build").
>>
>> Long term we'd like to decouple the tests/ build from the various
>> QEMU configurations, and build the tests once.
> 
> This argument applies only to macros from target-specific headers like
> $TARGET-config-target.h, not to macros from config-host.h.  #ifdef
> CONFIG_TPM should be fine, shouldn't it?

Some definitions depend on the host (OS, libraries installed, ...),
others depend on the --enable/--disable ./configure options.

IMO it would be nice if we could get qtests independent of the latter.

I suppose config-host.h holds both kinds.

[PATCH] hw/intc/arm_gicv3: Fix GICv3 redistributor security checking

[Tianrui Wei]

For redistributor to send sgi, we must test NSACR bits in secure mode.
However, current implementation inverts the security check, wrongly
skipping this it when the CPU is in secure state, and only carrying out
the check when the CPU is not secure or security is not implemented.
This patch corrects this problem by correcting the inversion of CPU
secure state checking. It has been tested to work with Linux version 5.11
in both aarch64 and arm version of qemu.

According to “Arm Generic Interrupt Controller Architecture
Specification GIC architecture version 3 and version 4,” p. 930, 2008.
Chapter 12, page 530, when there is only one security state implemented,
GICD.CTLR.DS is always 0, thus checking NSACR in non-secure state. When
cpu is in secure state, ns = 0, thus the NSACR check is never performed.

Signed-off-by: Tianrui Wei 
Signed-off-by: Jonathan Balkind 
Tested-by: Tianrui Wei 
---
 hw/intc/arm_gicv3_redist.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/intc/arm_gicv3_redist.c b/hw/intc/arm_gicv3_redist.c
index 53da703ed8..84cfcfd18f 100644
--- a/hw/intc/arm_gicv3_redist.c
+++ b/hw/intc/arm_gicv3_redist.c
@@ -564,7 +564,7 @@ void gicv3_redist_send_sgi(GICv3CPUState *cs, int grp, int 
irq, bool ns)
 return;
 }
 
-if (ns && !(cs->gic->gicd_ctlr & GICD_CTLR_DS)) {
+if (!ns && !(cs->gic->gicd_ctlr & GICD_CTLR_DS)) {
 /* If security is enabled we must test the NSACR bits */
 int nsaccess = gicr_ns_access(cs, irq);
 
-- 
2.32.0

Re: [PULL 0/3] VFIO update 2021-07-13 (for v6.1)

[Peter Maydell]

On Tue, 13 Jul 2021 at 22:42, Alex Williamson
 wrote:
>
> The following changes since commit 961fef0ace0b2a997544deec2f01981b9c9c96e3:
>
>   Merge remote-tracking branch 
> 'remotes/alistair/tags/pull-riscv-to-apply-20210712' into staging (2021-07-13 
> 17:51:50 +0100)
>
> are available in the Git repository at:
>
>   git://github.com/awilliam/qemu-vfio.git tags/vfio-update-20210713.0
>
> for you to fetch changes up to fefc1861d4ba8b9b4d7153dc6b359a65468d15cb:
>
>   vfio/pci: Add pba_offset PCI quirk for BAIDU KUNLUN AI processor 
> (2021-07-13 11:31:14 -0600)
>
> 
> VFIO update 2021-07-13
>
>  * Coverity fix to discard listener (David Hildenbrand)
>
>  * MSI-X PBA quirk for BAIDU VFs, additional helper use cases (Cai Huoqing)
>
> 
> Cai Huoqing (2):
>   vfio/pci: Change to use vfio_pci_is()
>   vfio/pci: Add pba_offset PCI quirk for BAIDU KUNLUN AI processor
>
> David Hildenbrand (1):
>   vfio: Fix CID 1458134 in vfio_register_ram_discard_listener()
>
>  hw/vfio/common.c |  3 ++-
>  hw/vfio/pci.c| 12 ++--
>  include/hw/pci/pci_ids.h |  3 +++
>  3 files changed, 15 insertions(+), 3 deletions(-)

Something seems to have gone wrong with your pullrequest. Specifically,
it appears to be based on commit 961fef0ace0b2a997 "Merge remote-tracking
branch 'remotes/alistair/tags/pull-riscv-to-apply-20210712' into staging",
which is not a commit that has ever been in master and indeed does not
compile on all systems. (This is lucky, because if it had compiled
I might not have noticed the mistake...)

Pull requests should always be based only on commits in master.

thanks
-- PMM

Re: [PULL 00/23] Python and Acceptance Tests

[Peter Maydell]

On Tue, 13 Jul 2021 at 22:19, Cleber Rosa  wrote:
>
> The following changes since commit 708f50199b59476ec4b45ebcdf171550086d6292:
>
>   Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2021-07-09-v2' 
> into staging (2021-07-13 14:32:20 +0100)
>
> are available in the Git repository at:
>
>   https://gitlab.com/cleber.gnu/qemu.git/ tags/python-next-pull-request
>
> for you to fetch changes up to c4e2d499c94fb7d6ea43d28e2613559861ef5d79:
>
>   tests/acceptance/cpu_queries.py: use the proper logging channels 
> (2021-07-13 16:27:43 -0400)
>
> 
> Python and Acceptance Tests
>
> - New SMMUv3 and Intel IOMMU tests
> - Respect "cpu" tags and reduce boiler plate code
> - Improved logging of qemu execution output
> - Other misc improvements
>


Applied, thanks.

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

-- PMM

Re: [PATCH v2 0/6] python: AQMP-TUI Prototype

[Niteesh G. S.]

Hello all,

UPDATE:  The pipelines have run and all tests passed #336491916
Usually, the pipelines start running as soon as I push my code. But this
time they took longer to start and there was no sign of starting. This is my
first experience with pipelines so I assumed I messed up something from
my side.

Thanks,
Niteesh.

On Wed, Jul 14, 2021 at 3:37 AM G S Niteesh Babu 
wrote:

> GitLab:
> https://gitlab.com/niteesh.gs/qemu/-/commits/aqmp-tui-prototype-v1/
> Based-on
> :
> <20210701041313.1696009-1-js...@redhat.com>
>  [PATCH 00/20] python: introduce Asynchronous QMP package
>
> Updates in V2:
> 1) Moved loop related initialization to 'run' function in 'App' class
> 2) Added a module logger with support in TUI log messages.
> 3) Corrected usage of logging.info and logging.debug
> 4) Added an option in setup.cfg to silent pylint regarding duplicate-code
> 4) Modified the arguments list to the TUI
>
> NOTE: I am not able to get the pipelines running after the v2 changes.
> I was only able to test the changes locally using *make check*.
>
> This patch series introduces AQMP-TUI prototype. This prototype has been
> helpfull in letting us try out different ideas and giving some insights
> into things that we had to take care of in the upcoming TUI. It was also
> helpfull in finding out bugs in the AQMP library.
>
> The intent for this patch series is to get comments on the architectural
> design of the prototype. These comments will lay down the foundation for
> the upcoming TUI.
>
> G S Niteesh Babu (6):
>   python: disable pylint errors for aqmp-tui
>   python: Add dependencies for AQMP TUI
>   python/aqmp-tui: Add AQMP TUI draft
>   python: add optional pygments dependency
>   python/aqmp-tui: add syntax highlighting
>   python: add entry point for aqmp-tui
>
>  python/Pipfile.lock  |  20 ++
>  python/qemu/aqmp/aqmp_tui.py | 342 +++
>  python/setup.cfg |  36 +++-
>  3 files changed, 397 insertions(+), 1 deletion(-)
>  create mode 100644 python/qemu/aqmp/aqmp_tui.py
>
> --
> 2.17.1
>
>

Re: [RFC PATCH 6/6] i386/sev: populate secrets and cpuid page and finalize the SNP launch

[Brijesh Singh]

On 7/14/21 12:29 PM, Dr. David Alan Gilbert wrote:>> +struct 
snp_pre_validated_range {

+uint32_t start;
+uint32_t end;
+};


Just a thought, but maybe use a 'Range' from include/qemu/range.h ?



I will look into it.

thanks

Re: [RFC PATCH 5/6] i386/sev: add support to encrypt BIOS when SEV-SNP is enabled

[Brijesh Singh]

On 7/14/21 12:08 PM, Connor Kuehl wrote:

On 7/9/21 3:55 PM, Brijesh Singh wrote:

The KVM_SEV_SNP_LAUNCH_UPDATE command is used for encrypting the bios
image used for booting the SEV-SNP guest.

Signed-off-by: Brijesh Singh 
---
  target/i386/sev.c| 33 -
  target/i386/trace-events |  1 +
  2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/target/i386/sev.c b/target/i386/sev.c
index 259408a8f1..41dcb084d1 100644
--- a/target/i386/sev.c
+++ b/target/i386/sev.c
@@ -883,6 +883,30 @@ out:
  return ret;
  }
  
+static int

+sev_snp_launch_update(SevGuestState *sev, uint8_t *addr, uint64_t len, int 
type)
+{
+int ret, fw_error;
+struct kvm_sev_snp_launch_update update = {};
+
+if (!addr || !len) {
+return 1;


Should this be a -1? It looks like the caller checks if this function
returns < 0, but doesn't check for res == 1.


Ah, it should be -1.



Alternatively, invoking error_report might provide more useful
information that the preconditions to this function were violated.



Sure, I will add error_report.

thanks

Re: [PULL V2 3/6] hmp-commands: Add new HMP command for filter passthrough

[Dr. David Alan Gilbert]

* Zhang Chen (chen.zh...@intel.com) wrote:
> Add hmp_passthrough_filter_add and hmp_passthrough_filter_del make user
> can maintain object network passthrough list in human monitor
> 
> Signed-off-by: Zhang Chen 
> ---
>  hmp-commands.hx   | 26 +
>  include/monitor/hmp.h |  2 ++
>  monitor/hmp-cmds.c| 67 +++
>  3 files changed, 95 insertions(+)
> 
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index 8e45bce2cd..426a7d6cda 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -1292,6 +1292,32 @@ SRST
>Remove host network device.
>  ERST
>  
> +{
> +.name   = "passthrough_filter_add",
> +.args_type  = "protocol:s?,object-name:s,src:s?,dst:s?",
> +.params = "[protocol] object-name [src] [dst]",
> +.help   = "Add network passthrough rule to object passthrough 
> list",
> +.cmd= hmp_passthrough_filter_add,
> +},
> +
> +SRST
> +``passthrough_filter_add``
> +  Add network stream to object passthrough list.
> +ERST
> +
> +{
> +.name   = "passthrough_filter_del",
> +.args_type  = "protocol:s?,object-name:s,src:s?,dst:s?",
> +.params = "[protocol] object-name [src] [dst]",
> +.help   = "Delete network passthrough rule from object 
> passthrough list",
> +.cmd= hmp_passthrough_filter_del,
> +},
> +
> +SRST
> +``passthrough_filter_del``
> +  Delete network stream from object passthrough list.
> +ERST
> +
>  {
>  .name   = "object_add",
>  .args_type  = "object:S",
> diff --git a/include/monitor/hmp.h b/include/monitor/hmp.h
> index 3baa1058e2..ba6987e552 100644
> --- a/include/monitor/hmp.h
> +++ b/include/monitor/hmp.h
> @@ -77,6 +77,8 @@ void hmp_device_del(Monitor *mon, const QDict *qdict);
>  void hmp_dump_guest_memory(Monitor *mon, const QDict *qdict);
>  void hmp_netdev_add(Monitor *mon, const QDict *qdict);
>  void hmp_netdev_del(Monitor *mon, const QDict *qdict);
> +void hmp_passthrough_filter_add(Monitor *mon, const QDict *qdict);
> +void hmp_passthrough_filter_del(Monitor *mon, const QDict *qdict);
>  void hmp_getfd(Monitor *mon, const QDict *qdict);
>  void hmp_closefd(Monitor *mon, const QDict *qdict);
>  void hmp_sendkey(Monitor *mon, const QDict *qdict);
> diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
> index 0942027208..b47a2e4850 100644
> --- a/monitor/hmp-cmds.c
> +++ b/monitor/hmp-cmds.c
> @@ -1638,6 +1638,73 @@ void hmp_netdev_del(Monitor *mon, const QDict *qdict)
>  hmp_handle_error(mon, err);
>  }
>  
> +IPFlowSpec *hmp_parse_IPFlowSpec(Monitor *mon, const QDict *qdict)
> +{
> +IPFlowSpec *spec = g_new0(IPFlowSpec, 1);
> +char *src, *dst;
> +
> +spec->protocol = g_strdup(qdict_get_try_str(qdict, "protocol"));
> +spec->object_name = g_strdup(qdict_get_try_str(qdict, "object-name"));
> +src = g_strdup(qdict_get_try_str(qdict, "src"));
> +dst = g_strdup(qdict_get_try_str(qdict, "dst"));
> +
> +if (src) {
> +spec->source = g_new0(InetSocketAddressBase, 1);
> +
> +if (inet_parse_base(spec->source, src, NULL)) {
> +monitor_printf(mon, "Incorrect passthrough src address\n");
> +g_free(spec->source);
> +g_free(src);
> +goto err;

That leaks dst if dst is set.

> +}
> +g_free(src);
> +}
> +
> +if (dst) {
> +spec->destination = g_new0(InetSocketAddressBase, 1);
> +
> +if (inet_parse_base(spec->destination, dst, NULL)) {
> +monitor_printf(mon, "Incorrect passthrough dst address\n");
> +g_free(spec->destination);
> +g_free(dst);

That leaks src, and spec->source

Perhaps the easiest thing would be:
  g_autofree *src = NULL;
  g_autofree *dst = NULL;

and then they'll get free'd up automatically.
Then in err:  you can do a g_free() of spec->source and
spec->destination and finally spec.

Dave

> +goto err;
> +}
> +g_free(dst);
> +}
> +
> +return spec;
> +
> +err:
> +g_free(spec);
> +return NULL;
> +}
> +
> +void hmp_passthrough_filter_add(Monitor *mon, const QDict *qdict)
> +{
> +IPFlowSpec *spec;
> +Error *err = NULL;
> +
> +spec = hmp_parse_IPFlowSpec(mon, qdict);
> +if (spec) {
> +qmp_passthrough_filter_add(spec, );
> +}
> +
> +hmp_handle_error(mon, err);
> +}
> +
> +void hmp_passthrough_filter_del(Monitor *mon, const QDict *qdict)
> +{
> +IPFlowSpec *spec;
> +Error *err = NULL;
> +
> +spec = hmp_parse_IPFlowSpec(mon, qdict);
> +if (spec) {
> +qmp_passthrough_filter_del(spec, );
> +}
> +
> +hmp_handle_error(mon, err);
> +}
> +
>  void hmp_object_add(Monitor *mon, const QDict *qdict)
>  {
>  const char *options = qdict_get_str(qdict, "object");
> -- 
> 2.25.1
> 
-- 
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH v2 19/21] contrib/gitdm: add an explicit academic entry for BU

[Alexander Bulekov]

On 210714 1920, Alex Bennée wrote:
> For some reason Alexander's contributions were not getting grouped
> from the plain "edu" mapping.
> 
> Signed-off-by: Alex Bennée 
> Cc: Alexander Bulekov 

Reviewed-by: Alexander Bulekov 

Thanks!

> Message-Id: <20210714093638.21077-20-alex.ben...@linaro.org>
> ---
>  contrib/gitdm/group-map-academics | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/contrib/gitdm/group-map-academics 
> b/contrib/gitdm/group-map-academics
> index bf3c894821..44745ca85b 100644
> --- a/contrib/gitdm/group-map-academics
> +++ b/contrib/gitdm/group-map-academics
> @@ -16,3 +16,6 @@ c...@braap.org
>  uni-paderborn.de
>  edu
>  edu.cn
> +
> +# Boston University
> +bu.edu
> -- 
> 2.20.1
> 

Re: [PATCH 1/2] qapi/run-state: Add a new shutdown cause 'migration-completed'

[Dr. David Alan Gilbert]

* Kunkun Jiang (jiangkun...@huawei.com) wrote:
> On 2021/7/6 18:27, Dr. David Alan Gilbert wrote:
> > * Kunkun Jiang (jiangkun...@huawei.com) wrote:
> > > Hi Daniel,
> > > 
> > > On 2021/7/5 20:48, Daniel P. Berrangé wrote:
> > > > On Mon, Jul 05, 2021 at 08:36:52PM +0800, Kunkun Jiang wrote:
> > > > > In the current version, the source QEMU process does not automatic
> > > > > exit after a successful migration. Additional action is required,
> > > > > such as sending { "execute": "quit" } or ctrl+c. For simplify, add
> > > > > a new shutdown cause 'migration-completed' to exit the source QEMU
> > > > > process after a successful migration.
> > > > IIUC, 'STATUS_COMPLETED' state is entered on the source host
> > > > once it has finished sending all VM state, and thus does not
> > > > guarantee that the target host has successfully received and
> > > > loaded all VM state.
> > > Thanks for your reply.
> > > 
> > > If the target host doesn't successfully receive and load all VM state,
> > > we can send { "execute": "cont" } to resume the soruce in time to
> > > ensure that VM will not lost?
> > Yes, that's pretty common at the moment;  the failed migration can
> > happen at lots of different points:
> >a) The last part of the actual migration stream/loading the devices
> >  - that's pretty easy, since the destination hasn't actually got
> >  the full migration stream.
> > 
> >b) If the migration itself completes, but then the management system
> >  then tries to reconfigure the networking/storage on the destination,
> >  and something goes wrong in that, then it can roll that back and
> >  cont on the source.
> > 
> > So, it's a pretty common type of failure/recovery  - the management
> > application has to be a bit careful not to do anything destructive
> > until as late as possible, so it knows it can switch back.
> Okay， I see.
> > > > Typically a mgmt app will need to directly confirm that the
> > > > target host QEMU has succesfully started running, before it
> > > > will tell the source QEMU to quit.
> > > 'a mgmt app', such as libvirt?
> > Yes, it's currently libvirt that does that; but any of the control
> > things could (it's just libvirt has been going long enough so it knows
> > about lots and lots of nasty cases of migration failure, and recovering
> > properly).
> > 
> > Can you explain why did you want to get the source to automatically
> > quit?  In a real setup where does it help?
> Sorry, my thoughts on live migration scenarios are not comprehensive enough.

That's OK; it takes a little while to understand all of the recovery and
error cases;  people *really* want to recover from a failed migration;
so we try and be very careful about not throwing away the source.

Dave

> Thanks,
> Kunkun Jiang
> > Dave
> > 
> > 
> > > Thanks,
> > > Kunkun Jiang
> > > > So, AFAICT, this automatic exit after STATUS_COMPLETED is
> > > > not safe and could lead to total loss of the running VM in
> > > > error scenarios.
> > > > 
> > > > 
> > > > 
> > > > > Signed-off-by: Kunkun Jiang 
> > > > > ---
> > > > >migration/migration.c | 1 +
> > > > >qapi/run-state.json   | 4 +++-
> > > > >2 files changed, 4 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/migration/migration.c b/migration/migration.c
> > > > > index 4228635d18..16782c93c2 100644
> > > > > --- a/migration/migration.c
> > > > > +++ b/migration/migration.c
> > > > > @@ -3539,6 +3539,7 @@ static void 
> > > > > migration_iteration_finish(MigrationState *s)
> > > > >case MIGRATION_STATUS_COMPLETED:
> > > > >migration_calculate_complete(s);
> > > > >runstate_set(RUN_STATE_POSTMIGRATE);
> > > > > +
> > > > > qemu_system_shutdown_request(SHUTDOWN_CAUSE_MIGRATION_COMPLETED);
> > > > >break;
> > > > >case MIGRATION_STATUS_ACTIVE:
> > > > > diff --git a/qapi/run-state.json b/qapi/run-state.json
> > > > > index 43d66d700f..66aaef4e2b 100644
> > > > > --- a/qapi/run-state.json
> > > > > +++ b/qapi/run-state.json
> > > > > @@ -86,12 +86,14 @@
> > > > >#   ignores --no-reboot. This is useful for 
> > > > > sanitizing
> > > > >#   hypercalls on s390 that are used during 
> > > > > kexec/kdump/boot
> > > > >#
> > > > > +# @migration-completed: Reaction to the successful migration
> > > > > +#
> > > > >##
> > > > >{ 'enum': 'ShutdownCause',
> > > > >  # Beware, shutdown_caused_by_guest() depends on enumeration order
> > > > >  'data': [ 'none', 'host-error', 'host-qmp-quit', 
> > > > > 'host-qmp-system-reset',
> > > > >'host-signal', 'host-ui', 'guest-shutdown', 
> > > > > 'guest-reset',
> > > > > -'guest-panic', 'subsystem-reset'] }
> > > > > +'guest-panic', 'subsystem-reset', 'migration-completed'] 
> > > > > }
> > > > >##
> > > > ># @StatusInfo:
> > > > > -- 
> > > > > 2.23.0
> > > > > 
> > > > > 
> > > > Regards,
> > > > Daniel
> > > 
> 
-- 

[PATCH v2 20/21] contrib/gitdm: add a new interns group-map for GSoC/Outreachy work

[Alex Bennée]

It makes sense to put our various interns in a group so we can see the
overall impact of GSoC and Outreachy on the project.

Signed-off-by: Alex Bennée 
Cc: Ahmed Karaman 
Cc: Mahmoud Mandour 
Cc: César Belley 
Message-Id: <20210714093638.21077-21-alex.ben...@linaro.org>
---
 contrib/gitdm/group-map-interns | 13 +
 gitdm.config|  3 ++-
 2 files changed, 15 insertions(+), 1 deletion(-)
 create mode 100644 contrib/gitdm/group-map-interns

diff --git a/contrib/gitdm/group-map-interns b/contrib/gitdm/group-map-interns
new file mode 100644
index 00..fe33a3231e
--- /dev/null
+++ b/contrib/gitdm/group-map-interns
@@ -0,0 +1,13 @@
+#
+# Group together everyone working as an intern via one of the various
+# outreach programs.
+#
+
+# GSoC 2020 Virtual FIDO/U2F security key
+cesar.bel...@lse.epita.fr
+
+# GSoC 2020 TCG performance
+ahmedkhaledkara...@gmail.com
+
+# GSoC 2021 TCG plugins
+ma.mando...@gmail.com
diff --git a/gitdm.config b/gitdm.config
index 17a7746892..21bb63aff1 100644
--- a/gitdm.config
+++ b/gitdm.config
@@ -41,9 +41,10 @@ GroupMap contrib/gitdm/group-map-samsung Samsung
 GroupMap contrib/gitdm/group-map-wavecomp Wave Computing
 
 # Also group together our prolific individual contributors
-# and those working under academic auspices
+# and those working under academic or intern auspices
 GroupMap contrib/gitdm/group-map-individuals (None)
 GroupMap contrib/gitdm/group-map-academics Academics (various)
+GroupMap contrib/gitdm/group-map-interns GSoC/Outreachy Interns
 
 # Group together robots and other auto-reporters
 GroupMap contrib/gitdm/group-map-robots Robots (various)
-- 
2.20.1

[PATCH v2 16/21] contrib/gitdm: add domain-map for Syrmia

[Alex Bennée]

We have multiple engineers contributing from this domain.

Signed-off-by: Alex Bennée 
Cc: Filip Bozuta 
Cc: Aleksandar Rikalo 
Message-Id: <20210714093638.21077-17-alex.ben...@linaro.org>
---
 contrib/gitdm/domain-map | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
index bada5384dd..0b0cd9feee 100644
--- a/contrib/gitdm/domain-map
+++ b/contrib/gitdm/domain-map
@@ -34,6 +34,7 @@ siemens.com Siemens
 sifive.com  SiFive
 suse.comSUSE
 suse.de SUSE
+syrmia.com  Syrmia
 virtuozzo.com   Virtuozzo
 wdc.com Western Digital
 windriver.com   Wind River
-- 
2.20.1

[PATCH v2 15/21] contrib/gitdm: add domain-map for ZTE

[Alex Bennée]

Signed-off-by: Alex Bennée 
Cc: Yi Wang 
Cc: Yun Liu 
Message-Id: <20210714093638.21077-16-alex.ben...@linaro.org>
---
 contrib/gitdm/domain-map | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
index e42861cd11..bada5384dd 100644
--- a/contrib/gitdm/domain-map
+++ b/contrib/gitdm/domain-map
@@ -40,3 +40,4 @@ windriver.com   Wind River
 xilinx.com  Xilinx
 yadro.com   YADRO
 yandex-team.ru  Yandex
+zte.com.cn  ZTE
-- 
2.20.1

[PATCH v2 11/21] contrib/gitdm: add domain-map for Eldorado

[Alex Bennée]

Signed-off-by: Alex Bennée 
Cc: Bruno Larsen (billionai) 
Cc: Luis Pires 
Message-Id: <20210714093638.21077-12-alex.ben...@linaro.org>
---
 contrib/gitdm/domain-map | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
index beeb24341e..41875c9e75 100644
--- a/contrib/gitdm/domain-map
+++ b/contrib/gitdm/domain-map
@@ -9,6 +9,7 @@ baidu.com   Baidu
 bytedance.com   ByteDance
 cmss.chinamobile.com China Mobile
 citrix.com  Citrix
+eldorado.org.br Instituto de Pesquisas Eldorado
 fujitsu.com Fujitsu
 google.com  Google
 greensocs.com   GreenSocs
-- 
2.20.1

[PATCH v2 17/21] contrib/gitdm: add domain-map for NVIDIA

[Alex Bennée]

Signed-off-by: Alex Bennée 
Cc: Kirti Wankhede 
Cc: Yishai Hadas 
Message-Id: <20210714093638.21077-18-alex.ben...@linaro.org>
---
 contrib/gitdm/domain-map | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
index 0b0cd9feee..329ff09029 100644
--- a/contrib/gitdm/domain-map
+++ b/contrib/gitdm/domain-map
@@ -24,6 +24,7 @@ microsoft.com   Microsoft
 mvista.com  MontaVista
 nokia.com   Nokia
 nuviainc.comNUVIA
+nvidia.com  NVIDIA
 oracle.com  Oracle
 proxmox.com Proxmox
 quicinc.com Qualcomm Innovation Center
-- 
2.20.1

[PATCH v2 19/21] contrib/gitdm: add an explicit academic entry for BU

[Alex Bennée]

For some reason Alexander's contributions were not getting grouped
from the plain "edu" mapping.

Signed-off-by: Alex Bennée 
Cc: Alexander Bulekov 
Message-Id: <20210714093638.21077-20-alex.ben...@linaro.org>
---
 contrib/gitdm/group-map-academics | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/contrib/gitdm/group-map-academics 
b/contrib/gitdm/group-map-academics
index bf3c894821..44745ca85b 100644
--- a/contrib/gitdm/group-map-academics
+++ b/contrib/gitdm/group-map-academics
@@ -16,3 +16,6 @@ c...@braap.org
 uni-paderborn.de
 edu
 edu.cn
+
+# Boston University
+bu.edu
-- 
2.20.1

[PATCH v2 04/21] configure: remove needless if leg

[Alex Bennée]

It was pointed out in review of the previous patch that the if leg
isn't needed as the for loop will not enter on an empty $device_archs.

Fixes: d1d5e9eefd ("configure: allow the selection of alternate config in the 
build")
Signed-off-by: Alex Bennée 
Message-Id: <20210714093638.21077-5-alex.ben...@linaro.org>
---
 configure | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/configure b/configure
index 4d0a2bfdd8..013f327f4a 100755
--- a/configure
+++ b/configure
@@ -5083,12 +5083,10 @@ if test "$skip_meson" = no; then
   echo "[properties]" >> $cross
 
   # unroll any custom device configs
-  if test -n "$device_archs"; then
-  for a in $device_archs; do
-  eval "c=\$devices_${a}"
-  echo "${a}-softmmu = '$c'" >> $cross
-  done
-  fi
+  for a in $device_archs; do
+  eval "c=\$devices_${a}"
+  echo "${a}-softmmu = '$c'" >> $cross
+  done
 
   test -z "$cxx" && echo "link_language = 'c'" >> $cross
   echo "[built-in options]" >> $cross
-- 
2.20.1

[PATCH v2 12/21] contrib/gitdm: add domain-map/group-map for Wind River

[Alex Bennée]

As per discussion at:
  
http://patchwork.ozlabs.org/project/qemu-devel/patch/20201004180443.2035359-19-f4...@amsat.org/

I've added Bin's personal email as an individual contributor.

Signed-off-by: Alex Bennée 
Acked-by: Bin Meng 
Cc: Ruimei Yan 
Cc: Xuzhou Cheng 
Message-Id: <20210714093719.21429-13-alex.ben...@linaro.org>

---
v2
  - moved Bin's personal address to group-map-individuals
---
 contrib/gitdm/domain-map| 1 +
 contrib/gitdm/group-map-individuals | 1 +
 2 files changed, 2 insertions(+)

diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
index 41875c9e75..27b8fbdf8a 100644
--- a/contrib/gitdm/domain-map
+++ b/contrib/gitdm/domain-map
@@ -34,6 +34,7 @@ suse.comSUSE
 suse.de SUSE
 virtuozzo.com   Virtuozzo
 wdc.com Western Digital
+windriver.com   Wind River
 xilinx.com  Xilinx
 yadro.com   YADRO
 yandex-team.ru  Yandex
diff --git a/contrib/gitdm/group-map-individuals 
b/contrib/gitdm/group-map-individuals
index 4ac2f98823..9b6406e624 100644
--- a/contrib/gitdm/group-map-individuals
+++ b/contrib/gitdm/group-map-individuals
@@ -30,3 +30,4 @@ h...@tuxfamily.org
 jho...@kernel.org
 atar4q...@gmail.com
 minwoo.im@gmail.com
+bmeng...@gmail.com
-- 
2.20.1

[PATCH v2 13/21] contrib/gitdm: un-ironically add a mapping for LWN

[Alex Bennée]

I think this mainly comes from kernel-doc stuff imported into the QEMU
tree.

Signed-off-by: Alex Bennée 
Cc: Jonathan Corbet 
Message-Id: <20210714093638.21077-14-alex.ben...@linaro.org>
---
 contrib/gitdm/domain-map | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
index 27b8fbdf8a..5ac8288716 100644
--- a/contrib/gitdm/domain-map
+++ b/contrib/gitdm/domain-map
@@ -18,6 +18,7 @@ ibm.com IBM
 igalia.com  Igalia
 intel.com   Intel
 linaro.org  Linaro
+lwn.net LWN
 microsoft.com   Microsoft
 mvista.com  MontaVista
 nokia.com   Nokia
-- 
2.20.1

[PATCH v2 18/21] contrib/gitdm: add group-map for Netflix

[Alex Bennée]

Warner confirmed he works for Netflix on IRC.

Message-Id: <20210714093638.21077-19-alex.ben...@linaro.org>
Signed-off-by: Alex Bennée 
Reviewed-by: Warner Losh 
---
 contrib/gitdm/group-map-netflix | 5 +
 gitdm.config| 1 +
 2 files changed, 6 insertions(+)
 create mode 100644 contrib/gitdm/group-map-netflix

diff --git a/contrib/gitdm/group-map-netflix b/contrib/gitdm/group-map-netflix
new file mode 100644
index 00..468f95dcb2
--- /dev/null
+++ b/contrib/gitdm/group-map-netflix
@@ -0,0 +1,5 @@
+#
+# Netflix contributors using their personal emails
+#
+
+i...@bsdimp.com
diff --git a/gitdm.config b/gitdm.config
index e7a744146e..17a7746892 100644
--- a/gitdm.config
+++ b/gitdm.config
@@ -35,6 +35,7 @@ GroupMap contrib/gitdm/group-map-cadence Cadence Design 
Systems
 GroupMap contrib/gitdm/group-map-codeweavers CodeWeavers
 GroupMap contrib/gitdm/group-map-ibm IBM
 GroupMap contrib/gitdm/group-map-janustech Janus Technologies
+GroupMap contrib/gitdm/group-map-netflix Netflix
 GroupMap contrib/gitdm/group-map-redhat Red Hat
 GroupMap contrib/gitdm/group-map-samsung Samsung
 GroupMap contrib/gitdm/group-map-wavecomp Wave Computing
-- 
2.20.1

[PATCH v2 02/21] docs: collect the disparate device emulation docs into one section

[Alex Bennée]

While we are at it add a brief preamble that explains some of the
common concepts in QEMU's device emulation which will hopefully lead
to less confusing about our dizzying command line options.

Signed-off-by: Alex Bennée 
Message-Id: <20210714093638.21077-3-alex.ben...@linaro.org>
---
 docs/system/device-emulation.rst  | 78 +++
 docs/system/{ => devices}/ivshmem.rst |  0
 docs/system/{ => devices}/net.rst |  0
 docs/system/{ => devices}/nvme.rst|  0
 docs/system/{ => devices}/usb.rst |  0
 docs/system/{ => devices}/virtio-pmem.rst |  0
 docs/system/index.rst |  6 +-
 7 files changed, 79 insertions(+), 5 deletions(-)
 create mode 100644 docs/system/device-emulation.rst
 rename docs/system/{ => devices}/ivshmem.rst (100%)
 rename docs/system/{ => devices}/net.rst (100%)
 rename docs/system/{ => devices}/nvme.rst (100%)
 rename docs/system/{ => devices}/usb.rst (100%)
 rename docs/system/{ => devices}/virtio-pmem.rst (100%)

diff --git a/docs/system/device-emulation.rst b/docs/system/device-emulation.rst
new file mode 100644
index 00..3156eeac2d
--- /dev/null
+++ b/docs/system/device-emulation.rst
@@ -0,0 +1,78 @@
+.. _device-emulation:
+
+Device Emulation
+
+
+QEMU supports the emulation of a large number of devices from
+peripherals such network cards and USB devices to integrated systems
+on a chip (SoCs). Configuration of these is often a source of
+confusion so it helps to have an understanding of some of the terms
+used to describes devices within QEMU.
+
+Common Terms
+
+
+Device Front End
+
+
+A device front end is how a device is presented to the guest. The type
+of device presented should match the hardware that the guest operating
+system is expecting to see. All devices can be specified with the
+``--device`` command line option. Running QEMU with the command line
+options ``--device help`` will list all devices it is aware of. Using
+the command line ``--device foo,help`` will list the additional
+configuration options available for that device.
+
+A front end is often paired with a back end, which describes how the
+host's resources are used in the emulation.
+
+Device Buses
+
+
+All devices exist on a BUS. Depending on the machine model you choose
+(``-M foo``) a number of buses will have been automatically created.
+In most cases the BUS a device is attached to can be inferred, for
+example PCI devices are generally automatically allocated to the next
+free slot of the PCI bus. However in complicated configurations you
+can explicitly specify what bus a device is attached to and its
+address. Some devices, for example a PCI SCSI host controller, will
+add an additional bus to the system that other devices can be attached
+to.
+
+Device Back End
+===
+
+The back end describes how the data from the emulated device will be
+processed by QEMU. The configuration of the back end is usually
+specific to the class of device being emulated. For example serial
+devices will be backed by a ``--chardev`` which can redirect the data
+to a file or socket or some other system. Storage devices are handled
+by ``--blockdev`` which will specify how blocks are handled, for
+example being stored in a qcow2 file or accessing a raw host disk
+partition. Back ends can sometimes be stacked to implement features
+like snapshots.
+
+While the choice of back end is generally transparent to the guest
+there are cases where features will not be reported to the guest if
+the back end is unable to support it.
+
+Device Pass Through
+===
+
+Device pass through is where the device is actually given access to
+the underlying hardware. This can be as simple as exposing a single
+USB device on the host system to the guest or dedicating a video card
+in a PCI slot to the exclusive use of the guest.
+
+
+Emulated Devices
+
+
+.. toctree::
+   :maxdepth: 1
+
+   devices/ivshmem.rst
+   devices/net.rst
+   devices/nvme.rst
+   devices/usb.rst
+   devices/virtio-pmem.rst
diff --git a/docs/system/ivshmem.rst b/docs/system/devices/ivshmem.rst
similarity index 100%
rename from docs/system/ivshmem.rst
rename to docs/system/devices/ivshmem.rst
diff --git a/docs/system/net.rst b/docs/system/devices/net.rst
similarity index 100%
rename from docs/system/net.rst
rename to docs/system/devices/net.rst
diff --git a/docs/system/nvme.rst b/docs/system/devices/nvme.rst
similarity index 100%
rename from docs/system/nvme.rst
rename to docs/system/devices/nvme.rst
diff --git a/docs/system/usb.rst b/docs/system/devices/usb.rst
similarity index 100%
rename from docs/system/usb.rst
rename to docs/system/devices/usb.rst
diff --git a/docs/system/virtio-pmem.rst b/docs/system/devices/virtio-pmem.rst
similarity index 100%
rename from docs/system/virtio-pmem.rst
rename to docs/system/devices/virtio-pmem.rst
diff --git a/docs/system/index.rst b/docs/system/index.rst
index 

[PATCH v2 21/21] contrib/gitdm: add more individual contributor entries.

[Alex Bennée]

Also ensure Li's canonical gmail address is used.

Message-Id: <20210714100628.10460-1-alex.ben...@linaro.org>
Signed-off-by: Alex Bennée 
Acked-by: Li Qiang 
Acked-by: Chetan Pant 
Acked-by: Akihiko Odaki 

---
v2
  - dropped un-acked individuals
---
 contrib/gitdm/aliases   | 3 +++
 contrib/gitdm/group-map-individuals | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/contrib/gitdm/aliases b/contrib/gitdm/aliases
index c6ed215e68..4792413ce7 100644
--- a/contrib/gitdm/aliases
+++ b/contrib/gitdm/aliases
@@ -31,6 +31,9 @@ pbrook@c046a42c-6fe2-441c-8c8c-71466251a162 
p...@codesourcery.com
 ths@c046a42c-6fe2-441c-8c8c-71466251a162 t...@networkno.de
 malc@c046a42c-6fe2-441c-8c8c-71466251a162 av1...@comtv.ru
 
+# canonical emails
+liq...@163.com liq...@gmail.com
+
 # some broken tags
 yuval.shaia.ml.gmail.com yuval.shaia...@gmail.com
 
diff --git a/contrib/gitdm/group-map-individuals 
b/contrib/gitdm/group-map-individuals
index 9b6406e624..f816aa8770 100644
--- a/contrib/gitdm/group-map-individuals
+++ b/contrib/gitdm/group-map-individuals
@@ -31,3 +31,6 @@ jho...@kernel.org
 atar4q...@gmail.com
 minwoo.im@gmail.com
 bmeng...@gmail.com
+liq...@gmail.com
+chetan4wind...@gmail.com
+akihiko.od...@gmail.com
-- 
2.20.1

[PATCH v2 03/21] docs: add a section on the generalities of vhost-user

[Alex Bennée]

While we do mention some of this stuff in the various daemons and
manuals the subtleties of the socket and memory sharing are sometimes
missed. This document attempts to give some background on vhost-user
daemons in general terms.

Signed-off-by: Alex Bennée 
Cc: Stefan Hajnoczi 
Message-Id: <20210714093638.21077-4-alex.ben...@linaro.org>
---
 docs/interop/vhost-user.rst|  2 +
 docs/system/device-emulation.rst   |  1 +
 docs/system/devices/vhost-user.rst | 59 ++
 3 files changed, 62 insertions(+)
 create mode 100644 docs/system/devices/vhost-user.rst

diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
index d6085f7045..7fc693521e 100644
--- a/docs/interop/vhost-user.rst
+++ b/docs/interop/vhost-user.rst
@@ -1,3 +1,5 @@
+.. _vhost_user_proto:
+
 ===
 Vhost-user Protocol
 ===
diff --git a/docs/system/device-emulation.rst b/docs/system/device-emulation.rst
index 3156eeac2d..ea7e1fd491 100644
--- a/docs/system/device-emulation.rst
+++ b/docs/system/device-emulation.rst
@@ -75,4 +75,5 @@ Emulated Devices
devices/net.rst
devices/nvme.rst
devices/usb.rst
+   devices/vhost-user.rst
devices/virtio-pmem.rst
diff --git a/docs/system/devices/vhost-user.rst 
b/docs/system/devices/vhost-user.rst
new file mode 100644
index 00..86128114fa
--- /dev/null
+++ b/docs/system/devices/vhost-user.rst
@@ -0,0 +1,59 @@
+.. _vhost_user:
+
+vhost-user back ends
+
+
+vhost-user back ends are way to service the request of VirtIO devices
+outside of QEMU itself. To do this there are a number of things
+required.
+
+vhost-user device
+===
+
+These are simple stub devices that ensure the VirtIO device is visible
+to the guest. The code is mostly boilerplate although each device has
+a ``chardev`` option which specifies the ID of the ``--chardev``
+device that connects via a socket to the vhost-user *daemon*.
+
+vhost-user daemon
+=
+
+This is a separate process that is connected to by QEMU via a socket
+following the :ref:`vhost_user_proto`. There are a number of daemons
+that can be built when enabled by the project although any daemon that
+meets the specification for a given device can be used.
+
+Shared memory object
+
+
+In order for the daemon to access the VirtIO queues to process the
+requests it needs access to the guest's address space. This is
+achieved via the ``memory-backend-file`` or ``memory-backend-memfd``
+objects. A reference to a file-descriptor which can access this object
+will be passed via the socket as part of the protocol negotiation.
+
+Currently the shared memory object needs to match the size of the main
+system memory as defined by the ``-m`` argument.
+
+Example
+===
+
+First start you daemon.
+
+.. parsed-literal::
+
+  $ virtio-foo --socket-path=/var/run/foo.sock $OTHER_ARGS
+
+The you start your QEMU instance specifying the device, chardev and
+memory objects.
+
+.. parsed-literal::
+
+  $ |qemu_system| \\
+  -m 4096 \\
+  -chardev socket,id=ba1,path=/var/run/foo.sock \\
+  -device vhost-user-foo,chardev=ba1,$OTHER_ARGS \\
+  -object memory-backend-memfd,id=mem,size=4G,share=on \\
+  -numa node,memdev=mem \\
+...
+
-- 
2.20.1

[PATCH v2 10/21] contrib/gitdm: add domain-map/group-map mappings for Samsung

[Alex Bennée]

Minwoo's work from their personal address are treated as personal
contributions.

Signed-off-by: Alex Bennée 
Acked-by: Klaus Jensen 
Cc: Gollu Appalanaidu 
Cc: Minwoo Im 
Message-Id: <220210714093719.21429-11-alex.ben...@linaro.org>
---
 contrib/gitdm/domain-map| 1 +
 contrib/gitdm/group-map-individuals | 1 +
 contrib/gitdm/group-map-samsung | 5 +
 gitdm.config| 1 +
 4 files changed, 8 insertions(+)
 create mode 100644 contrib/gitdm/group-map-samsung

diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
index efbbb15643..beeb24341e 100644
--- a/contrib/gitdm/domain-map
+++ b/contrib/gitdm/domain-map
@@ -26,6 +26,7 @@ proxmox.com Proxmox
 quicinc.com Qualcomm Innovation Center
 redhat.com  Red Hat
 rt-rk.com   RT-RK
+samsung.com Samsung
 siemens.com Siemens
 sifive.com  SiFive
 suse.comSUSE
diff --git a/contrib/gitdm/group-map-individuals 
b/contrib/gitdm/group-map-individuals
index 36bbb77c39..4ac2f98823 100644
--- a/contrib/gitdm/group-map-individuals
+++ b/contrib/gitdm/group-map-individuals
@@ -29,3 +29,4 @@ mrol...@gmail.com
 h...@tuxfamily.org
 jho...@kernel.org
 atar4q...@gmail.com
+minwoo.im@gmail.com
diff --git a/contrib/gitdm/group-map-samsung b/contrib/gitdm/group-map-samsung
new file mode 100644
index 00..e38c7eeeac
--- /dev/null
+++ b/contrib/gitdm/group-map-samsung
@@ -0,0 +1,5 @@
+#
+# Some Samsung contributors submit via another domain
+#
+
+minwoo.im@gmail.com
diff --git a/gitdm.config b/gitdm.config
index a3542d2fc7..e7a744146e 100644
--- a/gitdm.config
+++ b/gitdm.config
@@ -36,6 +36,7 @@ GroupMap contrib/gitdm/group-map-codeweavers CodeWeavers
 GroupMap contrib/gitdm/group-map-ibm IBM
 GroupMap contrib/gitdm/group-map-janustech Janus Technologies
 GroupMap contrib/gitdm/group-map-redhat Red Hat
+GroupMap contrib/gitdm/group-map-samsung Samsung
 GroupMap contrib/gitdm/group-map-wavecomp Wave Computing
 
 # Also group together our prolific individual contributors
-- 
2.20.1

[PATCH v2 01/21] gitignore: Update with some filetypes

[Alex Bennée]

From: Viresh Kumar 

Update .gitignore to ignore .swp and .patch files.

Signed-off-by: Viresh Kumar 
Signed-off-by: Alex Bennée 
Reviewed-by: Alex Bennée 
Message-Id: 
<79262dbe1f7888eb02e1911501eebafa6f2f6400.1616583806.git.viresh.ku...@linaro.org>
Message-Id: <20210714093638.21077-2-alex.ben...@linaro.org>
---
 .gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.gitignore b/.gitignore
index 75a4be0724..eb2553026c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -13,3 +13,5 @@ GTAGS
 *~
 *.ast_raw
 *.depend_raw
+*.swp
+*.patch
-- 
2.20.1

[PATCH v2 09/21] gitdm.config: sort the corporate GroupMap entries

[Alex Bennée]

Lets try and keep them that way.

Signed-off-by: Alex Bennée 
Message-Id: <20210714093638.21077-10-alex.ben...@linaro.org>
---
 gitdm.config | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gitdm.config b/gitdm.config
index 7378238c20..a3542d2fc7 100644
--- a/gitdm.config
+++ b/gitdm.config
@@ -28,15 +28,15 @@ EmailMap contrib/gitdm/domain-map
 #
 # Use GroupMap to map a file full of addresses to the
 # same employer. This is used for people that don't post from easily
-# identifiable corporate emails.
+# identifiable corporate emails. Please keep this list sorted.
 #
 
-GroupMap contrib/gitdm/group-map-redhat Red Hat
-GroupMap contrib/gitdm/group-map-wavecomp Wave Computing
 GroupMap contrib/gitdm/group-map-cadence Cadence Design Systems
 GroupMap contrib/gitdm/group-map-codeweavers CodeWeavers
 GroupMap contrib/gitdm/group-map-ibm IBM
 GroupMap contrib/gitdm/group-map-janustech Janus Technologies
+GroupMap contrib/gitdm/group-map-redhat Red Hat
+GroupMap contrib/gitdm/group-map-wavecomp Wave Computing
 
 # Also group together our prolific individual contributors
 # and those working under academic auspices
-- 
2.20.1

[PATCH v2 14/21] contrib/gitdm: add domain-map for Crudebyte

[Alex Bennée]

Let me know if you want to be moved to individual contributor or you
want to keep with the work domain mapping.

Signed-off-by: Alex Bennée 
Reviewed-by: Christian Schoenebeck 
Message-Id: <20210714093638.21077-15-alex.ben...@linaro.org>
---
 contrib/gitdm/domain-map | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
index 5ac8288716..e42861cd11 100644
--- a/contrib/gitdm/domain-map
+++ b/contrib/gitdm/domain-map
@@ -9,6 +9,7 @@ baidu.com   Baidu
 bytedance.com   ByteDance
 cmss.chinamobile.com China Mobile
 citrix.com  Citrix
+crudebyte.com   Crudebyte
 eldorado.org.br Instituto de Pesquisas Eldorado
 fujitsu.com Fujitsu
 google.com  Google
-- 
2.20.1

[PATCH v2 07/21] contrib/gitdm: add domain-map for MontaVista

[Alex Bennée]

Signed-off-by: Alex Bennée 
Acked-by: Corey Minyard 
Cc: Corey Minyard 
Message-Id: <20210714093638.21077-8-alex.ben...@linaro.org>
---
 contrib/gitdm/domain-map | 1 +
 1 file changed, 1 insertion(+)

diff --git a/contrib/gitdm/domain-map b/contrib/gitdm/domain-map
index 0074da618f..efbbb15643 100644
--- a/contrib/gitdm/domain-map
+++ b/contrib/gitdm/domain-map
@@ -18,6 +18,7 @@ igalia.com  Igalia
 intel.com   Intel
 linaro.org  Linaro
 microsoft.com   Microsoft
+mvista.com  MontaVista
 nokia.com   Nokia
 nuviainc.comNUVIA
 oracle.com  Oracle
-- 
2.20.1

[PATCH v2 06/21] .mailmap: fix up some broken commit authors

[Alex Bennée]

Fixes: 49a6f3bffb ("target/arm: Correct the encoding of MDCCSR_EL0 and 
DBGDSCRint")
Fixes: 5a07192a04 ("target/i386: Fix handling of k_gs_base register in 32-bit 
mode in gdbstub")
Signed-off-by: Alex Bennée 
Cc: Nick Hudson 
Cc: Marek Dolata 
Message-Id: <20210714093638.21077-7-alex.ben...@linaro.org>
---
 .mailmap | 4 
 1 file changed, 4 insertions(+)

diff --git a/.mailmap b/.mailmap
index a1bd659817..082ff893ab 100644
--- a/.mailmap
+++ b/.mailmap
@@ -27,6 +27,10 @@ Paul Brook  pbrook 
 ths 

 malc  malc 
 
+# Corrupted Author fields
+Marek Dolata  mkdol...@us.ibm.com 
+Nick Hudson  hn...@vmware.com 
+
 # There is also a:
 #(no author) <(no author)@c046a42c-6fe2-441c-8c8c-71466251a162>
 # for the cvs2svn initialization commit e63c3dc74bf.
-- 
2.20.1

[PATCH v2 08/21] contrib/gitdm: add a group mapping for robot scanners

[Alex Bennée]

This mostly affects Reported-by: tags

Signed-off-by: Alex Bennée 
Message-Id: <20210714093638.21077-9-alex.ben...@linaro.org>
---
 contrib/gitdm/group-map-robots | 7 +++
 gitdm.config   | 3 +++
 2 files changed, 10 insertions(+)
 create mode 100644 contrib/gitdm/group-map-robots

diff --git a/contrib/gitdm/group-map-robots b/contrib/gitdm/group-map-robots
new file mode 100644
index 00..ffd956c2eb
--- /dev/null
+++ b/contrib/gitdm/group-map-robots
@@ -0,0 +1,7 @@
+#
+# There are various automatic robots that occasionally scan and report
+# bugs. Let's group them together here.
+#
+
+# Euler Robot
+euler.ro...@huawei.com
diff --git a/gitdm.config b/gitdm.config
index c01c219078..7378238c20 100644
--- a/gitdm.config
+++ b/gitdm.config
@@ -43,6 +43,9 @@ GroupMap contrib/gitdm/group-map-janustech Janus Technologies
 GroupMap contrib/gitdm/group-map-individuals (None)
 GroupMap contrib/gitdm/group-map-academics Academics (various)
 
+# Group together robots and other auto-reporters
+GroupMap contrib/gitdm/group-map-robots Robots (various)
+
 #
 #
 # Use FileTypeMap to map a file types to file names using regular
-- 
2.20.1

[PATCH v2 05/21] contrib/gitdm: add some new aliases to fix up commits

[Alex Bennée]

Signed-off-by: Alex Bennée 
Cc: Yuval Shaia 
Message-Id: <20210714093638.21077-6-alex.ben...@linaro.org>
---
 contrib/gitdm/aliases | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/contrib/gitdm/aliases b/contrib/gitdm/aliases
index c1e744312f..c6ed215e68 100644
--- a/contrib/gitdm/aliases
+++ b/contrib/gitdm/aliases
@@ -31,6 +31,9 @@ pbrook@c046a42c-6fe2-441c-8c8c-71466251a162 
p...@codesourcery.com
 ths@c046a42c-6fe2-441c-8c8c-71466251a162 t...@networkno.de
 malc@c046a42c-6fe2-441c-8c8c-71466251a162 av1...@comtv.ru
 
+# some broken tags
+yuval.shaia.ml.gmail.com yuval.shaia...@gmail.com
+
 # There is also a:
 #(no author) <(no author)@c046a42c-6fe2-441c-8c8c-71466251a162>
 # for the cvs2svn initialization commit e63c3dc74bf.
-- 
2.20.1

[PATCH v2 00/21] documentation and metadata updates

[Alex Bennée]

Hi,

Posting v2 as the v1 posting got double posted due to git problems so
it's easier if we reset here.

As with previous release cycles I'll switch to maintaining a single
tree of patches for the current release at any given time. The usual
patch admission rules apply so you won't find any feature changes in
here. This series is mostly a collection of documentation and metadata
tweaks, the later being me getting ready for KVM Forum later this year
;-)

All the gitdm changes are mostly waiting for the Cc'd people to
confirm their mappings but I will accept acks from within the
appropriate organisations. If you use the proper Reviewed-by or
Acked-by tags it will make my life easier because the tooling will do
most of the work for me. I've manually converted positive statements
from v1 to Acked-by.

Otherwise the following need review:

- contrib/gitdm: add more individual contributor entries. (3 acks, 1 sobs)
- contrib/gitdm: add a new interns group-map for GSoC/Outreachy work
- contrib/gitdm: add an explicit academic entry for BU
- contrib/gitdm: add domain-map for NVIDIA
- contrib/gitdm: add domain-map for Syrmia
- contrib/gitdm: add domain-map for ZTE
- contrib/gitdm: un-ironically add a mapping for LWN
- contrib/gitdm: add domain-map/group-map for Wind River
- contrib/gitdm: add domain-map for Eldorado
- contrib/gitdm: add domain-map/group-map mappings for Samsung
- gitdm.config: sort the corporate GroupMap entries
- contrib/gitdm: add a group mapping for robot scanners
- contrib/gitdm: add domain-map for MontaVista
- .mailmap: fix up some broken commit authors
- contrib/gitdm: add some new aliases to fix up commits
- configure: remove needless if leg
- docs: add a section on the generalities of vhost-user
- docs: collect the disparate device emulation docs into one section


Alex Bennée (20):
  docs: collect the disparate device emulation docs into one section
  docs: add a section on the generalities of vhost-user
  configure: remove needless if leg
  contrib/gitdm: add some new aliases to fix up commits
  .mailmap: fix up some broken commit authors
  contrib/gitdm: add domain-map for MontaVista
  contrib/gitdm: add a group mapping for robot scanners
  gitdm.config: sort the corporate GroupMap entries
  contrib/gitdm: add domain-map/group-map mappings for Samsung
  contrib/gitdm: add domain-map for Eldorado
  contrib/gitdm: add domain-map/group-map for Wind River
  contrib/gitdm: un-ironically add a mapping for LWN
  contrib/gitdm: add domain-map for Crudebyte
  contrib/gitdm: add domain-map for ZTE
  contrib/gitdm: add domain-map for Syrmia
  contrib/gitdm: add domain-map for NVIDIA
  contrib/gitdm: add group-map for Netflix
  contrib/gitdm: add an explicit academic entry for BU
  contrib/gitdm: add a new interns group-map for GSoC/Outreachy work
  contrib/gitdm: add more individual contributor entries.

Viresh Kumar (1):
  gitignore: Update with some filetypes

 docs/interop/vhost-user.rst   |  2 +
 docs/system/device-emulation.rst  | 79 +++
 docs/system/{ => devices}/ivshmem.rst |  0
 docs/system/{ => devices}/net.rst |  0
 docs/system/{ => devices}/nvme.rst|  0
 docs/system/{ => devices}/usb.rst |  0
 docs/system/devices/vhost-user.rst| 59 +
 docs/system/{ => devices}/virtio-pmem.rst |  0
 docs/system/index.rst |  6 +-
 configure | 10 ++-
 .gitignore|  2 +
 .mailmap  |  4 ++
 contrib/gitdm/aliases |  6 ++
 contrib/gitdm/domain-map  |  9 +++
 contrib/gitdm/group-map-academics |  3 +
 contrib/gitdm/group-map-individuals   |  5 ++
 contrib/gitdm/group-map-interns   | 13 
 contrib/gitdm/group-map-netflix   |  5 ++
 contrib/gitdm/group-map-robots|  7 ++
 contrib/gitdm/group-map-samsung   |  5 ++
 gitdm.config  | 14 ++--
 21 files changed, 214 insertions(+), 15 deletions(-)
 create mode 100644 docs/system/device-emulation.rst
 rename docs/system/{ => devices}/ivshmem.rst (100%)
 rename docs/system/{ => devices}/net.rst (100%)
 rename docs/system/{ => devices}/nvme.rst (100%)
 rename docs/system/{ => devices}/usb.rst (100%)
 create mode 100644 docs/system/devices/vhost-user.rst
 rename docs/system/{ => devices}/virtio-pmem.rst (100%)
 create mode 100644 contrib/gitdm/group-map-interns
 create mode 100644 contrib/gitdm/group-map-netflix
 create mode 100644 contrib/gitdm/group-map-robots
 create mode 100644 contrib/gitdm/group-map-samsung

-- 
2.20.1

Re: [PATCH-for-6.1] gitlab-ci: Extract EDK2 job rules to reusable section

[Cleber Rosa]

Philippe Mathieu-Daudé writes:

> All jobs depending on 'docker-edk2' job must use at most all
> the rules that triggers it. The simplest way to ensure that
> is to always use the same rules. Extract all the rules to a
> reusable section, and include this section (with the 'extends'
> keyword) in both 'docker-edk2' and 'build-edk2' jobs.
>
> The problem was introduced in commit 71920809cea ("gitlab-ci.yml:
> Add jobs to build EDK2 firmware binaries"), but was revealed in
> commit 1925468ddbf ("docker: EDK2 build job depends on EDK2
> container") and eventually failed on CI:
> https://gitlab.com/qemu-project/qemu/-/pipelines/335995843
>
> Reported-by: Daniel P. Berrangé 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
> If this is a correct fix, I'll send a similar fix for the
> OpenSBI jobs.
> ---
>  .gitlab-ci.d/edk2.yml | 27 ---
>  1 file changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/.gitlab-ci.d/edk2.yml b/.gitlab-ci.d/edk2.yml
> index ba7280605c4..aae2f7ad880 100644
> --- a/.gitlab-ci.d/edk2.yml
> +++ b/.gitlab-ci.d/edk2.yml
> @@ -1,10 +1,22 @@
> -docker-edk2:
> - stage: containers
> - rules: # Only run this job when the Dockerfile is modified
> +# All jobs needing docker-edk2 must use the same rules it uses.
> +.edk2_job_rules:
> + rules: # Only run this job when ...
>   - changes:
> +   # this file is modified
> - .gitlab-ci.d/edk2.yml
> +   # or the Dockerfile is modified
> - .gitlab-ci.d/edk2/Dockerfile
> +   # or roms/edk2/ is modified (submodule updated)
> +   - roms/edk2/*
> when: always
> + - if: '$CI_COMMIT_REF_NAME =~ /^edk2/' # or the branch/tag starts with 
> 'edk2'
> +   when: always
> + - if: '$CI_COMMIT_MESSAGE =~ /edk2/i' # or last commit description contains 
> 'EDK2'
> +   when: always
> +
> +docker-edk2:
> + extends: .edk2_job_rules
> + stage: containers
>   image: docker:19.03.1
>   services:
>   - docker:19.03.1-dind
> @@ -24,16 +36,9 @@ docker-edk2:
>   - docker push $IMAGE_TAG
>  
>  build-edk2:
> + extends: .edk2_job_rules
>   stage: build
>   needs: ['docker-edk2']
> - rules: # Only run this job when ...
> - - changes: # ... roms/edk2/ is modified (submodule updated)
> -   - roms/edk2/*
> -   when: always
> - - if: '$CI_COMMIT_REF_NAME =~ /^edk2/' # or the branch/tag starts with 
> 'edk2'
> -   when: always
> - - if: '$CI_COMMIT_MESSAGE =~ /edk2/i' # or last commit description contains 
> 'EDK2'
> -   when: always
>   artifacts:
> paths: # 'artifacts.zip' will contains the following files:
> - pc-bios/edk2*bz2


Hi Phil,

This looks good, but have you triggered a pipeline with these changes?
It'd be helpful for an extra level of assurance for the intended results.

Thanks!

-- 
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]
[  7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3  ]

[PATCH 2/2] target/arm: Add sve-default-vector-length cpu property

[Richard Henderson]

Mirror the behavour of /proc/sys/abi/sve_default_vector_length
under the real linux kernel.  We have no way of passing along
a real default across exec like the kernel can, but this is a
decent way of adjusting the startup vector length of a process.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/482
Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h   |  5 +
 target/arm/cpu.c   | 14 ++--
 target/arm/cpu64.c | 53 ++
 3 files changed, 70 insertions(+), 2 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 52e99344c5..ffd82edaef 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1006,6 +1006,11 @@ struct ARMCPU {
 /* Used to set the maximum vector length the cpu will support.  */
 uint32_t sve_max_vq;
 
+#ifdef CONFIG_USER_ONLY
+/* Used to set the default vector length at process start. */
+uint32_t sve_default_vq;
+#endif
+
 /*
  * In sve_vq_map each set bit is a supported vector length of
  * (bit-number + 1) * 16 bytes, i.e. each bit number + 1 is the vector
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 9cddfd6a44..b5a2c9eb45 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -201,7 +201,8 @@ static void arm_cpu_reset(DeviceState *dev)
 env->cp15.cpacr_el1 = deposit64(env->cp15.cpacr_el1, 16, 2, 3);
 /* with reasonable vector length */
 if (cpu_isar_feature(aa64_sve, cpu)) {
-env->vfp.zcr_el[1] = MIN(cpu->sve_max_vq - 1, 3);
+env->vfp.zcr_el[1] =
+aarch64_sve_zcr_get_valid_len(cpu, cpu->sve_default_vq - 1);
 }
 /*
  * Enable TBI0 but not TBI1.
@@ -1051,7 +1052,16 @@ static void arm_cpu_initfn(Object *obj)
 QLIST_INIT(>pre_el_change_hooks);
 QLIST_INIT(>el_change_hooks);
 
-#ifndef CONFIG_USER_ONLY
+#ifdef CONFIG_USER_ONLY
+# ifdef TARGET_AARCH64
+/*
+ * The linux kernel defaults to 512-bit vectors, when sve is supported.
+ * See documentation for /proc/sys/abi/sve_default_vector_length, and
+ * our corresponding sve-default-vector-length cpu property.
+ */
+cpu->sve_default_vq = 4;
+# endif
+#else
 /* Our inbound IRQ and FIQ lines */
 if (kvm_enabled()) {
 /* VIRQ and VFIQ are unused with KVM but we add them to maintain
diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index c7a1626bec..0e44a4f154 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -559,6 +559,52 @@ static void cpu_arm_set_sve(Object *obj, bool value, Error 
**errp)
 cpu->isar.id_aa64pfr0 = t;
 }
 
+#ifdef CONFIG_USER_ONLY
+/* Mirror linux /proc/sys/abi/sve_default_vector_length. */
+static void cpu_arm_set_sve_default_vec_len(Object *obj, Visitor *v,
+const char *name, void *opaque,
+Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+uint32_t default_len, default_vq, remainder;
+
+if (!visit_type_uint32(v, name, _len, errp)) {
+return;
+}
+
+default_vq = default_len / 128;
+remainder = default_len % 128;
+
+/*
+ * Note that the 512 max comes from include/uapi/asm/sve_context.h
+ * and is the maximum architectural width of ZCR_ELx.LEN.
+ */
+if (remainder || default_vq < 1 || default_vq > 512) {
+error_setg(errp, "cannot set sve-default-vector-length");
+if (remainder) {
+error_append_hint(errp, "Vector length not a multiple of 128\n");
+} else if (default_vq < 1) {
+error_append_hint(errp, "Vector length smaller than 128\n");
+} else {
+error_append_hint(errp, "Vector length larger than 65536\n");
+}
+return;
+}
+
+cpu->sve_default_vq = default_vq;
+}
+
+static void cpu_arm_get_sve_default_vec_len(Object *obj, Visitor *v,
+const char *name, void *opaque,
+Error **errp)
+{
+ARMCPU *cpu = ARM_CPU(obj);
+uint32_t value = cpu->sve_default_vq * 128;
+
+visit_type_uint32(v, name, , errp);
+}
+#endif
+
 void aarch64_add_sve_properties(Object *obj)
 {
 uint32_t vq;
@@ -571,6 +617,13 @@ void aarch64_add_sve_properties(Object *obj)
 object_property_add(obj, name, "bool", cpu_arm_get_sve_vq,
 cpu_arm_set_sve_vq, NULL, NULL);
 }
+
+#ifdef CONFIG_USER_ONLY
+/* Mirror linux /proc/sys/abi/sve_default_vector_length. */
+object_property_add(obj, "sve-default-vector-length", "uint32",
+cpu_arm_get_sve_default_vec_len,
+cpu_arm_set_sve_default_vec_len, NULL, NULL);
+#endif
 }
 
 void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp)
-- 
2.25.1

[PATCH 0/2] target/arm: Add sve-default-vector-length cpu property

[Richard Henderson]

This is intended to resolve #482.

I'm not sure where to document this.  The convenient place would
be in docs/system/arm/cpu-features.rst, where all of the rest of
the sve documentation lives.  But that's explicitly system-only,
and this new properly is explicitly user-only.

Suggestions?


r~


Richard Henderson (2):
  target/arm: Export aarch64_sve_zcr_get_valid_len
  target/arm: Add sve-default-vector-length cpu property

 target/arm/cpu.h|  7 ++
 target/arm/cpu.c| 14 ++--
 target/arm/cpu64.c  | 53 +
 target/arm/helper.c |  8 ---
 4 files changed, 77 insertions(+), 5 deletions(-)

-- 
2.25.1

[PATCH 1/2] target/arm: Export aarch64_sve_zcr_get_valid_len

[Richard Henderson]

Rename from sve_zcr_get_valid_len and make accessible
from outside of helper.c.

Signed-off-by: Richard Henderson 
---
 target/arm/cpu.h| 2 ++
 target/arm/helper.c | 8 +---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index be9a4dceae..52e99344c5 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1060,6 +1060,8 @@ int arm_cpu_write_elf64_note(WriteCoreDumpFunction f, 
CPUState *cs,
 int arm_cpu_write_elf32_note(WriteCoreDumpFunction f, CPUState *cs,
  int cpuid, void *opaque);
 
+uint32_t aarch64_sve_zcr_get_valid_len(ARMCPU *cpu, uint32_t start_len);
+
 #ifdef TARGET_AARCH64
 int aarch64_cpu_gdb_read_register(CPUState *cpu, GByteArray *buf, int reg);
 int aarch64_cpu_gdb_write_register(CPUState *cpu, uint8_t *buf, int reg);
diff --git a/target/arm/helper.c b/target/arm/helper.c
index 910ace4274..a49067c115 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -6454,11 +6454,13 @@ int sve_exception_el(CPUARMState *env, int el)
 return 0;
 }
 
-static uint32_t sve_zcr_get_valid_len(ARMCPU *cpu, uint32_t start_len)
+uint32_t aarch64_sve_zcr_get_valid_len(ARMCPU *cpu, uint32_t start_len)
 {
 uint32_t end_len;
 
-end_len = start_len &= 0xf;
+start_len = MIN(start_len, ARM_MAX_VQ - 1);
+end_len = start_len;
+
 if (!test_bit(start_len, cpu->sve_vq_map)) {
 end_len = find_last_bit(cpu->sve_vq_map, start_len);
 assert(end_len < start_len);
@@ -6484,7 +6486,7 @@ uint32_t sve_zcr_len_for_el(CPUARMState *env, int el)
 zcr_len = MIN(zcr_len, 0xf & (uint32_t)env->vfp.zcr_el[3]);
 }
 
-return sve_zcr_get_valid_len(cpu, zcr_len);
+return aarch64_sve_zcr_get_valid_len(cpu, zcr_len);
 }
 
 static void zcr_write(CPUARMState *env, const ARMCPRegInfo *ri,
-- 
2.25.1

Re: About two-dimensional page translation (e.g., Intel EPT) and shadow page table in Linux QEMU/KVM

[Sean Christopherson]

On Wed, Jul 14, 2021, harry harry wrote:
> > Heh, because the MMUs are all per-vCPU, it actually wouldn't be that much 
> > effort
> > beyond supporting !TDP and TDP for different VMs...
> 
> Sorry, may I know what do you mean by "MMUs are all per-vCPU"? Do you
> mean the MMUs walk the page tables of each vCPU?

No, each vCPU has its own MMU instance, where an "MMU instance" is (mostly) a 
KVM
construct.  Per-vCPU MMU instances are necessary because each vCPU has its own
relevant state, e.g. CR0, CR4, EFER, etc..., that affects the MMU instance in
some way.  E.g. the MMU instance is used to walk guest page tables when
translating GVA->GPA for emulation, so per-vCPU MMUs are necessary even when
using TDP.

However, shadow/TDP PTEs are shared between compatible MMU instances.  E.g. in
the common case where all vCPUs in a VM use identical settings, there will
effectively be a single set of TDP page tables shared by all vCPUs.

RE: [PATCH 03/11] softfloat: Introduce float_flag_inorm_denormal

[Michael Morrell]

OK, thanks for the update.  I also appreciate you looking at the NaN issue.

   Michael

-Original Message-
From: Richard Henderson  
Sent: Wednesday, July 14, 2021 9:57 AM
To: Michael Morrell ; qemu-devel@nongnu.org
Subject: Re: [PATCH 03/11] softfloat: Introduce float_flag_inorm_denormal

On 7/14/21 9:44 AM, Michael Morrell wrote:
> Just curious.  What's the expected timeline to get these denormal patches in 
> the tree?

Next development cycle, at minimum.  I need to fix the problems vs NaNs that 
you identified.


r~

[PATCH 4/6] tests/acceptance/virtio-gpu.py: combine kernel command line

[Cleber Rosa]

Both tests use the same kernel command line arguments, so there's no
need to have a common and then an additional set of arguments.

Signed-off-by: Cleber Rosa 
---
 tests/acceptance/virtio-gpu.py | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/tests/acceptance/virtio-gpu.py b/tests/acceptance/virtio-gpu.py
index 20a59fabf3..fbde278705 100644
--- a/tests/acceptance/virtio-gpu.py
+++ b/tests/acceptance/virtio-gpu.py
@@ -34,7 +34,7 @@ class VirtioGPUx86(Test):
 :avocado: tags=cpu:host
 """
 
-KERNEL_COMMON_COMMAND_LINE = "printk.time=0 "
+KERNEL_COMMAND_LINE = "printk.time=0 console=ttyS0 rdinit=/bin/bash"
 KERNEL_URL = (
 "https://archives.fedoraproject.org/pub/fedora;
 "/linux/releases/33/Everything/x86_64/os/images"
@@ -58,9 +58,6 @@ def test_virtio_vga_virgl(self):
 """
 :avocado: tags=device:virtio-vga
 """
-kernel_command_line = (
-self.KERNEL_COMMON_COMMAND_LINE + "console=ttyS0 rdinit=/bin/bash"
-)
 # FIXME: should check presence of virtio, virgl etc
 self.require_accelerator('kvm')
 
@@ -78,7 +75,7 @@ def test_virtio_vga_virgl(self):
 "-initrd",
 initrd_path,
 "-append",
-kernel_command_line,
+self.KERNEL_COMMAND_LINE,
 )
 try:
 self.vm.launch()
@@ -96,9 +93,6 @@ def test_vhost_user_vga_virgl(self):
 """
 :avocado: tags=device:vhost-user-vga
 """
-kernel_command_line = (
-self.KERNEL_COMMON_COMMAND_LINE + "console=ttyS0 rdinit=/bin/bash"
-)
 # FIXME: should check presence of vhost-user-gpu, virgl, memfd etc
 self.require_accelerator('kvm')
 
@@ -145,7 +139,7 @@ def test_vhost_user_vga_virgl(self):
 "-initrd",
 initrd_path,
 "-append",
-kernel_command_line,
+self.KERNEL_COMMAND_LINE,
 )
 self.vm.launch()
 self.wait_for_console_pattern("as init process")
-- 
2.31.1

[PATCH 6/6] tests/acceptance/virtio-gpu.py: provide kernel and initrd hashes

[Cleber Rosa]

By providing kernel and initrd hashes, the test guarantees the
integrity of the images used and avoids the warnings set by
fetch_asset() when hashes are lacking.

Signed-off-by: Cleber Rosa 
---
 tests/acceptance/virtio-gpu.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tests/acceptance/virtio-gpu.py b/tests/acceptance/virtio-gpu.py
index 0f84affe82..4acc1e6d5f 100644
--- a/tests/acceptance/virtio-gpu.py
+++ b/tests/acceptance/virtio-gpu.py
@@ -40,11 +40,13 @@ class VirtioGPUx86(Test):
 "/linux/releases/33/Everything/x86_64/os/images"
 "/pxeboot/vmlinuz"
 )
+KERNEL_HASH = '1433cfe3f2ffaa44de4ecfb57ec25dc2399cdecf'
 INITRD_URL = (
 "https://archives.fedoraproject.org/pub/fedora;
 "/linux/releases/33/Everything/x86_64/os/images"
 "/pxeboot/initrd.img"
 )
+INITRD_HASH = 'c828d68a027b53e5220536585efe03412332c2d9'
 
 def wait_for_console_pattern(self, success_message, vm=None):
 wait_for_console_pattern(
@@ -61,8 +63,8 @@ def test_virtio_vga_virgl(self):
 # FIXME: should check presence of virtio, virgl etc
 self.require_accelerator('kvm')
 
-kernel_path = self.fetch_asset(self.KERNEL_URL)
-initrd_path = self.fetch_asset(self.INITRD_URL)
+kernel_path = self.fetch_asset(self.KERNEL_URL, self.KERNEL_HASH)
+initrd_path = self.fetch_asset(self.INITRD_URL, self.INITRD_HASH)
 
 self.vm.set_console()
 self.vm.add_args("-m", "2G")
@@ -100,8 +102,8 @@ def test_vhost_user_vga_virgl(self):
 if not vug:
 self.cancel("Could not find vhost-user-gpu")
 
-kernel_path = self.fetch_asset(self.KERNEL_URL)
-initrd_path = self.fetch_asset(self.INITRD_URL)
+kernel_path = self.fetch_asset(self.KERNEL_URL, self.KERNEL_HASH)
+initrd_path = self.fetch_asset(self.INITRD_URL, self.INITRD_HASH)
 
 # Create socketpair to connect proxy and remote processes
 qemu_sock, vug_sock = socket.socketpair(
-- 
2.31.1

[PATCH 5/6] tests/acceptance/virtio-gpu.py: use virtio-vga-gl

[Cleber Rosa]

Since 49afbca3b, the use of an optional virgl renderer is not
available anymore, and since b36eb8860f, the way to choose a GL based
rendered is to use the "virtio-vga-gl" device.

Signed-off-by: Cleber Rosa 
---
 tests/acceptance/virtio-gpu.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/acceptance/virtio-gpu.py b/tests/acceptance/virtio-gpu.py
index fbde278705..0f84affe82 100644
--- a/tests/acceptance/virtio-gpu.py
+++ b/tests/acceptance/virtio-gpu.py
@@ -56,7 +56,7 @@ def wait_for_console_pattern(self, success_message, vm=None):
 
 def test_virtio_vga_virgl(self):
 """
-:avocado: tags=device:virtio-vga
+:avocado: tags=device:virtio-vga-gl
 """
 # FIXME: should check presence of virtio, virgl etc
 self.require_accelerator('kvm')
@@ -67,7 +67,7 @@ def test_virtio_vga_virgl(self):
 self.vm.set_console()
 self.vm.add_args("-m", "2G")
 self.vm.add_args("-machine", "pc,accel=kvm")
-self.vm.add_args("-device", "virtio-vga,virgl=on")
+self.vm.add_args("-device", "virtio-vga-gl")
 self.vm.add_args("-display", "egl-headless")
 self.vm.add_args(
 "-kernel",
-- 
2.31.1

[PATCH 3/6] tests/acceptance/virtio-gpu.py: combine CPU tags

[Cleber Rosa]

Like previously done with the arch tags, all tests use the same CPU
value so it's possible to combine them at the class level.

Signed-off-by: Cleber Rosa 
---
 tests/acceptance/virtio-gpu.py | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tests/acceptance/virtio-gpu.py b/tests/acceptance/virtio-gpu.py
index 729b99b2e5..20a59fabf3 100644
--- a/tests/acceptance/virtio-gpu.py
+++ b/tests/acceptance/virtio-gpu.py
@@ -31,6 +31,7 @@ class VirtioGPUx86(Test):
 """
 :avocado: tags=virtio-gpu
 :avocado: tags=arch:x86_64
+:avocado: tags=cpu:host
 """
 
 KERNEL_COMMON_COMMAND_LINE = "printk.time=0 "
@@ -56,7 +57,6 @@ def wait_for_console_pattern(self, success_message, vm=None):
 def test_virtio_vga_virgl(self):
 """
 :avocado: tags=device:virtio-vga
-:avocado: tags=cpu:host
 """
 kernel_command_line = (
 self.KERNEL_COMMON_COMMAND_LINE + "console=ttyS0 rdinit=/bin/bash"
@@ -95,7 +95,6 @@ def test_virtio_vga_virgl(self):
 def test_vhost_user_vga_virgl(self):
 """
 :avocado: tags=device:vhost-user-vga
-:avocado: tags=cpu:host
 """
 kernel_command_line = (
 self.KERNEL_COMMON_COMMAND_LINE + "console=ttyS0 rdinit=/bin/bash"
-- 
2.31.1