Re: [PATCH] target/riscv: write back unmodified value for csrrc/csrrs with rs1 is not x0 but holding zero

[Alistair Francis]

On Fri, Mar 11, 2022 at 2:58 PM Weiwei Li  wrote:
>
>
> 在 2022/3/11 上午10:58, Alistair Francis 写道:
> > On Wed, Mar 2, 2022 at 11:50 PM Weiwei Li  wrote:
> >>   For csrrs and csrrc, if rs1 specifies a register other than x0, 
> >> holding
> >>   a zero value, the instruction will still attempt to write the 
> >> unmodified
> >>   value back to the csr and will cause side effects
> >>
> >> Signed-off-by: Weiwei Li 
> >> Signed-off-by: Junqiang Wang 
> >> ---
> >>   target/riscv/csr.c   | 46 
> >>   target/riscv/op_helper.c |  7 +-
> >>   2 files changed, 39 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> >> index aea82dff4a..f4774ca07b 100644
> >> --- a/target/riscv/csr.c
> >> +++ b/target/riscv/csr.c
> >> @@ -2872,7 +2872,7 @@ static RISCVException write_upmbase(CPURISCVState 
> >> *env, int csrno,
> >>
> >>   static inline RISCVException riscv_csrrw_check(CPURISCVState *env,
> >>  int csrno,
> >> -   bool write_mask,
> >> +   bool write_csr,
> >>  RISCVCPU *cpu)
> >>   {
> >>   /* check privileges and return RISCV_EXCP_ILLEGAL_INST if check 
> >> fails */
> >> @@ -2895,7 +2895,7 @@ static inline RISCVException 
> >> riscv_csrrw_check(CPURISCVState *env,
> >>   return RISCV_EXCP_ILLEGAL_INST;
> >>   }
> >>   #endif
> >> -if (write_mask && read_only) {
> >> +if (write_csr && read_only) {
> >>   return RISCV_EXCP_ILLEGAL_INST;
> >>   }
> >>
> >> @@ -2915,7 +2915,8 @@ static inline RISCVException 
> >> riscv_csrrw_check(CPURISCVState *env,
> >>   static RISCVException riscv_csrrw_do64(CPURISCVState *env, int csrno,
> >>  target_ulong *ret_value,
> >>  target_ulong new_value,
> >> -   target_ulong write_mask)
> >> +   target_ulong write_mask,
> >> +   bool write_csr)
> >>   {
> >>   RISCVException ret;
> >>   target_ulong old_value;
> >> @@ -2935,8 +2936,8 @@ static RISCVException riscv_csrrw_do64(CPURISCVState 
> >> *env, int csrno,
> >>   return ret;
> >>   }
> >>
> >> -/* write value if writable and write mask set, otherwise drop writes 
> >> */
> >> -if (write_mask) {
> >> +/* write value if needed, otherwise drop writes */
> >> +if (write_csr) {
> >>   new_value = (old_value & ~write_mask) | (new_value & write_mask);
> >>   if (csr_ops[csrno].write) {
> >>   ret = csr_ops[csrno].write(env, csrno, new_value);
> >> @@ -2960,18 +2961,27 @@ RISCVException riscv_csrrw(CPURISCVState *env, int 
> >> csrno,
> >>   {
> >>   RISCVCPU *cpu = env_archcpu(env);
> >>
> >> -RISCVException ret = riscv_csrrw_check(env, csrno, write_mask, cpu);
> >> +/*
> >> + * write value when write_mask is set or rs1 is not x0 but holding 
> >> zero
> >> + * value for csrrc(new_value is zero) and csrrs(new_value is all-ones)
> > I don't understand this. Won't write_mask also be zero and when reading?
> >
> > Alistair
> >
> Yeah. It's true. To distinguish only-read operation with the special
> write case(write_mask = 0), I also modified the new_value of riscv_csrrw
> from 0 to 1 in helper_csrr :
>
>   target_ulong helper_csrr(CPURISCVState *env, int csr)
>   {
>   target_ulong val = 0;
> -RISCVException ret = riscv_csrrw(env, csr, , 0, 0);
> +
> +/*
> + * new_value here should be none-zero or none-all-ones here to
> + * distinguish with csrrc/csrrs with rs1 is not x0 but holding zero value
> + */
> +RISCVException ret = riscv_csrrw(env, csr, , 1, 0);

This is confusing though and I worry a future change will break this.
I think we should be explicit instead of using special combinations of
masks. What if a write operation occurred that wanted to write 1 with
a mark of 0?

The two options seem to either add a check for the seed CSR in
helper_csrr() to fault if the address matches. That's not the best as
then we have specific code, but this requirement seems pretty specific
as well so it's probably ok.

The other option would be to modify riscv_csrrw() to explicitly pass
in a `bool write_op` that you check against.

Alistair

>
>   if (ret != RISCV_EXCP_NONE) {
>   riscv_raise_exception(env, ret, GETPC());
>
>
> After modification, the cases for all csr related instructions is as follows:
>
> index instruction   helper write_mask
> new_valueRead/Write write_csr
>
> 1  csrrw csrrw/csrw all-ones
>  src1 (R)W true
>
> 2 csrrs(rs1=0) csrr  zero
> 1   R 

[PATCH] tcg/arm: Don't emit UNPREDICTABLE LDRD with Rm == Rt or Rt+1

[Richard Henderson]

The LDRD (register) instruction is UNPREDICTABLE if the Rm register
is the same as either Rt or Rt+1 (the two registers being loaded to).
We weren't making sure we avoided this, with the result that on some
host CPUs like the Cortex-A7 we would get a SIGILL because the CPU
chooses to UNDEF for this particular UNPREDICTABLE case.

Since we've already checked that datalo is aligned, we can simplify
the test vs the Rm operand by aligning it before comparison.  Check
for the two orderings before falling back to two ldr instructions.

We don't bother to do anything similar for tcg_out_ldrd_rwb(),
because it is only used in tcg_out_tlb_read() with a fixed set of
registers which don't overlap.

There is no equivalent UNPREDICTABLE case for STRD.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/896
Signed-off-by: Richard Henderson 
---
 tcg/arm/tcg-target.c.inc | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/tcg/arm/tcg-target.c.inc b/tcg/arm/tcg-target.c.inc
index e1ea69669c..4bc0420f4d 100644
--- a/tcg/arm/tcg-target.c.inc
+++ b/tcg/arm/tcg-target.c.inc
@@ -1689,8 +1689,21 @@ static void tcg_out_qemu_ld_index(TCGContext *s, MemOp 
opc,
 /* LDRD requires alignment; double-check that. */
 if (get_alignment_bits(opc) >= MO_64
 && (datalo & 1) == 0 && datahi == datalo + 1) {
-tcg_out_ldrd_r(s, COND_AL, datalo, addrlo, addend);
-} else if (scratch_addend) {
+/*
+ * Rm (the second address op) must not overlap Rt or Rt + 1.
+ * Since datalo is aligned, we can simplify the test via alignment.
+ * Flip the two address arguments if that works.
+ */
+if ((addend & ~1) != datalo) {
+tcg_out_ldrd_r(s, COND_AL, datalo, addrlo, addend);
+break;
+}
+if ((addrlo & ~1) != datalo) {
+tcg_out_ldrd_r(s, COND_AL, datalo, addend, addrlo);
+break;
+}
+}
+if (scratch_addend) {
 tcg_out_ld32_rwb(s, COND_AL, datalo, addend, addrlo);
 tcg_out_ld32_12(s, COND_AL, datahi, addend, 4);
 } else {
-- 
2.25.1

Re: [RFC PATCH] hw/i386/e820: remove legacy reserved entries for e820

[Ani Sinha]

On Thu, Mar 10, 2022 at 10:12 PM Igor Mammedov  wrote:
>
> On Thu, 10 Mar 2022 11:51:37 +0530
> Ani Sinha  wrote:
>
> > On Mon, Feb 28, 2022 at 8:56 PM Ani Sinha  wrote:
> > >
> > > e820 reserved entries were used before the dynamic entries with fw config 
> > > files
> > > were intoduced into qemu with the following change:
> > > 7d67110f2d9a6("pc: add etc/e820 fw_cfg file")
> > >
> > > Identical support was introduced into seabios as well with the following 
> > > commit:
> > > ce39bd4031820 ("Add support for etc/e820 fw_cfg file")
> > >
> > > Both the above commits are now quite old. Seabios uses fw config files and
> > > dynamic e820 entries by default and only falls back to using reserved 
> > > entries
> > > when it has to work with old qemu (versions earlier than 1.7). Please see
> > > functions qemu_cfg_e820() and qemu_early_e820(). It is safe to remove 
> > > legacy
> > > FW_CFG_E820_TABLE and associated code. It would be incredibly rare to run 
> > > the
> > > latest qemu version with a very old version of seabios that did not 
> > > support
> > > fw config files for e820.
> > >
> > > As far as I could see, edk2/ovfm never supported reserved entries and 
> > > uses fw
> > > config files from the beginning. So there should be no incompatibilities 
> > > with
> > > ovfm as well.
> >
> > Igor, Gerd, as I had replied in the other thread, I am not sure if we
> > need the compatibility dance in order to do this. I think we can't
> > carry this legacy stuff on forever.
> > Please advice.
>
> see commit 7d67110f2d
> until we have older machine types it must stay or have a compat knob,
> once they are gone we can remove it as 1.7 and older machine types
> are supposed to have newer SeaBIOS version that doesn't utilize
> it anymore.
>
> so add a compat knob (not sure if it's worth the trouble) or
> wait till pre 1.7 machines are gone and then rebase/repost.

Ok fine,. I will wait till 7.0 is released at which point
pc-1440fx-1.7 machine will be deprecated.
I will repost it again after that.

Re: [PATCH] ppc/xive2: Make type Xive2EndSource not user creatable

[Cédric Le Goater]

On 3/11/22 08:45, Thomas Huth wrote:

On 11/03/2022 08.43, Cédric Le Goater wrote:

Xive2EndSource objects can only be instantiated through a Xive2Router
(PnvXive2).

Suggested-by: Thomas Huth 
Signed-off-by: Cédric Le Goater 
---
  hw/intc/xive2.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/hw/intc/xive2.c b/hw/intc/xive2.c
index b6452f14784b..3aff42a69ef5 100644
--- a/hw/intc/xive2.c
+++ b/hw/intc/xive2.c
@@ -1000,6 +1000,7 @@ static void xive2_end_source_class_init(ObjectClass 
*klass, void *data)
  dc->desc    = "XIVE END Source";
  device_class_set_props(dc, xive2_end_source_properties);
  dc->realize = xive2_end_source_realize;
+    dc->user_creatable = false;
  }


Reviewed-by: Thomas Huth 


And,

Fixes: f8a233dedf25 ("ppc/xive2: Introduce a XIVE2 core framework")

Thanks,

C.
 

Re: [PATCH] ppc/xive2: Make type Xive2EndSource not user creatable

[Thomas Huth]

On 11/03/2022 08.43, Cédric Le Goater wrote:

Xive2EndSource objects can only be instantiated through a Xive2Router
(PnvXive2).

Suggested-by: Thomas Huth 
Signed-off-by: Cédric Le Goater 
---
  hw/intc/xive2.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/hw/intc/xive2.c b/hw/intc/xive2.c
index b6452f14784b..3aff42a69ef5 100644
--- a/hw/intc/xive2.c
+++ b/hw/intc/xive2.c
@@ -1000,6 +1000,7 @@ static void xive2_end_source_class_init(ObjectClass 
*klass, void *data)
  dc->desc= "XIVE END Source";
  device_class_set_props(dc, xive2_end_source_properties);
  dc->realize = xive2_end_source_realize;
+dc->user_creatable = false;
  }


Reviewed-by: Thomas Huth 

[PATCH] ppc/xive2: Make type Xive2EndSource not user creatable

[Cédric Le Goater]

Xive2EndSource objects can only be instantiated through a Xive2Router
(PnvXive2).

Suggested-by: Thomas Huth 
Signed-off-by: Cédric Le Goater 
---
 hw/intc/xive2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/intc/xive2.c b/hw/intc/xive2.c
index b6452f14784b..3aff42a69ef5 100644
--- a/hw/intc/xive2.c
+++ b/hw/intc/xive2.c
@@ -1000,6 +1000,7 @@ static void xive2_end_source_class_init(ObjectClass 
*klass, void *data)
 dc->desc= "XIVE END Source";
 device_class_set_props(dc, xive2_end_source_properties);
 dc->realize = xive2_end_source_realize;
+dc->user_creatable = false;
 }
 
 static const TypeInfo xive2_end_source_info = {
-- 
2.34.1

Re: [PATCH v4 01/18] ppc/xive2: Introduce a XIVE2 core framework

[Cédric Le Goater]

+static const TypeInfo xive2_end_source_info = {
+    .name  = TYPE_XIVE2_END_SOURCE,
+    .parent    = TYPE_DEVICE,
+    .instance_size = sizeof(Xive2EndSource),
+    .class_init    = xive2_end_source_class_init,
+};


This device can be used to crash QEMU:

$ ./qemu-system-ppc64 -nographic  -device xive2-end-source
qemu-system-ppc64: ../../devel/qemu/hw/intc/xive2.c:966: xive2_end_source_realize: 
Assertion `xsrc->xrtr' failed.
Aborted (core dumped)

Should it be user_creatable = false ?


Clearly yes.

Thanks,

C.

Re: [PATCH v8 09/14] target/riscv: rvk: add support for sha512 related instructions for RV32 in zknh extension

[Alistair Francis]

On Tue, Mar 1, 2022 at 10:01 PM Weiwei Li  wrote:
>
>  - add sha512sum0r, sha512sig0l, sha512sum1r, sha512sig1l, sha512sig0h and 
> sha512sig1h instructions
>
> Co-authored-by: Zewen Ye 
> Signed-off-by: Weiwei Li 
> Signed-off-by: Junqiang Wang 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/insn32.decode  |   6 ++
>  target/riscv/insn_trans/trans_rvk.c.inc | 100 
>  2 files changed, 106 insertions(+)
>
> diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
> index db28ecdd2b..02a0c71890 100644
> --- a/target/riscv/insn32.decode
> +++ b/target/riscv/insn32.decode
> @@ -862,3 +862,9 @@ sha256sig0  00 01000 00010 . 001 . 0010011 @r2
>  sha256sig1  00 01000 00011 . 001 . 0010011 @r2
>  sha256sum0  00 01000 0 . 001 . 0010011 @r2
>  sha256sum1  00 01000 1 . 001 . 0010011 @r2
> +sha512sum0r 01 01000 . . 000 . 0110011 @r
> +sha512sum1r 01 01001 . . 000 . 0110011 @r
> +sha512sig0l 01 01010 . . 000 . 0110011 @r
> +sha512sig0h 01 01110 . . 000 . 0110011 @r
> +sha512sig1l 01 01011 . . 000 . 0110011 @r
> +sha512sig1h 01 0 . . 000 . 0110011 @r
> diff --git a/target/riscv/insn_trans/trans_rvk.c.inc 
> b/target/riscv/insn_trans/trans_rvk.c.inc
> index beea7f8e96..bb89a53f52 100644
> --- a/target/riscv/insn_trans/trans_rvk.c.inc
> +++ b/target/riscv/insn_trans/trans_rvk.c.inc
> @@ -167,3 +167,103 @@ static bool trans_sha256sum1(DisasContext *ctx, 
> arg_sha256sum1 *a)
>  REQUIRE_ZKNH(ctx);
>  return gen_sha256(ctx, a, EXT_NONE, tcg_gen_rotri_i32, 6, 11, 25);
>  }
> +
> +static bool gen_sha512_rv32(DisasContext *ctx, arg_r *a, DisasExtend ext,
> +void (*func1)(TCGv_i64, TCGv_i64, int64_t),
> +void (*func2)(TCGv_i64, TCGv_i64, int64_t),
> +int64_t num1, int64_t num2, int64_t num3)
> +{
> +TCGv dest = dest_gpr(ctx, a->rd);
> +TCGv src1 = get_gpr(ctx, a->rs1, ext);
> +TCGv src2 = get_gpr(ctx, a->rs2, ext);
> +TCGv_i64 t0 = tcg_temp_new_i64();
> +TCGv_i64 t1 = tcg_temp_new_i64();
> +TCGv_i64 t2 = tcg_temp_new_i64();
> +
> +tcg_gen_concat_tl_i64(t0, src1, src2);
> +func1(t1, t0, num1);
> +func2(t2, t0, num2);
> +tcg_gen_xor_i64(t1, t1, t2);
> +tcg_gen_rotri_i64(t2, t0, num3);
> +tcg_gen_xor_i64(t1, t1, t2);
> +tcg_gen_trunc_i64_tl(dest, t1);
> +
> +gen_set_gpr(ctx, a->rd, dest);
> +tcg_temp_free_i64(t0);
> +tcg_temp_free_i64(t1);
> +tcg_temp_free_i64(t2);
> +return true;
> +}
> +
> +static bool trans_sha512sum0r(DisasContext *ctx, arg_sha512sum0r *a)
> +{
> +REQUIRE_32BIT(ctx);
> +REQUIRE_ZKNH(ctx);
> +return gen_sha512_rv32(ctx, a, EXT_NONE, tcg_gen_rotli_i64,
> +   tcg_gen_rotli_i64, 25, 30, 28);
> +}
> +
> +static bool trans_sha512sum1r(DisasContext *ctx, arg_sha512sum1r *a)
> +{
> +REQUIRE_32BIT(ctx);
> +REQUIRE_ZKNH(ctx);
> +return gen_sha512_rv32(ctx, a, EXT_NONE, tcg_gen_rotli_i64,
> +   tcg_gen_rotri_i64, 23, 14, 18);
> +}
> +
> +static bool trans_sha512sig0l(DisasContext *ctx, arg_sha512sig0l *a)
> +{
> +REQUIRE_32BIT(ctx);
> +REQUIRE_ZKNH(ctx);
> +return gen_sha512_rv32(ctx, a, EXT_NONE, tcg_gen_rotri_i64,
> +   tcg_gen_rotri_i64, 1, 7, 8);
> +}
> +
> +static bool trans_sha512sig1l(DisasContext *ctx, arg_sha512sig1l *a)
> +{
> +REQUIRE_32BIT(ctx);
> +REQUIRE_ZKNH(ctx);
> +return gen_sha512_rv32(ctx, a, EXT_NONE, tcg_gen_rotli_i64,
> +   tcg_gen_rotri_i64, 3, 6, 19);
> +}
> +
> +static bool gen_sha512h_rv32(DisasContext *ctx, arg_r *a, DisasExtend ext,
> + void (*func)(TCGv_i64, TCGv_i64, int64_t),
> + int64_t num1, int64_t num2, int64_t num3)
> +{
> +TCGv dest = dest_gpr(ctx, a->rd);
> +TCGv src1 = get_gpr(ctx, a->rs1, ext);
> +TCGv src2 = get_gpr(ctx, a->rs2, ext);
> +TCGv_i64 t0 = tcg_temp_new_i64();
> +TCGv_i64 t1 = tcg_temp_new_i64();
> +TCGv_i64 t2 = tcg_temp_new_i64();
> +
> +tcg_gen_concat_tl_i64(t0, src1, src2);
> +func(t1, t0, num1);
> +tcg_gen_ext32u_i64(t2, t0);
> +tcg_gen_shri_i64(t2, t2, num2);
> +tcg_gen_xor_i64(t1, t1, t2);
> +tcg_gen_rotri_i64(t2, t0, num3);
> +tcg_gen_xor_i64(t1, t1, t2);
> +tcg_gen_trunc_i64_tl(dest, t1);
> +
> +gen_set_gpr(ctx, a->rd, dest);
> +tcg_temp_free_i64(t0);
> +tcg_temp_free_i64(t1);
> +tcg_temp_free_i64(t2);
> +return true;
> +}
> +
> +static bool trans_sha512sig0h(DisasContext *ctx, arg_sha512sig0h *a)
> +{
> +REQUIRE_32BIT(ctx);
> +REQUIRE_ZKNH(ctx);
> +return gen_sha512h_rv32(ctx, a, EXT_NONE, tcg_gen_rotri_i64, 1, 7, 8);
> +}
> +
> +static bool trans_sha512sig1h(DisasContext *ctx, arg_sha512sig1h *a)
> +{
> +REQUIRE_32BIT(ctx);
> +

Re: [libvirt] [PATCH RESEND v2 0/4] re-introduce

[Erik Skultety]

On Wed, Mar 09, 2022 at 12:47:26PM +0530, Ani Sinha wrote:
> 
> 
> On Tue, 8 Mar 2022, Michael S. Tsirkin wrote:
> 
> > On Tue, Mar 08, 2022 at 10:23:20PM +0530, Ani Sinha wrote:
> > > On Tue, Mar 8, 2022 at 10:17 PM Michael S. Tsirkin  
> > > wrote:
> > > >
> > > > On Tue, Mar 08, 2022 at 10:15:11PM +0530, Ani Sinha wrote:
> > > > >
> > > > >
> > > > > On Tue, 8 Mar 2022, Laine Stump wrote:
> > > > >
> > > > > > Aha! the domain of qemu-devel@nongnu.org was incorrect in the 
> > > > > > original send
> > > > > > (it was "nognu.org"), so none of this thread was making it to that 
> > > > > > list.
> > > > >
> > > > >
> > > > > Not to give any excuses but this happened because on Qemu side I never
> > > > > have to type this manually. My git config is set up so that
> > > > > the cc in send-email is filled up automatically using
> > > > > scripts/get_maintainer.pl. On libvirt side also the domain and mailing
> > > > > list is easy to remember. Its only when I have to manually type stuff 
> > > > > that
> > > > > shit happens :-)
> > > >
> > > > Donnu about alpine, but with mutt you can easily set up
> > > > and alias and then it expands for you.
> > >
> > > I use alpine to only reply/review patches. I use git send-email to
> > > actually send the patch. There I am not sure the best way to avoid
> > > manually typing in the mailing list address.
> >
> > send-email supports aliases too.
> 
> Ah cool. I just set this up with some help from
> https://felipec.wordpress.com/2009/10/25/git-send-email-tricks/ . Now I
> can simply say
> 
> $ git send-email --to=qemu-list 
> 
> without worrying about typo :-) Thanks for the pointer.
> 

So, in context of sending patches to mailing lists, especially with libvirt and
QEMU, you could utilize 'git publish'. Both QEMU and libvirt have a .gitpublish
config in the repo which sets some git-send email options, especially the
QEMU's one is nice listing a bunch of common profile templates as well.
I'd say that if you're contributing to a project which doesn't have a
.gitpublish config yet, then rather than not using 'git publish', the project
should adopt the config instead :).

Regards,
Erik

Re: [PATCH v4 07/18] ppc/pnv: Add a HOMER model to POWER10

[Cédric Le Goater]

On 3/11/22 07:05, Alexey Kardashevskiy wrote:
What is that HOMER thing anyway? 


I don't remember what the acronym stands for, I think "HOst MEmory
Region". Vaidy or Mahesh could tell.


skiboot and qemu mention it a lot but I cannot find traces in any available 
spec.


It is really deep deep under the hood.

It is a logic (PBA) bridging system memory, power bus, OCC SRAM.
It exposes a memory region that can be accessed through the OCC,
FSP/BMC and the host. There, are mapped the power state table,
the sensor table among other things.

  See commit 8f09231631c7 ("ppc/pnv: Introduce PBA registers")

There are some experimental QEMU patches exposing these tables
which would be interesting to tune our skiboot and Linux support
in these areas. They were never completed.

Thanks,

C.



On 3/1/22 02:52, Cédric Le Goater wrote:

Reviewed-by: David Gibson 
Signed-off-by: Cédric Le Goater 
---
  include/hw/ppc/pnv.h   | 10 ++
  include/hw/ppc/pnv_homer.h |  3 ++
  include/hw/ppc/pnv_xscom.h |  3 ++
  hw/ppc/pnv.c   | 20 
  hw/ppc/pnv_homer.c | 64 ++
  5 files changed, 100 insertions(+)

diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index e5141851faed..1e34ddd502d8 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -129,6 +129,7 @@ struct Pnv10Chip {
  Pnv9Psi  psi;
  PnvLpcController lpc;
  PnvOCC   occ;
+    PnvHomer homer;
  uint32_t nr_quads;
  PnvQuad  *quads;
@@ -364,4 +365,13 @@ void pnv_bmc_set_pnor(IPMIBmc *bmc, PnvPnor *pnor);
  #define PNV10_XIVE2_END_SIZE    0x0200ull
  #define PNV10_XIVE2_END_BASE(chip)  PNV10_CHIP_BASE(chip, 
0x00060600ull)
+#define PNV10_OCC_COMMON_AREA_SIZE  0x0080ull
+#define PNV10_OCC_COMMON_AREA_BASE  0x300fff80ull
+#define PNV10_OCC_SENSOR_BASE(chip) (PNV10_OCC_COMMON_AREA_BASE +   \
+    PNV_OCC_SENSOR_DATA_BLOCK_BASE((chip)->chip_id))
+
+#define PNV10_HOMER_SIZE  0x0040ull
+#define PNV10_HOMER_BASE(chip)   \
+    (0x300ffd80ll + ((uint64_t)(chip)->chip_id) * PNV10_HOMER_SIZE)
+
  #endif /* PPC_PNV_H */
diff --git a/include/hw/ppc/pnv_homer.h b/include/hw/ppc/pnv_homer.h
index 1889e3083c57..07e8b193116e 100644
--- a/include/hw/ppc/pnv_homer.h
+++ b/include/hw/ppc/pnv_homer.h
@@ -32,6 +32,9 @@ DECLARE_INSTANCE_CHECKER(PnvHomer, PNV8_HOMER,
  #define TYPE_PNV9_HOMER TYPE_PNV_HOMER "-POWER9"
  DECLARE_INSTANCE_CHECKER(PnvHomer, PNV9_HOMER,
   TYPE_PNV9_HOMER)
+#define TYPE_PNV10_HOMER TYPE_PNV_HOMER "-POWER10"
+DECLARE_INSTANCE_CHECKER(PnvHomer, PNV10_HOMER,
+ TYPE_PNV10_HOMER)
  struct PnvHomer {
  DeviceState parent;
diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
index 75db33d46af6..7c7440de0c40 100644
--- a/include/hw/ppc/pnv_xscom.h
+++ b/include/hw/ppc/pnv_xscom.h
@@ -134,6 +134,9 @@ struct PnvXScomInterfaceClass {
  #define PNV10_XSCOM_OCC_BASE   PNV9_XSCOM_OCC_BASE
  #define PNV10_XSCOM_OCC_SIZE   PNV9_XSCOM_OCC_SIZE
+#define PNV10_XSCOM_PBA_BASE   0x01010CDA
+#define PNV10_XSCOM_PBA_SIZE   0x40
+
  #define PNV10_XSCOM_XIVE2_BASE 0x2010800
  #define PNV10_XSCOM_XIVE2_SIZE 0x400
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c
index 8ecdfb1884b4..0b53406fe29c 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1595,6 +1595,7 @@ static void pnv_chip_power10_instance_init(Object *obj)
  object_initialize_child(obj, "psi", >psi, TYPE_PNV10_PSI);
  object_initialize_child(obj, "lpc", >lpc, TYPE_PNV10_LPC);
  object_initialize_child(obj, "occ",  >occ, TYPE_PNV10_OCC);
+    object_initialize_child(obj, "homer", >homer, TYPE_PNV10_HOMER);
  if (defaults_enabled()) {
  chip->num_pecs = pcc->num_pecs;
@@ -1731,6 +1732,25 @@ static void pnv_chip_power10_realize(DeviceState *dev, 
Error **errp)
  pnv_xscom_add_subregion(chip, PNV10_XSCOM_OCC_BASE,
  >occ.xscom_regs);
+    /* OCC SRAM model */
+    memory_region_add_subregion(get_system_memory(),
+    PNV10_OCC_SENSOR_BASE(chip),
+    >occ.sram_regs);
+
+    /* HOMER */
+    object_property_set_link(OBJECT(>homer), "chip", OBJECT(chip),
+ _abort);
+    if (!qdev_realize(DEVICE(>homer), NULL, errp)) {
+    return;
+    }
+    /* Homer Xscom region */
+    pnv_xscom_add_subregion(chip, PNV10_XSCOM_PBA_BASE,
+    >homer.pba_regs);
+
+    /* Homer mmio region */
+    memory_region_add_subregion(get_system_memory(), PNV10_HOMER_BASE(chip),
+    >homer.regs);
+
  /* PHBs */
  pnv_chip_power10_phb_realize(chip, _err);
  if (local_err) {
diff --git a/hw/ppc/pnv_homer.c b/hw/ppc/pnv_homer.c
index 9a262629b73a..ea73919e54ca 100644
--- a/hw/ppc/pnv_homer.c
+++ b/hw/ppc/pnv_homer.c
@@ -332,6 +332,69 @@ 

Re: [PATCH v8 08/14] target/riscv: rvk: add support for sha256 related instructions in zknh extension

[Alistair Francis]

On Tue, Mar 1, 2022 at 10:09 PM Weiwei Li  wrote:
>
>  - add sha256sig0, sha256sig1, sha256sum0 and sha256sum1 instructions
>
> Co-authored-by: Zewen Ye 
> Signed-off-by: Weiwei Li 
> Signed-off-by: Junqiang Wang 
> Reviewed-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/insn32.decode  |  5 +++
>  target/riscv/insn_trans/trans_rvk.c.inc | 55 +
>  2 files changed, 60 insertions(+)
>
> diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
> index 0b800b4093..db28ecdd2b 100644
> --- a/target/riscv/insn32.decode
> +++ b/target/riscv/insn32.decode
> @@ -857,3 +857,8 @@ aes64esm00 11011 . . 000 . 0110011 @r
>  # *** RV64 Zkne/zknd Standard Extension ***
>  aes64ks201 1 . . 000 . 0110011 @r
>  aes64ks1i   00 11000 1 . 001 . 0010011 @i_aes
> +# *** RV32 Zknh Standard Extension ***
> +sha256sig0  00 01000 00010 . 001 . 0010011 @r2
> +sha256sig1  00 01000 00011 . 001 . 0010011 @r2
> +sha256sum0  00 01000 0 . 001 . 0010011 @r2
> +sha256sum1  00 01000 1 . 001 . 0010011 @r2
> diff --git a/target/riscv/insn_trans/trans_rvk.c.inc 
> b/target/riscv/insn_trans/trans_rvk.c.inc
> index b86f931b13..beea7f8e96 100644
> --- a/target/riscv/insn_trans/trans_rvk.c.inc
> +++ b/target/riscv/insn_trans/trans_rvk.c.inc
> @@ -29,6 +29,12 @@
>  }   \
>  } while (0)
>
> +#define REQUIRE_ZKNH(ctx) do {  \
> +if (!ctx->cfg_ptr->ext_zknh) {  \
> +return false;   \
> +}   \
> +} while (0)
> +
>  static bool gen_aes32_sm4(DisasContext *ctx, arg_k_aes *a,
>void (*func)(TCGv, TCGv, TCGv, TCGv))
>  {
> @@ -112,3 +118,52 @@ static bool trans_aes64im(DisasContext *ctx, arg_aes64im 
> *a)
>  REQUIRE_ZKND(ctx);
>  return gen_unary(ctx, a, EXT_NONE, gen_helper_aes64im);
>  }
> +
> +static bool gen_sha256(DisasContext *ctx, arg_r2 *a, DisasExtend ext,
> +   void (*func)(TCGv_i32, TCGv_i32, int32_t),
> +   int32_t num1, int32_t num2, int32_t num3)
> +{
> +TCGv dest = dest_gpr(ctx, a->rd);
> +TCGv src1 = get_gpr(ctx, a->rs1, ext);
> +TCGv_i32 t0 = tcg_temp_new_i32();
> +TCGv_i32 t1 = tcg_temp_new_i32();
> +TCGv_i32 t2 = tcg_temp_new_i32();
> +
> +tcg_gen_trunc_tl_i32(t0, src1);
> +tcg_gen_rotri_i32(t1, t0, num1);
> +tcg_gen_rotri_i32(t2, t0, num2);
> +tcg_gen_xor_i32(t1, t1, t2);
> +func(t2, t0, num3);
> +tcg_gen_xor_i32(t1, t1, t2);
> +tcg_gen_ext_i32_tl(dest, t1);
> +
> +gen_set_gpr(ctx, a->rd, dest);
> +tcg_temp_free_i32(t0);
> +tcg_temp_free_i32(t1);
> +tcg_temp_free_i32(t2);
> +return true;
> +}
> +
> +static bool trans_sha256sig0(DisasContext *ctx, arg_sha256sig0 *a)
> +{
> +REQUIRE_ZKNH(ctx);
> +return gen_sha256(ctx, a, EXT_NONE, tcg_gen_shri_i32, 7, 18, 3);
> +}
> +
> +static bool trans_sha256sig1(DisasContext *ctx, arg_sha256sig1 *a)
> +{
> +REQUIRE_ZKNH(ctx);
> +return gen_sha256(ctx, a, EXT_NONE, tcg_gen_shri_i32, 17, 19, 10);
> +}
> +
> +static bool trans_sha256sum0(DisasContext *ctx, arg_sha256sum0 *a)
> +{
> +REQUIRE_ZKNH(ctx);
> +return gen_sha256(ctx, a, EXT_NONE, tcg_gen_rotri_i32, 2, 13, 22);
> +}
> +
> +static bool trans_sha256sum1(DisasContext *ctx, arg_sha256sum1 *a)
> +{
> +REQUIRE_ZKNH(ctx);
> +return gen_sha256(ctx, a, EXT_NONE, tcg_gen_rotri_i32, 6, 11, 25);
> +}
> --
> 2.17.1
>
>

Re: [PATCH 2/3] tcg/s390x: Fix INDEX_op_bitsel_vec vs VSEL

[Thomas Huth]

On 10/03/2022 21.27, Richard Henderson wrote:

The operands are output in the wrong order: the tcg selector
argument is first, whereas the s390x selector argument is last.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/898
Fixes: 9bca986df88 ("tcg/s390x: Implement TCG_TARGET_HAS_bitsel_vec")
Signed-off-by: Richard Henderson 
---
  tcg/s390x/tcg-target.c.inc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tcg/s390x/tcg-target.c.inc b/tcg/s390x/tcg-target.c.inc
index 508f1bccc7..3b185b3c96 100644
--- a/tcg/s390x/tcg-target.c.inc
+++ b/tcg/s390x/tcg-target.c.inc
@@ -2868,7 +2868,7 @@ static void tcg_out_vec_op(TCGContext *s, TCGOpcode opc,
  break;
  
  case INDEX_op_bitsel_vec:

-tcg_out_insn(s, VRRe, VSEL, a0, a1, a2, args[3]);
+tcg_out_insn(s, VRRe, VSEL, a0, a2, args[3], a1);
  break;
  
  case INDEX_op_cmp_vec:


Thank you very much, this indeed fixes the sha512 tet for me!

Tested-by: Thomas Huth 

Re: [PATCH v4 07/18] ppc/pnv: Add a HOMER model to POWER10

[Alexey Kardashevskiy]

What is that HOMER thing anyway? skiboot and qemu mention it a lot but I 
cannot find traces in any available spec.



On 3/1/22 02:52, Cédric Le Goater wrote:

Reviewed-by: David Gibson 
Signed-off-by: Cédric Le Goater 
---
  include/hw/ppc/pnv.h   | 10 ++
  include/hw/ppc/pnv_homer.h |  3 ++
  include/hw/ppc/pnv_xscom.h |  3 ++
  hw/ppc/pnv.c   | 20 
  hw/ppc/pnv_homer.c | 64 ++
  5 files changed, 100 insertions(+)

diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
index e5141851faed..1e34ddd502d8 100644
--- a/include/hw/ppc/pnv.h
+++ b/include/hw/ppc/pnv.h
@@ -129,6 +129,7 @@ struct Pnv10Chip {
  Pnv9Psi  psi;
  PnvLpcController lpc;
  PnvOCC   occ;
+PnvHomer homer;
  
  uint32_t nr_quads;

  PnvQuad  *quads;
@@ -364,4 +365,13 @@ void pnv_bmc_set_pnor(IPMIBmc *bmc, PnvPnor *pnor);
  #define PNV10_XIVE2_END_SIZE0x0200ull
  #define PNV10_XIVE2_END_BASE(chip)  PNV10_CHIP_BASE(chip, 
0x00060600ull)
  
+#define PNV10_OCC_COMMON_AREA_SIZE  0x0080ull

+#define PNV10_OCC_COMMON_AREA_BASE  0x300fff80ull
+#define PNV10_OCC_SENSOR_BASE(chip) (PNV10_OCC_COMMON_AREA_BASE +   \
+PNV_OCC_SENSOR_DATA_BLOCK_BASE((chip)->chip_id))
+
+#define PNV10_HOMER_SIZE  0x0040ull
+#define PNV10_HOMER_BASE(chip)   \
+(0x300ffd80ll + ((uint64_t)(chip)->chip_id) * PNV10_HOMER_SIZE)
+
  #endif /* PPC_PNV_H */
diff --git a/include/hw/ppc/pnv_homer.h b/include/hw/ppc/pnv_homer.h
index 1889e3083c57..07e8b193116e 100644
--- a/include/hw/ppc/pnv_homer.h
+++ b/include/hw/ppc/pnv_homer.h
@@ -32,6 +32,9 @@ DECLARE_INSTANCE_CHECKER(PnvHomer, PNV8_HOMER,
  #define TYPE_PNV9_HOMER TYPE_PNV_HOMER "-POWER9"
  DECLARE_INSTANCE_CHECKER(PnvHomer, PNV9_HOMER,
   TYPE_PNV9_HOMER)
+#define TYPE_PNV10_HOMER TYPE_PNV_HOMER "-POWER10"
+DECLARE_INSTANCE_CHECKER(PnvHomer, PNV10_HOMER,
+ TYPE_PNV10_HOMER)
  
  struct PnvHomer {

  DeviceState parent;
diff --git a/include/hw/ppc/pnv_xscom.h b/include/hw/ppc/pnv_xscom.h
index 75db33d46af6..7c7440de0c40 100644
--- a/include/hw/ppc/pnv_xscom.h
+++ b/include/hw/ppc/pnv_xscom.h
@@ -134,6 +134,9 @@ struct PnvXScomInterfaceClass {
  #define PNV10_XSCOM_OCC_BASE   PNV9_XSCOM_OCC_BASE
  #define PNV10_XSCOM_OCC_SIZE   PNV9_XSCOM_OCC_SIZE
  
+#define PNV10_XSCOM_PBA_BASE   0x01010CDA

+#define PNV10_XSCOM_PBA_SIZE   0x40
+
  #define PNV10_XSCOM_XIVE2_BASE 0x2010800
  #define PNV10_XSCOM_XIVE2_SIZE 0x400
  
diff --git a/hw/ppc/pnv.c b/hw/ppc/pnv.c

index 8ecdfb1884b4..0b53406fe29c 100644
--- a/hw/ppc/pnv.c
+++ b/hw/ppc/pnv.c
@@ -1595,6 +1595,7 @@ static void pnv_chip_power10_instance_init(Object *obj)
  object_initialize_child(obj, "psi", >psi, TYPE_PNV10_PSI);
  object_initialize_child(obj, "lpc", >lpc, TYPE_PNV10_LPC);
  object_initialize_child(obj, "occ",  >occ, TYPE_PNV10_OCC);
+object_initialize_child(obj, "homer", >homer, TYPE_PNV10_HOMER);
  
  if (defaults_enabled()) {

  chip->num_pecs = pcc->num_pecs;
@@ -1731,6 +1732,25 @@ static void pnv_chip_power10_realize(DeviceState *dev, 
Error **errp)
  pnv_xscom_add_subregion(chip, PNV10_XSCOM_OCC_BASE,
  >occ.xscom_regs);
  
+/* OCC SRAM model */

+memory_region_add_subregion(get_system_memory(),
+PNV10_OCC_SENSOR_BASE(chip),
+>occ.sram_regs);
+
+/* HOMER */
+object_property_set_link(OBJECT(>homer), "chip", OBJECT(chip),
+ _abort);
+if (!qdev_realize(DEVICE(>homer), NULL, errp)) {
+return;
+}
+/* Homer Xscom region */
+pnv_xscom_add_subregion(chip, PNV10_XSCOM_PBA_BASE,
+>homer.pba_regs);
+
+/* Homer mmio region */
+memory_region_add_subregion(get_system_memory(), PNV10_HOMER_BASE(chip),
+>homer.regs);
+
  /* PHBs */
  pnv_chip_power10_phb_realize(chip, _err);
  if (local_err) {
diff --git a/hw/ppc/pnv_homer.c b/hw/ppc/pnv_homer.c
index 9a262629b73a..ea73919e54ca 100644
--- a/hw/ppc/pnv_homer.c
+++ b/hw/ppc/pnv_homer.c
@@ -332,6 +332,69 @@ static const TypeInfo pnv_homer_power9_type_info = {
  .class_init= pnv_homer_power9_class_init,
  };
  
+static uint64_t pnv_homer_power10_pba_read(void *opaque, hwaddr addr,

+  unsigned size)
+{
+PnvHomer *homer = PNV_HOMER(opaque);
+PnvChip *chip = homer->chip;
+uint32_t reg = addr >> 3;
+uint64_t val = 0;
+
+switch (reg) {
+case PBA_BAR0:
+val = PNV10_HOMER_BASE(chip);
+break;
+case PBA_BARMASK0: /* P10 homer region mask */
+val = (PNV10_HOMER_SIZE - 1) & 0x30;
+break;
+case PBA_BAR2: /* P10 occ common area */
+val = 

[PATCH v2 11/11] MAINTAINERS: take edk2

[Gerd Hoffmann]

Cc: Philippe Mathieu-Daudé 
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Philippe Mathieu-Daudé 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 68adaac373c7..ad1c9a7ea133 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3144,7 +3144,7 @@ F: docs/interop/firmware.json
 
 EDK2 Firmware
 M: Philippe Mathieu-Daudé 
-R: Gerd Hoffmann 
+M: Gerd Hoffmann 
 S: Supported
 F: hw/i386/*ovmf*
 F: pc-bios/descriptors/??-edk2-*.json
-- 
2.35.1

[PATCH v2 10/11] edk2/docker: use ubuntu 18.04

[Gerd Hoffmann]

Upstream CI uses ubuntu 18.04 too, so pick
that version (instead of something newer).

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Alex Bennée 
---
 .gitlab-ci.d/edk2/Dockerfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci.d/edk2/Dockerfile b/.gitlab-ci.d/edk2/Dockerfile
index 7484b3846d71..bbe50ff8328a 100644
--- a/.gitlab-ci.d/edk2/Dockerfile
+++ b/.gitlab-ci.d/edk2/Dockerfile
@@ -1,7 +1,7 @@
 #
 # Docker image to cross-compile EDK2 firmware binaries
 #
-FROM ubuntu:16.04
+FROM ubuntu:18.04
 
 MAINTAINER Philippe Mathieu-Daudé 
 
-- 
2.35.1

[PATCH v2 08/11] tests/acpi: disallow virt memory hotplug changes

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 tests/qtest/bios-tables-test-allowed-diff.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
b/tests/qtest/bios-tables-test-allowed-diff.h
index e569098abddc..dfb8523c8bf4 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1,2 +1 @@
 /* List of comma-separated changed AML files to ignore */
-"tests/data/acpi/virt/SSDT.memhp",
-- 
2.35.1

[PATCH v2 07/11] tests/acpi: update expected data files

[Gerd Hoffmann]

The switch to edk2 RELEASE builds changes the memory layout a bit,
resulting in a acpi table change.

 DefinitionBlock ("", "SSDT", 1, "BOCHS ", "NVDIMM", 0x0001)
 {
 Scope (\_SB)
 {
 Device (NVDR)
 {
 Name (_HID, "ACPI0012" /* NVDIMM Root Device */)  // _HID: 
Hardware ID
 Method (NCAL, 5, Serialized)
 {
 Local6 = MEMA /* \MEMA */
 {
 Return (NCAL (Arg0, Arg1, Arg2, Arg3, 0x02))
 }
 }

 Device (NV02)
 {
 Name (_ADR, 0x03)  // _ADR: Address
 Method (_DSM, 4, NotSerialized)  // _DSM: Device-Specific 
Method
 {
 Return (NCAL (Arg0, Arg1, Arg2, Arg3, 0x03))
 }
 }
 }
 }

-Name (MEMA, 0x43D1)
+Name (MEMA, 0x43F5)
 }

Signed-off-by: Gerd Hoffmann 
---
 tests/data/acpi/virt/SSDT.memhp | Bin 736 -> 736 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/tests/data/acpi/virt/SSDT.memhp b/tests/data/acpi/virt/SSDT.memhp
index 
375d7b6fc85a484f492a26ccd355c205f2c34473..4c363a6d95a7e2e826568c85f5719127748e7932
 100644
GIT binary patch
delta 22
dcmaFB`hb-yIM^lR0TTlQqx43uD@;sZodHo~2HXGu

delta 22
dcmaFB`hb-yIM^lR0TTlQqy0v%D@;rmodHrj2HXGu

-- 
2.35.1

[PATCH v2 09/11] edk2/docker: install python3

[Gerd Hoffmann]

python2 is not supported any more,
so go install python3 instead.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Alex Bennée 
---
 .gitlab-ci.d/edk2/Dockerfile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.gitlab-ci.d/edk2/Dockerfile b/.gitlab-ci.d/edk2/Dockerfile
index 13029310f6d6..7484b3846d71 100644
--- a/.gitlab-ci.d/edk2/Dockerfile
+++ b/.gitlab-ci.d/edk2/Dockerfile
@@ -20,7 +20,7 @@ RUN apt update \
 iasl \
 make \
 nasm \
-python \
+python3 \
 uuid-dev \
 && \
 \
-- 
2.35.1

[PATCH v2 04/11] edk2: .git can be a file

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
---
 roms/Makefile.edk2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
index 3d75a842a4df..6801ea62e8f1 100644
--- a/roms/Makefile.edk2
+++ b/roms/Makefile.edk2
@@ -51,7 +51,7 @@ all: $(foreach 
flashdev,$(flashdevs),../pc-bios/edk2-$(flashdev).fd.bz2) \
 # we're building from a tarball and that they've already been fetched by
 # make-release/tarball scripts.
 submodules:
-   if test -d edk2/.git; then \
+   if test -e edk2/.git; then \
cd edk2 && git submodule update --init --force -- \
ArmPkg/Library/ArmSoftFloatLib/berkeley-softfloat-3 \
BaseTools/Source/C/BrotliCompress/brotli \
-- 
2.35.1

[PATCH v2 02/11] edk2: update submodule to stable202202

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Alex Bennée 
---
 roms/edk2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/roms/edk2 b/roms/edk2
index 06dc822d045c..b24306f15daa 16
--- a/roms/edk2
+++ b/roms/edk2
@@ -1 +1 @@
-Subproject commit 06dc822d045c2bb42e497487935485302486e151
+Subproject commit b24306f15daa2ff8510b06702114724b33895d3c
-- 
2.35.1

[PATCH v2 05/11] edk2: add microvm build

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Philippe Mathieu-Daudé 
---
 roms/Makefile.edk2 | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
index 6801ea62e8f1..485f2244b159 100644
--- a/roms/Makefile.edk2
+++ b/roms/Makefile.edk2
@@ -33,6 +33,7 @@ flashdevs := \
i386-secure-code \
x86_64-code \
x86_64-secure-code \
+   x86_64-microvm \
\
arm-vars \
i386-vars
@@ -145,6 +146,16 @@ submodules:
-D SMM_REQUIRE
cp edk2/Build/Ovmf3264/$(target)_$(call 
toolchain,x86_64)/FV/OVMF_CODE.fd $@
 
+../pc-bios/edk2-x86_64-microvm.fd: submodules
+   +./edk2-build.sh \
+   x86_64 \
+   --arch=X64 \
+   --platform=OvmfPkg/Microvm/MicrovmX64.dsc \
+   -D NETWORK_IP6_ENABLE \
+   -D NETWORK_HTTP_BOOT_ENABLE \
+   -D NETWORK_TLS_ENABLE
+   cp edk2/Build/MicrovmX64/$(target)_$(call 
toolchain,x86_64)/FV/MICROVM.fd $@
+
 ../pc-bios/edk2-arm-vars.fd: ../pc-bios/edk2-arm-code.fd
cp edk2/Build/ArmVirtQemu-ARM/$(target)_$(call 
toolchain,arm)/FV/QEMU_VARS.fd \
$@
-- 
2.35.1

[PATCH v2 03/11] edk2: switch to release builds

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Philippe Mathieu-Daudé 
Reviewed-by: Alex Bennée 
---
 roms/Makefile.edk2 | 17 +
 roms/edk2-build.sh |  2 +-
 2 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/roms/Makefile.edk2 b/roms/Makefile.edk2
index fdae0b511f59..3d75a842a4df 100644
--- a/roms/Makefile.edk2
+++ b/roms/Makefile.edk2
@@ -13,6 +13,7 @@
 
 SHELL = /bin/bash
 
+target = RELEASE
 toolchain = $(shell source ./edk2-funcs.sh && qemu_edk2_get_toolchain $(1))
 
 licenses := \
@@ -73,7 +74,7 @@ submodules:
-D NETWORK_TLS_ENABLE \
-D TPM2_ENABLE \
-D TPM2_CONFIG_ENABLE
-   cp edk2/Build/ArmVirtQemu-AARCH64/DEBUG_$(call 
toolchain,aarch64)/FV/QEMU_EFI.fd \
+   cp edk2/Build/ArmVirtQemu-AARCH64/$(target)_$(call 
toolchain,aarch64)/FV/QEMU_EFI.fd \
$@
truncate --size=64M $@
 
@@ -87,7 +88,7 @@ submodules:
-D NETWORK_TLS_ENABLE \
-D TPM2_ENABLE \
-D TPM2_CONFIG_ENABLE
-   cp edk2/Build/ArmVirtQemu-ARM/DEBUG_$(call 
toolchain,arm)/FV/QEMU_EFI.fd \
+   cp edk2/Build/ArmVirtQemu-ARM/$(target)_$(call 
toolchain,arm)/FV/QEMU_EFI.fd \
$@
truncate --size=64M $@
 
@@ -101,7 +102,7 @@ submodules:
-D NETWORK_TLS_ENABLE \
-D TPM_ENABLE \
-D TPM_CONFIG_ENABLE
-   cp edk2/Build/OvmfIa32/DEBUG_$(call toolchain,i386)/FV/OVMF_CODE.fd $@
+   cp edk2/Build/OvmfIa32/$(target)_$(call toolchain,i386)/FV/OVMF_CODE.fd 
$@
 
 ../pc-bios/edk2-i386-secure-code.fd: submodules
+./edk2-build.sh \
@@ -115,7 +116,7 @@ submodules:
-D TPM_CONFIG_ENABLE \
-D SECURE_BOOT_ENABLE \
-D SMM_REQUIRE
-   cp edk2/Build/OvmfIa32/DEBUG_$(call toolchain,i386)/FV/OVMF_CODE.fd $@
+   cp edk2/Build/OvmfIa32/$(target)_$(call toolchain,i386)/FV/OVMF_CODE.fd 
$@
 
 ../pc-bios/edk2-x86_64-code.fd: submodules
+./edk2-build.sh \
@@ -127,7 +128,7 @@ submodules:
-D NETWORK_TLS_ENABLE \
-D TPM_ENABLE \
-D TPM_CONFIG_ENABLE
-   cp edk2/Build/OvmfX64/DEBUG_$(call toolchain,x86_64)/FV/OVMF_CODE.fd $@
+   cp edk2/Build/OvmfX64/$(target)_$(call 
toolchain,x86_64)/FV/OVMF_CODE.fd $@
 
 ../pc-bios/edk2-x86_64-secure-code.fd: submodules
+./edk2-build.sh \
@@ -142,15 +143,15 @@ submodules:
-D TPM_CONFIG_ENABLE \
-D SECURE_BOOT_ENABLE \
-D SMM_REQUIRE
-   cp edk2/Build/Ovmf3264/DEBUG_$(call toolchain,x86_64)/FV/OVMF_CODE.fd $@
+   cp edk2/Build/Ovmf3264/$(target)_$(call 
toolchain,x86_64)/FV/OVMF_CODE.fd $@
 
 ../pc-bios/edk2-arm-vars.fd: ../pc-bios/edk2-arm-code.fd
-   cp edk2/Build/ArmVirtQemu-ARM/DEBUG_$(call 
toolchain,arm)/FV/QEMU_VARS.fd \
+   cp edk2/Build/ArmVirtQemu-ARM/$(target)_$(call 
toolchain,arm)/FV/QEMU_VARS.fd \
$@
truncate --size=64M $@
 
 ../pc-bios/edk2-i386-vars.fd: ../pc-bios/edk2-i386-code.fd
-   cp edk2/Build/OvmfIa32/DEBUG_$(call toolchain,i386)/FV/OVMF_VARS.fd $@
+   cp edk2/Build/OvmfIa32/$(target)_$(call toolchain,i386)/FV/OVMF_VARS.fd 
$@
 
 # The license file accumulates several individual licenses from under edk2,
 # prefixing each individual license with a header (generated by "tail") that
diff --git a/roms/edk2-build.sh b/roms/edk2-build.sh
index d5391c763728..ea79dc27a269 100755
--- a/roms/edk2-build.sh
+++ b/roms/edk2-build.sh
@@ -50,6 +50,6 @@ qemu_edk2_set_cross_env "$emulation_target"
 build \
   --cmd-len=65536 \
   -n "$edk2_thread_count" \
-  --buildtarget=DEBUG \
+  --buildtarget=RELEASE \
   --tagname="$edk2_toolchain" \
   "${args[@]}"
-- 
2.35.1

[PATCH v2 00/11] edk2: update to stable202202

[Gerd Hoffmann]

While being at it switch to RELEASE builds,
which in turn needs acpi test data updates.

Add microvm build.  Update MAINTAINERS.
Some build/ci tweaks.

Also available here:
  https://gitlab.com/kraxel/qemu/-/commits/edk2

v2:
 - tweaked .git check
 - updated acpi table commit messages.
 - picked up review tags.

Gerd Hoffmann (11):
  tests/acpi: allow virt memory hotplug changes
  edk2: update submodule to stable202202
  edk2: switch to release builds
  edk2: .git can be a file
  edk2: add microvm build
  edk2: update binaries to stable202202
  tests/acpi: update expected data files
  tests/acpi: disallow virt memory hotplug changes
  edk2/docker: install python3
  edk2/docker: use ubuntu 18.04
  MAINTAINERS: take edk2

 .gitlab-ci.d/edk2/Dockerfile   |   4 ++--
 MAINTAINERS|   2 +-
 pc-bios/edk2-aarch64-code.fd.bz2   | Bin 1507722 -> 1161290 bytes
 pc-bios/edk2-arm-code.fd.bz2   | Bin 1503187 -> 1161845 bytes
 pc-bios/edk2-i386-code.fd.bz2  | Bin 1646741 -> 1282120 bytes
 pc-bios/edk2-i386-secure-code.fd.bz2   | Bin 1860546 -> 1473677 bytes
 pc-bios/edk2-x86_64-code.fd.bz2| Bin 1680164 -> 1327522 bytes
 pc-bios/edk2-x86_64-microvm.fd.bz2 | Bin 0 -> 1309407 bytes
 pc-bios/edk2-x86_64-secure-code.fd.bz2 | Bin 1912112 -> 1513711 bytes
 roms/Makefile.edk2 |  30 +
 roms/edk2  |   2 +-
 roms/edk2-build.sh |   2 +-
 tests/data/acpi/virt/SSDT.memhp| Bin 736 -> 736 bytes
 13 files changed, 26 insertions(+), 14 deletions(-)
 create mode 100644 pc-bios/edk2-x86_64-microvm.fd.bz2

-- 
2.35.1

[PATCH v2 01/11] tests/acpi: allow virt memory hotplug changes

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Alex Bennée 
---
 tests/qtest/bios-tables-test-allowed-diff.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/qtest/bios-tables-test-allowed-diff.h 
b/tests/qtest/bios-tables-test-allowed-diff.h
index dfb8523c8bf4..e569098abddc 100644
--- a/tests/qtest/bios-tables-test-allowed-diff.h
+++ b/tests/qtest/bios-tables-test-allowed-diff.h
@@ -1 +1,2 @@
 /* List of comma-separated changed AML files to ignore */
+"tests/data/acpi/virt/SSDT.memhp",
-- 
2.35.1

Re: [PATCH] target/riscv: write back unmodified value for csrrc/csrrs with rs1 is not x0 but holding zero

[Weiwei Li]

在 2022/3/11 上午10:58, Alistair Francis 写道:

On Wed, Mar 2, 2022 at 11:50 PM Weiwei Li  wrote:

  For csrrs and csrrc, if rs1 specifies a register other than x0, holding
  a zero value, the instruction will still attempt to write the unmodified
  value back to the csr and will cause side effects

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
  target/riscv/csr.c   | 46 
  target/riscv/op_helper.c |  7 +-
  2 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index aea82dff4a..f4774ca07b 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -2872,7 +2872,7 @@ static RISCVException write_upmbase(CPURISCVState *env, 
int csrno,

  static inline RISCVException riscv_csrrw_check(CPURISCVState *env,
 int csrno,
-   bool write_mask,
+   bool write_csr,
 RISCVCPU *cpu)
  {
  /* check privileges and return RISCV_EXCP_ILLEGAL_INST if check fails */
@@ -2895,7 +2895,7 @@ static inline RISCVException 
riscv_csrrw_check(CPURISCVState *env,
  return RISCV_EXCP_ILLEGAL_INST;
  }
  #endif
-if (write_mask && read_only) {
+if (write_csr && read_only) {
  return RISCV_EXCP_ILLEGAL_INST;
  }

@@ -2915,7 +2915,8 @@ static inline RISCVException 
riscv_csrrw_check(CPURISCVState *env,
  static RISCVException riscv_csrrw_do64(CPURISCVState *env, int csrno,
 target_ulong *ret_value,
 target_ulong new_value,
-   target_ulong write_mask)
+   target_ulong write_mask,
+   bool write_csr)
  {
  RISCVException ret;
  target_ulong old_value;
@@ -2935,8 +2936,8 @@ static RISCVException riscv_csrrw_do64(CPURISCVState 
*env, int csrno,
  return ret;
  }

-/* write value if writable and write mask set, otherwise drop writes */
-if (write_mask) {
+/* write value if needed, otherwise drop writes */
+if (write_csr) {
  new_value = (old_value & ~write_mask) | (new_value & write_mask);
  if (csr_ops[csrno].write) {
  ret = csr_ops[csrno].write(env, csrno, new_value);
@@ -2960,18 +2961,27 @@ RISCVException riscv_csrrw(CPURISCVState *env, int 
csrno,
  {
  RISCVCPU *cpu = env_archcpu(env);

-RISCVException ret = riscv_csrrw_check(env, csrno, write_mask, cpu);
+/*
+ * write value when write_mask is set or rs1 is not x0 but holding zero
+ * value for csrrc(new_value is zero) and csrrs(new_value is all-ones)

I don't understand this. Won't write_mask also be zero and when reading?

Alistair

Yeah. It's true. To distinguish only-read operation with the special 
write case(write_mask = 0), I also modified the new_value of riscv_csrrw 
from 0 to 1 in helper_csrr :


 target_ulong helper_csrr(CPURISCVState *env, int csr)
 {
 target_ulong val = 0;
-RISCVException ret = riscv_csrrw(env, csr, , 0, 0);
+
+/*
+ * new_value here should be none-zero or none-all-ones here to
+ * distinguish with csrrc/csrrs with rs1 is not x0 but holding zero value
+ */
+RISCVException ret = riscv_csrrw(env, csr, , 1, 0);

 if (ret != RISCV_EXCP_NONE) {
 riscv_raise_exception(env, ret, GETPC());


After modification, the cases for all csr related instructions is as follows:

index     instruction   helper write_mask  
new_value    Read/Write write_csr


1      csrrw                         csrrw/csrw all-ones         
        src1 (R)W true


2         csrrs(rs1=0) csrr  zero 
1   R  false


3      csrrs(rs1!=0)   csrrw   src1 
 all-ones RW   true


4      csrrs(rs1=0) csrr     zero 
1   R false


5      csrrc(rs1!=0)   csrrw   src1 
      zero     RW  true


6      csrrc(rs1=0) csrr      zero 
1   R    false


7      csrrwi                 csrrw/csrw 
all-ones    rs1 (R)W  true


8      csrrsi(rs1=0) csrr  zero 
1   R    false


9      csrrsi(rs1!=0)   csrrw    rs1 
 all-ones RW   true


10       csrrci(rs1=0) csrr  zero 
1   R    false


11       csrrci(rs1!=0)   csrrw   

Re: [PULL V2 00/15] Net patches

[Jason Wang]

On Fri, Mar 11, 2022 at 1:07 AM Peter Maydell 
wrote:

> On Thu, 10 Mar 2022 at 02:39, Jason Wang  wrote:
> >
> > The following changes since commit
> d9ccf33f9479201e5add8db0af68ca9ca8da358b:
> >
> >   Merge remote-tracking branch
> 'remotes/lvivier-gitlab/tags/linux-user-for-7.0-pull-request' into staging
> (2022-03-09 20:01:17 +)
> >
> > are available in the git repository at:
> >
> >   https://github.com/jasowang/qemu.git tags/net-pull-request
> >
> > for you to fetch changes up to eea40402ecf895ed345f8e8eb07dbb484f4542c5:
> >
> >   vdpa: Expose VHOST_F_LOG_ALL on SVQ (2022-03-10 10:26:32 +0800)
> >
> > 
> >
>
> Lots of 32-bit compile issues: this is 32-bit arm:
> https://gitlab.com/qemu-project/qemu/-/jobs/2188500721
> i386 the same:
> https://gitlab.com/qemu-project/qemu/-/jobs/2188500747
> and 32-bit mips:
> https://gitlab.com/qemu-project/qemu/-/jobs/2188500753


Eugenio, please fix those warnings and send a new version.

Thanks


>
>
> ../hw/virtio/vhost-shadow-virtqueue.c: In function
> 'vhost_svq_valid_features':
> ../hw/virtio/vhost-shadow-virtqueue.c:43:28: error: passing argument 2
> of 'set_bit' from incompatible pointer type
> [-Werror=incompatible-pointer-types]
> set_bit(b, _features);
> ^
> In file included from /builds/qemu-project/qemu/include/qemu/bitmap.h:16,
> from /builds/qemu-project/qemu/include/hw/qdev-core.h:5,
> from /builds/qemu-project/qemu/include/hw/virtio/virtio.h:18,
> from /builds/qemu-project/qemu/hw/virtio/vhost-shadow-virtqueue.h:14,
> from ../hw/virtio/vhost-shadow-virtqueue.c:11:
> /builds/qemu-project/qemu/include/qemu/bitops.h:36:52: note: expected
> 'long unsigned int *' but argument is of type 'uint64_t *' {aka 'long
> long unsigned int *'}
> static inline void set_bit(long nr, unsigned long *addr)
> ~~~^~~~
> ../hw/virtio/vhost-shadow-virtqueue.c:50:30: error: passing argument 2
> of 'clear_bit' from incompatible pointer type
> [-Werror=incompatible-pointer-types]
> clear_bit(b, _features);
> ^
> In file included from /builds/qemu-project/qemu/include/qemu/bitmap.h:16,
> from /builds/qemu-project/qemu/include/hw/qdev-core.h:5,
> from /builds/qemu-project/qemu/include/hw/virtio/virtio.h:18,
> from /builds/qemu-project/qemu/hw/virtio/vhost-shadow-virtqueue.h:14,
> from ../hw/virtio/vhost-shadow-virtqueue.c:11:
> /builds/qemu-project/qemu/include/qemu/bitops.h:62:54: note: expected
> 'long unsigned int *' but argument is of type 'uint64_t *' {aka 'long
> long unsigned int *'}
> static inline void clear_bit(long nr, unsigned long *addr)
> ~~~^~~~
> ../hw/virtio/vhost-shadow-virtqueue.c: In function
> 'vhost_svq_translate_addr':
> ../hw/virtio/vhost-shadow-virtqueue.c:91:32: error: cast from pointer
> to integer of different size [-Werror=pointer-to-int-cast]
> .translated_addr = (hwaddr)iovec[i].iov_base,
> ^
> ../hw/virtio/vhost-shadow-virtqueue.c:109:20: error: cast to pointer
> from integer of different size [-Werror=int-to-pointer-cast]
> addrs[i] = (void *)(map->iova + off);
> ^
> In file included from /builds/qemu-project/qemu/include/qemu/osdep.h:37,
> from ../hw/virtio/vhost-shadow-virtqueue.c:10:
> ../hw/virtio/vhost-shadow-virtqueue.c:111:49: error: incompatible type
> for argument 1 of 'int128_add'
> if (unlikely(int128_gt(int128_add(needle.translated_addr,
> ~~^~~~
> /builds/qemu-project/qemu/include/qemu/compiler.h:43:43: note: in
> definition of macro 'unlikely'
> #define unlikely(x) __builtin_expect(!!(x), 0)
> ^
> In file included from /builds/qemu-project/qemu/include/exec/memory.h:26,
> from /builds/qemu-project/qemu/include/hw/virtio/virtio.h:17,
> from /builds/qemu-project/qemu/hw/virtio/vhost-shadow-virtqueue.h:14,
> from ../hw/virtio/vhost-shadow-virtqueue.c:11:
> /builds/qemu-project/qemu/include/qemu/int128.h:313:40: note: expected
> 'Int128' {aka 'struct Int128'} but argument is of type 'hwaddr' {aka
> 'long long unsigned int'}
> static inline Int128 int128_add(Int128 a, Int128 b)
> ~~~^
> In file included from /builds/qemu-project/qemu/include/qemu/osdep.h:37,
> from ../hw/virtio/vhost-shadow-virtqueue.c:10:
> ../hw/virtio/vhost-shadow-virtqueue.c:112:51: error: incompatible type
> for argument 2 of 'int128_add'
> iovec[i].iov_len),
> ^~~~
> /builds/qemu-project/qemu/include/qemu/compiler.h:43:43: note: in
> definition of macro 'unlikely'
> #define unlikely(x) __builtin_expect(!!(x), 0)
> ^
> In file included from /builds/qemu-project/qemu/include/exec/memory.h:26,
> from /builds/qemu-project/qemu/include/hw/virtio/virtio.h:17,
> from /builds/qemu-project/qemu/hw/virtio/vhost-shadow-virtqueue.h:14,
> from ../hw/virtio/vhost-shadow-virtqueue.c:11:
> /builds/qemu-project/qemu/include/qemu/int128.h:313:50: note: expected
> 'Int128' {aka 'struct Int128'} but argument is of type 'size_t' {aka
> 'const unsigned int'}
> static inline Int128 int128_add(Int128 a, Int128 b)
> ~~~^
> In file 

Re: [PATCH v8 04/14] target/riscv: rvk: add support for zbkx extension

[Alistair Francis]

On Tue, Mar 1, 2022 at 10:06 PM Weiwei Li  wrote:
>
>  - add xperm4 and xperm8 instructions
>
> Signed-off-by: Weiwei Li 
> Signed-off-by: Junqiang Wang 
> Reviewed-by: Richard Henderson 

Acked-by: Alistair Francis 

Alistair

> ---
>  target/riscv/bitmanip_helper.c  | 27 +
>  target/riscv/helper.h   |  2 ++
>  target/riscv/insn32.decode  |  4 
>  target/riscv/insn_trans/trans_rvb.c.inc | 18 +
>  4 files changed, 51 insertions(+)
>
> diff --git a/target/riscv/bitmanip_helper.c b/target/riscv/bitmanip_helper.c
> index e003e8b25b..b99c4a39a1 100644
> --- a/target/riscv/bitmanip_helper.c
> +++ b/target/riscv/bitmanip_helper.c
> @@ -102,3 +102,30 @@ target_ulong HELPER(zip)(target_ulong rs1)
>  x = do_shuf_stage(x, shuf_masks[0], shuf_masks[0] >> 1, 1);
>  return x;
>  }
> +
> +static inline target_ulong do_xperm(target_ulong rs1, target_ulong rs2,
> +uint32_t sz_log2)
> +{
> +target_ulong r = 0;
> +target_ulong sz = 1LL << sz_log2;
> +target_ulong mask = (1LL << sz) - 1;
> +target_ulong pos;
> +
> +for (int i = 0; i < TARGET_LONG_BITS; i += sz) {
> +pos = ((rs2 >> i) & mask) << sz_log2;
> +if (pos < sizeof(target_ulong) * 8) {
> +r |= ((rs1 >> pos) & mask) << i;
> +}
> +}
> +return r;
> +}
> +
> +target_ulong HELPER(xperm4)(target_ulong rs1, target_ulong rs2)
> +{
> +return do_xperm(rs1, rs2, 2);
> +}
> +
> +target_ulong HELPER(xperm8)(target_ulong rs1, target_ulong rs2)
> +{
> +return do_xperm(rs1, rs2, 3);
> +}
> diff --git a/target/riscv/helper.h b/target/riscv/helper.h
> index 7331d32dbf..a1d28b257f 100644
> --- a/target/riscv/helper.h
> +++ b/target/riscv/helper.h
> @@ -69,6 +69,8 @@ DEF_HELPER_FLAGS_2(clmulr, TCG_CALL_NO_RWG_SE, tl, tl, tl)
>  DEF_HELPER_FLAGS_1(brev8, TCG_CALL_NO_RWG_SE, tl, tl)
>  DEF_HELPER_FLAGS_1(unzip, TCG_CALL_NO_RWG_SE, tl, tl)
>  DEF_HELPER_FLAGS_1(zip, TCG_CALL_NO_RWG_SE, tl, tl)
> +DEF_HELPER_FLAGS_2(xperm4, TCG_CALL_NO_RWG_SE, tl, tl, tl)
> +DEF_HELPER_FLAGS_2(xperm8, TCG_CALL_NO_RWG_SE, tl, tl, tl)
>
>  /* Floating Point - Half Precision */
>  DEF_HELPER_FLAGS_3(fadd_h, TCG_CALL_NO_RWG, i64, env, i64, i64)
> diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
> index 3a49acab37..75ffac9c81 100644
> --- a/target/riscv/insn32.decode
> +++ b/target/riscv/insn32.decode
> @@ -776,6 +776,10 @@ clmulh 101 .. 011 . 0110011 @r
>  # *** RV32 extra Zbc Standard Extension ***
>  clmulr 101 .. 010 . 0110011 @r
>
> +# *** RV32 Zbkx Standard Extension ***
> +xperm4 0010100 .. 010 . 0110011 @r
> +xperm8 0010100 .. 100 . 0110011 @r
> +
>  # *** RV32 Zbs Standard Extension ***
>  bclr   0100100 .. 001 . 0110011 @r
>  bclri  01001. ... 001 . 0010011 @sh
> diff --git a/target/riscv/insn_trans/trans_rvb.c.inc 
> b/target/riscv/insn_trans/trans_rvb.c.inc
> index 1980bfe971..54927ba763 100644
> --- a/target/riscv/insn_trans/trans_rvb.c.inc
> +++ b/target/riscv/insn_trans/trans_rvb.c.inc
> @@ -48,6 +48,12 @@
>  }\
>  } while (0)
>
> +#define REQUIRE_ZBKX(ctx) do {   \
> +if (!ctx->cfg_ptr->ext_zbkx) {   \
> +return false;\
> +}\
> +} while (0)
> +
>  static void gen_clz(TCGv ret, TCGv arg1)
>  {
>  tcg_gen_clzi_tl(ret, arg1, TARGET_LONG_BITS);
> @@ -574,3 +580,15 @@ static bool trans_zip(DisasContext *ctx, arg_zip *a)
>  REQUIRE_ZBKB(ctx);
>  return gen_unary(ctx, a, EXT_NONE, gen_helper_zip);
>  }
> +
> +static bool trans_xperm4(DisasContext *ctx, arg_xperm4 *a)
> +{
> +REQUIRE_ZBKX(ctx);
> +return gen_arith(ctx, a, EXT_NONE, gen_helper_xperm4, NULL);
> +}
> +
> +static bool trans_xperm8(DisasContext *ctx, arg_xperm8 *a)
> +{
> +REQUIRE_ZBKX(ctx);
> +return gen_arith(ctx, a, EXT_NONE, gen_helper_xperm8, NULL);
> +}
> --
> 2.17.1
>
>

Re: [PATCH v3 1/4] target/ppc: Fix masked PVR matching

[Alexey Kardashevskiy]

On 3/7/22 17:55, Nicholas Piggin wrote:

The pvr_match for a CPU class is not supposed to just match for any
CPU in the family, but rather whether this particular CPU class is the
best match in the family.

Prior to this fix, e.g., a POWER9 DD2.3 KVM host matches to the
power9_v1.0 class (because that's first in the list). After the patch,
it matches the power9_v2.0 class.



So if we get now another revision of p10, this just won't work at all 
instead of matching DD1. Not that we have a reasonable chance of this 
happening though...






Fixes: 03ae4133ab8 ("target-ppc: Add pvr_match() callback")
Signed-off-by: Nicholas Piggin 
---
  target/ppc/cpu_init.c | 51 ---
  1 file changed, 34 insertions(+), 17 deletions(-)

diff --git a/target/ppc/cpu_init.c b/target/ppc/cpu_init.c
index 073fd10168..83ca741bea 100644
--- a/target/ppc/cpu_init.c
+++ b/target/ppc/cpu_init.c
@@ -5910,13 +5910,14 @@ static void init_proc_POWER7(CPUPPCState *env)
  
  static bool ppc_pvr_match_power7(PowerPCCPUClass *pcc, uint32_t pvr)

  {
-if ((pvr & CPU_POWERPC_POWER_SERVER_MASK) == CPU_POWERPC_POWER7P_BASE) {
-return true;
-}
-if ((pvr & CPU_POWERPC_POWER_SERVER_MASK) == CPU_POWERPC_POWER7_BASE) {
-return true;
+uint32_t base = pvr & CPU_POWERPC_POWER_SERVER_MASK;
+uint32_t pcc_base = pcc->pvr & CPU_POWERPC_POWER_SERVER_MASK;
+
+if (base != pcc_base) {
+return false;
  }
-return false;
+
+return true;
  }
  
  static bool cpu_has_work_POWER7(CPUState *cs)

@@ -6070,16 +6071,14 @@ static void init_proc_POWER8(CPUPPCState *env)
  
  static bool ppc_pvr_match_power8(PowerPCCPUClass *pcc, uint32_t pvr)

  {
-if ((pvr & CPU_POWERPC_POWER_SERVER_MASK) == CPU_POWERPC_POWER8NVL_BASE) {
-return true;
-}
-if ((pvr & CPU_POWERPC_POWER_SERVER_MASK) == CPU_POWERPC_POWER8E_BASE) {
-return true;
-}
-if ((pvr & CPU_POWERPC_POWER_SERVER_MASK) == CPU_POWERPC_POWER8_BASE) {
-return true;
+uint32_t base = pvr & CPU_POWERPC_POWER_SERVER_MASK;
+uint32_t pcc_base = pcc->pvr & CPU_POWERPC_POWER_SERVER_MASK;


(after looking at failing 
"QTEST_QEMU_BINARY=~/pbuild/qemu-localhost-ppc64/qemu-system-ppc64 
~/pbuild/qemu-localhost-ppc64/tests/qtest/pnv-xscom-test")


So this breaks using different family masks for the same machine type,
like, 0x004[BCD] for pnv_machine_power8_class_init()'s 
POWERPC_CPU_TYPE_NAME("power8_v2.0").


So I'd keep P7/P8 where they are today and create a new machine type for 
every family mask (higher 16 bits of PVR). Thanks,





+
+if (base != pcc_base) {
+return false;
  }
-return false;
+
+return true;
  }
  
  static bool cpu_has_work_POWER8(CPUState *cs)

@@ -6277,9 +6276,18 @@ static void init_proc_POWER9(CPUPPCState *env)
  
  static bool ppc_pvr_match_power9(PowerPCCPUClass *pcc, uint32_t pvr)

  {
-if ((pvr & CPU_POWERPC_POWER_SERVER_MASK) == CPU_POWERPC_POWER9_BASE) {
+uint32_t base = pvr & CPU_POWERPC_POWER_SERVER_MASK;
+uint32_t pcc_base = pcc->pvr & CPU_POWERPC_POWER_SERVER_MASK;
+
+if (base != pcc_base) {
+return false;
+}
+
+if ((pvr & 0x0f00) == (pcc->pvr & 0x0f00)) {
+/* Major DD version matches to power9_v1.0 and power9_v2.0 */
  return true;
  }
+
  return false;
  }
  
@@ -6489,9 +6497,18 @@ static void init_proc_POWER10(CPUPPCState *env)
  
  static bool ppc_pvr_match_power10(PowerPCCPUClass *pcc, uint32_t pvr)

  {
-if ((pvr & CPU_POWERPC_POWER_SERVER_MASK) == CPU_POWERPC_POWER10_BASE) {
+uint32_t base = pvr & CPU_POWERPC_POWER_SERVER_MASK;
+uint32_t pcc_base = pcc->pvr & CPU_POWERPC_POWER_SERVER_MASK;
+
+if (base != pcc_base) {
+return false;
+}
+
+if ((pvr & 0x0f00) == (pcc->pvr & 0x0f00)) {
+/* Major DD version matches to power10_v1.0 and power10_v2.0 */
  return true;
  }
+
  return false;
  }
  

Re: [PATCH] target/riscv: write back unmodified value for csrrc/csrrs with rs1 is not x0 but holding zero

[Alistair Francis]

On Wed, Mar 2, 2022 at 11:50 PM Weiwei Li  wrote:
>
>  For csrrs and csrrc, if rs1 specifies a register other than x0, holding
>  a zero value, the instruction will still attempt to write the unmodified
>  value back to the csr and will cause side effects
>
> Signed-off-by: Weiwei Li 
> Signed-off-by: Junqiang Wang 
> ---
>  target/riscv/csr.c   | 46 
>  target/riscv/op_helper.c |  7 +-
>  2 files changed, 39 insertions(+), 14 deletions(-)
>
> diff --git a/target/riscv/csr.c b/target/riscv/csr.c
> index aea82dff4a..f4774ca07b 100644
> --- a/target/riscv/csr.c
> +++ b/target/riscv/csr.c
> @@ -2872,7 +2872,7 @@ static RISCVException write_upmbase(CPURISCVState *env, 
> int csrno,
>
>  static inline RISCVException riscv_csrrw_check(CPURISCVState *env,
> int csrno,
> -   bool write_mask,
> +   bool write_csr,
> RISCVCPU *cpu)
>  {
>  /* check privileges and return RISCV_EXCP_ILLEGAL_INST if check fails */
> @@ -2895,7 +2895,7 @@ static inline RISCVException 
> riscv_csrrw_check(CPURISCVState *env,
>  return RISCV_EXCP_ILLEGAL_INST;
>  }
>  #endif
> -if (write_mask && read_only) {
> +if (write_csr && read_only) {
>  return RISCV_EXCP_ILLEGAL_INST;
>  }
>
> @@ -2915,7 +2915,8 @@ static inline RISCVException 
> riscv_csrrw_check(CPURISCVState *env,
>  static RISCVException riscv_csrrw_do64(CPURISCVState *env, int csrno,
> target_ulong *ret_value,
> target_ulong new_value,
> -   target_ulong write_mask)
> +   target_ulong write_mask,
> +   bool write_csr)
>  {
>  RISCVException ret;
>  target_ulong old_value;
> @@ -2935,8 +2936,8 @@ static RISCVException riscv_csrrw_do64(CPURISCVState 
> *env, int csrno,
>  return ret;
>  }
>
> -/* write value if writable and write mask set, otherwise drop writes */
> -if (write_mask) {
> +/* write value if needed, otherwise drop writes */
> +if (write_csr) {
>  new_value = (old_value & ~write_mask) | (new_value & write_mask);
>  if (csr_ops[csrno].write) {
>  ret = csr_ops[csrno].write(env, csrno, new_value);
> @@ -2960,18 +2961,27 @@ RISCVException riscv_csrrw(CPURISCVState *env, int 
> csrno,
>  {
>  RISCVCPU *cpu = env_archcpu(env);
>
> -RISCVException ret = riscv_csrrw_check(env, csrno, write_mask, cpu);
> +/*
> + * write value when write_mask is set or rs1 is not x0 but holding zero
> + * value for csrrc(new_value is zero) and csrrs(new_value is all-ones)

I don't understand this. Won't write_mask also be zero and when reading?

Alistair

> + */
> +bool write_csr = write_mask || ((write_mask == 0) &&
> +((new_value == 0) ||
> + (new_value == (target_ulong)-1)));
> +
> +RISCVException ret = riscv_csrrw_check(env, csrno, write_csr, cpu);
>  if (ret != RISCV_EXCP_NONE) {
>  return ret;
>  }
>
> -return riscv_csrrw_do64(env, csrno, ret_value, new_value, write_mask);
> +return riscv_csrrw_do64(env, csrno, ret_value, new_value, write_mask,
> +write_csr);
>  }
>
>  static RISCVException riscv_csrrw_do128(CPURISCVState *env, int csrno,
>  Int128 *ret_value,
>  Int128 new_value,
> -Int128 write_mask)
> +Int128 write_mask, bool write_csr)
>  {
>  RISCVException ret;
>  Int128 old_value;
> @@ -2982,8 +2992,8 @@ static RISCVException riscv_csrrw_do128(CPURISCVState 
> *env, int csrno,
>  return ret;
>  }
>
> -/* write value if writable and write mask set, otherwise drop writes */
> -if (int128_nz(write_mask)) {
> +/* write value if needed, otherwise drop writes */
> +if (write_csr) {
>  new_value = int128_or(int128_and(old_value, int128_not(write_mask)),
>int128_and(new_value, write_mask));
>  if (csr_ops[csrno].write128) {
> @@ -3015,13 +3025,22 @@ RISCVException riscv_csrrw_i128(CPURISCVState *env, 
> int csrno,
>  RISCVException ret;
>  RISCVCPU *cpu = env_archcpu(env);
>
> -ret = riscv_csrrw_check(env, csrno, int128_nz(write_mask), cpu);
> +/*
> + * write value when write_mask is set or rs1 is not x0 but holding zero
> + * value for csrrc(new_value is zero) and csrrs(new_value is all-ones)
> + */
> +bool write_csr = write_mask || ((write_mask == 0) &&
> +((new_value == 0) ||
> +

Re: [PATCH v8 07/14] target/riscv: rvk: add support for zkne/zknd extension in RV64

[Alistair Francis]

On Tue, Mar 1, 2022 at 10:03 PM Weiwei Li  wrote:
>
>  - add aes64dsm, aes64ds, aes64im, aes64es, aes64esm, aes64ks2, aes64ks1i 
> instructions
>
> Co-authored-by: Ruibo Lu 
> Co-authored-by: Zewen Ye 
> Signed-off-by: Weiwei Li 
> Signed-off-by: Junqiang Wang 
> Reviewed-by: Richard Henderson 

Acked-by: Alistair Francis 

Alistair

> ---
>  target/riscv/crypto_helper.c| 169 
>  target/riscv/helper.h   |   8 ++
>  target/riscv/insn32.decode  |  12 ++
>  target/riscv/insn_trans/trans_rvk.c.inc |  47 +++
>  4 files changed, 236 insertions(+)
>
> diff --git a/target/riscv/crypto_helper.c b/target/riscv/crypto_helper.c
> index 220d51c742..cb4783a1e9 100644
> --- a/target/riscv/crypto_helper.c
> +++ b/target/riscv/crypto_helper.c
> @@ -102,4 +102,173 @@ target_ulong HELPER(aes32dsi)(target_ulong rs1, 
> target_ulong rs2,
>  {
>  return aes32_operation(shamt, rs1, rs2, false, false);
>  }
> +
> +#define BY(X, I) ((X >> (8 * I)) & 0xFF)
> +
> +#define AES_SHIFROWS_LO(RS1, RS2) ( \
> +(((RS1 >> 24) & 0xFF) << 56) | (((RS2 >> 48) & 0xFF) << 48) | \
> +(((RS2 >> 8) & 0xFF) << 40) | (((RS1 >> 32) & 0xFF) << 32) | \
> +(((RS2 >> 56) & 0xFF) << 24) | (((RS2 >> 16) & 0xFF) << 16) | \
> +(((RS1 >> 40) & 0xFF) << 8) | (((RS1 >> 0) & 0xFF) << 0))
> +
> +#define AES_INVSHIFROWS_LO(RS1, RS2) ( \
> +(((RS2 >> 24) & 0xFF) << 56) | (((RS2 >> 48) & 0xFF) << 48) | \
> +(((RS1 >> 8) & 0xFF) << 40) | (((RS1 >> 32) & 0xFF) << 32) | \
> +(((RS1 >> 56) & 0xFF) << 24) | (((RS2 >> 16) & 0xFF) << 16) | \
> +(((RS2 >> 40) & 0xFF) << 8) | (((RS1 >> 0) & 0xFF) << 0))
> +
> +#define AES_MIXBYTE(COL, B0, B1, B2, B3) ( \
> +BY(COL, B3) ^ BY(COL, B2) ^ AES_GFMUL(BY(COL, B1), 3) ^ \
> +AES_GFMUL(BY(COL, B0), 2))
> +
> +#define AES_MIXCOLUMN(COL) ( \
> +AES_MIXBYTE(COL, 3, 0, 1, 2) << 24 | \
> +AES_MIXBYTE(COL, 2, 3, 0, 1) << 16 | \
> +AES_MIXBYTE(COL, 1, 2, 3, 0) << 8 | AES_MIXBYTE(COL, 0, 1, 2, 3) << 0)
> +
> +#define AES_INVMIXBYTE(COL, B0, B1, B2, B3) ( \
> +AES_GFMUL(BY(COL, B3), 0x9) ^ AES_GFMUL(BY(COL, B2), 0xd) ^ \
> +AES_GFMUL(BY(COL, B1), 0xb) ^ AES_GFMUL(BY(COL, B0), 0xe))
> +
> +#define AES_INVMIXCOLUMN(COL) ( \
> +AES_INVMIXBYTE(COL, 3, 0, 1, 2) << 24 | \
> +AES_INVMIXBYTE(COL, 2, 3, 0, 1) << 16 | \
> +AES_INVMIXBYTE(COL, 1, 2, 3, 0) << 8 | \
> +AES_INVMIXBYTE(COL, 0, 1, 2, 3) << 0)
> +
> +static inline target_ulong aes64_operation(target_ulong rs1, target_ulong 
> rs2,
> +   bool enc, bool mix)
> +{
> +uint64_t RS1 = rs1;
> +uint64_t RS2 = rs2;
> +uint64_t result;
> +uint64_t temp;
> +uint32_t col_0;
> +uint32_t col_1;
> +
> +if (enc) {
> +temp = AES_SHIFROWS_LO(RS1, RS2);
> +temp = (((uint64_t)AES_sbox[(temp >> 0) & 0xFF] << 0) |
> +((uint64_t)AES_sbox[(temp >> 8) & 0xFF] << 8) |
> +((uint64_t)AES_sbox[(temp >> 16) & 0xFF] << 16) |
> +((uint64_t)AES_sbox[(temp >> 24) & 0xFF] << 24) |
> +((uint64_t)AES_sbox[(temp >> 32) & 0xFF] << 32) |
> +((uint64_t)AES_sbox[(temp >> 40) & 0xFF] << 40) |
> +((uint64_t)AES_sbox[(temp >> 48) & 0xFF] << 48) |
> +((uint64_t)AES_sbox[(temp >> 56) & 0xFF] << 56));
> +if (mix) {
> +col_0 = temp & 0x;
> +col_1 = temp >> 32;
> +
> +col_0 = AES_MIXCOLUMN(col_0);
> +col_1 = AES_MIXCOLUMN(col_1);
> +
> +result = ((uint64_t)col_1 << 32) | col_0;
> +} else {
> +result = temp;
> +}
> +} else {
> +temp = AES_INVSHIFROWS_LO(RS1, RS2);
> +temp = (((uint64_t)AES_isbox[(temp >> 0) & 0xFF] << 0) |
> +((uint64_t)AES_isbox[(temp >> 8) & 0xFF] << 8) |
> +((uint64_t)AES_isbox[(temp >> 16) & 0xFF] << 16) |
> +((uint64_t)AES_isbox[(temp >> 24) & 0xFF] << 24) |
> +((uint64_t)AES_isbox[(temp >> 32) & 0xFF] << 32) |
> +((uint64_t)AES_isbox[(temp >> 40) & 0xFF] << 40) |
> +((uint64_t)AES_isbox[(temp >> 48) & 0xFF] << 48) |
> +((uint64_t)AES_isbox[(temp >> 56) & 0xFF] << 56));
> +if (mix) {
> +col_0 = temp & 0x;
> +col_1 = temp >> 32;
> +
> +col_0 = AES_INVMIXCOLUMN(col_0);
> +col_1 = AES_INVMIXCOLUMN(col_1);
> +
> +result = ((uint64_t)col_1 << 32) | col_0;
> +} else {
> +result = temp;
> +}
> +}
> +
> +return result;
> +}
> +
> +target_ulong HELPER(aes64esm)(target_ulong rs1, target_ulong rs2)
> +{
> +return aes64_operation(rs1, rs2, true, true);
> +}
> +
> +target_ulong HELPER(aes64es)(target_ulong rs1, target_ulong rs2)
> +{
> +return aes64_operation(rs1, rs2, true, false);
> +}
> +
> +target_ulong HELPER(aes64ds)(target_ulong rs1, 

Re: [PATCH v8 06/14] target/riscv: rvk: add support for zknd/zkne extension in RV32

[Alistair Francis]

On Tue, Mar 1, 2022 at 10:08 PM Weiwei Li  wrote:
>
>  - add aes32esmi, aes32esi, aes32dsmi and aes32dsi instructions
>
> Co-authored-by: Zewen Ye 
> Signed-off-by: Weiwei Li 
> Signed-off-by: Junqiang Wang 
> Reviewed-by: Richard Henderson 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/riscv/crypto_helper.c| 105 
>  target/riscv/helper.h   |   6 ++
>  target/riscv/insn32.decode  |  11 +++
>  target/riscv/insn_trans/trans_rvk.c.inc |  67 +++
>  target/riscv/meson.build|   3 +-
>  target/riscv/translate.c|   1 +
>  6 files changed, 192 insertions(+), 1 deletion(-)
>  create mode 100644 target/riscv/crypto_helper.c
>  create mode 100644 target/riscv/insn_trans/trans_rvk.c.inc
>
> diff --git a/target/riscv/crypto_helper.c b/target/riscv/crypto_helper.c
> new file mode 100644
> index 00..220d51c742
> --- /dev/null
> +++ b/target/riscv/crypto_helper.c
> @@ -0,0 +1,105 @@
> +/*
> + * RISC-V Crypto Emulation Helpers for QEMU.
> + *
> + * Copyright (c) 2021 Ruibo Lu, luruibo2...@163.com
> + * Copyright (c) 2021 Zewen Ye, lust...@foxmail.com
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2 or later, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include "qemu/osdep.h"
> +#include "cpu.h"
> +#include "exec/exec-all.h"
> +#include "exec/helper-proto.h"
> +#include "crypto/aes.h"
> +#include "crypto/sm4.h"
> +
> +#define AES_XTIME(a) \
> +((a << 1) ^ ((a & 0x80) ? 0x1b : 0))
> +
> +#define AES_GFMUL(a, b) (( \
> +(((b) & 0x1) ? (a) : 0) ^ \
> +(((b) & 0x2) ? AES_XTIME(a) : 0) ^ \
> +(((b) & 0x4) ? AES_XTIME(AES_XTIME(a)) : 0) ^ \
> +(((b) & 0x8) ? AES_XTIME(AES_XTIME(AES_XTIME(a))) : 0)) & 0xFF)
> +
> +static inline uint32_t aes_mixcolumn_byte(uint8_t x, bool fwd)
> +{
> +uint32_t u;
> +
> +if (fwd) {
> +u = (AES_GFMUL(x, 3) << 24) | (x << 16) | (x << 8) |
> +(AES_GFMUL(x, 2) << 0);
> +} else {
> +u = (AES_GFMUL(x, 0xb) << 24) | (AES_GFMUL(x, 0xd) << 16) |
> +(AES_GFMUL(x, 0x9) << 8) | (AES_GFMUL(x, 0xe) << 0);
> +}
> +return u;
> +}
> +
> +#define sext32_xlen(x) (target_ulong)(int32_t)(x)
> +
> +static inline target_ulong aes32_operation(target_ulong shamt,
> +   target_ulong rs1, target_ulong 
> rs2,
> +   bool enc, bool mix)
> +{
> +uint8_t si = rs2 >> shamt;
> +uint8_t so;
> +uint32_t mixed;
> +target_ulong res;
> +
> +if (enc) {
> +so = AES_sbox[si];
> +if (mix) {
> +mixed = aes_mixcolumn_byte(so, true);
> +} else {
> +mixed = so;
> +}
> +} else {
> +so = AES_isbox[si];
> +if (mix) {
> +mixed = aes_mixcolumn_byte(so, false);
> +} else {
> +mixed = so;
> +}
> +}
> +mixed = rol32(mixed, shamt);
> +res = rs1 ^ mixed;
> +
> +return sext32_xlen(res);
> +}
> +
> +target_ulong HELPER(aes32esmi)(target_ulong rs1, target_ulong rs2,
> +   target_ulong shamt)
> +{
> +return aes32_operation(shamt, rs1, rs2, true, true);
> +}
> +
> +target_ulong HELPER(aes32esi)(target_ulong rs1, target_ulong rs2,
> +  target_ulong shamt)
> +{
> +return aes32_operation(shamt, rs1, rs2, true, false);
> +}
> +
> +target_ulong HELPER(aes32dsmi)(target_ulong rs1, target_ulong rs2,
> +   target_ulong shamt)
> +{
> +return aes32_operation(shamt, rs1, rs2, false, true);
> +}
> +
> +target_ulong HELPER(aes32dsi)(target_ulong rs1, target_ulong rs2,
> +  target_ulong shamt)
> +{
> +return aes32_operation(shamt, rs1, rs2, false, false);
> +}
> +#undef sext32_xlen
> diff --git a/target/riscv/helper.h b/target/riscv/helper.h
> index a1d28b257f..d31bfadb3e 100644
> --- a/target/riscv/helper.h
> +++ b/target/riscv/helper.h
> @@ -1115,3 +1115,9 @@ DEF_HELPER_5(divu_i128, tl, env, tl, tl, tl, tl)
>  DEF_HELPER_5(divs_i128, tl, env, tl, tl, tl, tl)
>  DEF_HELPER_5(remu_i128, tl, env, tl, tl, tl, tl)
>  DEF_HELPER_5(rems_i128, tl, env, tl, tl, tl, tl)
> +
> +/* Crypto functions */
> +DEF_HELPER_FLAGS_3(aes32esmi, TCG_CALL_NO_RWG_SE, tl, tl, tl, tl)
> +DEF_HELPER_FLAGS_3(aes32esi, TCG_CALL_NO_RWG_SE, tl, tl, tl, tl)
> +DEF_HELPER_FLAGS_3(aes32dsmi, 

Re: QEMU device refcounting when device creates a container MR

[Peter Xu]

On Thu, Mar 10, 2022 at 01:45:31PM +, Peter Maydell wrote:
> The other theory I had was "maybe if you put an MR into another
> MR and they both have the same owner then don't bump the refcount"
> but I haven't thought that through at all.

Maybe it'll work, it just sounds a bit more tricky.

> 
> > That means, perhaps in object_init_with_type() we should make sure the
> > object refcount==1 after the ->instance_init() call?
> 
> That's probably a useful invariant, which I bet we don't
> currently get right for every object :-)

Yeah same feeling.. :)

We could have looped over each device and try creating them and fix one by
one?  But I think that doesn't cover all the cases, because instance_init()
could have some sub-regions conditionally added depending on the device
parameters and so on, so they may not be covered by the default values
being tested with.

-- 
Peter Xu

Re: [PATCH v5 0/5] user creatable pnv-phb4 devices

[Daniel Henrique Barboza]

On 3/10/22 15:49, Thomas Huth wrote:

On 11/01/2022 14.10, Daniel Henrique Barboza wrote:

Hi,

This version implements Cedric's review suggestions from v4. No
drastic design changes were made.

Changes from v4:
- patches 1,3,5: unchanged
- patch 2:
   * renamed function to pnv_phb4_xscom_realize()
   * pnv4_phb4_xscom_realize() is now called at the end of phb4_realize()
- patch 4:
   * changed pnv_phb4_get_stack signature to use chip and phb
   * added a new helper called pnv_pec_stk_default_phb_realize() to
realize the default phb when running with defaults
- v4 link: https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg02148.html

Daniel Henrique Barboza (5):
   ppc/pnv: set phb4 properties in stk_realize()
   ppc/pnv: move PHB4 XSCOM init to phb4_realize()
   ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStack
   ppc/pnv: Introduce user creatable pnv-phb4 devices
   ppc/pnv: turn pnv_phb4_update_regions() into static


It's now possible to crash QEMU with the pnv-phb4 device:

$ ./qemu-system-ppc64 -nographic -M powernv9 -device pnv-phb4
Unexpected error in object_property_try_add() at 
../../devel/qemu/qom/object.c:1229:
qemu-system-ppc64: -device pnv-phb4: attempt to add duplicate property 
'pnv-phb4[0]' to object (type 'power9_v2.0-pnv-chip')
Aborted (core dumped)

Any ideas how to fix this?


Thanks for catching this up.

The issue here is that we're not handling the case where an user adds a 
pnv-phb4 device
when running default settings (no -nodefaults). With default settings we are 
adding all
pnv-phb4 devices that are available to the machine, having no room for any 
additional
user creatable pnv-phb4 devices.

A similar situation happens with the powernv8 machine which errors out with a 
different
error message:

$ ./qemu-system-ppc64 -nographic -M powernv8 -device pnv-phb3
qemu-system-ppc64: -device pnv-phb3: Can't add chassis slot, error -16


Adding all possible phbs by default is a behavior these machines had since they 
were introduced,
and I don't think we want to change it. Thus, a fix would be to forbid user 
created pnv-phb devices
when running with defaults.


I'll see what I can do. Thanks,



Daniel




  Thomas

Re: [RFC PATCH v6 00/29] Add LoongArch softmmu support

[yangxiaojuan]

Ping !!!

On 2022/2/25 下午4:02, Xiaojuan Yang wrote:

This series patch add softmmu support for LoongArch.
The latest kernel:
   * https://github.com/loongson/linux/tree/loongarch-next
The latest uefi:
   * https://github.com/loongson/edk2
   * https://github.com/loongson/edk2-platforms
The manual:
   * https://github.com/loongson/LoongArch-Documentation/releases/tag/2021.10.11

You can get LoongArch qemu series like this:
git clone https://github.com/loongson/qemu.git
git checkout tcg-dev


Changes for v6:

1. Add the new loongarch_cpu_init function.
2. Improved extioi memory region.
3. Replaced the original LS7A bridge with a new GPEX bridge.


Changes for v5:

1. Fix host bridge map irq function.
2. Move cpu timer init function into machine init.
3. Adjust memory region layout.
4. Add the documentation at docs/system/loongarch/loongson3.rst.
- Introduction to 3a5000 virt.
- Output of "info mtree".


Changes for v4:
1. Uefi code is open and add some fdt interface to pass info between qemu and 
uefi.
2. Use a per cpu address space for iocsr.
3. Modify the tlb emulation.
4. Machine and board code mainly follow Mark's advice.
5. Adjust pci host space map.
6. Use more memregion to simplify the interrupt controller's emulate.


Changes for v3:
1.Target code mainly follow Richard's code review comments.
2.Put the csr and iocsr read/write instruction emulate into 2 different patch.
3.Simply the tlb emulation.
4.Delete some unused csr registers defintion.
5.Machine and board code mainly follow Mark's advice, discard the obsolete 
interface.
6.NUMA function is removed for it is not completed.
7.Adjust some format problem and the Naming problem


Changes for v3:
1.Target code mainly follow Richard's code review comments.
2.Put the csr and iocsr read/write instruction emulate into 2 different patch.
3.Simply the tlb emulation.
4.Delete some unused csr registers defintion.
5.Machine and board code mainly follow Mark's advice, discard the obsolete 
interface.
6.NUMA function is removed for it is not completed.
7.Adjust some format problem and the Naming problem


Changes for v2:
1.Combine patch 2 and 3 into one.
2.Adjust the order of the patch.
3.Put all the binaries on the github.
4.Modify some emulate errors when use the kernel from the github.
5.Adjust some format problem and the Naming problem
6.Others mainly follow Richard's code review comments.

Please help review!

Thanks


Xiaojuan Yang (29):
   target/loongarch: Add system emulation introduction
   target/loongarch: Add CSRs definition
   target/loongarch: Add basic vmstate description of CPU.
   target/loongarch: Implement qmp_query_cpu_definitions()
   target/loongarch: Add constant timer support
   target/loongarch: Add MMU support for LoongArch CPU.
   target/loongarch: Add LoongArch CSR instruction
   target/loongarch: Add LoongArch IOCSR instruction
   target/loongarch: Add TLB instruction support
   target/loongarch: Add other core instructions support
   target/loongarch: Add LoongArch interrupt and exception handle
   target/loongarch: Add timer related instructions support.
   target/loongarch: Add gdb support.
   hw/loongarch: Add support loongson3 virt machine type.
   hw/loongarch: Add LoongArch cpu interrupt support(CPUINTC)
   hw/loongarch: Add LoongArch ipi interrupt support(IPI)
   hw/intc: Add LoongArch ls7a interrupt controller support(PCH-PIC)
   hw/intc: Add LoongArch ls7a msi interrupt controller support(PCH-MSI)
   hw/intc: Add LoongArch extioi interrupt controller(EIOINTC)
   hw/loongarch: Add irq hierarchy for the system
   Enable common virtio pci support for LoongArch
   hw/loongarch: Add some devices support for 3A5000.
   hw/loongarch: Add LoongArch ls7a rtc device support
   hw/loongarch: Add default bios startup support.
   hw/loongarch: Add -kernel and -initrd options support
   hw/loongarch: Add LoongArch smbios support
   hw/loongarch: Add LoongArch acpi support
   hw/loongarch: Add fdt support.
   tests/tcg/loongarch64: Add hello/memory test in loongarch64 system

  MAINTAINERS   |  20 +
  .../devices/loongarch64-softmmu/default.mak   |   3 +
  configs/targets/loongarch64-softmmu.mak   |   4 +
  docs/system/loongarch/loongson3.rst   |  37 +
  gdb-xml/loongarch-base64.xml  |  43 +
  gdb-xml/loongarch-fpu64.xml   |  57 ++
  hw/Kconfig|   1 +
  hw/acpi/Kconfig   |   4 +
  hw/acpi/ls7a.c| 374 +
  hw/acpi/meson.build   |   1 +
  hw/intc/Kconfig   |  15 +
  hw/intc/loongarch_extioi.c| 417 ++
  hw/intc/loongarch_ipi.c   | 164 
  hw/intc/loongarch_pch_msi.c   |  75 ++
  hw/intc/loongarch_pch_pic.c   | 488 +++
  hw/intc/meson.build   |   4 +
  hw/intc/trace-events   

Re: [PATCH v2 00/18] tests: introduce testing coverage for TLS with migration

[Peter Xu]

On Thu, Mar 10, 2022 at 05:18:03PM +, Daniel P. Berrangé wrote:
> This significantly expands the migration test suite to cover testing
> with TLS over TCP and UNIX sockets, with both PSK (pre shared keys)
> and x509 credentials, and for both single and multifd scenarios.
> 
> It identified one bug in handling PSK credentials with UNIX sockets,
> but other than that everything was operating as expected.
> 
> To minimize the impact on code duplication alopt of refactoring is
> done of the migration tests to introduce a common helper for running
> the migration process. The various tests mostly just have to provide
> a callback to set a few parameters/capabilities before migration
> starts, and sometimes a callback to cleanup or validate after
> completion/failure.
> 
> There is one functional bugfix in patch 6, I would like to see
> in 7.0. The rest is all test suite additions, and I don't mind
> if they are in 7.0 or 7.1

At least patch 1-4, 6-10 look already good candidates for 7.0, imho, if not
all..

Thanks for doing this, Daniel.

-- 
Peter Xu

Re: [PATCH v2 10/18] tests: switch migration FD passing test to use common precopy helper

[Peter Xu]

On Thu, Mar 10, 2022 at 05:18:13PM +, Daniel P. Berrangé wrote:
> The combination of the start and finish hooks allow the FD passing
> code to use the precopy helper
> 
> Signed-off-by: Daniel P. Berrangé 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v2 08/18] tests: merge code for UNIX and TCP migration pre-copy tests

[Peter Xu]

On Thu, Mar 10, 2022 at 05:18:11PM +, Daniel P. Berrangé wrote:
> The test cases differ only in the URI they provide to the migration
> commands, and the ability to set the dirty_ring mode. This code is
> trivially merged into a common helper.
> 
> Signed-off-by: Daniel P. Berrangé 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v2 11/18] tests: expand the migration precopy helper to support failures

[Peter Xu]

On Thu, Mar 10, 2022 at 05:18:14PM +, Daniel P. Berrangé wrote:
> The migration precopy testing helper function always expects the
> migration to run to a completion state. There will be test scenarios
> for TLS where expect either the client or server to fail the migration.
> This expands the helper to cope with these scenarios.
> 
> Signed-off-by: Daniel P. Berrangé 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v2 14/18] tests: convert XBZRLE migration test to use common helper

[Peter Xu]

On Thu, Mar 10, 2022 at 05:18:17PM +, Daniel P. Berrangé wrote:
> Most of the XBZRLE migration test logic is common with the rest of the
> precopy tests, so it can use the helper with just one small tweak.
> 
> Signed-off-by: Daniel P. Berrangé 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v2 15/18] tests: convert multifd migration tests to use common helper

[Peter Xu]

On Thu, Mar 10, 2022 at 05:18:18PM +, Daniel P. Berrangé wrote:
> Most of the multifd migration test logic is common with the rest of the
> precopy tests, so it can use the helper without difficulty. The only
> exception of the multifd cancellation test which tries to run multiple
> migrations in a row.
> 
> Signed-off-by: Daniel P. Berrangé 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v2 09/18] tests: introduce ability to provide hooks for migration precopy test

[Peter Xu]

On Thu, Mar 10, 2022 at 05:18:12PM +, Daniel P. Berrangé wrote:
> There are alot of different scenarios to test with migration due to the
> wide number of parameters and capabilities available. To enable sharing
> of the basic precopy test scenario, we need to be able to set arbitrary
> parameters and capabilities before the migration is initiated, but don't
> want to have all this logic in the common helper function. Solve this
> by defining two hooks that can be provided by the test case, one before
> migration starts and one after migration finishes.
> 
> Signed-off-by: Daniel P. Berrangé 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v2 04/18] tests: print newline after QMP response in qtest logs

[Peter Xu]

On Thu, Mar 10, 2022 at 05:18:07PM +, Daniel P. Berrangé wrote:
> The QMP commands have a trailing newline, but the response does not.
> This makes the qtest logs hard to follow as the next QMP command
> appears in the same line as the previous QMP response.
> 
> Reviewed-by: Thomas Huth 
> Signed-off-by: Daniel P. Berrangé 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH v2 07/18] tests: switch MigrateStart struct to be stack allocated

[Peter Xu]

On Thu, Mar 10, 2022 at 05:18:10PM +, Daniel P. Berrangé wrote:
> There's no compelling reason why the MigrateStart struct needs to be
> heap allocated. Using stack allocation and static initializers is
> simpler.
> 
> Signed-off-by: Daniel P. Berrangé 

Reviewed-by: Peter Xu 

-- 
Peter Xu

Re: [PATCH] target/ppc: fix xxspltw for big endian hosts

[Richard Henderson]

On 3/10/22 09:20, matheus.fe...@eldorado.org.br wrote:

From: Matheus Ferst

Fix a typo in the host endianness macro and add a simple test to detect
regressions.

Fixes: 9bb0048ec6f8 ("target/ppc: convert xxspltw to vector operations")
Signed-off-by: Matheus Ferst
---
  target/ppc/translate/vsx-impl.c.inc |  2 +-
  tests/tcg/ppc64/Makefile.target |  1 +
  tests/tcg/ppc64le/Makefile.target   |  1 +
  tests/tcg/ppc64le/xxspltw.c | 46 +
  4 files changed, 49 insertions(+), 1 deletion(-)
  create mode 100644 tests/tcg/ppc64le/xxspltw.c


Reviewed-by: Richard Henderson 


r~

Re: [PATCH v4] target/riscv: Add isa extenstion strings to the device tree

[Frank Chang]

On Fri, Mar 11, 2022 at 2:42 AM Atish Kumar Patra 
wrote:

> On Wed, Mar 9, 2022 at 5:47 AM Frank Chang  wrote:
> >
> > Atish Patra  於 2022年3月9日 週三 上午8:53寫道：
> >>
> >> The Linux kernel parses the ISA extensions from "riscv,isa" DT
> >> property. It used to parse only the single letter base extensions
> >> until now. A generic ISA extension parsing framework was proposed[1]
> >> recently that can parse multi-letter ISA extensions as well.
> >>
> >> Generate the extended ISA string by appending  the available ISA
> extensions
> >> to the "riscv,isa" string if it is enabled so that kernel can process
> it.
> >>
> >> [1] https://lkml.org/lkml/2022/2/15/263
> >>
> >> Reviewed-by: Anup Patel 
> >> Reviewed-by: Alistair Francis 
> >> Suggested-by: Heiko Stubner 
> >> Signed-off-by: Atish Patra 
> >> ---
> >>
> >> Changes from v3->v4:
> >> 1. Fixed the order of the extension names.
> >> 2. Added all the available ISA extensions in Qemu.
> >>
> >> Changes from v2->v3:
> >> 1. Used g_strconcat to replace snprintf & a max isa string length as
> >> suggested by Anup.
> >> 2. I have not included the Tested-by Tag from Heiko because the
> >> implementation changed from v2 to v3.
> >>
> >> Changes from v1->v2:
> >> 1. Improved the code redability by using arrays instead of individual
> check
> >> ---
> >>  target/riscv/cpu.c | 43 +++
> >>  1 file changed, 43 insertions(+)
> >>
> >> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> >> index ddda4906ffb7..2521a6f31f9f 100644
> >> --- a/target/riscv/cpu.c
> >> +++ b/target/riscv/cpu.c
> >> @@ -34,6 +34,12 @@
> >>
> >>  /* RISC-V CPU definitions */
> >>
> >> +/* This includes the null terminated character '\0' */
> >> +struct isa_ext_data {
> >> +const char *name;
> >> +bool enabled;
> >> +};
> >> +
> >>  static const char riscv_exts[26] = "IEMAFDQCLBJTPVNSUHKORWXYZG";
> >>
> >>  const char * const riscv_int_regnames[] = {
> >> @@ -898,6 +904,42 @@ static void riscv_cpu_class_init(ObjectClass *c,
> void *data)
> >>  device_class_set_props(dc, riscv_cpu_properties);
> >>  }
> >>
> >> +#define ISA_EDATA_ENTRY(name, prop) {#name, cpu->cfg.prop}
> >> +
> >> +static void riscv_isa_string_ext(RISCVCPU *cpu, char **isa_str, int
> max_str_len)
> >> +{
> >> +char *old = *isa_str;
> >> +char *new = *isa_str;
> >> +int i;
> >> +struct isa_ext_data isa_edata_arr[] = {
> >> +ISA_EDATA_ENTRY(svinval, ext_svinval),
> >> +ISA_EDATA_ENTRY(svnapot, ext_svnapot),
> >> +ISA_EDATA_ENTRY(svpbmt, ext_svpbmt),
> >> +ISA_EDATA_ENTRY(zba, ext_zba),
> >> +ISA_EDATA_ENTRY(zbb, ext_zbb),
> >> +ISA_EDATA_ENTRY(zbc, ext_zbc),
> >> +ISA_EDATA_ENTRY(zbs, ext_zbs),
> >> +ISA_EDATA_ENTRY(zdinx, ext_zdinx),
> >> +ISA_EDATA_ENTRY(zfh, ext_zfhmin),
> >> +ISA_EDATA_ENTRY(zfhmin, ext_zfhmin),
> >> +ISA_EDATA_ENTRY(zfinx, ext_zfinx),
> >> +ISA_EDATA_ENTRY(zhinx, ext_zhinx),
> >> +ISA_EDATA_ENTRY(zhinxmin, ext_zhinxmin),
> >> +ISA_EDATA_ENTRY(zve32f, ext_zve32f),
> >> +ISA_EDATA_ENTRY(zve64f, ext_zve64f),
> >> +};
> >
> >
> > Hi Atish,
> >
> > According to RISC-V Unpriviledge spec, Section 28.6:
> > https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L85
> >
> > "The first letter following the “Z” conventionally indicates the most
> closely
> > related alphabetical extension category, IMAFDQLCBKJTPV.
> > For the “Zam” extension for misaligned atomics,
> > for example, the letter “a” indicates the extension is related to the
> “A” standard extension.
> > If multiple “Z” extensions are named, they should be ordered first by
> category,
> > then alphabetically within a category—for example, “Zicsr Zifencei Zam”."
> >
>
> Yes. Sorry I missed that part. Will fix it.
>
> > So I think the order of "Z" extensions should be:
> > zfh, zfhmin, zfinx, zdinx, zba, zbb, zbc, zbs, zve32f, zve64f, zhinx,
> zhinxmin
> >
> > Also, I think "Zifencei" and "Zicsr" should also be covered as well,
> > and all extensions should follow the order defined in Table 28.11:
> >
> https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L141
> >
>
> I thought about that earlier as well. Zifencei & Zicsr was already
> part of the ISA and carved out as an extension later.
> Qemu/Any supervisor support that by default and won't work without
> that. We can't possibly disable those and boot anything.
>
> Do you think there is any benefit adding it ?
>

I believe Zifencei & Zicsr are mostly supported by default.
They do appear in our internal hardware-generated DTS.
So... it's fine to either add them or not.
I don't see any penalty (as well as the benefit) to add them.

Regards,
Frank Chang


>
>
> > "The table also defines the canonical order in which extension names
> must appear in the name string,
> > with top-to-bottom in table indicating first-to-last in the name string,
> > e.g., RV32IMACV is legal, whereas 

Re: [RFC PATCH 1/2] spapr: Report correct GTSE support via ov5

[Daniel Henrique Barboza]

On 3/10/22 16:51, Fabiano Rosas wrote:

Fabiano Rosas  writes:


QEMU reports MMU support to the guest via the ibm,architecture-vec-5
property of the /chosen node. Byte number 26 specifies Radix Table
Expansions, currently only GTSE (Guest Translation Shootdown
Enable). This feature determines whether the tlbie instruction (and
others) are HV privileged.

Up until now, we always reported GTSE=1 to guests. Even after the
support for GTSE=0 was added. As part of that support, a kernel
command line radix_hcall_invalidate=on was introduced that overrides
the GTSE value received via CAS. So a guest can run with GTSE=0 and
use the H_RPT_INVALIDATE hcall instead of tlbie.

In this scenario, having GTSE always set to 1 by QEMU leads to a crash
when running nested KVM guests because KVM does not allow a nested
hypervisor to set GTSE support for its nested guests. So a nested
guest always uses the same value for LPCR_GTSE as its HV. Since the
nested HV disabled GTSE, but the L2 QEMU always reports GTSE=1, we run
into a crash when:

L1 LPCR_GTSE=0
L2 LPCR_GTSE=0
L2 CAS GTSE=1

The nested guest will run 'tlbie' and crash because the HW looks at
LPCR_GTSE, which is clear.

Having GTSE disabled in the L1 and enabled in the L2 is not an option
because the whole purpose of GTSE is to disallow access to tlbie and
we cannot allow L1 to spawn L2s that can access features that L1
itself cannot.

We also cannot have the guest check the LPCR bit, because LPCR is
HV-privileged.

So this patch goes through the most intuitive route which is to have
QEMU ask KVM about GTSE support and advertise the correct value to the
guest. A new KVM_CAP_PPC_GTSE capability is being added.

TCG continues to always enable GTSE.

Signed-off-by: Fabiano Rosas 
---
  hw/ppc/spapr.c   | 38 +++---
  target/ppc/kvm.c |  8 
  target/ppc/kvm_ppc.h |  6 ++
  3 files changed, 45 insertions(+), 7 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 4cc204f90d..3e95a1831f 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -971,7 +971,7 @@ static void spapr_dt_ov5_platform_support(SpaprMachineState 
*spapr, void *fdt,
  23, 0x00, /* XICS / XIVE mode */
  24, 0x00, /* Hash/Radix, filled in below. */
  25, 0x00, /* Hash options: Segment Tables == no, GTSE == no. */
-26, 0x40, /* Radix options: GTSE == yes. */
+26, 0x00, /* Radix options, filled in below. */
  };
  
  if (spapr->irq->xics && spapr->irq->xive) {

@@ -1000,10 +1000,16 @@ static void 
spapr_dt_ov5_platform_support(SpaprMachineState *spapr, void *fdt,
  } else {
  val[3] = 0x00; /* Hash */
  }
+
+if (kvmppc_has_cap_gtse()) {
+val[7] = 0x40 /* OV5_MMU_RADIX_GTSE */;
+}


This needs the same treatment as below to support kernels that don't
know about the cap. Also, look at that semicolon! =D



hahaha. There's another one down ...




  } else {
  /* V3 MMU supports both hash and radix in tcg (with dynamic 
switching) */
  val[3] = 0xC0;
+val[7] = 0x40 /* OV5_MMU_RADIX_GTSE */;


^ here



Daniel


  }
+
  _FDT(fdt_setprop(fdt, chosen, "ibm,arch-vec-5-platform-support",
   val, sizeof(val)));
  }
@@ -2824,14 +2830,32 @@ static void spapr_machine_init(MachineState *machine)
  /* Init numa_assoc_array */
  spapr_numa_associativity_init(spapr, machine);
  
-if ((!kvm_enabled() || kvmppc_has_cap_mmu_radix()) &&

-ppc_type_check_compat(machine->cpu_type, CPU_POWERPC_LOGICAL_3_00, 0,
+if (ppc_type_check_compat(machine->cpu_type, CPU_POWERPC_LOGICAL_3_00, 0,
spapr->max_compat_pvr)) {
-spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_300);
-/* KVM and TCG always allow GTSE with radix... */
-spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
+
+/* TCG always supports Radix w/ GTSE */
+if (!kvm_enabled()) {
+spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_300);
+spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
+} else {
+if (kvmppc_has_cap_mmu_radix()) {
+spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_300);
+}
+
+/*
+ * Only disable Guest Translation Shootdown if KVM
+ * supports the H_RPT_INVALIDATE hypercall, otherwise we'd
+ * leave the guest with no way to make TLB invalidations.
+ */
+if (kvmppc_has_cap_rpt_invalidate()) {
+if (kvmppc_has_cap_gtse()) {
+spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
+}
+} else {
+spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
+}
+}
  }
-/* ... but not with hash (currently). */
  
  if (kvm_enabled()) {

  /* Enable H_LOGICAL_CI_* so SLOF can talk to in-kernel devices */
diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c

Re: [PATCH 0/9] --disable-tcg avocado fixes for ppc-softmmu

[Murilo Opsfelder Araújo]

On 3/10/22 15:30, Daniel Henrique Barboza wrote:

Hi,

These are more test fixes that I missed from my first series [1]. Thanks
Murilo Opsfelder and Fabiano for letting me know that we still had broken
tests to deal with.

All these tests were either a case of 'this needs kvm_pr' or 'this needs
kvm_hv'. Since avocado doesn't have yet a way of detecting if the host
is running kvm_hv or kvm_pr, the workaround for now is to skip them if
TCG isn't available.

[1] https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg00866.html


Daniel Henrique Barboza (9):
   avocado/boot_linux_console.py: check TCG accel in test_ppc_g3beige()
   avocado/boot_linux_console.py: check TCG accel in test_ppc_mac99()
   avocado/ppc_405.py: remove test_ppc_taihu()
   avocado/ppc_405.py: check TCG accel in test_ppc_ref405ep()
   avocado/ppc_74xx.py: check TCG accel for all tests
   avocado/ppc_bamboo.py: check TCG accel in test_ppc_bamboo()
   avocado/ppc_mpc8544ds.py: check TCG accel in test_ppc_mpc8544ds()
   avocado/ppc_prep_40p.py: check TCG accel in all tests
   avocado/ppc_virtex_ml507.py: check TCG accel in
 test_ppc_virtex_ml507()

  tests/avocado/boot_linux_console.py | 12 
  tests/avocado/ppc_405.py| 10 ++
  tests/avocado/ppc_74xx.py   | 13 +
  tests/avocado/ppc_bamboo.py |  2 ++
  tests/avocado/ppc_mpc8544ds.py  |  2 ++
  tests/avocado/ppc_prep_40p.py   |  6 ++
  tests/avocado/ppc_virtex_ml507.py   |  2 ++
  7 files changed, 39 insertions(+), 8 deletions(-)



Hi, Daniel.

With this series and series "--disable-tcg qtest/avocado fixes for ppc64" [0]
applied, check-avocado passed for QEMU built with --disable-tcg 
--disable-linux-user.

[0] https://lists.nongnu.org/archive/html/qemu-devel/2022-03/msg00866.html

So:

Tested-by: Murilo Opsfelder Araujo 

--
Murilo

Re: [PATCH v5 03/13] mm/shmem: Support memfile_notifier

[Dave Chinner]

On Thu, Mar 10, 2022 at 10:09:01PM +0800, Chao Peng wrote:
> From: "Kirill A. Shutemov" 
> 
> It maintains a memfile_notifier list in shmem_inode_info structure and
> implements memfile_pfn_ops callbacks defined by memfile_notifier. It
> then exposes them to memfile_notifier via
> shmem_get_memfile_notifier_info.
> 
> We use SGP_NOALLOC in shmem_get_lock_pfn since the pages should be
> allocated by userspace for private memory. If there is no pages
> allocated at the offset then error should be returned so KVM knows that
> the memory is not private memory.
> 
> Signed-off-by: Kirill A. Shutemov 
> Signed-off-by: Chao Peng 
> ---
>  include/linux/shmem_fs.h |  4 +++
>  mm/shmem.c   | 76 
>  2 files changed, 80 insertions(+)
> 
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index 2dde843f28ef..7bb16f2d2825 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* inode in-kernel data */
>  
> @@ -28,6 +29,9 @@ struct shmem_inode_info {
>   struct simple_xattrsxattrs; /* list of xattrs */
>   atomic_tstop_eviction;  /* hold when working on inode */
>   unsigned intxflags; /* shmem extended flags */
> +#ifdef CONFIG_MEMFILE_NOTIFIER
> + struct memfile_notifier_list memfile_notifiers;
> +#endif
>   struct inodevfs_inode;
>  };
>  
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 9b31a7056009..7b43e274c9a2 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -903,6 +903,28 @@ static struct folio *shmem_get_partial_folio(struct 
> inode *inode, pgoff_t index)
>   return page ? page_folio(page) : NULL;
>  }
>  
> +static void notify_fallocate(struct inode *inode, pgoff_t start, pgoff_t end)
> +{
> +#ifdef CONFIG_MEMFILE_NOTIFIER
> + struct shmem_inode_info *info = SHMEM_I(inode);
> +
> + memfile_notifier_fallocate(>memfile_notifiers, start, end);
> +#endif
> +}

*notify_populate(), not fallocate.  This is a notification that a
range has been populated, not that the fallocate() syscall was run
to populate the backing store of a file.

i.e.  fallocate is the name of a userspace filesystem API that can
be used to manipulate the backing store of a file in various ways.
It can both populate and punch away the backing store of a file, and
some operations that fallocate() can run will do both (e.g.
FALLOC_FL_ZERO_RANGE) and so could generate both
notify_invalidate() and a notify_populate() events.

Hence "fallocate" as an internal mm namespace or operation does not
belong anywhere in core MM infrastructure - it should never get used
anywhere other than the VFS/filesystem layers that implement the
fallocate() syscall or use it directly.

Cheers,

Dave.

-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH 8/9] avocado/ppc_prep_40p.py: check TCG accel in all tests

[Philippe Mathieu-Daudé]

On 10/3/22 19:30, Daniel Henrique Barboza wrote:

All tests in the file times out when running in an IBM POWER host and
--disable-tcg with an error like the following:

 Command: ./qemu-system-ppc -display none -vga none (...)
-machine 40p (...)
 Output: qemu-system-ppc: Register sync failed... If you're using
kvm-hv.ko, only "-cpu host" is possible
qemu-system-ppc: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument

Since we don't have a way to detect whether the host is running kvm_hv
or kvm_pr, skip all tests if TCG is not available.

Signed-off-by: Daniel Henrique Barboza 
---
  tests/avocado/ppc_prep_40p.py | 6 ++
  1 file changed, 6 insertions(+)


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH-for-7.0] linux-user: Fix missing space in error message

[Philippe Mathieu-Daudé]

On 10/3/22 20:21, Patrick Venture wrote:

From: Fergus Henderson 

Signed-off-by: Fergus Henderson 
Signed-off-by: Patrick Venture 
---
  linux-user/elfload.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 9628a38361..c45da4d633 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2504,7 +2504,7 @@ static void pgb_reserved_va(const char *image_name, 
abi_ulong guest_loaddr,
  addr = mmap(test, reserved_va, PROT_NONE, flags, -1, 0);
  if (addr == MAP_FAILED || addr != test) {
  error_report("Unable to reserve 0x%lx bytes of virtual address "
- "space at %p (%s) for use as guest address space (check 
your"
+ "space at %p (%s) for use as guest address space (check your 
"
   "virtual memory ulimit setting, min_mmap_addr or reserve less 
"
   "using -R option)", reserved_va, test, strerror(errno));
  exit(EXIT_FAILURE);


Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH V7 19/29] vfio-pci: cpr part 1 (fd and dma)

[Alex Williamson]

On Thu, 10 Mar 2022 14:55:50 -0500
Steven Sistare  wrote:

> On 3/10/2022 1:35 PM, Alex Williamson wrote:
> > On Thu, 10 Mar 2022 10:00:29 -0500
> > Steven Sistare  wrote:
> >   
> >> On 3/7/2022 5:16 PM, Alex Williamson wrote:  
> >>> On Wed, 22 Dec 2021 11:05:24 -0800
> >>> Steve Sistare  wrote:  
>  @@ -1878,6 +1908,18 @@ static int vfio_init_container(VFIOContainer 
>  *container, int group_fd,
>   {
>   int iommu_type, ret;
>   
>  +/*
>  + * If container is reused, just set its type and skip the ioctls, 
>  as the
>  + * container and group are already configured in the kernel.
>  + * VFIO_TYPE1v2_IOMMU is the only type that supports reuse/cpr.
>  + * If you ever add new types or spapr cpr support, kind reader, 
>  please
>  + * also implement VFIO_GET_IOMMU.
>  + */
> >>>
> >>> VFIO_CHECK_EXTENSION should be able to tell us this, right?  Maybe the
> >>> problem is that vfio_iommu_type1_check_extension() should actually base
> >>> some of the details on the instantiated vfio_iommu, ex.
> >>>
> >>>   switch (arg) {
> >>>   case VFIO_TYPE1_IOMMU:
> >>>   return (iommu && iommu->v2) ? 0 : 1;
> >>>   case VFIO_UNMAP_ALL:
> >>>   case VFIO_UPDATE_VADDR:
> >>>   case VFIO_TYPE1v2_IOMMU:
> >>>   return (iommu && !iommu->v2) ? 0 : 1;
> >>>   case VFIO_TYPE1_NESTING_IOMMU:
> >>>   return (iommu && !iommu->nesting) ? 0 : 1;
> >>>   ...
> >>>
> >>> We can't support v1 if we've already set a v2 container and vice versa.
> >>> There are probably some corner cases and compatibility to puzzle
> >>> through, but I wouldn't think we need a new ioctl to check this.
> >>
> >> That change makes sense, and may be worth while on its own merits, but 
> >> does not
> >> solve the problem, which is that qemu will not be able to infer iommu_type 
> >> in
> >> the future if new types are added.  Given:
> >>   * a new kernel supporting shiny new TYPE1v3
> >>   * old qemu starts and selects TYPE1v2 in vfio_get_iommu_type because it 
> >> has no
> >> knowledge of v3
> >>   * live update to qemu which supports v3, which will be listed first in 
> >> vfio_get_iommu_type.
> >>
> >> Then the new qemu has no way to infer iommu_type.  If it has code that 
> >> makes 
> >> decisions based on iommu_type (eg, VFIO_SPAPR_TCE_v2_IOMMU in 
> >> vfio_container_region_add,
> >> or vfio_ram_block_discard_disable, or ...), then new qemu cannot function 
> >> correctly.
> >>
> >> For that, VFIO_GET_IOMMU would be the cleanest solution, to be added the 
> >> same time our
> >> hypothetical future developer adds TYPE1v3.  The current inability to ask 
> >> the kernel
> >> "what are you" about a container feels like a bug to me.  
> > 
> > Hmm, I don't think the kernel has an innate responsibility to remind
> > the user of a configuration that they've already made.
> 
> No, but it can make userland cleaner.  For example, CRIU checkpoint/restart 
> queries
> the kernel to save process state, and later makes syscalls to restore it.  
> Where the
> kernel does not export sufficient information, CRIU must provide interpose 
> libraries
> so it can remember state internally on its way to the kernel.  And 
> applications must
> link against the interpose libraries.

The counter argument is that it bloats the kernel to add interfaces to
report back things that userspace should already know.  Which has more
exploit vectors, a new kernel ioctl or yet another userspace library?
 
> > But I also
> > don't follow your TYPE1v3 example.  If we added such a type, I imagine
> > the switch would change to:
> > 
> > switch (arg)
> > case VFIO_TYPE1_IOMMU:
> > return (iommu && (iommu->v2 || iommu->v3) ? 0 : 1;
> > case VFIO_UNMAP_ALL:
> > case VFIO_UPDATE_VADDR:
> > return (iommu && !(iommu-v2 || iommu->v3) ? 0 : 1;
> > case VFIO_TYPE1v2_IOMMU:
> > return (iommu && !iommu-v2) ? 0 : 1;
> > case VFIO_TYPE1v3_IOMMU:
> > return (iommu && !iommu->v3) ? 0 : 1;
> > ...
> > 
> > How would that not allow exactly the scenario described, ie. new QEMU
> > can see that old QEMU left it a v2 IOMMU.  
> 
> OK, that works as long as the switch returns true for all options before
> VFIO_SET_IOMMU is called.  I guess your test for "iommu" above does that,
> which I missed before.  If we are on the same page now, I will modify my
> comment "please also implement VFIO_GET_IOMMU".

Yes, in the above all extensions are supported before the container
type is set, then once set only the relevant extensions are available.

...
>  diff --git a/migration/cpr.c b/migration/cpr.c
>  index 37eca66..cee82cf 100644
>  --- a/migration/cpr.c
>  +++ b/migration/cpr.c
>  @@ -7,6 +7,7 @@
>   
>   #include "qemu/osdep.h"
>   #include "exec/memory.h"
>  +#include "hw/vfio/vfio-common.h"
>   #include "io/channel-buffer.h"
>   #include "io/channel-file.h"
>   

Re: [PATCH-for-7.0] softmmu: List CPU types again

[Max Filippov]

On Thu, Mar 10, 2022 at 3:55 AM Philippe Mathieu-Daudé
 wrote:
>
> From: Philippe Mathieu-Daudé 
>
> Commit e0220bb5b2 made cpus.c target-agnostic but didn't notice
> the cpu_list() function is only defined in target-specific code
> in "cpu.h". Extract list_cpus() from the generic cpus.c into a
> new target-specific unit.
>
> Fixes: e0220bb5b2 ("softmmu: Build target-agnostic objects once")
> Reported-by: Max Filippov 
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  softmmu/cpus.c  |  8 
>  softmmu/cpus_list.c | 36 
>  softmmu/meson.build |  1 +
>  3 files changed, 37 insertions(+), 8 deletions(-)
>  create mode 100644 softmmu/cpus_list.c

Tested-by: Max Filippov 

-- 
Thanks.
-- Max

Re: [PATCH] block-qdict: Fix -Werror=maybe-uninitialized build failure

[Daniel Henrique Barboza]

On 3/10/22 17:05, Murilo Opsfelder Araujo wrote:

Building QEMU on Fedora 37 (Rawhide Prerelease) ppc64le failed with the
following error:

 $ ../configure --prefix=/usr/local/qemu-disabletcg 
--target-list=ppc-softmmu,ppc64-softmmu --disable-tcg --disable-linux-user
 ...
 $ make -j$(nproc)
 ...
 FAILED: libqemuutil.a.p/qobject_block-qdict.c.o
 cc -m64 -mlittle-endian -Ilibqemuutil.a.p -I. -I.. 
-Isubprojects/libvhost-user -I../subprojects/libvhost-user -Iqapi -Itrace -Iui 
-Iui/shader -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
-I/usr/include/sysprof-4 -I/usr/include/lib
 mount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 
-I/usr/include/p11-kit-1 -I/usr/include/pixman-1 -fdiagnostics-color=auto -Wall 
-Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /root/qemu/linux-headers 
-isystem linux-headers -iquote
  . -iquote /root/qemu -iquote /root/qemu/include -iquote 
/root/qemu/disas/libvixl -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wundef -Wwrite
 -strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs 
-Wendif-label
 s -Wexpansion-to-defined -Wimplicit-fallthrough=2 
-Wno-missing-include-dirs -Wno-shift-negative-value -Wno-psabi 
-fstack-protector-strong -fPIE -MD -MQ libqemuutil.a.p/qobject_block-qdict.c.o 
-MF libqemuutil.a.p/qobject_block-qdict.c.o.d -
 o libqemuutil.a.p/qobject_block-qdict.c.o -c ../qobject/block-qdict.c
 In file included from /root/qemu/include/qapi/qmp/qdict.h:16,
  from /root/qemu/include/block/qdict.h:13,
  from ../qobject/block-qdict.c:11:
 /root/qemu/include/qapi/qmp/qobject.h: In function ‘qdict_array_split’:
 /root/qemu/include/qapi/qmp/qobject.h:49:17: error: ‘subqdict’ may be used 
uninitialized [-Werror=maybe-uninitialized]
49 | typeof(obj) _obj = (obj);   \
   | ^~~~
 ../qobject/block-qdict.c:227:16: note: ‘subqdict’ declared here
   227 | QDict *subqdict;
   |^~~~
 cc1: all warnings being treated as errors

Fix build failure by initializing the QDict variable with NULL.

Signed-off-by: Murilo Opsfelder Araujo 
Cc: Kevin Wolf 
Cc: Hanna Reitz 
Cc: Markus Armbruster 
---


Reviewed-by: Daniel Henrique Barboza 


  qobject/block-qdict.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qobject/block-qdict.c b/qobject/block-qdict.c
index 1487cc5dd8..b26524429c 100644
--- a/qobject/block-qdict.c
+++ b/qobject/block-qdict.c
@@ -224,7 +224,7 @@ void qdict_array_split(QDict *src, QList **dst)
  for (i = 0; i < UINT_MAX; i++) {
  QObject *subqobj;
  bool is_subqdict;
-QDict *subqdict;
+QDict *subqdict = NULL;
  char indexstr[32], prefix[32];
  size_t snprintf_ret;
  

Re: [PATCH] linux-user: Fix missing space in error message

[Peter Maydell]

On Thu, 10 Mar 2022 at 19:29, Patrick Venture  wrote:
>
> From: Fergus Henderson 
>
> Signed-off-by: Fergus Henderson 
> Signed-off-by: Patrick Venture 
> ---
Reviewed-by: Peter Maydell 

thanks
-- PMM

[PATCH 2/3] tcg/s390x: Fix INDEX_op_bitsel_vec vs VSEL

[Richard Henderson]

The operands are output in the wrong order: the tcg selector
argument is first, whereas the s390x selector argument is last.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/898
Fixes: 9bca986df88 ("tcg/s390x: Implement TCG_TARGET_HAS_bitsel_vec")
Signed-off-by: Richard Henderson 
---
 tcg/s390x/tcg-target.c.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tcg/s390x/tcg-target.c.inc b/tcg/s390x/tcg-target.c.inc
index 508f1bccc7..3b185b3c96 100644
--- a/tcg/s390x/tcg-target.c.inc
+++ b/tcg/s390x/tcg-target.c.inc
@@ -2868,7 +2868,7 @@ static void tcg_out_vec_op(TCGContext *s, TCGOpcode opc,
 break;
 
 case INDEX_op_bitsel_vec:
-tcg_out_insn(s, VRRe, VSEL, a0, a1, a2, args[3]);
+tcg_out_insn(s, VRRe, VSEL, a0, a2, args[3], a1);
 break;
 
 case INDEX_op_cmp_vec:
-- 
2.25.1

[PATCH 1/3] tcg/s390x: Fix tcg_out_dupi_vec vs VGM

[Richard Henderson]

The immediate operands to VGM were in the wrong order,
producing an inverse mask.

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

diff --git a/tcg/s390x/tcg-target.c.inc b/tcg/s390x/tcg-target.c.inc
index 6e65828c09..508f1bccc7 100644
--- a/tcg/s390x/tcg-target.c.inc
+++ b/tcg/s390x/tcg-target.c.inc
@@ -2715,7 +2715,7 @@ static void tcg_out_dupi_vec(TCGContext *s, TCGType type, 
unsigned vece,
 msb = clz32(val);
 lsb = 31 - ctz32(val);
 }
-tcg_out_insn(s, VRIb, VGM, dst, lsb, msb, MO_32);
+tcg_out_insn(s, VRIb, VGM, dst, msb, lsb, MO_32);
 return;
 }
 } else {
@@ -2729,7 +2729,7 @@ static void tcg_out_dupi_vec(TCGContext *s, TCGType type, 
unsigned vece,
 msb = clz64(val);
 lsb = 63 - ctz64(val);
 }
-tcg_out_insn(s, VRIb, VGM, dst, lsb, msb, MO_64);
+tcg_out_insn(s, VRIb, VGM, dst, msb, lsb, MO_64);
 return;
 }
 }
-- 
2.25.1

[PATCH 3/3] tcg/s390x: Fix tcg_out_dup_vec vs general registers

[Richard Henderson]

We copied the data from the general register input to the
vector register output, but have not yet replicated it.
We intended to fall through into the vector-vector case,
but failed to redirect the input register.

This is caught by an assertion failure in tcg_out_insn_VRIc,
which diagnosed the incorrect register class.

Signed-off-by: Richard Henderson 
---
 tcg/s390x/tcg-target.c.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tcg/s390x/tcg-target.c.inc b/tcg/s390x/tcg-target.c.inc
index 3b185b3c96..33becd7694 100644
--- a/tcg/s390x/tcg-target.c.inc
+++ b/tcg/s390x/tcg-target.c.inc
@@ -2675,6 +2675,7 @@ static bool tcg_out_dup_vec(TCGContext *s, TCGType type, 
unsigned vece,
 if (vece == MO_64) {
 return true;
 }
+src = dst;
 }
 
 /*
-- 
2.25.1

[PATCH 0/3] tcg/s390x vector fixes

[Richard Henderson]

These 3 issues were found by running risu on arm neon test cases.
In the meantime, Thomas encountered one of the same with the new
tests of vectorized sha512.


r~


Richard Henderson (3):
  tcg/s390x: Fix tcg_out_dupi_vec vs VGM
  tcg/s390x: Fix INDEX_op_bitsel_vec vs VSEL
  tcg/s390x: Fix tcg_out_dup_vec vs general registers

 tcg/s390x/tcg-target.c.inc | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

-- 
2.25.1

Re: [PULL 00/12] Hexagon (target/hexagon) queue

[Alex Bennée]

Taylor Simpson  writes:

> My apologies.  I'll investigate the mismatch between the toolchain I'm
> using and the one CI is using.

I don't recall seeing a new binary docker since the previous one had ABI
issues with signal handling.

-- 
Alex Bennée

Re: [PATCH experiment 00/35] stackless coroutine backend

[Paolo Bonzini]

On 3/10/22 18:42, Stefan Hajnoczi wrote:

There are a lot of details to decide on in the translator tool and
runtime to optimize the code. I think the way the stack frames are
organized in this patch series is probably for convenience rather than
performance.


Yes, sometimes the optimizations are there but mostly because they made 
my job easier.



Out of curiousity, did you run the perf tests and compare against
ucontext?


Not quite voluntarily, but I noticed I had to add one 0 to make them run 
for a decent amount of time.  So yeah, it's much faster than siglongjmp.


Paolo

[PATCH] block-qdict: Fix -Werror=maybe-uninitialized build failure

[Murilo Opsfelder Araujo]

Building QEMU on Fedora 37 (Rawhide Prerelease) ppc64le failed with the
following error:

$ ../configure --prefix=/usr/local/qemu-disabletcg 
--target-list=ppc-softmmu,ppc64-softmmu --disable-tcg --disable-linux-user
...
$ make -j$(nproc)
...
FAILED: libqemuutil.a.p/qobject_block-qdict.c.o
cc -m64 -mlittle-endian -Ilibqemuutil.a.p -I. -I.. 
-Isubprojects/libvhost-user -I../subprojects/libvhost-user -Iqapi -Itrace -Iui 
-Iui/shader -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include 
-I/usr/include/sysprof-4 -I/usr/include/lib
mount -I/usr/include/blkid -I/usr/include/gio-unix-2.0 
-I/usr/include/p11-kit-1 -I/usr/include/pixman-1 -fdiagnostics-color=auto -Wall 
-Winvalid-pch -Werror -std=gnu11 -O2 -g -isystem /root/qemu/linux-headers 
-isystem linux-headers -iquote
 . -iquote /root/qemu -iquote /root/qemu/include -iquote 
/root/qemu/disas/libvixl -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes 
-Wredundant-decls -Wundef -Wwrite
-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-Wold-style-declaration -Wold-style-definition -Wtype-limits -Wformat-security 
-Wformat-y2k -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs 
-Wendif-label
s -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs 
-Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -MD -MQ 
libqemuutil.a.p/qobject_block-qdict.c.o -MF 
libqemuutil.a.p/qobject_block-qdict.c.o.d -
o libqemuutil.a.p/qobject_block-qdict.c.o -c ../qobject/block-qdict.c
In file included from /root/qemu/include/qapi/qmp/qdict.h:16,
 from /root/qemu/include/block/qdict.h:13,
 from ../qobject/block-qdict.c:11:
/root/qemu/include/qapi/qmp/qobject.h: In function ‘qdict_array_split’:
/root/qemu/include/qapi/qmp/qobject.h:49:17: error: ‘subqdict’ may be used 
uninitialized [-Werror=maybe-uninitialized]
   49 | typeof(obj) _obj = (obj);   \
  | ^~~~
../qobject/block-qdict.c:227:16: note: ‘subqdict’ declared here
  227 | QDict *subqdict;
  |^~~~
cc1: all warnings being treated as errors

Fix build failure by initializing the QDict variable with NULL.

Signed-off-by: Murilo Opsfelder Araujo 
Cc: Kevin Wolf 
Cc: Hanna Reitz 
Cc: Markus Armbruster 
---
 qobject/block-qdict.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/qobject/block-qdict.c b/qobject/block-qdict.c
index 1487cc5dd8..b26524429c 100644
--- a/qobject/block-qdict.c
+++ b/qobject/block-qdict.c
@@ -224,7 +224,7 @@ void qdict_array_split(QDict *src, QList **dst)
 for (i = 0; i < UINT_MAX; i++) {
 QObject *subqobj;
 bool is_subqdict;
-QDict *subqdict;
+QDict *subqdict = NULL;
 char indexstr[32], prefix[32];
 size_t snprintf_ret;
 
-- 
2.35.1

Re: [PATCH V7 19/29] vfio-pci: cpr part 1 (fd and dma)

[Steven Sistare]

On 3/10/2022 1:35 PM, Alex Williamson wrote:
> On Thu, 10 Mar 2022 10:00:29 -0500
> Steven Sistare  wrote:
> 
>> On 3/7/2022 5:16 PM, Alex Williamson wrote:
>>> On Wed, 22 Dec 2021 11:05:24 -0800
>>> Steve Sistare  wrote:
 @@ -1878,6 +1908,18 @@ static int vfio_init_container(VFIOContainer 
 *container, int group_fd,
  {
  int iommu_type, ret;
  
 +/*
 + * If container is reused, just set its type and skip the ioctls, as 
 the
 + * container and group are already configured in the kernel.
 + * VFIO_TYPE1v2_IOMMU is the only type that supports reuse/cpr.
 + * If you ever add new types or spapr cpr support, kind reader, please
 + * also implement VFIO_GET_IOMMU.
 + */  
>>>
>>> VFIO_CHECK_EXTENSION should be able to tell us this, right?  Maybe the
>>> problem is that vfio_iommu_type1_check_extension() should actually base
>>> some of the details on the instantiated vfio_iommu, ex.
>>>
>>> switch (arg) {
>>> case VFIO_TYPE1_IOMMU:
>>> return (iommu && iommu->v2) ? 0 : 1;
>>> case VFIO_UNMAP_ALL:
>>> case VFIO_UPDATE_VADDR:
>>> case VFIO_TYPE1v2_IOMMU:
>>> return (iommu && !iommu->v2) ? 0 : 1;
>>> case VFIO_TYPE1_NESTING_IOMMU:
>>> return (iommu && !iommu->nesting) ? 0 : 1;
>>> ...
>>>
>>> We can't support v1 if we've already set a v2 container and vice versa.
>>> There are probably some corner cases and compatibility to puzzle
>>> through, but I wouldn't think we need a new ioctl to check this.  
>>
>> That change makes sense, and may be worth while on its own merits, but does 
>> not
>> solve the problem, which is that qemu will not be able to infer iommu_type in
>> the future if new types are added.  Given:
>>   * a new kernel supporting shiny new TYPE1v3
>>   * old qemu starts and selects TYPE1v2 in vfio_get_iommu_type because it 
>> has no
>> knowledge of v3
>>   * live update to qemu which supports v3, which will be listed first in 
>> vfio_get_iommu_type.
>>
>> Then the new qemu has no way to infer iommu_type.  If it has code that makes 
>> decisions based on iommu_type (eg, VFIO_SPAPR_TCE_v2_IOMMU in 
>> vfio_container_region_add,
>> or vfio_ram_block_discard_disable, or ...), then new qemu cannot function 
>> correctly.
>>
>> For that, VFIO_GET_IOMMU would be the cleanest solution, to be added the 
>> same time our
>> hypothetical future developer adds TYPE1v3.  The current inability to ask 
>> the kernel
>> "what are you" about a container feels like a bug to me.
> 
> Hmm, I don't think the kernel has an innate responsibility to remind
> the user of a configuration that they've already made.  

No, but it can make userland cleaner.  For example, CRIU checkpoint/restart 
queries
the kernel to save process state, and later makes syscalls to restore it.  
Where the
kernel does not export sufficient information, CRIU must provide interpose 
libraries
so it can remember state internally on its way to the kernel.  And applications 
must
link against the interpose libraries.

> But I also
> don't follow your TYPE1v3 example.  If we added such a type, I imagine
> the switch would change to:
> 
>   switch (arg)
>   case VFIO_TYPE1_IOMMU:
>   return (iommu && (iommu->v2 || iommu->v3) ? 0 : 1;
>   case VFIO_UNMAP_ALL:
>   case VFIO_UPDATE_VADDR:
>   return (iommu && !(iommu-v2 || iommu->v3) ? 0 : 1;
>   case VFIO_TYPE1v2_IOMMU:
>   return (iommu && !iommu-v2) ? 0 : 1;
>   case VFIO_TYPE1v3_IOMMU:
>   return (iommu && !iommu->v3) ? 0 : 1;
>   ...
> 
> How would that not allow exactly the scenario described, ie. new QEMU
> can see that old QEMU left it a v2 IOMMU.

OK, that works as long as the switch returns true for all options before
VFIO_SET_IOMMU is called.  I guess your test for "iommu" above does that,
which I missed before.  If we are on the same page now, I will modify my
comment "please also implement VFIO_GET_IOMMU".

> ...
 +
 +bool vfio_is_cpr_capable(VFIOContainer *container, Error **errp)
 +{
 +if (!ioctl(container->fd, VFIO_CHECK_EXTENSION, VFIO_UPDATE_VADDR) ||
 +!ioctl(container->fd, VFIO_CHECK_EXTENSION, VFIO_UNMAP_ALL)) {
 +error_setg(errp, "VFIO container does not support 
 VFIO_UPDATE_VADDR "
 + "or VFIO_UNMAP_ALL");
 +return false;
 +} else {
 +return true;
 +}
 +}  
>>>
>>> We could have minimally used this where we assumed a TYPE1v2 container.  
>>
>> Are you referring to vfio_init_container (discussed above)?
>> Are you suggesting that, if reused is true, we validate those extensions are
>> present, before setting iommu_type = VFIO_TYPE1v2_IOMMU?
> 
> Yeah, though maybe it's not sufficiently precise to be worthwhile given
> the current kernel behavior.
> 
 +
 +/*
 + * Verify that all containers support CPR, and unmap all dma vaddr's.

Re: [RFC PATCH 1/2] spapr: Report correct GTSE support via ov5

[Fabiano Rosas]

Fabiano Rosas  writes:

> QEMU reports MMU support to the guest via the ibm,architecture-vec-5
> property of the /chosen node. Byte number 26 specifies Radix Table
> Expansions, currently only GTSE (Guest Translation Shootdown
> Enable). This feature determines whether the tlbie instruction (and
> others) are HV privileged.
>
> Up until now, we always reported GTSE=1 to guests. Even after the
> support for GTSE=0 was added. As part of that support, a kernel
> command line radix_hcall_invalidate=on was introduced that overrides
> the GTSE value received via CAS. So a guest can run with GTSE=0 and
> use the H_RPT_INVALIDATE hcall instead of tlbie.
>
> In this scenario, having GTSE always set to 1 by QEMU leads to a crash
> when running nested KVM guests because KVM does not allow a nested
> hypervisor to set GTSE support for its nested guests. So a nested
> guest always uses the same value for LPCR_GTSE as its HV. Since the
> nested HV disabled GTSE, but the L2 QEMU always reports GTSE=1, we run
> into a crash when:
>
> L1 LPCR_GTSE=0
> L2 LPCR_GTSE=0
> L2 CAS GTSE=1
>
> The nested guest will run 'tlbie' and crash because the HW looks at
> LPCR_GTSE, which is clear.
>
> Having GTSE disabled in the L1 and enabled in the L2 is not an option
> because the whole purpose of GTSE is to disallow access to tlbie and
> we cannot allow L1 to spawn L2s that can access features that L1
> itself cannot.
>
> We also cannot have the guest check the LPCR bit, because LPCR is
> HV-privileged.
>
> So this patch goes through the most intuitive route which is to have
> QEMU ask KVM about GTSE support and advertise the correct value to the
> guest. A new KVM_CAP_PPC_GTSE capability is being added.
>
> TCG continues to always enable GTSE.
>
> Signed-off-by: Fabiano Rosas 
> ---
>  hw/ppc/spapr.c   | 38 +++---
>  target/ppc/kvm.c |  8 
>  target/ppc/kvm_ppc.h |  6 ++
>  3 files changed, 45 insertions(+), 7 deletions(-)
>
> diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> index 4cc204f90d..3e95a1831f 100644
> --- a/hw/ppc/spapr.c
> +++ b/hw/ppc/spapr.c
> @@ -971,7 +971,7 @@ static void 
> spapr_dt_ov5_platform_support(SpaprMachineState *spapr, void *fdt,
>  23, 0x00, /* XICS / XIVE mode */
>  24, 0x00, /* Hash/Radix, filled in below. */
>  25, 0x00, /* Hash options: Segment Tables == no, GTSE == no. */
> -26, 0x40, /* Radix options: GTSE == yes. */
> +26, 0x00, /* Radix options, filled in below. */
>  };
>  
>  if (spapr->irq->xics && spapr->irq->xive) {
> @@ -1000,10 +1000,16 @@ static void 
> spapr_dt_ov5_platform_support(SpaprMachineState *spapr, void *fdt,
>  } else {
>  val[3] = 0x00; /* Hash */
>  }
> +
> +if (kvmppc_has_cap_gtse()) {
> +val[7] = 0x40 /* OV5_MMU_RADIX_GTSE */;
> +}

This needs the same treatment as below to support kernels that don't
know about the cap. Also, look at that semicolon! =D

>  } else {
>  /* V3 MMU supports both hash and radix in tcg (with dynamic 
> switching) */
>  val[3] = 0xC0;
> +val[7] = 0x40 /* OV5_MMU_RADIX_GTSE */;
>  }
> +
>  _FDT(fdt_setprop(fdt, chosen, "ibm,arch-vec-5-platform-support",
>   val, sizeof(val)));
>  }
> @@ -2824,14 +2830,32 @@ static void spapr_machine_init(MachineState *machine)
>  /* Init numa_assoc_array */
>  spapr_numa_associativity_init(spapr, machine);
>  
> -if ((!kvm_enabled() || kvmppc_has_cap_mmu_radix()) &&
> -ppc_type_check_compat(machine->cpu_type, CPU_POWERPC_LOGICAL_3_00, 0,
> +if (ppc_type_check_compat(machine->cpu_type, CPU_POWERPC_LOGICAL_3_00, 0,
>spapr->max_compat_pvr)) {
> -spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_300);
> -/* KVM and TCG always allow GTSE with radix... */
> -spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
> +
> +/* TCG always supports Radix w/ GTSE */
> +if (!kvm_enabled()) {
> +spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_300);
> +spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
> +} else {
> +if (kvmppc_has_cap_mmu_radix()) {
> +spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_300);
> +}
> +
> +/*
> + * Only disable Guest Translation Shootdown if KVM
> + * supports the H_RPT_INVALIDATE hypercall, otherwise we'd
> + * leave the guest with no way to make TLB invalidations.
> + */
> +if (kvmppc_has_cap_rpt_invalidate()) {
> +if (kvmppc_has_cap_gtse()) {
> +spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
> +}
> +} else {
> +spapr_ovec_set(spapr->ov5, OV5_MMU_RADIX_GTSE);
> +}
> +}
>  }
> -/* ... but not with hash (currently). */
>  
>  if (kvm_enabled()) {
>  /* Enable H_LOGICAL_CI_* so 

[PATCH] linux-user: Fix missing space in error message

[Patrick Venture]

From: Fergus Henderson 

Signed-off-by: Fergus Henderson 
Signed-off-by: Patrick Venture 
---
 linux-user/elfload.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/linux-user/elfload.c b/linux-user/elfload.c
index 9628a38361..c45da4d633 100644
--- a/linux-user/elfload.c
+++ b/linux-user/elfload.c
@@ -2504,7 +2504,7 @@ static void pgb_reserved_va(const char *image_name, 
abi_ulong guest_loaddr,
 addr = mmap(test, reserved_va, PROT_NONE, flags, -1, 0);
 if (addr == MAP_FAILED || addr != test) {
 error_report("Unable to reserve 0x%lx bytes of virtual address "
- "space at %p (%s) for use as guest address space (check 
your"
+ "space at %p (%s) for use as guest address space (check 
your "
  "virtual memory ulimit setting, min_mmap_addr or reserve 
less "
  "using -R option)", reserved_va, test, strerror(errno));
 exit(EXIT_FAILURE);
-- 
2.35.1.723.g4982287a31-goog

Re: [PATCH v5 0/5] user creatable pnv-phb4 devices

[Thomas Huth]

On 11/01/2022 14.10, Daniel Henrique Barboza wrote:

Hi,

This version implements Cedric's review suggestions from v4. No
drastic design changes were made.

Changes from v4:
- patches 1,3,5: unchanged
- patch 2:
   * renamed function to pnv_phb4_xscom_realize()
   * pnv4_phb4_xscom_realize() is now called at the end of phb4_realize()
- patch 4:
   * changed pnv_phb4_get_stack signature to use chip and phb
   * added a new helper called pnv_pec_stk_default_phb_realize() to
realize the default phb when running with defaults
- v4 link: https://lists.gnu.org/archive/html/qemu-devel/2022-01/msg02148.html

Daniel Henrique Barboza (5):
   ppc/pnv: set phb4 properties in stk_realize()
   ppc/pnv: move PHB4 XSCOM init to phb4_realize()
   ppc/pnv: turn 'phb' into a pointer in struct PnvPhb4PecStack
   ppc/pnv: Introduce user creatable pnv-phb4 devices
   ppc/pnv: turn pnv_phb4_update_regions() into static


It's now possible to crash QEMU with the pnv-phb4 device:

$ ./qemu-system-ppc64 -nographic -M powernv9 -device pnv-phb4
Unexpected error in object_property_try_add() at 
../../devel/qemu/qom/object.c:1229:
qemu-system-ppc64: -device pnv-phb4: attempt to add duplicate property 
'pnv-phb4[0]' to object (type 'power9_v2.0-pnv-chip')

Aborted (core dumped)

Any ideas how to fix this?

 Thomas

Re: [PATCH v5 11/48] target/nios2: Do not zero the general registers on reset

[Richard Henderson]

On 3/10/22 04:21, Peter Maydell wrote:

On Thu, 10 Mar 2022 at 11:27, Richard Henderson
 wrote:


The bulk of the general register set is undefined on reset.


They might be architecturally undefined, but for QEMU's
purposes we want the state of the CPU on reset to be
identical to the state it is in when QEMU is first started.


Ok, I've dropped this.

The intent had been to remove a user/sysemu difference when we get to introducing shadow 
regs, but it isn't that big of a deal.



r~

Re: [PATCH v4] target/riscv: Add isa extenstion strings to the device tree

[Atish Kumar Patra]

On Wed, Mar 9, 2022 at 5:47 AM Frank Chang  wrote:
>
> Atish Patra  於 2022年3月9日 週三 上午8:53寫道：
>>
>> The Linux kernel parses the ISA extensions from "riscv,isa" DT
>> property. It used to parse only the single letter base extensions
>> until now. A generic ISA extension parsing framework was proposed[1]
>> recently that can parse multi-letter ISA extensions as well.
>>
>> Generate the extended ISA string by appending  the available ISA extensions
>> to the "riscv,isa" string if it is enabled so that kernel can process it.
>>
>> [1] https://lkml.org/lkml/2022/2/15/263
>>
>> Reviewed-by: Anup Patel 
>> Reviewed-by: Alistair Francis 
>> Suggested-by: Heiko Stubner 
>> Signed-off-by: Atish Patra 
>> ---
>>
>> Changes from v3->v4:
>> 1. Fixed the order of the extension names.
>> 2. Added all the available ISA extensions in Qemu.
>>
>> Changes from v2->v3:
>> 1. Used g_strconcat to replace snprintf & a max isa string length as
>> suggested by Anup.
>> 2. I have not included the Tested-by Tag from Heiko because the
>> implementation changed from v2 to v3.
>>
>> Changes from v1->v2:
>> 1. Improved the code redability by using arrays instead of individual check
>> ---
>>  target/riscv/cpu.c | 43 +++
>>  1 file changed, 43 insertions(+)
>>
>> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
>> index ddda4906ffb7..2521a6f31f9f 100644
>> --- a/target/riscv/cpu.c
>> +++ b/target/riscv/cpu.c
>> @@ -34,6 +34,12 @@
>>
>>  /* RISC-V CPU definitions */
>>
>> +/* This includes the null terminated character '\0' */
>> +struct isa_ext_data {
>> +const char *name;
>> +bool enabled;
>> +};
>> +
>>  static const char riscv_exts[26] = "IEMAFDQCLBJTPVNSUHKORWXYZG";
>>
>>  const char * const riscv_int_regnames[] = {
>> @@ -898,6 +904,42 @@ static void riscv_cpu_class_init(ObjectClass *c, void 
>> *data)
>>  device_class_set_props(dc, riscv_cpu_properties);
>>  }
>>
>> +#define ISA_EDATA_ENTRY(name, prop) {#name, cpu->cfg.prop}
>> +
>> +static void riscv_isa_string_ext(RISCVCPU *cpu, char **isa_str, int 
>> max_str_len)
>> +{
>> +char *old = *isa_str;
>> +char *new = *isa_str;
>> +int i;
>> +struct isa_ext_data isa_edata_arr[] = {
>> +ISA_EDATA_ENTRY(svinval, ext_svinval),
>> +ISA_EDATA_ENTRY(svnapot, ext_svnapot),
>> +ISA_EDATA_ENTRY(svpbmt, ext_svpbmt),
>> +ISA_EDATA_ENTRY(zba, ext_zba),
>> +ISA_EDATA_ENTRY(zbb, ext_zbb),
>> +ISA_EDATA_ENTRY(zbc, ext_zbc),
>> +ISA_EDATA_ENTRY(zbs, ext_zbs),
>> +ISA_EDATA_ENTRY(zdinx, ext_zdinx),
>> +ISA_EDATA_ENTRY(zfh, ext_zfhmin),
>> +ISA_EDATA_ENTRY(zfhmin, ext_zfhmin),
>> +ISA_EDATA_ENTRY(zfinx, ext_zfinx),
>> +ISA_EDATA_ENTRY(zhinx, ext_zhinx),
>> +ISA_EDATA_ENTRY(zhinxmin, ext_zhinxmin),
>> +ISA_EDATA_ENTRY(zve32f, ext_zve32f),
>> +ISA_EDATA_ENTRY(zve64f, ext_zve64f),
>> +};
>
>
> Hi Atish,
>
> According to RISC-V Unpriviledge spec, Section 28.6:
> https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L85
>
> "The first letter following the “Z” conventionally indicates the most closely
> related alphabetical extension category, IMAFDQLCBKJTPV.
> For the “Zam” extension for misaligned atomics,
> for example, the letter “a” indicates the extension is related to the “A” 
> standard extension.
> If multiple “Z” extensions are named, they should be ordered first by 
> category,
> then alphabetically within a category—for example, “Zicsr Zifencei Zam”."
>

Yes. Sorry I missed that part. Will fix it.

> So I think the order of "Z" extensions should be:
> zfh, zfhmin, zfinx, zdinx, zba, zbb, zbc, zbs, zve32f, zve64f, zhinx, zhinxmin
>
> Also, I think "Zifencei" and "Zicsr" should also be covered as well,
> and all extensions should follow the order defined in Table 28.11:
> https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L141
>

I thought about that earlier as well. Zifencei & Zicsr was already
part of the ISA and carved out as an extension later.
Qemu/Any supervisor support that by default and won't work without
that. We can't possibly disable those and boot anything.

Do you think there is any benefit adding it ?


> "The table also defines the canonical order in which extension names must 
> appear in the name string,
> with top-to-bottom in table indicating first-to-last in the name string,
> e.g., RV32IMACV is legal, whereas RV32IMAVC is not."
>
> So the overall order would be:
> zicsr, zifencei, zfh, zfhmin, zfinx, zdinx, zba, zbb, zbc, zbs, zve32f, 
> zve64f, zhinx, zhinxmin, svinval, svnapot, svpbmt,
>
> Regards,
> Frank Chang
>
>>
>> +
>> +for (i = 0; i < ARRAY_SIZE(isa_edata_arr); i++) {
>> +if (isa_edata_arr[i].enabled) {
>> +new = g_strconcat(old, "_", isa_edata_arr[i].name, NULL);
>> +g_free(old);
>> +old = new;
>> +}
>> +}
>> +
>> +*isa_str = new;
>> +}
>> +
>>  char 

Re: [PATCH V7 19/29] vfio-pci: cpr part 1 (fd and dma)

[Alex Williamson]

On Thu, 10 Mar 2022 10:00:29 -0500
Steven Sistare  wrote:

> On 3/7/2022 5:16 PM, Alex Williamson wrote:
> > On Wed, 22 Dec 2021 11:05:24 -0800
> > Steve Sistare  wrote:
> >> @@ -1878,6 +1908,18 @@ static int vfio_init_container(VFIOContainer 
> >> *container, int group_fd,
> >>  {
> >>  int iommu_type, ret;
> >>  
> >> +/*
> >> + * If container is reused, just set its type and skip the ioctls, as 
> >> the
> >> + * container and group are already configured in the kernel.
> >> + * VFIO_TYPE1v2_IOMMU is the only type that supports reuse/cpr.
> >> + * If you ever add new types or spapr cpr support, kind reader, please
> >> + * also implement VFIO_GET_IOMMU.
> >> + */  
> > 
> > VFIO_CHECK_EXTENSION should be able to tell us this, right?  Maybe the
> > problem is that vfio_iommu_type1_check_extension() should actually base
> > some of the details on the instantiated vfio_iommu, ex.
> > 
> > switch (arg) {
> > case VFIO_TYPE1_IOMMU:
> > return (iommu && iommu->v2) ? 0 : 1;
> > case VFIO_UNMAP_ALL:
> > case VFIO_UPDATE_VADDR:
> > case VFIO_TYPE1v2_IOMMU:
> > return (iommu && !iommu->v2) ? 0 : 1;
> > case VFIO_TYPE1_NESTING_IOMMU:
> > return (iommu && !iommu->nesting) ? 0 : 1;
> > ...
> > 
> > We can't support v1 if we've already set a v2 container and vice versa.
> > There are probably some corner cases and compatibility to puzzle
> > through, but I wouldn't think we need a new ioctl to check this.  
> 
> That change makes sense, and may be worth while on its own merits, but does 
> not
> solve the problem, which is that qemu will not be able to infer iommu_type in
> the future if new types are added.  Given:
>   * a new kernel supporting shiny new TYPE1v3
>   * old qemu starts and selects TYPE1v2 in vfio_get_iommu_type because it has 
> no
> knowledge of v3
>   * live update to qemu which supports v3, which will be listed first in 
> vfio_get_iommu_type.
> 
> Then the new qemu has no way to infer iommu_type.  If it has code that makes 
> decisions based on iommu_type (eg, VFIO_SPAPR_TCE_v2_IOMMU in 
> vfio_container_region_add,
> or vfio_ram_block_discard_disable, or ...), then new qemu cannot function 
> correctly.
> 
> For that, VFIO_GET_IOMMU would be the cleanest solution, to be added the same 
> time our
> hypothetical future developer adds TYPE1v3.  The current inability to ask the 
> kernel
> "what are you" about a container feels like a bug to me.

Hmm, I don't think the kernel has an innate responsibility to remind
the user of a configuration that they've already made.  But I also
don't follow your TYPE1v3 example.  If we added such a type, I imagine
the switch would change to:

switch (arg)
case VFIO_TYPE1_IOMMU:
return (iommu && (iommu->v2 || iommu->v3) ? 0 : 1;
case VFIO_UNMAP_ALL:
case VFIO_UPDATE_VADDR:
return (iommu && !(iommu-v2 || iommu->v3) ? 0 : 1;
case VFIO_TYPE1v2_IOMMU:
return (iommu && !iommu-v2) ? 0 : 1;
case VFIO_TYPE1v3_IOMMU:
return (iommu && !iommu->v3) ? 0 : 1;
...

How would that not allow exactly the scenario described, ie. new QEMU
can see that old QEMU left it a v2 IOMMU.

...
> >> +
> >> +bool vfio_is_cpr_capable(VFIOContainer *container, Error **errp)
> >> +{
> >> +if (!ioctl(container->fd, VFIO_CHECK_EXTENSION, VFIO_UPDATE_VADDR) ||
> >> +!ioctl(container->fd, VFIO_CHECK_EXTENSION, VFIO_UNMAP_ALL)) {
> >> +error_setg(errp, "VFIO container does not support 
> >> VFIO_UPDATE_VADDR "
> >> + "or VFIO_UNMAP_ALL");
> >> +return false;
> >> +} else {
> >> +return true;
> >> +}
> >> +}  
> > 
> > We could have minimally used this where we assumed a TYPE1v2 container.  
> 
> Are you referring to vfio_init_container (discussed above)?
> Are you suggesting that, if reused is true, we validate those extensions are
> present, before setting iommu_type = VFIO_TYPE1v2_IOMMU?

Yeah, though maybe it's not sufficiently precise to be worthwhile given
the current kernel behavior.

> >> +
> >> +/*
> >> + * Verify that all containers support CPR, and unmap all dma vaddr's.
> >> + */
> >> +int vfio_cpr_save(Error **errp)
> >> +{
> >> +ERRP_GUARD();
> >> +VFIOAddressSpace *space;
> >> +VFIOContainer *container;
> >> +
> >> +QLIST_FOREACH(space, _address_spaces, list) {
> >> +QLIST_FOREACH(container, >containers, next) {
> >> +if (!vfio_is_cpr_capable(container, errp)) {
> >> +return -1;
> >> +}
> >> +if (vfio_dma_unmap_vaddr_all(container, errp)) {
> >> +return -1;
> >> +}
> >> +}
> >> +}  
> > 
> > Seems like we ought to validate all containers support CPR before we
> > start blasting vaddrs.  It looks like qmp_cpr_exec() simply returns if
> > this fails with no attempt to unwind!  Yikes!  Wouldn't 

[PATCH 3/9] avocado/ppc_405.py: remove test_ppc_taihu()

[Daniel Henrique Barboza]

Running this test gives us a deprecation warning telling that this
machine type is no longer supported:

Output: qemu-system-ppc: Machine type 'taihu' is deprecated:
incomplete, use 'ref405ep' instead

Moreover, this test fails to pass running in an IBM POWER host when
building QEMU with --disable-tcg.

Since the machine type is already being considered deprecated let's not
bother fixing the test with --disable-tcg. Remove test_ppc_taihu().

Signed-off-by: Daniel Henrique Barboza 
---
 tests/avocado/ppc_405.py | 8 
 1 file changed, 8 deletions(-)

diff --git a/tests/avocado/ppc_405.py b/tests/avocado/ppc_405.py
index a47f89b934..a69b7c5e97 100644
--- a/tests/avocado/ppc_405.py
+++ b/tests/avocado/ppc_405.py
@@ -25,14 +25,6 @@ def do_test_ppc405(self):
 wait_for_console_pattern(self, 'AMCC PPC405EP Evaluation Board')
 exec_command_and_wait_for_pattern(self, 'reset', 'AMCC PowerPC 405EP')
 
-def test_ppc_taihu(self):
-"""
-:avocado: tags=arch:ppc
-:avocado: tags=machine:taihu
-:avocado: tags=cpu:405ep
-"""
-self.do_test_ppc405()
-
 def test_ppc_ref405ep(self):
 """
 :avocado: tags=arch:ppc
-- 
2.35.1

[PATCH 9/9] avocado/ppc_virtex_ml507.py: check TCG accel in test_ppc_virtex_ml507()

[Daniel Henrique Barboza]

This test times out when running in an IBM POWER host and --disable-tcg.

Signed-off-by: Daniel Henrique Barboza 
---
 tests/avocado/ppc_virtex_ml507.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/avocado/ppc_virtex_ml507.py 
b/tests/avocado/ppc_virtex_ml507.py
index a6912ee579..6b07686b56 100644
--- a/tests/avocado/ppc_virtex_ml507.py
+++ b/tests/avocado/ppc_virtex_ml507.py
@@ -19,7 +19,9 @@ def test_ppc_virtex_ml507(self):
 """
 :avocado: tags=arch:ppc
 :avocado: tags=machine:virtex-ml507
+:avocado: tags=accel:tcg
 """
+self.require_accelerator("tcg")
 tar_url = ('https://www.qemu-advent-calendar.org'
'/2020/download/hippo.tar.gz')
 tar_hash = '306b95bfe7d147f125aa176a877e266db8ef914a'
-- 
2.35.1

[PATCH 2/9] avocado/boot_linux_console.py: check TCG accel in test_ppc_mac99()

[Daniel Henrique Barboza]

This test breaks when run in an IBM POWER host with a QEMU compiled
with --disable-tcg and the ppc-softmmu target in a similar manner as
test_ppc_g3beige did.

There's also an observation made about kvm_pr in the error message:

Command: ./qemu-system-ppc -display none -vga none (...)
-machine mac99 (...)
Output: ioctl(KVM_CREATE_VM) failed: 22 Invalid argument
PPC KVM module is not loaded. Try modprobe kvm_pr.
qemu-system-ppc: failed to initialize kvm: Invalid argument

This means that, when/if we're able to detect kvm_pr support in these
avocado tests, we can revisit this test to not rely solely on TCG
availability.

Signed-off-by: Daniel Henrique Barboza 
---
 tests/avocado/boot_linux_console.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tests/avocado/boot_linux_console.py 
b/tests/avocado/boot_linux_console.py
index 2f8d8e2fe6..b40a3abc81 100644
--- a/tests/avocado/boot_linux_console.py
+++ b/tests/avocado/boot_linux_console.py
@@ -1228,7 +1228,13 @@ def test_ppc_mac99(self):
 """
 :avocado: tags=arch:ppc
 :avocado: tags=machine:mac99
+:avocado: tags=accel:tcg
 """
+# TODO: mac99 works with kvm_pr but we don't have a
+# reliable way ATM (e.g. looking at /proc/modules) to detect
+# whether we're running kvm_hv or kvm_pr. For now let's
+# disable this test if we don't have TCG support.
+self.require_accelerator("tcg")
 tar_hash = 'e0b872a5eb8fdc5bed19bd43ffe863900ebcedfc'
 self.vm.add_args('-M', 'graphics=off')
 self.do_test_advcal_2018('15', tar_hash, 'invaders.elf')
-- 
2.35.1

[PATCH 8/9] avocado/ppc_prep_40p.py: check TCG accel in all tests

[Daniel Henrique Barboza]

All tests in the file times out when running in an IBM POWER host and
--disable-tcg with an error like the following:

Command: ./qemu-system-ppc -display none -vga none (...)
-machine 40p (...)
Output: qemu-system-ppc: Register sync failed... If you're using
kvm-hv.ko, only "-cpu host" is possible
qemu-system-ppc: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument

Since we don't have a way to detect whether the host is running kvm_hv
or kvm_pr, skip all tests if TCG is not available.

Signed-off-by: Daniel Henrique Barboza 
---
 tests/avocado/ppc_prep_40p.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tests/avocado/ppc_prep_40p.py b/tests/avocado/ppc_prep_40p.py
index 4bd956584d..d4f1eb7e1d 100644
--- a/tests/avocado/ppc_prep_40p.py
+++ b/tests/avocado/ppc_prep_40p.py
@@ -28,7 +28,9 @@ def test_factory_firmware_and_netbsd(self):
 :avocado: tags=machine:40p
 :avocado: tags=os:netbsd
 :avocado: tags=slowness:high
+:avocado: tags=accel:tcg
 """
+self.require_accelerator("tcg")
 bios_url = ('http://ftpmirror.your.org/pub/misc/'
 'ftp.software.ibm.com/rs6000/firmware/'
 '7020-40p/P12H0456.IMG')
@@ -51,7 +53,9 @@ def test_openbios_192m(self):
 """
 :avocado: tags=arch:ppc
 :avocado: tags=machine:40p
+:avocado: tags=accel:tcg
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.add_args('-m', '192') # test fw_cfg
 
@@ -65,7 +69,9 @@ def test_openbios_and_netbsd(self):
 :avocado: tags=arch:ppc
 :avocado: tags=machine:40p
 :avocado: tags=os:netbsd
+:avocado: tags=accel:tcg
 """
+self.require_accelerator("tcg")
 drive_url = ('https://archive.netbsd.org/pub/NetBSD-archive/'
  'NetBSD-7.1.2/iso/NetBSD-7.1.2-prep.iso')
 drive_hash = 'ac6fa2707d888b36d6fa64de6e7fe48e'
-- 
2.35.1

[PATCH 6/9] avocado/ppc_bamboo.py: check TCG accel in test_ppc_bamboo()

[Daniel Henrique Barboza]

This tests times out in an IBM POWER host when compiled with
--disable-tcg.

Signed-off-by: Daniel Henrique Barboza 
---
 tests/avocado/ppc_bamboo.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/avocado/ppc_bamboo.py b/tests/avocado/ppc_bamboo.py
index 40629e3478..102ff252df 100644
--- a/tests/avocado/ppc_bamboo.py
+++ b/tests/avocado/ppc_bamboo.py
@@ -20,7 +20,9 @@ def test_ppc_bamboo(self):
 :avocado: tags=machine:bamboo
 :avocado: tags=cpu:440epb
 :avocado: tags=device:rtl8139
+:avocado: tags=accel:tcg
 """
+self.require_accelerator("tcg")
 tar_url = ('http://landley.net/aboriginal/downloads/binaries/'
'system-image-powerpc-440fp.tar.gz')
 tar_hash = '53e5f16414b195b82d2c70272f81c2eedb39bad9'
-- 
2.35.1

[PATCH 1/9] avocado/boot_linux_console.py: check TCG accel in test_ppc_g3beige()

[Daniel Henrique Barboza]

This test breaks when run in an IBM POWER host with a QEMU compiled
with --disable-tcg and the ppc-softmmu target.

One thing to note is that the error message explictly mentions kvm_pr
support:

Command: ./qemu-system-ppc -display none -vga none (...)
-machine g3beige (...)
Output: ioctl(KVM_CREATE_VM) failed: 22 Invalid argument
PPC KVM module is not loaded. Try modprobe kvm_pr.
qemu-system-ppc: failed to initialize kvm: Invalid argument

The host was running kvm_hv, not kvm_pr, and the machine failed to load.

Unfortunately we don't have a way to detect whether the KVM module loaded
is kvm_hv or kvm_pr - we do a check for /dev/kvm to detect KVM support but
both modules create this file so that's not helpful.

Let's skip this test for now until we have a way of detecting kvm_pr support in 
the host.

Reported-by: Murilo Opsfelder Araujo 
Signed-off-by: Daniel Henrique Barboza 
---
 tests/avocado/boot_linux_console.py | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tests/avocado/boot_linux_console.py 
b/tests/avocado/boot_linux_console.py
index 6d6e748572..2f8d8e2fe6 100644
--- a/tests/avocado/boot_linux_console.py
+++ b/tests/avocado/boot_linux_console.py
@@ -1213,7 +1213,13 @@ def test_ppc_g3beige(self):
 """
 :avocado: tags=arch:ppc
 :avocado: tags=machine:g3beige
+:avocado: tags=accel:tcg
 """
+# TODO: g3beige works with kvm_pr but we don't have a
+# reliable way ATM (e.g. looking at /proc/modules) to detect
+# whether we're running kvm_hv or kvm_pr. For now let's
+# disable this test if we don't have TCG support.
+self.require_accelerator("tcg")
 tar_hash = 'e0b872a5eb8fdc5bed19bd43ffe863900ebcedfc'
 self.vm.add_args('-M', 'graphics=off')
 self.do_test_advcal_2018('15', tar_hash, 'invaders.elf')
-- 
2.35.1

[PATCH 7/9] avocado/ppc_mpc8544ds.py: check TCG accel in test_ppc_mpc8544ds()

[Daniel Henrique Barboza]

This tests times out in an IBM POWER host when compiled with
--disable-tcg.

Signed-off-by: Daniel Henrique Barboza 
---
 tests/avocado/ppc_mpc8544ds.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/avocado/ppc_mpc8544ds.py b/tests/avocado/ppc_mpc8544ds.py
index 886f967b15..8d6a749201 100644
--- a/tests/avocado/ppc_mpc8544ds.py
+++ b/tests/avocado/ppc_mpc8544ds.py
@@ -19,7 +19,9 @@ def test_ppc_mpc8544ds(self):
 """
 :avocado: tags=arch:ppc
 :avocado: tags=machine:mpc8544ds
+:avocado: tags=accel:tcg
 """
+self.require_accelerator("tcg")
 tar_url = ('https://www.qemu-advent-calendar.org'
'/2020/download/day17.tar.gz')
 tar_hash = '7a5239542a7c4257aa4d3b7f6ddf08fb6775c494'
-- 
2.35.1

[PATCH 5/9] avocado/ppc_74xx.py: check TCG accel for all tests

[Daniel Henrique Barboza]

All tests of this file, when running in an IBM POWER host and with
--disable-tcg, fail in a similar manner:

Command: ./qemu-system-ppc -display none -vga none (...)
-cpu 7400 (...)
Output: ioctl(KVM_CREATE_VM) failed: 22 Invalid argument
PPC KVM module is not loaded. Try modprobe kvm_pr.
qemu-system-ppc: failed to initialize kvm: Invalid argument

We don't have a way of telling which KVM module is loaded in a Power
host (kvm_hv or kvm_pr). For now let's make all the tests of this
file depend on TCG support.

Signed-off-by: Daniel Henrique Barboza 
---
 tests/avocado/ppc_74xx.py | 13 +
 1 file changed, 13 insertions(+)

diff --git a/tests/avocado/ppc_74xx.py b/tests/avocado/ppc_74xx.py
index 556a9a7da9..f54757c243 100644
--- a/tests/avocado/ppc_74xx.py
+++ b/tests/avocado/ppc_74xx.py
@@ -11,6 +11,7 @@
 class ppc74xxCpu(QemuSystemTest):
 """
 :avocado: tags=arch:ppc
+:avocado: tags=accel:tcg
 """
 timeout = 5
 
@@ -18,6 +19,7 @@ def test_ppc_7400(self):
 """
 :avocado: tags=cpu:7400
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -27,6 +29,7 @@ def test_ppc_7410(self):
 """
 :avocado: tags=cpu:7410
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -36,6 +39,7 @@ def test_ppc_7441(self):
 """
 :avocado: tags=cpu:7441
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -45,6 +49,7 @@ def test_ppc_7445(self):
 """
 :avocado: tags=cpu:7445
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -54,6 +59,7 @@ def test_ppc_7447(self):
 """
 :avocado: tags=cpu:7447
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -63,6 +69,7 @@ def test_ppc_7447a(self):
 """
 :avocado: tags=cpu:7447a
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -72,6 +79,7 @@ def test_ppc_7448(self):
 """
 :avocado: tags=cpu:7448
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -81,6 +89,7 @@ def test_ppc_7450(self):
 """
 :avocado: tags=cpu:7450
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -90,6 +99,7 @@ def test_ppc_7451(self):
 """
 :avocado: tags=cpu:7451
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -99,6 +109,7 @@ def test_ppc_7455(self):
 """
 :avocado: tags=cpu:7455
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -108,6 +119,7 @@ def test_ppc_7457(self):
 """
 :avocado: tags=cpu:7457
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
@@ -117,6 +129,7 @@ def test_ppc_7457a(self):
 """
 :avocado: tags=cpu:7457a
 """
+self.require_accelerator("tcg")
 self.vm.set_console()
 self.vm.launch()
 wait_for_console_pattern(self, '>> OpenBIOS')
-- 
2.35.1

[PATCH 4/9] avocado/ppc_405.py: check TCG accel in test_ppc_ref405ep()

[Daniel Henrique Barboza]

Running this test without TCG support in an IBM POWER server results
in the following error:

Command: ./qemu-system-ppc -display none -vga none (...)
-machine ref405ep (...)
Output: qemu-system-ppc: Register sync failed... If you're using
kvm-hv.ko, only "-cpu host" is possible
qemu-system-ppc: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument

Although the host is running kvm_hv we don't have a way of differentiate
between kvm_hv and kvm_pr, meaning that this test would've failed in the
same way if kvm_pr was the KVM module loaded in the host.

Since we don't have a way of checking which KVM module is being loaded
when using avocado, make a TCG accel check in test_ppc_ref405ep().

Signed-off-by: Daniel Henrique Barboza 
---
 tests/avocado/ppc_405.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/avocado/ppc_405.py b/tests/avocado/ppc_405.py
index a69b7c5e97..4e7e01aa76 100644
--- a/tests/avocado/ppc_405.py
+++ b/tests/avocado/ppc_405.py
@@ -30,5 +30,7 @@ def test_ppc_ref405ep(self):
 :avocado: tags=arch:ppc
 :avocado: tags=machine:ref405ep
 :avocado: tags=cpu:405ep
+:avocado: tags=accel:tcg
 """
+self.require_accelerator("tcg")
 self.do_test_ppc405()
-- 
2.35.1

[PATCH 0/9] --disable-tcg avocado fixes for ppc-softmmu

[Daniel Henrique Barboza]

Hi,

These are more test fixes that I missed from my first series [1]. Thanks
Murilo Opsfelder and Fabiano for letting me know that we still had broken
tests to deal with.

All these tests were either a case of 'this needs kvm_pr' or 'this needs
kvm_hv'. Since avocado doesn't have yet a way of detecting if the host
is running kvm_hv or kvm_pr, the workaround for now is to skip them if
TCG isn't available.

[1] https://lists.gnu.org/archive/html/qemu-devel/2022-03/msg00866.html


Daniel Henrique Barboza (9):
  avocado/boot_linux_console.py: check TCG accel in test_ppc_g3beige()
  avocado/boot_linux_console.py: check TCG accel in test_ppc_mac99()
  avocado/ppc_405.py: remove test_ppc_taihu()
  avocado/ppc_405.py: check TCG accel in test_ppc_ref405ep()
  avocado/ppc_74xx.py: check TCG accel for all tests
  avocado/ppc_bamboo.py: check TCG accel in test_ppc_bamboo()
  avocado/ppc_mpc8544ds.py: check TCG accel in test_ppc_mpc8544ds()
  avocado/ppc_prep_40p.py: check TCG accel in all tests
  avocado/ppc_virtex_ml507.py: check TCG accel in
test_ppc_virtex_ml507()

 tests/avocado/boot_linux_console.py | 12 
 tests/avocado/ppc_405.py| 10 ++
 tests/avocado/ppc_74xx.py   | 13 +
 tests/avocado/ppc_bamboo.py |  2 ++
 tests/avocado/ppc_mpc8544ds.py  |  2 ++
 tests/avocado/ppc_prep_40p.py   |  6 ++
 tests/avocado/ppc_virtex_ml507.py   |  2 ++
 7 files changed, 39 insertions(+), 8 deletions(-)

-- 
2.35.1

Re: [PATCH V7 10/29] machine: memfd-alloc option

[Steven Sistare]

On 3/10/2022 12:28 PM, Steven Sistare wrote:
> On 3/10/2022 11:00 AM, Igor Mammedov wrote:
>> On Thu, 10 Mar 2022 10:36:08 -0500
>> Steven Sistare  wrote:
>>
>>> On 3/8/2022 2:20 AM, Igor Mammedov wrote:
 On Tue, 8 Mar 2022 01:50:11 -0500
 "Michael S. Tsirkin"  wrote:
   
> On Mon, Mar 07, 2022 at 09:41:44AM -0500, Steven Sistare wrote:  
>> On 3/4/2022 5:41 AM, Igor Mammedov wrote:
>>> On Thu, 3 Mar 2022 12:21:15 -0500
>>> "Michael S. Tsirkin"  wrote:
>>> 
 On Wed, Dec 22, 2021 at 11:05:15AM -0800, Steve Sistare wrote:
> Allocate anonymous memory using memfd_create if the memfd-alloc 
> machine
> option is set.
>
> Signed-off-by: Steve Sistare 
> ---
>  hw/core/machine.c   | 19 +++
>  include/hw/boards.h |  1 +
>  qemu-options.hx |  6 ++
>  softmmu/physmem.c   | 47 
> ++-
>  softmmu/vl.c|  1 +
>  trace-events|  1 +
>  util/qemu-config.c  |  4 
>  7 files changed, 70 insertions(+), 9 deletions(-)
>
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index 53a99ab..7739d88 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -392,6 +392,20 @@ static void machine_set_mem_merge(Object *obj, 
> bool value, Error **errp)
>  ms->mem_merge = value;
>  }
>  
> +static bool machine_get_memfd_alloc(Object *obj, Error **errp)
> +{
> +MachineState *ms = MACHINE(obj);
> +
> +return ms->memfd_alloc;
> +}
> +
> +static void machine_set_memfd_alloc(Object *obj, bool value, Error 
> **errp)
> +{
> +MachineState *ms = MACHINE(obj);
> +
> +ms->memfd_alloc = value;
> +}
> +
>  static bool machine_get_usb(Object *obj, Error **errp)
>  {
>  MachineState *ms = MACHINE(obj);
> @@ -829,6 +843,11 @@ static void machine_class_init(ObjectClass *oc, 
> void *data)
>  object_class_property_set_description(oc, "mem-merge",
>  "Enable/disable memory merge support");
>  
> +object_class_property_add_bool(oc, "memfd-alloc",
> +machine_get_memfd_alloc, machine_set_memfd_alloc);
> +object_class_property_set_description(oc, "memfd-alloc",
> +"Enable/disable allocating anonymous memory using 
> memfd_create");
> +
>  object_class_property_add_bool(oc, "usb",
>  machine_get_usb, machine_set_usb);
>  object_class_property_set_description(oc, "usb",
> diff --git a/include/hw/boards.h b/include/hw/boards.h
> index 9c1c190..a57d7a0 100644
> --- a/include/hw/boards.h
> +++ b/include/hw/boards.h
> @@ -327,6 +327,7 @@ struct MachineState {
>  char *dt_compatible;
>  bool dump_guest_core;
>  bool mem_merge;
> +bool memfd_alloc;
>  bool usb;
>  bool usb_disabled;
>  char *firmware;
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 7d47510..33c8173 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -30,6 +30,7 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
>  "vmport=on|off|auto controls emulation of vmport 
> (default: auto)\n"
>  "dump-guest-core=on|off include guest memory in 
> a core dump (default=on)\n"
>  "mem-merge=on|off controls memory merge support 
> (default: on)\n"
> +"memfd-alloc=on|off controls allocating 
> anonymous guest RAM using memfd_create (default: off)\n"  

 Question: are there any disadvantages associated with using
 memfd_create? I guess we are using up an fd, but that seems minor.  Any
 reason not to set to on by default? maybe with a fallback option to
 disable that?
>>
>> Old Linux host kernels, circa 4.1, do not support huge pages for shared 
>> memory.
>> Also, the tunable to enable huge pages for share memory is different 
>> than for
>> anon memory, so there could be performance loss if it is not set 
>> correctly.
>> /sys/kernel/mm/transparent_hugepage/enabled
>> vs
>> /sys/kernel/mm/transparent_hugepage/shmem_enabled
>
> I guess we can test this when launching the VM, and select
> a good default.
>  
>> It might make sense to use memfd_create by default for the secondary 
>> segments.
>
> Well there's also KSM now you mention it.  

 then another quest, is there downside to 

Re: [PATCH v3] target/arm: Fix sve2 ldnt1 and stnt1

[Peter Maydell]

On Tue, 8 Mar 2022 at 11:56, Peter Maydell  wrote:
>
> Anyway
> Reviewed-by: Peter Maydell 

...and applied to target-arm.next.

-- PMM

Re: [PATCH v4 01/18] ppc/xive2: Introduce a XIVE2 core framework

[Thomas Huth]

On 28/02/2022 16.52, Cédric Le Goater wrote:

The XIVE2 interrupt controller of the POWER10 processor as the same
logic as on POWER9 but its SW interface has been largely reworked. The
interrupt controller has a new register interface, different BARs,
extra VSDs. These will be described when we add the device model for
the baremetal machine.

The XIVE internal structures for the EAS, END, NVT have different
layouts which is a problem for the current core XIVE framework. To
avoid adding too much complexity in the XIVE models, a new XIVE2 core
framework is introduced. It duplicates the models which are closely
linked to the XIVE internal structures : Xive2Router and
Xive2ENDSource and reuses the XiveSource, XivePresenter, XiveTCTX
models, as they are more generic.

Reviewed-by: Daniel Henrique Barboza 
Signed-off-by: Cédric Le Goater 
---

[...]

+static Property xive2_end_source_properties[] = {
+DEFINE_PROP_UINT32("nr-ends", Xive2EndSource, nr_ends, 0),
+DEFINE_PROP_UINT32("shift", Xive2EndSource, esb_shift, XIVE_ESB_64K),
+DEFINE_PROP_LINK("xive", Xive2EndSource, xrtr, TYPE_XIVE2_ROUTER,
+ Xive2Router *),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void xive2_end_source_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->desc= "XIVE END Source";
+device_class_set_props(dc, xive2_end_source_properties);
+dc->realize = xive2_end_source_realize;
+}
+
+static const TypeInfo xive2_end_source_info = {
+.name  = TYPE_XIVE2_END_SOURCE,
+.parent= TYPE_DEVICE,
+.instance_size = sizeof(Xive2EndSource),
+.class_init= xive2_end_source_class_init,
+};


This device can be used to crash QEMU:

$ ./qemu-system-ppc64 -nographic  -device xive2-end-source
qemu-system-ppc64: ../../devel/qemu/hw/intc/xive2.c:966: 
xive2_end_source_realize: Assertion `xsrc->xrtr' failed.

Aborted (core dumped)

Should it be user_creatable = false ?

 Thomas

Re: [PATCH-for-6.2 0/2] hw/block/fdc: Fix CVE-2021-3507

[Jon Maloy]

On 3/10/22 12:14, Thomas Huth wrote:

On 06/02/2022 20.19, Jon Maloy wrote:

Trying again with correct email address.
///jon

On 2/6/22 14:15, Jon Maloy wrote:



On 1/27/22 15:14, Jon Maloy wrote:


On 11/18/21 06:57, Philippe Mathieu-Daudé wrote:

Trivial fix for CVE-2021-3507.

Philippe Mathieu-Daudé (2):
   hw/block/fdc: Prevent end-of-track overrun (CVE-2021-3507)
   tests/qtest/fdc-test: Add a regression test for CVE-2021-3507

  hw/block/fdc.c |  8 
  tests/qtest/fdc-test.c | 20 
  2 files changed, 28 insertions(+)


Series
Acked-by: Jon Maloy 


Philippe,
I hear from other sources that you earlier have qualified this one 
as "incomplete".
I am of course aware that this one, just like my own patch, is just 
a mitigation and not a complete correction of the erroneous 
calculation.

Or did you have anything else in mind?


Any news on this one? It would be nice to get the CVE fixed for 7.0 ?

 Thomas


The ball is currently with John Snow, as I understand it.
The concern is that this fix may not take the driver back to a 
consistent state, so that we may have other problems later.

Maybe Philippe can chip in with a comment here?

///jon

Re: [PATCH v5 14/48] target/nios2: Use hw/registerfields.h for CR_EXCEPTION fields

[Richard Henderson]

On 3/10/22 04:26, Peter Maydell wrote:

+FIELD(CR_EXCEPTION, CAUSE, 2, 5)
+FIELD(CR_EXCEPTION, ECCFTL, 31, 1)
+


Is this definitely the right bit for ECCFTL? The copy of
the manual I have has "ECCFTL" as an extra bit to the left of
bit 31 (!). I'm guessing that's a docs formatting error, though...


I assumed the same thing, obviously.  I could perhaps have left this out, since it seems 
unlikely that anyone will care about the ECC feature with qemu...



r~

Re: [PATCH] tests/avocado: Cancel BootLinux tests in case there is no free port

[Cleber Rosa]

Thomas Huth  writes:

> The BootLinux tests are currently failing with an ugly python
> stack trace on my RHEL8 system since they cannot get a free port
> (likely due to the firewall settings on my system). Let's properly
> check the return value of find_free_port() instead and cancel the
> test gracefully if it cannot get a free port.
>
> Signed-off-by: Thomas Huth 
> ---
>  Unfortunately, it still takes > 70 seconds for each and every
>  tests from tests/avocado/boot_linux.py to get canceled, so
>  tests/avocado/boot_linux.py still renders "make check-avocado"
>  for me pretty unusable... looking at the implementation of
>  find_free_port() in Avocado, I wonder whether there isn't a
>  better way to get a free port number in Python? Brute-forcing
>  all ports between 1024 and 65536 seems just quite cumbersome
>  to me...
>
>  tests/avocado/avocado_qemu/__init__.py | 2 ++
>  1 file changed, 2 insertions(+)
>

LGTM, despite  the root issue is being addressed in Avocado.

Reviewed-by: Cleber Rosa 

Re: [PATCH v3 1/4] target/ppc: Fix masked PVR matching

[Cédric Le Goater]

Hello Nick,

On 3/7/22 07:55, Nicholas Piggin wrote:

The pvr_match for a CPU class is not supposed to just match for any
CPU in the family, but rather whether this particular CPU class is the
best match in the family.

Prior to this fix, e.g., a POWER9 DD2.3 KVM host matches to the
power9_v1.0 class (because that's first in the list). After the patch,
it matches the power9_v2.0 class.

Fixes: 03ae4133ab8 ("target-ppc: Add pvr_match() callback")
Signed-off-by: Nicholas Piggin > ---
  target/ppc/cpu_init.c | 51 ---
  1 file changed, 34 insertions(+), 17 deletions(-)

make check-qtest-ppc64 fails with :

―― ✀  
――
stderr:
qemu-system-ppc64: invalid CPU model 'power8nvl_v1.0-powerpc64-cpu' for 
powernv8 machine
Broken pipe


TAP parsing error: Too few tests run (expected 6, got 1)
(test program exited with status code -6)


# QTEST_QEMU_BINARY=build/ppc64-softmmu/qemu-system-ppc64 
QTEST_QEMU_IMG=qemu-img build/tests/qtest/pnv-xscom-test
1..6
# Start of ppc64 tests
# Start of pnv-xscom tests
# Start of cfam_id tests
# starting QEMU: exec build/ppc64-softmmu/qemu-system-ppc64 -qtest 
unix:/tmp/qtest-2994797.sock -qtest-log /dev/null -chardev 
socket,path=/tmp/qtest-2994797.qmp,id=char0 -mon chardev=char0,mode=control 
-display none -M powernv8 -accel tcg -cpu POWER8 -accel qtest
ok 1 /ppc64/pnv-xscom/cfam_id/POWER8
# starting QEMU: exec build/ppc64-softmmu/qemu-system-ppc64 -qtest 
unix:/tmp/qtest-2994797.sock -qtest-log /dev/null -chardev 
socket,path=/tmp/qtest-2994797.qmp,id=char0 -mon chardev=char0,mode=control 
-display none -M powernv8 -accel tcg -cpu POWER8NVL -accel qtest
qemu-system-ppc64: invalid CPU model 'power8nvl_v1.0-powerpc64-cpu' for 
powernv8 machine
Broken pipe
Aborted (core dumped)


Thanks,

C.

Re: [PATCH experiment 00/35] stackless coroutine backend

[Stefan Hajnoczi]

On Thu, Mar 10, 2022 at 01:43:38PM +0100, Paolo Bonzini wrote:
> Here is an experiment with using stackless coroutines in QEMU.  It
> only compiles enough code to run tests/unit/test-coroutine, but at
> least it proves that it's possible to quickly test ideas in the
> area of coroutine runtimes.  Another idea that could be toyed with
> in a similar manner could be (whoa) C++ coroutines.
> 
> As expected, this also found some issues in existing code, so I
> plan to submit patches 1-5 separately.
> 
> The new backend (which is the only one that works, due to the required
> code changes) is in patch 7.  For the big description of what stackless
> coroutines are, please refer to that patch.
> 
> Patches 8-11 do some initial conversions.  Patch 12 introduce some
> preprocessor magic that greatly eases the rest of the work, and then
> the tests are converted one at a time, until patch 27 where the only
> ones missing are the CoRwlock tests.
> 
> Therefore, patches 28-33 convert CoRwlock and pathces 34-35 take care
> of the corresponding tests, thus concluding the experiment.

Nice, the transformation is clear. It's simpler than Continuation
Passing Style transform because the loops and if statements remain
unmodified. This is a big advantage with the Duff's device-style
approach.

There are a lot of details to decide on in the translator tool and
runtime to optimize the code. I think the way the stack frames are
organized in this patch series is probably for convenience rather than
performance.

Out of curiousity, did you run the perf tests and compare against
ucontext?

Stefan


signature.asc
Description: PGP signature

Re: [PATCH V7 10/29] machine: memfd-alloc option

[Steven Sistare]

On 3/10/2022 11:00 AM, Igor Mammedov wrote:
> On Thu, 10 Mar 2022 10:36:08 -0500
> Steven Sistare  wrote:
> 
>> On 3/8/2022 2:20 AM, Igor Mammedov wrote:
>>> On Tue, 8 Mar 2022 01:50:11 -0500
>>> "Michael S. Tsirkin"  wrote:
>>>   
 On Mon, Mar 07, 2022 at 09:41:44AM -0500, Steven Sistare wrote:  
> On 3/4/2022 5:41 AM, Igor Mammedov wrote:
>> On Thu, 3 Mar 2022 12:21:15 -0500
>> "Michael S. Tsirkin"  wrote:
>> 
>>> On Wed, Dec 22, 2021 at 11:05:15AM -0800, Steve Sistare wrote:
 Allocate anonymous memory using memfd_create if the memfd-alloc machine
 option is set.

 Signed-off-by: Steve Sistare 
 ---
  hw/core/machine.c   | 19 +++
  include/hw/boards.h |  1 +
  qemu-options.hx |  6 ++
  softmmu/physmem.c   | 47 
 ++-
  softmmu/vl.c|  1 +
  trace-events|  1 +
  util/qemu-config.c  |  4 
  7 files changed, 70 insertions(+), 9 deletions(-)

 diff --git a/hw/core/machine.c b/hw/core/machine.c
 index 53a99ab..7739d88 100644
 --- a/hw/core/machine.c
 +++ b/hw/core/machine.c
 @@ -392,6 +392,20 @@ static void machine_set_mem_merge(Object *obj, 
 bool value, Error **errp)
  ms->mem_merge = value;
  }
  
 +static bool machine_get_memfd_alloc(Object *obj, Error **errp)
 +{
 +MachineState *ms = MACHINE(obj);
 +
 +return ms->memfd_alloc;
 +}
 +
 +static void machine_set_memfd_alloc(Object *obj, bool value, Error 
 **errp)
 +{
 +MachineState *ms = MACHINE(obj);
 +
 +ms->memfd_alloc = value;
 +}
 +
  static bool machine_get_usb(Object *obj, Error **errp)
  {
  MachineState *ms = MACHINE(obj);
 @@ -829,6 +843,11 @@ static void machine_class_init(ObjectClass *oc, 
 void *data)
  object_class_property_set_description(oc, "mem-merge",
  "Enable/disable memory merge support");
  
 +object_class_property_add_bool(oc, "memfd-alloc",
 +machine_get_memfd_alloc, machine_set_memfd_alloc);
 +object_class_property_set_description(oc, "memfd-alloc",
 +"Enable/disable allocating anonymous memory using 
 memfd_create");
 +
  object_class_property_add_bool(oc, "usb",
  machine_get_usb, machine_set_usb);
  object_class_property_set_description(oc, "usb",
 diff --git a/include/hw/boards.h b/include/hw/boards.h
 index 9c1c190..a57d7a0 100644
 --- a/include/hw/boards.h
 +++ b/include/hw/boards.h
 @@ -327,6 +327,7 @@ struct MachineState {
  char *dt_compatible;
  bool dump_guest_core;
  bool mem_merge;
 +bool memfd_alloc;
  bool usb;
  bool usb_disabled;
  char *firmware;
 diff --git a/qemu-options.hx b/qemu-options.hx
 index 7d47510..33c8173 100644
 --- a/qemu-options.hx
 +++ b/qemu-options.hx
 @@ -30,6 +30,7 @@ DEF("machine", HAS_ARG, QEMU_OPTION_machine, \
  "vmport=on|off|auto controls emulation of vmport 
 (default: auto)\n"
  "dump-guest-core=on|off include guest memory in a 
 core dump (default=on)\n"
  "mem-merge=on|off controls memory merge support 
 (default: on)\n"
 +"memfd-alloc=on|off controls allocating anonymous 
 guest RAM using memfd_create (default: off)\n"  
>>>
>>> Question: are there any disadvantages associated with using
>>> memfd_create? I guess we are using up an fd, but that seems minor.  Any
>>> reason not to set to on by default? maybe with a fallback option to
>>> disable that?
>
> Old Linux host kernels, circa 4.1, do not support huge pages for shared 
> memory.
> Also, the tunable to enable huge pages for share memory is different than 
> for
> anon memory, so there could be performance loss if it is not set 
> correctly.
> /sys/kernel/mm/transparent_hugepage/enabled
> vs
> /sys/kernel/mm/transparent_hugepage/shmem_enabled

 I guess we can test this when launching the VM, and select
 a good default.
  
> It might make sense to use memfd_create by default for the secondary 
> segments.

 Well there's also KSM now you mention it.  
>>>
>>> then another quest, is there downside to always using memfd_create
>>> without any knobs being involved?  
>>
>> Lower performance if small pages are used (but Michael suggests qemu could 
>> automatically check the 

Re: [PATCH-for-7.0] tulip: Assign default MAC address if not specified

[Philippe Mathieu-Daudé]

On 10/3/22 17:55, Helge Deller wrote:

The MAC of the tulip card is stored in the EEPROM and at startup
tulip_fill_eeprom() is called to initialize the EEPROM with the MAC
address given on the command line, e.g.:
 -device tulip,mac=00:11:22:33:44:55

In case the mac address was not given on the command line,
tulip_fill_eeprom() initializes the MAC in EEPROM with 00:00:00:00:00:00
which breaks e.g. a HP-UX guest.

Fix this problem by moving qemu_macaddr_default_if_unset() a few lines
up, so that a default mac address is assigned before tulip_fill_eeprom()
initializes the EEPROM.

Signed-off-by: Helge Deller 


Reviewed-by: Philippe Mathieu-Daudé 


diff --git a/hw/net/tulip.c b/hw/net/tulip.c
index d5b6cc5ee6..097e905bec 100644
--- a/hw/net/tulip.c
+++ b/hw/net/tulip.c
@@ -967,6 +967,8 @@ static void pci_tulip_realize(PCIDevice *pci_dev, Error 
**errp)
  pci_conf = s->dev.config;
  pci_conf[PCI_INTERRUPT_PIN] = 1; /* interrupt pin A */

+qemu_macaddr_default_if_unset(>c.macaddr);
+
  s->eeprom = eeprom93xx_new(_dev->qdev, 64);
  tulip_fill_eeprom(s);

@@ -981,8 +983,6 @@ static void pci_tulip_realize(PCIDevice *pci_dev, Error 
**errp)

  s->irq = pci_allocate_irq(>dev);

-qemu_macaddr_default_if_unset(>c.macaddr);
-
  s->nic = qemu_new_nic(_tulip_info, >c,
object_get_typename(OBJECT(pci_dev)),
pci_dev->qdev.id, s);

[PATCH] target/ppc: fix xxspltw for big endian hosts

[matheus . ferst]

From: Matheus Ferst 

Fix a typo in the host endianness macro and add a simple test to detect
regressions.

Fixes: 9bb0048ec6f8 ("target/ppc: convert xxspltw to vector operations")
Signed-off-by: Matheus Ferst 
---
 target/ppc/translate/vsx-impl.c.inc |  2 +-
 tests/tcg/ppc64/Makefile.target |  1 +
 tests/tcg/ppc64le/Makefile.target   |  1 +
 tests/tcg/ppc64le/xxspltw.c | 46 +
 4 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100644 tests/tcg/ppc64le/xxspltw.c

diff --git a/target/ppc/translate/vsx-impl.c.inc 
b/target/ppc/translate/vsx-impl.c.inc
index 48a97b2d7e..e67fbf2bb8 100644
--- a/target/ppc/translate/vsx-impl.c.inc
+++ b/target/ppc/translate/vsx-impl.c.inc
@@ -1552,7 +1552,7 @@ static bool trans_XXSPLTW(DisasContext *ctx, arg_XX2_uim2 
*a)
 tofs = vsr_full_offset(a->xt);
 bofs = vsr_full_offset(a->xb);
 bofs += a->uim << MO_32;
-#ifndef HOST_WORDS_BIG_ENDIAN
+#ifndef HOST_WORDS_BIGENDIAN
 bofs ^= 8 | 4;
 #endif
 
diff --git a/tests/tcg/ppc64/Makefile.target b/tests/tcg/ppc64/Makefile.target
index c9498053df..8197c288a7 100644
--- a/tests/tcg/ppc64/Makefile.target
+++ b/tests/tcg/ppc64/Makefile.target
@@ -27,5 +27,6 @@ run-sha512-vector: QEMU_OPTS+=-cpu POWER10
 run-plugin-sha512-vector-with-%: QEMU_OPTS+=-cpu POWER10
 
 PPC64_TESTS += signal_save_restore_xer
+PPC64_TESTS += xxspltw
 
 TESTS += $(PPC64_TESTS)
diff --git a/tests/tcg/ppc64le/Makefile.target 
b/tests/tcg/ppc64le/Makefile.target
index 12d85e946b..9624bb1e9c 100644
--- a/tests/tcg/ppc64le/Makefile.target
+++ b/tests/tcg/ppc64le/Makefile.target
@@ -25,5 +25,6 @@ run-plugin-sha512-vector-with-%: QEMU_OPTS+=-cpu POWER10
 
 PPC64LE_TESTS += mtfsf
 PPC64LE_TESTS += signal_save_restore_xer
+PPC64LE_TESTS += xxspltw
 
 TESTS += $(PPC64LE_TESTS)
diff --git a/tests/tcg/ppc64le/xxspltw.c b/tests/tcg/ppc64le/xxspltw.c
new file mode 100644
index 00..def7321f14
--- /dev/null
+++ b/tests/tcg/ppc64le/xxspltw.c
@@ -0,0 +1,46 @@
+#include 
+#include 
+#include 
+#include 
+
+#define WORD_A 0xUL
+#define WORD_B 0xUL
+#define WORD_C 0xUL
+#define WORD_D 0xUL
+
+#define DWORD_HI (WORD_A << 32 | WORD_B)
+#define DWORD_LO (WORD_C << 32 | WORD_D)
+
+#define TEST(HI, LO, UIM, RES) \
+do {\
+union { \
+uint64_t u; \
+double f;   \
+} h = { .u = HI }, l = { .u = LO }; \
+/*  \
+ * Use a pair of FPRs to load the VSR avoiding insns\
+ * newer than xxswapd.  \
+ */ \
+asm("xxmrghd 32, %0, %1\n\t"\
+"xxspltw 32, 32, %2\n\t"\
+"xxmrghd %0, 32, %0\n\t"\
+"xxswapd 32, 32\n\t"\
+"xxmrghd %1, 32, %1\n\t"\
+: "+f" (h.f), "+f" (l.f)\
+: "i" (UIM) \
+: "v0");\
+printf("xxspltw(0x%016" PRIx64 "%016" PRIx64 ", %d) ="  \
+   " %016" PRIx64 "%016" PRIx64 "\n", HI, LO, UIM,  \
+   h.u, l.u);   \
+assert(h.u == (RES));   \
+assert(l.u == (RES));   \
+} while (0)
+
+int main(void)
+{
+TEST(DWORD_HI, DWORD_LO, 0, WORD_A << 32 | WORD_A);
+TEST(DWORD_HI, DWORD_LO, 1, WORD_B << 32 | WORD_B);
+TEST(DWORD_HI, DWORD_LO, 2, WORD_C << 32 | WORD_C);
+TEST(DWORD_HI, DWORD_LO, 3, WORD_D << 32 | WORD_D);
+return 0;
+}
-- 
2.25.1

[PATCH v2 16/18] tests: add multifd migration tests of TLS with PSK credentials

[Daniel P . Berrangé]

This validates that we correctly handle multifd migration success
and failure scenarios when using TLS with pre shared keys.

Signed-off-by: Daniel P. Berrangé 
---
 tests/qtest/migration-test.c | 60 +---
 1 file changed, 56 insertions(+), 4 deletions(-)

diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index c1b0b3aca4..f47e4797e2 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -1815,6 +1815,48 @@ static void test_multifd_tcp_zstd(void)
 }
 #endif
 
+#ifdef CONFIG_GNUTLS
+static void *
+test_migrate_multifd_tcp_tls_psk_start_match(QTestState *from,
+ QTestState *to)
+{
+test_migrate_precopy_tcp_multifd_start_common(from, to, "none");
+return test_migrate_tls_psk_start_match(from, to);
+}
+
+static void *
+test_migrate_multifd_tcp_tls_psk_start_mismatch(QTestState *from,
+QTestState *to)
+{
+test_migrate_precopy_tcp_multifd_start_common(from, to, "none");
+return test_migrate_tls_psk_start_mismatch(from, to);
+}
+
+static void test_multifd_tcp_tls_psk_match(void)
+{
+MigrateCommon args = {
+.listen_uri = "defer",
+.start_hook = test_migrate_multifd_tcp_tls_psk_start_match,
+.finish_hook = test_migrate_tls_psk_finish,
+};
+test_precopy_common();
+}
+
+static void test_multifd_tcp_tls_psk_mismatch(void)
+{
+MigrateCommon args = {
+.start = {
+.hide_stderr = true,
+},
+.listen_uri = "defer",
+.start_hook = test_migrate_multifd_tcp_tls_psk_start_mismatch,
+.finish_hook = test_migrate_tls_psk_finish,
+.result = MIG_TEST_FAIL,
+};
+test_precopy_common();
+}
+#endif /* CONFIG_GNUTLS */
+
 /*
  * This test does:
  *  source   target
@@ -2025,12 +2067,22 @@ int main(int argc, char **argv)
test_validate_uuid_dst_not_set);
 
 qtest_add_func("/migration/auto_converge", test_migrate_auto_converge);
-qtest_add_func("/migration/multifd/tcp/none", test_multifd_tcp_none);
-qtest_add_func("/migration/multifd/tcp/cancel", test_multifd_tcp_cancel);
-qtest_add_func("/migration/multifd/tcp/zlib", test_multifd_tcp_zlib);
+qtest_add_func("/migration/multifd/tcp/plain/none",
+   test_multifd_tcp_none);
+qtest_add_func("/migration/multifd/tcp/plain/cancel",
+   test_multifd_tcp_cancel);
+qtest_add_func("/migration/multifd/tcp/plain/zlib",
+   test_multifd_tcp_zlib);
 #ifdef CONFIG_ZSTD
-qtest_add_func("/migration/multifd/tcp/zstd", test_multifd_tcp_zstd);
+qtest_add_func("/migration/multifd/tcp/plain/zstd",
+   test_multifd_tcp_zstd);
 #endif
+#ifdef CONFIG_GNUTLS
+qtest_add_func("/migration/multifd/tcp/tls/psk/match",
+   test_multifd_tcp_tls_psk_match);
+qtest_add_func("/migration/multifd/tcp/tls/psk/mismatch",
+   test_multifd_tcp_tls_psk_mismatch);
+#endif /* CONFIG_GNUTLS */
 
 if (kvm_dirty_ring_supported()) {
 qtest_add_func("/migration/dirty_ring",
-- 
2.34.1

[PATCH v2 04/18] tests: print newline after QMP response in qtest logs

[Daniel P . Berrangé]

The QMP commands have a trailing newline, but the response does not.
This makes the qtest logs hard to follow as the next QMP command
appears in the same line as the previous QMP response.

Reviewed-by: Thomas Huth 
Signed-off-by: Daniel P. Berrangé 
---
 tests/qtest/libqtest.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/qtest/libqtest.c b/tests/qtest/libqtest.c
index a85f8a6d05..d5b6558876 100644
--- a/tests/qtest/libqtest.c
+++ b/tests/qtest/libqtest.c
@@ -625,10 +625,13 @@ QDict *qmp_fd_receive(int fd)
 }
 
 if (log) {
-len = write(2, , 1);
+g_assert(write(2, , 1) == 1);
 }
 json_message_parser_feed(, , 1);
 }
+if (log) {
+g_assert(write(2, "\n", 1) == 1);
+}
 json_message_parser_destroy();
 
 return qmp.response;
-- 
2.34.1

[PATCH v2 18/18] tests: ensure migration status isn't reported as failed

[Daniel P . Berrangé]

Various methods in the migration test call 'query_migrate' to fetch the
current status and then access a particular field. Almost all of these
cases expect the migration to be in a non-failed state. In the case of
'wait_for_migration_pass' in particular, if the status is 'failed' then
it will get into an infinite loop. By validating that the status is
not 'failed' the test suite will assert rather than hang when getting
into an unexpected state.

Reviewed-by: Peter Xu 
Signed-off-by: Daniel P. Berrangé 
---
 tests/qtest/migration-helpers.c | 13 +
 tests/qtest/migration-helpers.h |  1 +
 tests/qtest/migration-test.c|  6 +++---
 3 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/tests/qtest/migration-helpers.c b/tests/qtest/migration-helpers.c
index 4ee26014b7..a6aa59e4e6 100644
--- a/tests/qtest/migration-helpers.c
+++ b/tests/qtest/migration-helpers.c
@@ -107,6 +107,19 @@ QDict *migrate_query(QTestState *who)
 return wait_command(who, "{ 'execute': 'query-migrate' }");
 }
 
+QDict *migrate_query_not_failed(QTestState *who)
+{
+const char *status;
+QDict *rsp = migrate_query(who);
+status = qdict_get_str(rsp, "status");
+if (g_str_equal(status, "failed")) {
+g_printerr("query-migrate shows failed migration: %s\n",
+   qdict_get_str(rsp, "error-desc"));
+}
+g_assert(!g_str_equal(status, "failed"));
+return rsp;
+}
+
 /*
  * Note: caller is responsible to free the returned object via
  * g_free() after use
diff --git a/tests/qtest/migration-helpers.h b/tests/qtest/migration-helpers.h
index d63bba9630..b710ece67e 100644
--- a/tests/qtest/migration-helpers.h
+++ b/tests/qtest/migration-helpers.h
@@ -26,6 +26,7 @@ GCC_FMT_ATTR(3, 4)
 void migrate_qmp(QTestState *who, const char *uri, const char *fmt, ...);
 
 QDict *migrate_query(QTestState *who);
+QDict *migrate_query_not_failed(QTestState *who);
 
 void wait_for_migration_status(QTestState *who,
const char *goal, const char **ungoals);
diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index 5ea0b9360a..d9f444ea14 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -181,7 +181,7 @@ static int64_t read_ram_property_int(QTestState *who, const 
char *property)
 QDict *rsp_return, *rsp_ram;
 int64_t result;
 
-rsp_return = migrate_query(who);
+rsp_return = migrate_query_not_failed(who);
 if (!qdict_haskey(rsp_return, "ram")) {
 /* Still in setup */
 result = 0;
@@ -198,7 +198,7 @@ static int64_t read_migrate_property_int(QTestState *who, 
const char *property)
 QDict *rsp_return;
 int64_t result;
 
-rsp_return = migrate_query(who);
+rsp_return = migrate_query_not_failed(who);
 result = qdict_get_try_int(rsp_return, property, 0);
 qobject_unref(rsp_return);
 return result;
@@ -213,7 +213,7 @@ static void read_blocktime(QTestState *who)
 {
 QDict *rsp_return;
 
-rsp_return = migrate_query(who);
+rsp_return = migrate_query_not_failed(who);
 g_assert(qdict_haskey(rsp_return, "postcopy-blocktime"));
 qobject_unref(rsp_return);
 }
-- 
2.34.1

[PATCH v2 07/18] tests: switch MigrateStart struct to be stack allocated

[Daniel P . Berrangé]

There's no compelling reason why the MigrateStart struct needs to be
heap allocated. Using stack allocation and static initializers is
simpler.

Signed-off-by: Daniel P. Berrangé 
---
 tests/qtest/migration-test.c | 134 +++
 1 file changed, 56 insertions(+), 78 deletions(-)

diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index 0870656d82..36e5408702 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -474,28 +474,12 @@ typedef struct {
 bool only_target;
 /* Use dirty ring if true; dirty logging otherwise */
 bool use_dirty_ring;
-char *opts_source;
-char *opts_target;
+const char *opts_source;
+const char *opts_target;
 } MigrateStart;
 
-static MigrateStart *migrate_start_new(void)
-{
-MigrateStart *args = g_new0(MigrateStart, 1);
-
-args->opts_source = g_strdup("");
-args->opts_target = g_strdup("");
-return args;
-}
-
-static void migrate_start_destroy(MigrateStart *args)
-{
-g_free(args->opts_source);
-g_free(args->opts_target);
-g_free(args);
-}
-
 static int test_migrate_start(QTestState **from, QTestState **to,
-  const char *uri, MigrateStart **pargs)
+  const char *uri, MigrateStart *args)
 {
 g_autofree gchar *arch_source = NULL;
 g_autofree gchar *arch_target = NULL;
@@ -507,15 +491,12 @@ static int test_migrate_start(QTestState **from, 
QTestState **to,
 g_autofree char *shmem_path = NULL;
 const char *arch = qtest_get_arch();
 const char *machine_opts = NULL;
-MigrateStart *args = *pargs;
 const char *memory_size;
-int ret = 0;
 
 if (args->use_shmem) {
 if (!g_file_test("/dev/shm", G_FILE_TEST_IS_DIR)) {
 g_test_skip("/dev/shm is not supported");
-ret = -1;
-goto out;
+return -1;
 }
 }
 
@@ -591,7 +572,8 @@ static int test_migrate_start(QTestState **from, QTestState 
**to,
  machine_opts ? " -machine " : "",
  machine_opts ? machine_opts : "",
  memory_size, tmpfs,
- arch_source, shmem_opts, args->opts_source,
+ arch_source, shmem_opts,
+ args->opts_source ? args->opts_source : "",
  ignore_stderr);
 if (!args->only_target) {
 *from = qtest_init(cmd_source);
@@ -609,7 +591,8 @@ static int test_migrate_start(QTestState **from, QTestState 
**to,
  machine_opts ? machine_opts : "",
  memory_size, tmpfs, uri,
  arch_target, shmem_opts,
- args->opts_target, ignore_stderr);
+ args->opts_target ? args->opts_target : "",
+ ignore_stderr);
 *to = qtest_init(cmd_target);
 
 /*
@@ -620,11 +603,7 @@ static int test_migrate_start(QTestState **from, 
QTestState **to,
 unlink(shmem_path);
 }
 
-out:
-migrate_start_destroy(args);
-/* This tells the caller that this structure is gone */
-*pargs = NULL;
-return ret;
+return 0;
 }
 
 static void test_migrate_end(QTestState *from, QTestState *to, bool test_dest)
@@ -668,7 +647,7 @@ static int migrate_postcopy_prepare(QTestState **from_ptr,
 g_autofree char *uri = g_strdup_printf("unix:%s/migsocket", tmpfs);
 QTestState *from, *to;
 
-if (test_migrate_start(, , uri, )) {
+if (test_migrate_start(, , uri, args)) {
 return -1;
 }
 
@@ -712,10 +691,10 @@ static void migrate_postcopy_complete(QTestState *from, 
QTestState *to)
 
 static void test_postcopy(void)
 {
-MigrateStart *args = migrate_start_new();
+MigrateStart args = {};
 QTestState *from, *to;
 
-if (migrate_postcopy_prepare(, , args)) {
+if (migrate_postcopy_prepare(, , )) {
 return;
 }
 migrate_postcopy_start(from, to);
@@ -724,13 +703,13 @@ static void test_postcopy(void)
 
 static void test_postcopy_recovery(void)
 {
-MigrateStart *args = migrate_start_new();
+MigrateStart args = {
+.hide_stderr = true,
+};
 QTestState *from, *to;
 g_autofree char *uri = NULL;
 
-args->hide_stderr = true;
-
-if (migrate_postcopy_prepare(, , args)) {
+if (migrate_postcopy_prepare(, , )) {
 return;
 }
 
@@ -786,11 +765,11 @@ static void test_postcopy_recovery(void)
 
 static void test_baddest(void)
 {
-MigrateStart *args = migrate_start_new();
+MigrateStart args = {
+.hide_stderr = true
+};
 QTestState *from, *to;
 
-args->hide_stderr = true;
-
 if (test_migrate_start(, , "tcp:127.0.0.1:0", )) {
 return;
 }
@@ -802,11 +781,11 @@ static void test_baddest(void)
 static void test_precopy_unix_common(bool 

[PATCH v2 15/18] tests: convert multifd migration tests to use common helper

[Daniel P . Berrangé]

Most of the multifd migration test logic is common with the rest of the
precopy tests, so it can use the helper without difficulty. The only
exception of the multifd cancellation test which tries to run multiple
migrations in a row.

Signed-off-by: Daniel P. Berrangé 
---
 tests/qtest/migration-test.c | 77 +++-
 1 file changed, 40 insertions(+), 37 deletions(-)

diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index 043ae94089..c1b0b3aca4 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -1739,26 +1739,12 @@ static void test_migrate_auto_converge(void)
 test_migrate_end(from, to, true);
 }
 
-static void test_multifd_tcp(const char *method)
+static void *
+test_migrate_precopy_tcp_multifd_start_common(QTestState *from,
+  QTestState *to,
+  const char *method)
 {
-MigrateStart args = {};
-QTestState *from, *to;
 QDict *rsp;
-g_autofree char *uri = NULL;
-
-if (test_migrate_start(, , "defer", )) {
-return;
-}
-
-/*
- * We want to pick a speed slow enough that the test completes
- * quickly, but that it doesn't complete precopy even on a slow
- * machine, so also set the downtime.
- */
-/* 1 ms should make it not converge*/
-migrate_set_parameter_int(from, "downtime-limit", 1);
-/* 1GB/s */
-migrate_set_parameter_int(from, "max-bandwidth", 10);
 
 migrate_set_parameter_int(from, "multifd-channels", 16);
 migrate_set_parameter_int(to, "multifd-channels", 16);
@@ -1774,41 +1760,58 @@ static void test_multifd_tcp(const char *method)
"  'arguments': { 'uri': 'tcp:127.0.0.1:0' }}");
 qobject_unref(rsp);
 
-/* Wait for the first serial output from the source */
-wait_for_serial("src_serial");
-
-uri = migrate_get_socket_address(to, "socket-address");
-
-migrate_qmp(from, uri, "{}");
-
-wait_for_migration_pass(from);
+return NULL;
+}
 
-migrate_set_parameter_int(from, "downtime-limit", CONVERGE_DOWNTIME);
+static void *
+test_migrate_precopy_tcp_multifd_start(QTestState *from,
+   QTestState *to)
+{
+return test_migrate_precopy_tcp_multifd_start_common(from, to, "none");
+}
 
-if (!got_stop) {
-qtest_qmp_eventwait(from, "STOP");
-}
-qtest_qmp_eventwait(to, "RESUME");
+static void *
+test_migrate_precopy_tcp_multifd_zlib_start(QTestState *from,
+QTestState *to)
+{
+return test_migrate_precopy_tcp_multifd_start_common(from, to, "zlib");
+}
 
-wait_for_serial("dest_serial");
-wait_for_migration_complete(from);
-test_migrate_end(from, to, true);
+#ifdef CONFIG_ZSTD
+static void *
+test_migrate_precopy_tcp_multifd_zstd_start(QTestState *from,
+QTestState *to)
+{
+return test_migrate_precopy_tcp_multifd_start_common(from, to, "zstd");
 }
+#endif /* CONFIG_ZSTD */
 
 static void test_multifd_tcp_none(void)
 {
-test_multifd_tcp("none");
+MigrateCommon args = {
+.listen_uri = "defer",
+.start_hook = test_migrate_precopy_tcp_multifd_start,
+};
+test_precopy_common();
 }
 
 static void test_multifd_tcp_zlib(void)
 {
-test_multifd_tcp("zlib");
+MigrateCommon args = {
+.listen_uri = "defer",
+.start_hook = test_migrate_precopy_tcp_multifd_zlib_start,
+};
+test_precopy_common();
 }
 
 #ifdef CONFIG_ZSTD
 static void test_multifd_tcp_zstd(void)
 {
-test_multifd_tcp("zstd");
+MigrateCommon args = {
+.listen_uri = "defer",
+.start_hook = test_migrate_precopy_tcp_multifd_zstd_start,
+};
+test_precopy_common();
 }
 #endif
 
-- 
2.34.1

[PATCH v2 11/18] tests: expand the migration precopy helper to support failures

[Daniel P . Berrangé]

The migration precopy testing helper function always expects the
migration to run to a completion state. There will be test scenarios
for TLS where expect either the client or server to fail the migration.
This expands the helper to cope with these scenarios.

Signed-off-by: Daniel P. Berrangé 
---
 tests/qtest/migration-test.c | 51 +---
 1 file changed, 42 insertions(+), 9 deletions(-)

diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index 04f749aaa1..2af36c16a3 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -821,6 +821,30 @@ typedef struct {
 TestMigrateStartHook start_hook;
 /* Optional: callback to run at finish to cleanup */
 TestMigrateFinishHook finish_hook;
+
+/*
+ * Optional: normally we expect the migration process to complete.
+ *
+ * There can be a variety of reasons and stages in which failure
+ * can happen during tests.
+ *
+ * If a failure is expected to happen at time of establishing
+ * the connection, then MIG_TEST_FAIL will indicate that the dst
+ * QEMU is expected to stay running and accept future migration
+ * connections.
+ *
+ * If a failure is expected to happen while processing the
+ * migration stream, then MIG_TEST_FAIL_DEST_QUIT_ERR will indicate
+ * that the dst QEMU is expected to quit with non-zero exit status
+ */
+enum {
+/* This test should succeed, the default */
+MIG_TEST_SUCCEED = 0,
+/* This test should fail, dest qemu should keep alive */
+MIG_TEST_FAIL,
+/* This test should fail, dest qemu should fail with abnormal status */
+MIG_TEST_FAIL_DEST_QUIT_ERR,
+} result;
 } MigrateCommon;
 
 static void test_precopy_common(MigrateCommon *args)
@@ -858,24 +882,33 @@ static void test_precopy_common(MigrateCommon *args)
 }
 
 
-wait_for_migration_pass(from);
+if (args->result != MIG_TEST_SUCCEED) {
+bool allow_active = args->result == MIG_TEST_FAIL;
+wait_for_migration_fail(from, allow_active);
 
-migrate_set_parameter_int(from, "downtime-limit", CONVERGE_DOWNTIME);
+if (args->result == MIG_TEST_FAIL_DEST_QUIT_ERR) {
+qtest_set_expected_status(to, 1);
+}
+} else {
+wait_for_migration_pass(from);
 
-if (!got_stop) {
-qtest_qmp_eventwait(from, "STOP");
-}
+migrate_set_parameter_int(from, "downtime-limit", CONVERGE_DOWNTIME);
 
-qtest_qmp_eventwait(to, "RESUME");
+if (!got_stop) {
+qtest_qmp_eventwait(from, "STOP");
+}
 
-wait_for_serial("dest_serial");
-wait_for_migration_complete(from);
+qtest_qmp_eventwait(to, "RESUME");
+
+wait_for_serial("dest_serial");
+wait_for_migration_complete(from);
+}
 
 if (args->finish_hook) {
 args->finish_hook(from, to, data_hook);
 }
 
-test_migrate_end(from, to, true);
+test_migrate_end(from, to, args->result == MIG_TEST_SUCCEED);
 }
 
 static void test_precopy_unix(void)
-- 
2.34.1

[PATCH v2 17/18] tests: add multifd migration tests of TLS with x509 credentials

[Daniel P . Berrangé]

This validates that we correctly handle multifd migration success
and failure scenarios when using TLS with x509 certificates. There
are quite a few different scenarios that matter in relation to
hostname validation, but we skip a couple as we can assume that
the non-multifd coverage applies to some extent.

Signed-off-by: Daniel P. Berrangé 
---
 tests/qtest/migration-test.c | 127 +++
 1 file changed, 127 insertions(+)

diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index f47e4797e2..5ea0b9360a 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -1832,6 +1832,48 @@ 
test_migrate_multifd_tcp_tls_psk_start_mismatch(QTestState *from,
 return test_migrate_tls_psk_start_mismatch(from, to);
 }
 
+#ifdef CONFIG_TASN1
+static void *
+test_migrate_multifd_tls_x509_start_default_host(QTestState *from,
+ QTestState *to)
+{
+test_migrate_precopy_tcp_multifd_start_common(from, to, "none");
+return test_migrate_tls_x509_start_default_host(from, to);
+}
+
+static void *
+test_migrate_multifd_tls_x509_start_override_host(QTestState *from,
+  QTestState *to)
+{
+test_migrate_precopy_tcp_multifd_start_common(from, to, "none");
+return test_migrate_tls_x509_start_override_host(from, to);
+}
+
+static void *
+test_migrate_multifd_tls_x509_start_mismatch_host(QTestState *from,
+  QTestState *to)
+{
+test_migrate_precopy_tcp_multifd_start_common(from, to, "none");
+return test_migrate_tls_x509_start_mismatch_host(from, to);
+}
+
+static void *
+test_migrate_multifd_tls_x509_start_allow_anon_client(QTestState *from,
+  QTestState *to)
+{
+test_migrate_precopy_tcp_multifd_start_common(from, to, "none");
+return test_migrate_tls_x509_start_allow_anon_client(from, to);
+}
+
+static void *
+test_migrate_multifd_tls_x509_start_reject_anon_client(QTestState *from,
+   QTestState *to)
+{
+test_migrate_precopy_tcp_multifd_start_common(from, to, "none");
+return test_migrate_tls_x509_start_reject_anon_client(from, to);
+}
+#endif /* CONFIG_TASN1 */
+
 static void test_multifd_tcp_tls_psk_match(void)
 {
 MigrateCommon args = {
@@ -1855,6 +1897,79 @@ static void test_multifd_tcp_tls_psk_mismatch(void)
 };
 test_precopy_common();
 }
+
+#ifdef CONFIG_TASN1
+static void test_multifd_tcp_tls_x509_default_host(void)
+{
+MigrateCommon args = {
+.listen_uri = "defer",
+.start_hook = test_migrate_multifd_tls_x509_start_default_host,
+.finish_hook = test_migrate_tls_x509_finish,
+};
+test_precopy_common();
+}
+
+static void test_multifd_tcp_tls_x509_override_host(void)
+{
+MigrateCommon args = {
+.listen_uri = "defer",
+.start_hook = test_migrate_multifd_tls_x509_start_override_host,
+.finish_hook = test_migrate_tls_x509_finish,
+};
+test_precopy_common();
+}
+
+static void test_multifd_tcp_tls_x509_mismatch_host(void)
+{
+/*
+ * This has different behaviour to the non-multifd case.
+ *
+ * In non-multifd case when client aborts due to mismatched
+ * cert host, the server has already started trying to load
+ * migration state, and so it exits with I/O  failure.
+ *
+ * In multifd case when client aborts due to mismatched
+ * cert host, the server is still waiting for the other
+ * multifd connections to arrive so hasn't started trying
+ * to load migration state, and thus just aborts the migration
+ * without exiting
+ */
+MigrateCommon args = {
+.start = {
+.hide_stderr = true,
+},
+.listen_uri = "defer",
+.start_hook = test_migrate_multifd_tls_x509_start_mismatch_host,
+.finish_hook = test_migrate_tls_x509_finish,
+.result = MIG_TEST_FAIL,
+};
+test_precopy_common();
+}
+
+static void test_multifd_tcp_tls_x509_allow_anon_client(void)
+{
+MigrateCommon args = {
+.listen_uri = "defer",
+.start_hook = test_migrate_multifd_tls_x509_start_allow_anon_client,
+.finish_hook = test_migrate_tls_x509_finish,
+};
+test_precopy_common();
+}
+
+static void test_multifd_tcp_tls_x509_reject_anon_client(void)
+{
+MigrateCommon args = {
+.start = {
+.hide_stderr = true,
+},
+.listen_uri = "defer",
+.start_hook = test_migrate_multifd_tls_x509_start_reject_anon_client,
+.finish_hook = test_migrate_tls_x509_finish,
+.result = MIG_TEST_FAIL,
+};
+test_precopy_common();
+}
+#endif /* CONFIG_TASN1 */
 #endif /* CONFIG_GNUTLS */
 
 /*
@@ -2082,6 +2197,18 @@ int main(int argc, char **argv)
test_multifd_tcp_tls_psk_match);
 

[PATCH v2 10/18] tests: switch migration FD passing test to use common precopy helper

[Daniel P . Berrangé]

The combination of the start and finish hooks allow the FD passing
code to use the precopy helper

Signed-off-by: Daniel P. Berrangé 
---
 tests/qtest/migration-test.c | 57 +---
 1 file changed, 21 insertions(+), 36 deletions(-)

diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index ae40429798..04f749aaa1 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -1002,31 +1002,12 @@ static void test_precopy_tcp(void)
 test_precopy_common();
 }
 
-static void test_migrate_fd_proto(void)
+static void *test_migrate_fd_start_hook(QTestState *from,
+QTestState *to)
 {
-MigrateStart args = {};
-QTestState *from, *to;
+QDict *rsp;
 int ret;
 int pair[2];
-QDict *rsp;
-const char *error_desc;
-
-if (test_migrate_start(, , "defer", )) {
-return;
-}
-
-/*
- * We want to pick a speed slow enough that the test completes
- * quickly, but that it doesn't complete precopy even on a slow
- * machine, so also set the downtime.
- */
-/* 1 ms should make it not converge */
-migrate_set_parameter_int(from, "downtime-limit", 1);
-/* 1GB/s */
-migrate_set_parameter_int(from, "max-bandwidth", 10);
-
-/* Wait for the first serial output from the source */
-wait_for_serial("src_serial");
 
 /* Create two connected sockets for migration */
 ret = socketpair(PF_LOCAL, SOCK_STREAM, 0, pair);
@@ -1051,17 +1032,15 @@ static void test_migrate_fd_proto(void)
 qobject_unref(rsp);
 close(pair[1]);
 
-/* Start migration to the 2nd socket*/
-migrate_qmp(from, "fd:fd-mig", "{}");
-
-wait_for_migration_pass(from);
-
-migrate_set_parameter_int(from, "downtime-limit", CONVERGE_DOWNTIME);
+return NULL;
+}
 
-if (!got_stop) {
-qtest_qmp_eventwait(from, "STOP");
-}
-qtest_qmp_eventwait(to, "RESUME");
+static void test_migrate_fd_finish_hook(QTestState *from,
+QTestState *to,
+void *opaque)
+{
+QDict *rsp;
+const char *error_desc;
 
 /* Test closing fds */
 /* We assume, that QEMU removes named fd from its list,
@@ -1079,11 +1058,17 @@ static void test_migrate_fd_proto(void)
 error_desc = qdict_get_str(qdict_get_qdict(rsp, "error"), "desc");
 g_assert_cmpstr(error_desc, ==, "File descriptor named 'fd-mig' not 
found");
 qobject_unref(rsp);
+}
 
-/* Complete migration */
-wait_for_serial("dest_serial");
-wait_for_migration_complete(from);
-test_migrate_end(from, to, true);
+static void test_migrate_fd_proto(void)
+{
+MigrateCommon args = {
+.listen_uri = "defer",
+.connect_uri = "fd:fd-mig",
+.start_hook = test_migrate_fd_start_hook,
+.finish_hook = test_migrate_fd_finish_hook
+};
+test_precopy_common();
 }
 
 static void do_test_validate_uuid(MigrateStart *args, bool should_fail)
-- 
2.34.1

[PATCH v2 13/18] tests: add migration tests of TLS with x509 credentials

[Daniel P . Berrangé]

This validates that we correctly handle migration success and failure
scenarios when using TLS with x509 certificates. There are quite a few
different scenarios that matter in relation to hostname validation.

Signed-off-by: Daniel P. Berrangé 
---
 meson.build  |   1 +
 tests/qtest/meson.build  |   5 +
 tests/qtest/migration-test.c | 382 ++-
 3 files changed, 386 insertions(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index 2d6601467f..89c0283ebe 100644
--- a/meson.build
+++ b/meson.build
@@ -1562,6 +1562,7 @@ config_host_data.set('CONFIG_KEYUTILS', keyutils.found())
 config_host_data.set('CONFIG_GETTID', has_gettid)
 config_host_data.set('CONFIG_GNUTLS', gnutls.found())
 config_host_data.set('CONFIG_GNUTLS_CRYPTO', gnutls_crypto.found())
+config_host_data.set('CONFIG_TASN1', tasn1.found())
 config_host_data.set('CONFIG_GCRYPT', gcrypt.found())
 config_host_data.set('CONFIG_NETTLE', nettle.found())
 config_host_data.set('CONFIG_QEMU_PRIVATE_XTS', xts == 'private')
diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index 81e7b9d530..ce94380a08 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -281,6 +281,11 @@ tpmemu_files = ['tpm-emu.c', 'tpm-util.c', 'tpm-tests.c']
 migration_files = [files('migration-helpers.c')]
 if gnutls.found()
   migration_files += [files('../unit/crypto-tls-psk-helpers.c'), gnutls]
+
+  if tasn1.found()
+migration_files += [files('../unit/crypto-tls-x509-helpers.c',
+  '../unit/pkix_asn1_tab.c'), tasn1]
+  endif
 endif
 
 qtests = {
diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index f733aa352e..c730697f74 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -29,6 +29,9 @@
 #include "tests/migration/migration-test.h"
 #ifdef CONFIG_GNUTLS
 # include "tests/unit/crypto-tls-psk-helpers.h"
+# ifdef CONFIG_TASN1
+#  include "tests/unit/crypto-tls-x509-helpers.h"
+# endif /* CONFIG_TASN1 */
 #endif /* CONFIG_GNUTLS */
 
 /* For dirty ring test; so far only x86_64 is supported */
@@ -736,6 +739,234 @@ test_migrate_tls_psk_finish(QTestState *from,
 g_free(data->pskfile);
 g_free(data);
 }
+
+#ifdef CONFIG_TASN1
+typedef struct {
+char *workdir;
+char *keyfile;
+char *cacert;
+char *servercert;
+char *serverkey;
+char *clientcert;
+char *clientkey;
+} TestMigrateTLSX509Data;
+
+typedef struct {
+bool verifyclient;
+bool clientcert;
+bool hostileclient;
+bool authzclient;
+const char *certhostname;
+const char *certipaddr;
+} TestMigrateTLSX509;
+
+static void *
+test_migrate_tls_x509_start_common(QTestState *from,
+   QTestState *to,
+   TestMigrateTLSX509 *args)
+{
+TestMigrateTLSX509Data *data = g_new0(TestMigrateTLSX509Data, 1);
+QDict *rsp;
+
+data->workdir = g_strdup_printf("%s/tlscredsx5090", tmpfs);
+data->keyfile = g_strdup_printf("%s/key.pem", data->workdir);
+
+data->cacert = g_strdup_printf("%s/ca-cert.pem", data->workdir);
+data->serverkey = g_strdup_printf("%s/server-key.pem", data->workdir);
+data->servercert = g_strdup_printf("%s/server-cert.pem", data->workdir);
+if (args->clientcert) {
+data->clientkey = g_strdup_printf("%s/client-key.pem", data->workdir);
+data->clientcert = g_strdup_printf("%s/client-cert.pem", 
data->workdir);
+}
+
+mkdir(data->workdir, 0700);
+
+test_tls_init(data->keyfile);
+g_assert(link(data->keyfile, data->serverkey) == 0);
+if (args->clientcert) {
+g_assert(link(data->keyfile, data->clientkey) == 0);
+}
+
+TLS_ROOT_REQ_SIMPLE(cacertreq, data->cacert);
+if (args->clientcert) {
+TLS_CERT_REQ_SIMPLE_CLIENT(servercertreq, cacertreq,
+   args->hostileclient ?
+   QCRYPTO_TLS_TEST_CLIENT_HOSTILE_NAME :
+   QCRYPTO_TLS_TEST_CLIENT_NAME,
+   data->clientcert);
+}
+
+TLS_CERT_REQ_SIMPLE_SERVER(clientcertreq, cacertreq,
+   data->servercert,
+   args->certhostname,
+   args->certipaddr);
+
+rsp = wait_command(from,
+   "{ 'execute': 'object-add',"
+   "  'arguments': { 'qom-type': 'tls-creds-x509',"
+   " 'id': 'tlscredsx509client0',"
+   " 'endpoint': 'client',"
+   " 'dir': %s,"
+   " 'sanity-check': true,"
+   " 'verify-peer': true} }",
+   data->workdir);
+qobject_unref(rsp);
+migrate_set_parameter_str(from, "tls-creds", "tlscredsx509client0");
+if (args->certhostname) {
+

[PATCH v2 14/18] tests: convert XBZRLE migration test to use common helper

[Daniel P . Berrangé]

Most of the XBZRLE migration test logic is common with the rest of the
precopy tests, so it can use the helper with just one small tweak.

Signed-off-by: Daniel P. Berrangé 
---
 tests/qtest/migration-test.c | 67 ++--
 1 file changed, 25 insertions(+), 42 deletions(-)

diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
index c730697f74..043ae94089 100644
--- a/tests/qtest/migration-test.c
+++ b/tests/qtest/migration-test.c
@@ -1174,6 +1174,9 @@ typedef struct {
 /* This test should fail, dest qemu should fail with abnormal status */
 MIG_TEST_FAIL_DEST_QUIT_ERR,
 } result;
+
+/* Optional: set number of migration passes to wait for */
+unsigned int iterations;
 } MigrateCommon;
 
 static void test_precopy_common(MigrateCommon *args)
@@ -1219,7 +1222,13 @@ static void test_precopy_common(MigrateCommon *args)
 qtest_set_expected_status(to, 1);
 }
 } else {
-wait_for_migration_pass(from);
+if (args->iterations) {
+while (args->iterations--) {
+wait_for_migration_pass(from);
+}
+} else {
+wait_for_migration_pass(from);
+}
 
 migrate_set_parameter_int(from, "downtime-limit", CONVERGE_DOWNTIME);
 
@@ -1349,57 +1358,31 @@ static void test_ignore_shared(void)
 }
 #endif
 
-static void test_xbzrle(const char *uri)
+static void *
+test_migrate_xbzrle_start(QTestState *from,
+  QTestState *to)
 {
-MigrateStart args = {};
-QTestState *from, *to;
-
-if (test_migrate_start(, , uri, )) {
-return;
-}
-
-/*
- * We want to pick a speed slow enough that the test completes
- * quickly, but that it doesn't complete precopy even on a slow
- * machine, so also set the downtime.
- */
-/* 1 ms should make it not converge*/
-migrate_set_parameter_int(from, "downtime-limit", 1);
-/* 1GB/s */
-migrate_set_parameter_int(from, "max-bandwidth", 10);
-
 migrate_set_parameter_int(from, "xbzrle-cache-size", 33554432);
 
 migrate_set_capability(from, "xbzrle", true);
 migrate_set_capability(to, "xbzrle", true);
-/* Wait for the first serial output from the source */
-wait_for_serial("src_serial");
 
-migrate_qmp(from, uri, "{}");
-
-wait_for_migration_pass(from);
-/* Make sure we have 2 passes, so the xbzrle cache gets a workout */
-wait_for_migration_pass(from);
-
-/* 1000ms should converge */
-migrate_set_parameter_int(from, "downtime-limit", 1000);
-
-if (!got_stop) {
-qtest_qmp_eventwait(from, "STOP");
-}
-qtest_qmp_eventwait(to, "RESUME");
-
-wait_for_serial("dest_serial");
-wait_for_migration_complete(from);
-
-test_migrate_end(from, to, true);
+return NULL;
 }
 
-static void test_xbzrle_unix(void)
+static void test_precopy_unix_xbzrle(void)
 {
 g_autofree char *uri = g_strdup_printf("unix:%s/migsocket", tmpfs);
+MigrateCommon args = {
+.connect_uri = uri,
+.listen_uri = uri,
+
+.start_hook = test_migrate_xbzrle_start,
 
-test_xbzrle(uri);
+.iterations = 2,
+};
+
+test_precopy_common();
 }
 
 static void test_precopy_tcp_plain(void)
@@ -1993,6 +1976,7 @@ int main(int argc, char **argv)
 qtest_add_func("/migration/postcopy/recovery", test_postcopy_recovery);
 qtest_add_func("/migration/bad_dest", test_baddest);
 qtest_add_func("/migration/precopy/unix/plain", test_precopy_unix_plain);
+qtest_add_func("/migration/precopy/unix/xbzrle", test_precopy_unix_xbzrle);
 #ifdef CONFIG_GNUTLS
 qtest_add_func("/migration/precopy/unix/tls/psk",
test_precopy_unix_tls_psk);
@@ -2029,7 +2013,6 @@ int main(int argc, char **argv)
 #endif /* CONFIG_GNUTLS */
 
 /* qtest_add_func("/migration/ignore_shared", test_ignore_shared); */
-qtest_add_func("/migration/xbzrle/unix", test_xbzrle_unix);
 qtest_add_func("/migration/fd_proto", test_migrate_fd_proto);
 qtest_add_func("/migration/validate_uuid", test_validate_uuid);
 qtest_add_func("/migration/validate_uuid_error", test_validate_uuid_error);
-- 
2.34.1

[PATCH v2 00/18] tests: introduce testing coverage for TLS with migration

[Daniel P . Berrangé]

This significantly expands the migration test suite to cover testing
with TLS over TCP and UNIX sockets, with both PSK (pre shared keys)
and x509 credentials, and for both single and multifd scenarios.

It identified one bug in handling PSK credentials with UNIX sockets,
but other than that everything was operating as expected.

To minimize the impact on code duplication alopt of refactoring is
done of the migration tests to introduce a common helper for running
the migration process. The various tests mostly just have to provide
a callback to set a few parameters/capabilities before migration
starts, and sometimes a callback to cleanup or validate after
completion/failure.

There is one functional bugfix in patch 6, I would like to see
in 7.0. The rest is all test suite additions, and I don't mind
if they are in 7.0 or 7.1

Changed in v2:

  - Use structs to pass around most parameters
  - Hide expected errors from stderr

Daniel P. Berrangé (18):
  tests: fix encoding of IP addresses in x509 certs
  tests: improve error message when saving TLS PSK file fails
  tests: support QTEST_TRACE env variable
  tests: print newline after QMP response in qtest logs
  tests: add more helper macros for creating TLS x509 certs
  migration: fix use of TLS PSK credentials with a UNIX socket
  tests: switch MigrateStart struct to be stack allocated
  tests: merge code for UNIX and TCP migration pre-copy tests
  tests: introduce ability to provide hooks for migration precopy test
  tests: switch migration FD passing test to use common precopy helper
  tests: expand the migration precopy helper to support failures
  tests: add migration tests of TLS with PSK credentials
  tests: add migration tests of TLS with x509 credentials
  tests: convert XBZRLE migration test to use common helper
  tests: convert multifd migration tests to use common helper
  tests: add multifd migration tests of TLS with PSK credentials
  tests: add multifd migration tests of TLS with x509 credentials
  tests: ensure migration status isn't reported as failed

 meson.build  |1 +
 migration/tls.c  |4 -
 tests/qtest/libqtest.c   |   13 +-
 tests/qtest/meson.build  |   12 +-
 tests/qtest/migration-helpers.c  |   13 +
 tests/qtest/migration-helpers.h  |1 +
 tests/qtest/migration-test.c | 1208 +-
 tests/unit/crypto-tls-psk-helpers.c  |   20 +-
 tests/unit/crypto-tls-psk-helpers.h  |1 +
 tests/unit/crypto-tls-x509-helpers.c |   16 +-
 tests/unit/crypto-tls-x509-helpers.h |   53 ++
 tests/unit/test-crypto-tlssession.c  |   11 +-
 12 files changed, 1096 insertions(+), 257 deletions(-)

-- 
2.34.1