date:20211220


On 18/12/2021 12.43, Laurent Vivier wrote:

Signed-off-by: Laurent Vivier 
---
Based-On: <20211217143948.289995-1-coh...@redhat.com>

  hw/m68k/virt.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/hw/m68k/virt.c b/hw/m68k/virt.c
index 0efa4a45c7f4..78e926a55457 100644
--- a/hw/m68k/virt.c
+++ b/hw/m68k/virt.c
@@ -304,10 +304,17 @@ type_init(virt_machine_register_types)
  } \
  type_init(machvirt_machine_##major##_##minor##_init);
  
+static void virt_machine_7_0_options(MachineClass *mc)

+{
+}
+DEFINE_VIRT_MACHINE(7, 0, true)
+
  static void virt_machine_6_2_options(MachineClass *mc)
  {
+virt_machine_7_0_options(mc);
+compat_props_add(mc->compat_props, hw_compat_6_2, hw_compat_6_2_len);
  }
-DEFINE_VIRT_MACHINE(6, 2, true)
+DEFINE_VIRT_MACHINE(6, 2, false)
  
  static void virt_machine_6_1_options(MachineClass *mc)

  {



Reviewed-by: Thomas Huth

[PATCH] [RESEND] docs: Add spec of OVMF GUIDed table for SEV guests

2021-12-20 Thread Dov Murik

Add docs/specs/sev-guest-firmware.rst which describes the GUIDed table
in the end of OVMF's image which is parsed by QEMU, and currently used
to describe some values for SEV and SEV-ES guests.

Signed-off-by: Dov Murik 
---
 docs/specs/index.rst  |   1 +
 docs/specs/sev-guest-firmware.rst | 125 ++
 2 files changed, 126 insertions(+)
 create mode 100644 docs/specs/sev-guest-firmware.rst

diff --git a/docs/specs/index.rst b/docs/specs/index.rst
index ecc43896bb..2a35700fb3 100644
--- a/docs/specs/index.rst
+++ b/docs/specs/index.rst
@@ -18,3 +18,4 @@ guest hardware that is specific to QEMU.
acpi_mem_hotplug
acpi_pci_hotplug
acpi_nvdimm
+   sev-guest-firmware
diff --git a/docs/specs/sev-guest-firmware.rst 
b/docs/specs/sev-guest-firmware.rst
new file mode 100644
index 00..3f7f082df5
--- /dev/null
+++ b/docs/specs/sev-guest-firmware.rst
@@ -0,0 +1,125 @@
+
+QEMU/Guest Firmware Interface for AMD SEV and SEV-ES
+
+
+Overview
+
+
+The guest firmware image (OVMF) may contain some configuration entries
+which are used by QEMU before the guest launches.  These are listed in a
+GUIDed table at a known location in the firmware image.  QEMU parses
+this table when it loads the firmware image into memory, and then QEMU
+reads individual entries when their values are needed.
+
+Though nothing in the table structure is SEV-specific, currently all the
+entries in the table are related to SEV and SEV-ES features.
+
+
+Table parsing in QEMU
+-
+
+The table is parsed from the footer: first the presence of the table
+footer GUID (96b582de-1fb2-45f7-baea-a366c55a082d) at 0xffd0 is
+verified.  If that is found, two bytes at 0xffce are the entire
+table length.
+
+Then the table is scanned backwards looking for the specific entry GUID.
+
+QEMU files related to parsing and scanning the OVMF table:
+ - ``hw/i386/pc_sysfw_ovmf.c``
+
+The edk2 firmware code that constructs this structure is in the
+`OVMF Reset Vector file`_.
+
+
+Table memory layout
+---
+
++++-+
+|GPA | Length |   Description   |
++++=+
+| 0xff80 | 4  | Zero padding|
++++-+
+| 0xff84 | 4  | SEV hashes table base address   |
++++-+
+| 0xff88 | 4  | SEV hashes table size (=0x400)  |
++++-+
+| 0xff8c | 2  | SEV hashes table entry length (=0x1a)   |
++++-+
+| 0xff8e | 16 | SEV hashes table GUID:  |
+||| 7255371f-3a3b-4b04-927b-1da6efa8d454|
++++-+
+| 0xff9e | 4  | SEV secret block base address   |
++++-+
+| 0xffa2 | 4  | SEV secret block size (=0xc00)  |
++++-+
+| 0xffa6 | 2  | SEV secret block entry length (=0x1a)   |
++++-+
+| 0xffa8 | 16 | SEV secret block GUID:  |
+||| 4c2eb361-7d9b-4cc3-8081-127c90d3d294|
++++-+
+| 0xffb8 | 4  | SEV-ES AP reset RIP |
++++-+
+| 0xffbc | 2  | SEV-ES reset block entry length (=0x16) |
++++-+
+| 0xffbe | 16 | SEV-ES reset block entry GUID:  |
+||| 00f771de-1a7e-4fcb-890e-68c77e2fb44e|
++++-+
+| 0xffce | 2  | Length of entire table including table  |
+||| footer GUID and length (=0x72)  |
++++-+
+| 0xffd0 | 16 | OVMF GUIDed table footer GUID:  |
+||| 96b582de-1fb2-45f7-baea-a366c55a082d|
++++-+
+| 0xffe0 | 8  | Application processor entry point code  |
++++-+
+| 0xffe8 | 8  | "\0\0\0\0VTF\0" |
++++-+
+| 0xfff0 | 16 | Reset vector code   |
++++-+
+
+
+T

[PULL 71/88] target/riscv: add "set round to odd" rounding mode helper function

From: Frank Chang 

helper_set_rounding_mode() is responsible for SIGILL, and "round to odd"
should be an interface private to translation, so add a new independent
helper_set_rod_rounding_mode().

Signed-off-by: Frank Chang 
Acked-by: Alistair Francis 
Message-Id: <20211210075704.23951-64-frank.ch...@sifive.com>
Signed-off-by: Alistair Francis 
---
 target/riscv/helper.h | 1 +
 target/riscv/internals.h  | 1 +
 target/riscv/fpu_helper.c | 5 +
 target/riscv/translate.c  | 7 +++
 4 files changed, 14 insertions(+)

diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 53cf88cd40..606bf72d5c 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -3,6 +3,7 @@ DEF_HELPER_2(raise_exception, noreturn, env, i32)
 
 /* Floating Point - rounding mode */
 DEF_HELPER_FLAGS_2(set_rounding_mode, TCG_CALL_NO_WG, void, env, i32)
+DEF_HELPER_FLAGS_1(set_rod_rounding_mode, TCG_CALL_NO_WG, void, env)
 
 /* Floating Point - fused */
 DEF_HELPER_FLAGS_4(fmadd_s, TCG_CALL_NO_RWG, i64, env, i64, i64, i64)
diff --git a/target/riscv/internals.h b/target/riscv/internals.h
index db105d4d64..065e8162a2 100644
--- a/target/riscv/internals.h
+++ b/target/riscv/internals.h
@@ -43,6 +43,7 @@ enum {
 RISCV_FRM_RUP = 3,  /* Round Up */
 RISCV_FRM_RMM = 4,  /* Round to Nearest, ties to Max Magnitude */
 RISCV_FRM_DYN = 7,  /* Dynamic rounding mode */
+RISCV_FRM_ROD = 8,  /* Round to Odd */
 };
 
 static inline uint64_t nanbox_s(float32 f)
diff --git a/target/riscv/fpu_helper.c b/target/riscv/fpu_helper.c
index dec39d4a9e..4a5982d594 100644
--- a/target/riscv/fpu_helper.c
+++ b/target/riscv/fpu_helper.c
@@ -81,6 +81,11 @@ void helper_set_rounding_mode(CPURISCVState *env, uint32_t 
rm)
 set_float_rounding_mode(softrm, &env->fp_status);
 }
 
+void helper_set_rod_rounding_mode(CPURISCVState *env)
+{
+set_float_rounding_mode(float_round_to_odd, &env->fp_status);
+}
+
 static uint64_t do_fmadd_h(CPURISCVState *env, uint64_t rs1, uint64_t rs2,
uint64_t rs3, int flags)
 {
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 3688e80d03..b4df21bda3 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -30,6 +30,7 @@
 #include "exec/log.h"
 
 #include "instmap.h"
+#include "internals.h"
 
 /* global register indices */
 static TCGv cpu_gpr[32], cpu_pc, cpu_vl;
@@ -403,6 +404,12 @@ static void gen_set_rm(DisasContext *ctx, int rm)
 return;
 }
 ctx->frm = rm;
+
+if (rm == RISCV_FRM_ROD) {
+gen_helper_set_rod_rounding_mode(cpu_env);
+return;
+}
+
 gen_helper_set_rounding_mode(cpu_env, tcg_constant_i32(rm));
 }
 
-- 
2.31.1

[PATCH v4 0/3] RISC-V: Populate mtval and stval

From: Alistair Francis 

Populate mtval and stval when taking an illegal instruction exception.

The RISC-V spec states that "The stval register can optionally also be
used to return the faulting instruction bits on an illegal instruction
exception...". In this case we are always writing the value on an
illegal instruction.

This doesn't match all CPUs (some CPUs won't write the data), but in
QEMU let's just populate the value on illegal instructions. This won't
break any guest software, but will provide more information to guests.

Alistair Francis (3):
  target/riscv: Set the opcode in DisasContext
  target/riscv: Fixup setting GVA
  target/riscv: Implement the stval/mtval illegal instruction

 target/riscv/cpu.h|  2 ++
 target/riscv/cpu_helper.c | 24 +---
 target/riscv/translate.c  |  5 +
 3 files changed, 16 insertions(+), 15 deletions(-)

-- 
2.31.1

[PULL 74/88] target/riscv: rvv-1.0: implement vstart CSR

From: Frank Chang 

* Update and check vstart value for vector instructions.
* Add whole register move instruction helper functions as we have to
  call helper function for case where vstart is not zero.
* Remove probe_pages() calls in vector load/store instructions
  (except fault-only-first loads) to raise the memory access exception
  at the exact processed vector element.

Signed-off-by: Frank Chang 
Reviewed-by: Alistair Francis 
Message-Id: <20211210075704.23951-67-frank.ch...@sifive.com>
Signed-off-by: Alistair Francis 
---
 target/riscv/helper.h   |   5 +
 target/riscv/csr.c  |   6 +-
 target/riscv/translate.c|   6 +-
 target/riscv/vector_helper.c| 210 +++-
 target/riscv/insn_trans/trans_rvv.c.inc |  75 ++---
 5 files changed, 199 insertions(+), 103 deletions(-)

diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 1a0d817f0f..a717a87a0e 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -1073,6 +1073,11 @@ DEF_HELPER_6(vcompress_vm_h, void, ptr, ptr, ptr, ptr, 
env, i32)
 DEF_HELPER_6(vcompress_vm_w, void, ptr, ptr, ptr, ptr, env, i32)
 DEF_HELPER_6(vcompress_vm_d, void, ptr, ptr, ptr, ptr, env, i32)
 
+DEF_HELPER_4(vmv1r_v, void, ptr, ptr, env, i32)
+DEF_HELPER_4(vmv2r_v, void, ptr, ptr, env, i32)
+DEF_HELPER_4(vmv4r_v, void, ptr, ptr, env, i32)
+DEF_HELPER_4(vmv8r_v, void, ptr, ptr, env, i32)
+
 DEF_HELPER_5(vzext_vf2_h, void, ptr, ptr, ptr, env, i32)
 DEF_HELPER_5(vzext_vf2_w, void, ptr, ptr, ptr, env, i32)
 DEF_HELPER_5(vzext_vf2_d, void, ptr, ptr, ptr, env, i32)
diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 3dfbc17738..146447eac5 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -343,7 +343,11 @@ static RISCVException write_vstart(CPURISCVState *env, int 
csrno,
 #if !defined(CONFIG_USER_ONLY)
 env->mstatus |= MSTATUS_VS;
 #endif
-env->vstart = val;
+/*
+ * The vstart CSR is defined to have only enough writable bits
+ * to hold the largest element index, i.e. lg2(VLEN) bits.
+ */
+env->vstart = val & ~(~0ULL << ctzl(env_archcpu(env)->cfg.vlen));
 return RISCV_EXCP_NONE;
 }
 
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index b4df21bda3..68edaaf6ac 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -33,7 +33,7 @@
 #include "internals.h"
 
 /* global register indices */
-static TCGv cpu_gpr[32], cpu_pc, cpu_vl;
+static TCGv cpu_gpr[32], cpu_pc, cpu_vl, cpu_vstart;
 static TCGv_i64 cpu_fpr[32]; /* assume F and D extensions */
 static TCGv load_res;
 static TCGv load_val;
@@ -96,6 +96,7 @@ typedef struct DisasContext {
 int8_t lmul;
 uint8_t sew;
 uint16_t vlen;
+target_ulong vstart;
 bool vl_eq_vlmax;
 uint8_t ntemp;
 CPUState *cs;
@@ -710,6 +711,7 @@ static void riscv_tr_init_disas_context(DisasContextBase 
*dcbase, CPUState *cs)
 ctx->vill = FIELD_EX32(tb_flags, TB_FLAGS, VILL);
 ctx->sew = FIELD_EX32(tb_flags, TB_FLAGS, SEW);
 ctx->lmul = sextract32(FIELD_EX32(tb_flags, TB_FLAGS, LMUL), 0, 3);
+ctx->vstart = env->vstart;
 ctx->vl_eq_vlmax = FIELD_EX32(tb_flags, TB_FLAGS, VL_EQ_VLMAX);
 ctx->xl = FIELD_EX32(tb_flags, TB_FLAGS, XL);
 ctx->cs = cs;
@@ -828,6 +830,8 @@ void riscv_translate_init(void)
 
 cpu_pc = tcg_global_mem_new(cpu_env, offsetof(CPURISCVState, pc), "pc");
 cpu_vl = tcg_global_mem_new(cpu_env, offsetof(CPURISCVState, vl), "vl");
+cpu_vstart = tcg_global_mem_new(cpu_env, offsetof(CPURISCVState, vstart),
+"vstart");
 load_res = tcg_global_mem_new(cpu_env, offsetof(CPURISCVState, load_res),
  "load_res");
 load_val = tcg_global_mem_new(cpu_env, offsetof(CPURISCVState, load_val),
diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c
index e61c873142..22848d6b68 100644
--- a/target/riscv/vector_helper.c
+++ b/target/riscv/vector_helper.c
@@ -226,25 +226,19 @@ vext_ldst_stride(void *vd, void *v0, target_ulong base,
 uint32_t nf = vext_nf(desc);
 uint32_t max_elems = vext_max_elems(desc, esz);
 
-/* probe every access*/
-for (i = 0; i < env->vl; i++) {
+for (i = env->vstart; i < env->vl; i++, env->vstart++) {
 if (!vm && !vext_elem_mask(v0, i)) {
 continue;
 }
-probe_pages(env, base + stride * i, nf << esz, ra, access_type);
-}
-/* do real access */
-for (i = 0; i < env->vl; i++) {
+
 k = 0;
-if (!vm && !vext_elem_mask(v0, i)) {
-continue;
-}
 while (k < nf) {
 target_ulong addr = base + stride * i + (k << esz);
 ldst_elem(env, addr, i + k * max_elems, vd, ra);
 k++;
 }
 }
+env->vstart = 0;
 }
 
 #define GEN_VEXT_LD_STRIDE(NAME, ETYPE, LOAD_FN)\
@@ -291,10 +285,8 @@ vext_ldst_us(void *vd, target_ulong base, CPURISCVState 
*env, uint32_t desc,

Re: [PATCH qemu] s390x/css: fix PMCW invalid mask

2021-12-20 Thread Pierre Morel





On 12/17/21 20:28, Halil Pasic wrote:

On Fri, 17 Dec 2021 18:13:47 +0100
Pierre Morel  wrote:


Previously, we required bits 5, 6 and 7 to be zero (0x07 == 0b111). But,
as per the principles of operation, bit 5 is ignored in MSCH and bits 0,
1, 6 and 7 need to be zero.


On a second thought, don't we have to make sure then that bit 5 is
ignored?

static void copy_pmcw_from_guest(PMCW *dest, const PMCW *src)
{
  int i;

  dest->intparm = be32_to_cpu(src->intparm);
  dest->flags = be16_to_cpu(src->flags);
  dest->devno = be16_to_cpu(src->devno);

Here we seem to grab flags as a whole, but actually we would have to
mask of bit 5.


Why?
If this bit is ignored by the machine shouldn't we just ignore it?
Forcing it to 0 or to 1 is purely arbitrary no?


We do the masking later on:
IOInstEnding css_do_msch(SubchDev *sch, const SCHIB *orig_schib)
{
[..]
 /* Only update the program-modifiable fields. */
 schib->pmcw.intparm = schib_copy.pmcw.intparm;
 oldflags = schib->pmcw.flags;
 schib->pmcw.flags &= ~(PMCW_FLAGS_MASK_ISC | PMCW_FLAGS_MASK_ENA |
   PMCW_FLAGS_MASK_LM | PMCW_FLAGS_MASK_MME |
   PMCW_FLAGS_MASK_MP);
 schib->pmcw.flags |= schib_copy.pmcw.flags &
 (PMCW_FLAGS_MASK_ISC | PMCW_FLAGS_MASK_ENA |
  PMCW_FLAGS_MASK_LM | PMCW_FLAGS_MASK_MME |
  PMCW_FLAGS_MASK_MP);
[..]

I just didn't read far enough. We do that for a while now.


yes.



The PoP says that the machine shall ignore other fields
of the PMCW when an MSCH is performed. I.e. we should not update
"our" pmcw.flags bit 5 from 0 to 1 even if 1 was supplied, and
thus STSCH should keep storing the bit 5 as 0 even if there was
a MSCH with bit 5 set.


So I do understand that there is no problem, we do not keep track
of this bit in our pmcw.flags and stsch keep storing this bit as 0. right?

Regards,
Pierre



Regards,
Halil



--
Pierre Morel
IBM Lab Boeblingen

Re: [PATCH 0/2] hw/nvme: Fix CVE-2021-3929 (DMA re-entrancy exploitation)

2021-12-20 Thread Klaus Jensen

On Dec 16 20:55, Klaus Jensen wrote:
> On Dec 16 20:13, Klaus Jensen wrote:
> > On Dec 16 18:55, Philippe Mathieu-Daudé wrote:
> > > Now that the DMA API allow passing MemTxAttrs argument and
> > > returning MemTxResult (with MEMTX_BUS_ERROR in particular),
> > > we can restrict the NVMe controller to memories (prohibitting
> > > accesses by the DMA engine to devices) and block yet another
> > > DMA re-entrancy attack.
> > > 
> > > I'll will try to get a reproducer (and authorization to commit
> > > it as qtest) from the reporter.
> > > 
> > > Based-on: <20211216123558.799425-1-phi...@redhat.com>
> > > "hw: Have DMA API take MemTxAttrs arg & propagate MemTxResult (part 2)"
> > > https://lore.kernel.org/qemu-devel/20211216123558.799425-1-phi...@redhat.com/
> > > 
> > > Philippe Mathieu-Daudé (2):
> > >   hw/nvme/ctrl: Do not ignore DMA access errors
> > >   hw/nvme/ctrl: Prohibit DMA accesses to devices (CVE-2021-3929)
> > > 
> > >  hw/nvme/ctrl.c | 9 +
> > >  1 file changed, 5 insertions(+), 4 deletions(-)
> > > 
> > 
> > LGTM.
> > 
> > Reviewed-by: Klaus Jensen 
> 
> Ugh. Jumped the gun here.
> 
> This all looked fine, but since this prohibits DMA to other devices it
> breaks DMA'ing to a controller memory buffer on another device, which is
> a used feature of some setups.
> 
> I think we need to fix this like e1000 did?

Something like this maybe?

This fixes CVE-2021-3929 "locally" by denying DMA to the iomem of the
device itself. This still allows DMA to MMIO regions of other devices
(e.g. doing P2P DMA to the controller memory buffer of another NVMe
device).


diff --git a/hw/nvme/ctrl.c b/hw/nvme/ctrl.c
index 5f573c417b3d..9a79f6728867 100644
--- a/hw/nvme/ctrl.c
+++ b/hw/nvme/ctrl.c
@@ -357,6 +357,16 @@ static inline void *nvme_addr_to_pmr(NvmeCtrl *n, hwaddr 
addr)
 return memory_region_get_ram_ptr(&n->pmr.dev->mr) + (addr - n->pmr.cba);
 }

+static inline bool nvme_addr_is_iomem(NvmeCtrl *n, hwaddr addr)
+{
+hwaddr hi, lo;
+
+lo = n->bar0.addr;
+hi = lo + int128_get64(n->bar0.size);
+
+return addr >= lo && addr < hi;
+}
+
 static int nvme_addr_read(NvmeCtrl *n, hwaddr addr, void *buf, int size)
 {
 hwaddr hi = addr + size - 1;
@@ -614,6 +624,10 @@ static uint16_t nvme_map_addr(NvmeCtrl *n, NvmeSg *sg, 
hwaddr addr, size_t len)

 trace_pci_nvme_map_addr(addr, len);

+if (nvme_addr_is_iomem(n, addr)) {
+return NVME_DATA_TRAS_ERROR;
+}
+
 if (nvme_addr_is_cmb(n, addr)) {
 cmb = true;
 } else if (nvme_addr_is_pmr(n, addr)) {


signature.asc
Description: PGP signature

[PULL 69/88] target/riscv: rvv-1.0: floating-point/integer type-convert instructions

From: Frank Chang 

Add the following instructions:

* vfcvt.rtz.xu.f.v
* vfcvt.rtz.x.f.v

Also adjust GEN_OPFV_TRANS() to accept multiple floating-point rounding
modes.

Signed-off-by: Frank Chang 
Reviewed-by: Alistair Francis 
Message-Id: <20211210075704.23951-62-frank.ch...@sifive.com>
Signed-off-by: Alistair Francis 
---
 target/riscv/insn32.decode  | 11 ++--
 target/riscv/insn_trans/trans_rvv.c.inc | 84 +++--
 2 files changed, 59 insertions(+), 36 deletions(-)

diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 20b3095f56..02064f8ec9 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -585,10 +585,13 @@ vmfge_vf01 . . . 101 . 1010111 
@r_vm
 vfclass_v   010011 . . 1 001 . 1010111 @r2_vm
 vfmerge_vfm 010111 0 . . 101 . 1010111 @r_vm_0
 vfmv_v_f010111 1 0 . 101 . 1010111 @r2
-vfcvt_xu_f_v100010 . . 0 001 . 1010111 @r2_vm
-vfcvt_x_f_v 100010 . . 1 001 . 1010111 @r2_vm
-vfcvt_f_xu_v100010 . . 00010 001 . 1010111 @r2_vm
-vfcvt_f_x_v 100010 . . 00011 001 . 1010111 @r2_vm
+
+vfcvt_xu_f_v   010010 . . 0 001 . 1010111 @r2_vm
+vfcvt_x_f_v010010 . . 1 001 . 1010111 @r2_vm
+vfcvt_f_xu_v   010010 . . 00010 001 . 1010111 @r2_vm
+vfcvt_f_x_v010010 . . 00011 001 . 1010111 @r2_vm
+vfcvt_rtz_xu_f_v   010010 . . 00110 001 . 1010111 @r2_vm
+vfcvt_rtz_x_f_v010010 . . 00111 001 . 1010111 @r2_vm
 vfwcvt_xu_f_v   100010 . . 01000 001 . 1010111 @r2_vm
 vfwcvt_x_f_v100010 . . 01001 001 . 1010111 @r2_vm
 vfwcvt_f_xu_v   100010 . . 01010 001 . 1010111 @r2_vm
diff --git a/target/riscv/insn_trans/trans_rvv.c.inc 
b/target/riscv/insn_trans/trans_rvv.c.inc
index 047be5d5c4..4bc4dfa69f 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -1,5 +1,4 @@
 /*
- * RISC-V translation routines for the RVV Standard Extension.
  *
  * Copyright (c) 2020 T-Head Semiconductor Co., Ltd. All rights reserved.
  *
@@ -2369,34 +2368,41 @@ static bool opfv_check(DisasContext *s, arg_rmr *a)
vext_check_ss(s, a->rd, a->rs2, a->vm);
 }
 
-#define GEN_OPFV_TRANS(NAME, CHECK)\
-static bool trans_##NAME(DisasContext *s, arg_rmr *a)  \
-{  \
-if (CHECK(s, a)) { \
-uint32_t data = 0; \
-static gen_helper_gvec_3_ptr * const fns[3] = {\
-gen_helper_##NAME##_h, \
-gen_helper_##NAME##_w, \
-gen_helper_##NAME##_d, \
-}; \
-TCGLabel *over = gen_new_label();  \
-gen_set_rm(s, RISCV_FRM_DYN);  \
-tcg_gen_brcondi_tl(TCG_COND_EQ, cpu_vl, 0, over);  \
-   \
-data = FIELD_DP32(data, VDATA, VM, a->vm); \
-data = FIELD_DP32(data, VDATA, LMUL, s->lmul); \
-tcg_gen_gvec_3_ptr(vreg_ofs(s, a->rd), vreg_ofs(s, 0), \
-   vreg_ofs(s, a->rs2), cpu_env,   \
-   s->vlen / 8, s->vlen / 8, data, \
-   fns[s->sew - 1]);   \
-mark_vs_dirty(s);  \
-gen_set_label(over);   \
-return true;   \
-}  \
-return false;  \
+static bool do_opfv(DisasContext *s, arg_rmr *a,
+gen_helper_gvec_3_ptr *fn,
+bool (*checkfn)(DisasContext *, arg_rmr *),
+int rm)
+{
+if (checkfn(s, a)) {
+uint32_t data = 0;
+TCGLabel *over = gen_new_label();
+gen_set_rm(s, rm);
+tcg_gen_brcondi_tl(TCG_COND_EQ, cpu_vl, 0, over);
+
+data = FIELD_DP32(data, VDATA, VM, a->vm);
+data = FIELD_DP32(data, VDATA, LMUL, s->lmul);
+tcg_gen_gvec_3_ptr(vreg_ofs(s, a->rd), vreg_ofs(s, 0),
+   vreg_ofs(s, a->rs2), cpu_env,
+   s->vlen / 8, s->vlen / 8, data, fn);
+mark_vs_dirty(s);
+gen_set_label(over);
+return true;
+}
+return false;
+}
+
+#define GEN_OPFV_TRANS(NAME, CHECK, FRM)   \
+static bool trans_##NAME(DisasContext *s, arg_rmr *a)  \
+{

Re: [PULL 00/16] qtest and gitlab-CI improvements


On 20/12/2021 10.24, Philippe Mathieu-Daudé wrote:

+Alex & Paolo

On 12/20/21 07:52, Thomas Huth wrote:

On 18/12/2021 17.33, Philippe Mathieu-Daudé wrote:

Hi,

On 12/15/21 08:33, Thomas Huth wrote:



* Add virtio-net failover test
* Make qtests a little bit more flexible with regards to reduced configs
* Move libssh setup from configure to meson.build
* Run device-crash-test in CI
* Add jobs for NetBSD and OpenBSD to the CI
* Test compilation with MSYS2 in the gitlab-ci, too
* Add new virtio-iommu test





Laurent Vivier (4):
    qtest/libqos: add a function to initialize secondary PCI buses
    tests/qtest: add some tests for virtio-net failover
    tests/libqtest: add some virtio-net failover migration
cancelling tests
    tests/libqtest: add a migration test with two couples of
failover devices


On my ASan build directory I'm sometime getting:

Running test qtest-i386/virtio-net-failover
(process:1558675): GLib-CRITICAL **: 16:19:12.556: g_rand_int: assertion
'rand != NULL' failed


Weird, since the test is not using that function?


Well it calls g_test_rand_int(), which calls it:
https://github.com/GNOME/glib/blob/main/glib/gtestutils.c#L1800


Ah, right. I think the problem is that g_test_rand_int() must not be called 
before g_test_init().


But actually, I think in this case we even don't want to use 
g_test_rand_int() since it's about generating a true random temporary file 
name, not a random number for a test case that could be influenced with the 
"--seed" CLI option.

So I think using g_random_int() might be the better choice instead?

 Thomas

[PULL 70/88] target/riscv: rvv-1.0: widening floating-point/integer type-convert

From: Frank Chang 

Add the following instructions:

* vfwcvt.rtz.xu.f.v
* vfwcvt.rtz.x.f.v

Also adjust GEN_OPFV_WIDEN_TRANS() to accept multiple floating-point
rounding modes.

Signed-off-by: Frank Chang 
Acked-by: Alistair Francis 
Message-Id: <20211210075704.23951-63-frank.ch...@sifive.com>
Signed-off-by: Alistair Francis 
---
 target/riscv/helper.h   |  2 +
 target/riscv/insn32.decode  | 13 +++---
 target/riscv/vector_helper.c|  7 +++-
 target/riscv/insn_trans/trans_rvv.c.inc | 55 +
 4 files changed, 63 insertions(+), 14 deletions(-)

diff --git a/target/riscv/helper.h b/target/riscv/helper.h
index 1727075dce..53cf88cd40 100644
--- a/target/riscv/helper.h
+++ b/target/riscv/helper.h
@@ -928,8 +928,10 @@ DEF_HELPER_5(vfwcvt_xu_f_v_h, void, ptr, ptr, ptr, env, 
i32)
 DEF_HELPER_5(vfwcvt_xu_f_v_w, void, ptr, ptr, ptr, env, i32)
 DEF_HELPER_5(vfwcvt_x_f_v_h, void, ptr, ptr, ptr, env, i32)
 DEF_HELPER_5(vfwcvt_x_f_v_w, void, ptr, ptr, ptr, env, i32)
+DEF_HELPER_5(vfwcvt_f_xu_v_b, void, ptr, ptr, ptr, env, i32)
 DEF_HELPER_5(vfwcvt_f_xu_v_h, void, ptr, ptr, ptr, env, i32)
 DEF_HELPER_5(vfwcvt_f_xu_v_w, void, ptr, ptr, ptr, env, i32)
+DEF_HELPER_5(vfwcvt_f_x_v_b, void, ptr, ptr, ptr, env, i32)
 DEF_HELPER_5(vfwcvt_f_x_v_h, void, ptr, ptr, ptr, env, i32)
 DEF_HELPER_5(vfwcvt_f_x_v_w, void, ptr, ptr, ptr, env, i32)
 DEF_HELPER_5(vfwcvt_f_f_v_h, void, ptr, ptr, ptr, env, i32)
diff --git a/target/riscv/insn32.decode b/target/riscv/insn32.decode
index 02064f8ec9..664d0fb371 100644
--- a/target/riscv/insn32.decode
+++ b/target/riscv/insn32.decode
@@ -592,11 +592,14 @@ vfcvt_f_xu_v   010010 . . 00010 001 . 1010111 
@r2_vm
 vfcvt_f_x_v010010 . . 00011 001 . 1010111 @r2_vm
 vfcvt_rtz_xu_f_v   010010 . . 00110 001 . 1010111 @r2_vm
 vfcvt_rtz_x_f_v010010 . . 00111 001 . 1010111 @r2_vm
-vfwcvt_xu_f_v   100010 . . 01000 001 . 1010111 @r2_vm
-vfwcvt_x_f_v100010 . . 01001 001 . 1010111 @r2_vm
-vfwcvt_f_xu_v   100010 . . 01010 001 . 1010111 @r2_vm
-vfwcvt_f_x_v100010 . . 01011 001 . 1010111 @r2_vm
-vfwcvt_f_f_v100010 . . 01100 001 . 1010111 @r2_vm
+
+vfwcvt_xu_f_v  010010 . . 01000 001 . 1010111 @r2_vm
+vfwcvt_x_f_v   010010 . . 01001 001 . 1010111 @r2_vm
+vfwcvt_f_xu_v  010010 . . 01010 001 . 1010111 @r2_vm
+vfwcvt_f_x_v   010010 . . 01011 001 . 1010111 @r2_vm
+vfwcvt_f_f_v   010010 . . 01100 001 . 1010111 @r2_vm
+vfwcvt_rtz_xu_f_v  010010 . . 01110 001 . 1010111 @r2_vm
+vfwcvt_rtz_x_f_v   010010 . . 0 001 . 1010111 @r2_vm
 vfncvt_xu_f_v   100010 . . 1 001 . 1010111 @r2_vm
 vfncvt_x_f_v100010 . . 10001 001 . 1010111 @r2_vm
 vfncvt_f_xu_v   100010 . . 10010 001 . 1010111 @r2_vm
diff --git a/target/riscv/vector_helper.c b/target/riscv/vector_helper.c
index cc95b69255..c3b7719291 100644
--- a/target/riscv/vector_helper.c
+++ b/target/riscv/vector_helper.c
@@ -3773,6 +3773,7 @@ GEN_VEXT_V_ENV(vfcvt_f_x_v_d, 8, 8)
 
 /* Widening Floating-Point/Integer Type-Convert Instructions */
 /* (TD, T2, TX2) */
+#define WOP_UU_B uint16_t, uint8_t,  uint8_t
 #define WOP_UU_H uint32_t, uint16_t, uint16_t
 #define WOP_UU_W uint64_t, uint32_t, uint32_t
 /* vfwcvt.xu.f.v vd, vs2, vm # Convert float to double-width unsigned 
integer.*/
@@ -3788,19 +3789,23 @@ GEN_VEXT_V_ENV(vfwcvt_x_f_v_h, 2, 4)
 GEN_VEXT_V_ENV(vfwcvt_x_f_v_w, 4, 8)
 
 /* vfwcvt.f.xu.v vd, vs2, vm # Convert unsigned integer to double-width float 
*/
+RVVCALL(OPFVV1, vfwcvt_f_xu_v_b, WOP_UU_B, H2, H1, uint8_to_float16)
 RVVCALL(OPFVV1, vfwcvt_f_xu_v_h, WOP_UU_H, H4, H2, uint16_to_float32)
 RVVCALL(OPFVV1, vfwcvt_f_xu_v_w, WOP_UU_W, H8, H4, uint32_to_float64)
+GEN_VEXT_V_ENV(vfwcvt_f_xu_v_b, 1, 2)
 GEN_VEXT_V_ENV(vfwcvt_f_xu_v_h, 2, 4)
 GEN_VEXT_V_ENV(vfwcvt_f_xu_v_w, 4, 8)
 
 /* vfwcvt.f.x.v vd, vs2, vm # Convert integer to double-width float. */
+RVVCALL(OPFVV1, vfwcvt_f_x_v_b, WOP_UU_B, H2, H1, int8_to_float16)
 RVVCALL(OPFVV1, vfwcvt_f_x_v_h, WOP_UU_H, H4, H2, int16_to_float32)
 RVVCALL(OPFVV1, vfwcvt_f_x_v_w, WOP_UU_W, H8, H4, int32_to_float64)
+GEN_VEXT_V_ENV(vfwcvt_f_x_v_b, 1, 2)
 GEN_VEXT_V_ENV(vfwcvt_f_x_v_h, 2, 4)
 GEN_VEXT_V_ENV(vfwcvt_f_x_v_w, 4, 8)
 
 /*
- * vfwcvt.f.f.v vd, vs2, vm #
+ * vfwcvt.f.f.v vd, vs2, vm
  * Convert single-width float to double-width float.
  */
 static uint32_t vfwcvtffv16(uint16_t a, float_status *s)
diff --git a/target/riscv/insn_trans/trans_rvv.c.inc 
b/target/riscv/insn_trans/trans_rvv.c.inc
index 4bc4dfa69f..b4cf044450 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -2536,12 +2536,55 @@ static bool opfv_widen_check(DisasContext *s, arg_rmr 
*a)
vext_check_ds(s, a->rd, a->rs2, a->vm);
 }
 
-#define GEN_OPFV_WIDEN_TRANS(NAME) \
+#define GEN_OPFV_WIDEN_TRANS(NAME, HELPER,

Re: [PULL 09/11] ui/vnc: clipboard support

2021-12-20 Thread Vladimir Sementsov-Ogievskiy


21.05.2021 15:51, Gerd Hoffmann wrote:

This patch adds support for cut+paste to the qemu vnc server, which
allows the vnc client exchange clipbaord data with qemu and other peers
like the qemu vdagent implementation.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Marc-André Lureau 
Message-id: 20210519053940.1888907-1-kra...@redhat.com
Message-Id: <20210519053940.1888907-8-kra...@redhat.com>
---


[..]


--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -25,6 +25,7 @@
   */
  
  #include "qemu/osdep.h"

+#include "qemu-common.h"
  #include "vnc.h"
  #include "vnc-jobs.h"
  #include "trace.h"
@@ -1352,6 +1353,9 @@ void vnc_disconnect_finish(VncState *vs)
  /* last client gone */
  vnc_update_server_surface(vs->vd);
  }
+if (vs->cbpeer.update.notify) {
+qemu_clipboard_peer_unregister(&vs->cbpeer);
+}
  
  vnc_unlock_output(vs);
  


Hi Gerd!

Something is wrong here.

We are already under mutex, but calling qemu_clipboard_peer_unregister may 
trigger taking this mutex again in same call stack:

(gdb) bt
#0  0x7f4c979b77b0 in __lll_lock_wait () at /lib64/libpthread.so.0
#1  0x7f4c979b0553 in pthread_mutex_lock () at /lib64/libpthread.so.0
#2  0x558fb33bbb72 in qemu_mutex_lock_impl (mutex=0x558fb5416598, file=0x558fb3447fb7 
"../ui/vnc-jobs.h", line=60) at ../util/qemu-thread-posix.c:80
#3  0x558fb2ca16c6 in vnc_lock_output (vs=0x558fb540a400) at 
../ui/vnc-jobs.h:60
#4  0x558fb2ca1ab0 in vnc_clipboard_send (vs=0x558fb540a400, count=1, 
dwords=0x7ffe37f5f968) at ../ui/vnc-clipboard.c:138
#5  0x558fb2ca1f17 in vnc_clipboard_notify (notifier=0x558fb541a700, 
data=0x558fb524ee70) at ../ui/vnc-clipboard.c:209
#6  0x558fb33c25f0 in notifier_list_notify (list=0x558fb3a142f0 
, data=0x558fb524ee70) at ../util/notify.c:39
#7  0x558fb2c6d601 in qemu_clipboard_update (info=0x558fb524ee70) at 
../ui/clipboard.c:50
#8  0x558fb2c6d570 in qemu_clipboard_peer_release (peer=0x558fb541a6f8, 
selection=QEMU_CLIPBOARD_SELECTION_CLIPBOARD) at ../ui/clipboard.c:41
#9  0x558fb2c6d4b6 in qemu_clipboard_peer_unregister (peer=0x558fb541a6f8) 
at ../ui/clipboard.c:19
#10 0x558fb2c8518a in vnc_disconnect_finish (vs=0x558fb540a400) at 
../ui/vnc.c:1358
#11 0x558fb2c848b0 in vnc_update_client (vs=0x558fb540a400, has_dirty=0) at 
../ui/vnc.c:1167
#12 0x558fb2c8a1ce in vnc_refresh (dcl=0x558fb5882610) at ../ui/vnc.c:3207
#13 0x558fb2c72dec in dpy_refresh (s=0x558fb4fe7970) at ../ui/console.c:1673
#14 0x558fb2c6ebe4 in gui_update (opaque=0x558fb4fe7970) at 
../ui/console.c:158
#15 0x558fb33e862b in timerlist_run_timers (timer_list=0x558fb45ed200) at 
../util/qemu-timer.c:573
#16 0x558fb33e86d5 in qemu_clock_run_timers (type=QEMU_CLOCK_REALTIME) at 
../util/qemu-timer.c:587
#17 0x558fb33e899a in qemu_clock_run_all_timers () at 
../util/qemu-timer.c:669
#18 0x558fb33e26ec in main_loop_wait (nonblocking=0) at 
../util/main-loop.c:542
#19 0x558fb3099c75 in qemu_main_loop () at ../softmmu/runstate.c:726
#20 0x558fb2c62ae6 in main (argc=5, argv=0x7ffe37f5fdf8, 
envp=0x7ffe37f5fe28) at ../softmmu/main.c:50
(gdb) fr 2
#2  0x558fb33bbb72 in qemu_mutex_lock_impl (mutex=0x558fb5416598, file=0x558fb3447fb7 
"../ui/vnc-jobs.h", line=60) at ../util/qemu-thread-posix.c:80
80  err = pthread_mutex_lock(&mutex->lock);
(gdb) p *mutex
$1 = {lock = {__data = {__lock = 2, __count = 0, __owner = 1549902, __nusers = 
1, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 
0x0}},
__size = "\002\000\000\000\000\000\000\000N\246\027\000\001", '\000' , __align = 2}, file = 0x558fb3442aaf "../ui/vnc-jobs.h", line = 60, initialized = 
true}
(gdb) info thr
  Id   Target Id Frame
* 1Thread 0x7f4c89ba8fc0 (LWP 1549902) "qemu-system-x86" 0x7f4c979b77b0 
in __lll_lock_wait () from /lib64/libpthread.so.0
  2Thread 0x7f4c89a36640 (LWP 1549903) "qemu-system-x86" 0x7f4c96ad8e0d 
in syscall () from /lib64/libc.so.6
  3Thread 0x7f4c890b3640 (LWP 1549904) "qemu-system-x86" 0x7f4c96ad35bf 
in poll () from /lib64/libc.so.6
  4Thread 0x7f4c03fff640 (LWP 1549905) "qemu-system-x86" 0x7f4c979baa8a 
in __futex_abstimed_wait_common64 () from /lib64/libpthread.so.0
  5Thread 0x7f4c01bff640 (LWP 1549906) "qemu-system-x86" 0x7f4c979baa8a 
in __futex_abstimed_wait_common64 () from /lib64/libpthread.so.0


Reproduce is simple:

On master branch, run something like this:

  ./build/qemu-system-x86_64 -vnc :7 --qmp stdio

Then, in two different terminals start connecting loops:

  while true; do vncviewer :5907; done

Then wait. If vncviewer loop stack for some reason, when qemu is not yet 
dead-locked, just restart the loop. Qemu screen becoming black - good sign of 
dead-lock happen, go into gdb and check.
By default vncviewer does non-shared connection, so previous client is closed 
when new one is connected. So we trigger many disconnects and connects in a 
loop.


I don

[PATCH v2 2/8] migration: Don't return for postcopy_chunk_hostpages()

It always return zero, because it just can't go wrong so far.  Simplify the
code with no functional change.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Peter Xu 
---
 migration/ram.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 7d9c8a508b..0ed0f51a09 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2580,12 +2580,10 @@ static void 
postcopy_chunk_hostpages_pass(MigrationState *ms, RAMBlock *block)
  * dirty host-page size chunks as all dirty.  In this case the host-page
  * is the host-page for the particular RAMBlock, i.e. it might be a huge page
  *
- * Returns zero on success
- *
  * @ms: current migration state
  * @block: block we want to work with
  */
-static int postcopy_chunk_hostpages(MigrationState *ms, RAMBlock *block)
+static void postcopy_chunk_hostpages(MigrationState *ms, RAMBlock *block)
 {
 postcopy_discard_send_init(ms, block->idstr);
 
@@ -2595,7 +2593,6 @@ static int postcopy_chunk_hostpages(MigrationState *ms, 
RAMBlock *block)
 postcopy_chunk_hostpages_pass(ms, block);
 
 postcopy_discard_send_finish(ms);
-return 0;
 }
 
 /**
@@ -2617,7 +2614,6 @@ int ram_postcopy_send_discard_bitmap(MigrationState *ms)
 {
 RAMState *rs = ram_state;
 RAMBlock *block;
-int ret;
 
 RCU_READ_LOCK_GUARD();
 
@@ -2631,10 +2627,7 @@ int ram_postcopy_send_discard_bitmap(MigrationState *ms)
 
 RAMBLOCK_FOREACH_NOT_IGNORED(block) {
 /* Deal with TPS != HPS and huge pages */
-ret = postcopy_chunk_hostpages(ms, block);
-if (ret) {
-return ret;
-}
+postcopy_chunk_hostpages(ms, block);
 }
 trace_ram_postcopy_send_discard_bitmap();
 
-- 
2.32.0

[PATCH v4 1/3] target/riscv: Set the opcode in DisasContext

From: Alistair Francis 

Signed-off-by: Alistair Francis 
Reviewed-by: Richard Henderson 
---
 target/riscv/translate.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 1d57bc97b5..24251bc8cc 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -586,6 +586,7 @@ static void decode_opc(CPURISCVState *env, DisasContext 
*ctx, uint16_t opcode)
 if (!has_ext(ctx, RVC)) {
 gen_exception_illegal(ctx);
 } else {
+ctx->opcode = opcode;
 ctx->pc_succ_insn = ctx->base.pc_next + 2;
 if (!decode_insn16(ctx, opcode)) {
 gen_exception_illegal(ctx);
@@ -596,6 +597,7 @@ static void decode_opc(CPURISCVState *env, DisasContext 
*ctx, uint16_t opcode)
 opcode32 = deposit32(opcode32, 16, 16,
  translator_lduw(env, &ctx->base,
  ctx->base.pc_next + 2));
+ctx->opcode = opcode32;
 ctx->pc_succ_insn = ctx->base.pc_next + 4;
 if (!decode_insn32(ctx, opcode32)) {
 gen_exception_illegal(ctx);
-- 
2.31.1

Re: Virtio-GPU Xres and Yres seettings

Cc'ing Gerd & Marc-André.

On 12/20/21 05:26, Pratik Parvati wrote:
> Hi Team,
> 
> I am working on a Virtio-GPU device (backend) for one of our customer
> projects - we are using the Virtio-GPU driver (frontend) to drive our
> device. Our device code has been written using Qemu virtio-gpu device
> code as a reference. Our device is setting the resolution to 1024x768 as
> a response to the command received from the driver (i.e,
> VIRTIO_GPU_CMD_GET_DISPLAY_INFO) - I also verified that driver is
> receiving the response bytes properly, but the next
> command (i.e, VIRTIO_GPU_CMD_RESOURCE_CREATE_2D) that device receive has
> a width and height as 4096 and 2160 respectively. The driver is assuming
> a 4k display for some reason and I need your help to understand why this
> is happening.
> 
> Our display is corrupted for the same Xres and Yres misunderstanding
> between the device and the driver - Please guide me to understand the
> problem. Let me know if you have any questions or need more information.
> 
> Thanks & Regards,
> Pratik

Re: [PATCH v4 4/7] iotests.py: add qemu_tool_popen()



On 12/13/21 18:32, Vladimir Sementsov-Ogievskiy wrote:


Split qemu_tool_popen() from qemu_tool_pipe_and_status() to be used
separately.

Signed-off-by: Vladimir Sementsov-Ogievskiy



Reviewed-by: Nikita Lapshin

[PATCH v2 4/8] migration: Do chunk page in postcopy_each_ram_send_discard()

Right now we loop ramblocks for twice, the 1st time chunk the dirty bits with
huge page information; the 2nd time we send the discard ranges.  That's not
necessary - we can do them in a single loop.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Peter Xu 
---
 migration/ram.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index b22c9e7432..e7107b9790 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2468,6 +2468,8 @@ static int postcopy_send_discard_bm_ram(MigrationState 
*ms, RAMBlock *block)
 return 0;
 }
 
+static void postcopy_chunk_hostpages_pass(MigrationState *ms, RAMBlock *block);
+
 /**
  * postcopy_each_ram_send_discard: discard all RAMBlocks
  *
@@ -2489,6 +2491,14 @@ static int postcopy_each_ram_send_discard(MigrationState 
*ms)
 RAMBLOCK_FOREACH_NOT_IGNORED(block) {
 postcopy_discard_send_init(ms, block->idstr);
 
+/*
+ * Deal with TPS != HPS and huge pages.  It discard any partially sent
+ * host-page size chunks, mark any partially dirty host-page size
+ * chunks as all dirty.  In this case the host-page is the host-page
+ * for the particular RAMBlock, i.e. it might be a huge page.
+ */
+postcopy_chunk_hostpages_pass(ms, block);
+
 /*
  * Postcopy sends chunks of bitmap over the wire, but it
  * just needs indexes at this point, avoids it having
@@ -2589,7 +2599,6 @@ static void postcopy_chunk_hostpages_pass(MigrationState 
*ms, RAMBlock *block)
 int ram_postcopy_send_discard_bitmap(MigrationState *ms)
 {
 RAMState *rs = ram_state;
-RAMBlock *block;
 
 RCU_READ_LOCK_GUARD();
 
@@ -2601,15 +2610,6 @@ int ram_postcopy_send_discard_bitmap(MigrationState *ms)
 rs->last_sent_block = NULL;
 rs->last_page = 0;
 
-RAMBLOCK_FOREACH_NOT_IGNORED(block) {
-/*
- * Deal with TPS != HPS and huge pages.  It discard any partially sent
- * host-page size chunks, mark any partially dirty host-page size
- * chunks as all dirty.  In this case the host-page is the host-page
- * for the particular RAMBlock, i.e. it might be a huge page.
- */
-postcopy_chunk_hostpages_pass(ms, block);
-}
 trace_ram_postcopy_send_discard_bitmap();
 
 return postcopy_each_ram_send_discard(ms);
-- 
2.32.0

Re: [PATCH 07/10] configure: unify x86_64 and x32

On 12/17/21 22:48, Richard Henderson wrote:
> On 12/16/21 7:30 AM, Paolo Bonzini wrote:
>> On 12/16/21 10:10, Philippe Mathieu-Daudé wrote:
>>> On 12/16/21 09:51, Paolo Bonzini wrote:
 The only difference between the two, as far as either configure or
 Meson are concerned, is in the multilib flags passed to the compiler.

 For QEMU, this fixes the handling of TYPE_OLDDEVT in
 include/exec/user/thunk.h and enables testing of dirty ring buffer,
 because both are using HOST_X86_64.

 For tests/tcg, this means that on a hypothetical x32 host the
 cross compiler will not be used to build the tests.
>>>
>>> Why not add the cross compiler definitions to tests/tcg?
>>>
>>> +: ${cross_cc_x32="$cross_cc_x86_64"}
>>> +: ${cross_cc_cflags_x32="-mx32"}
>>
>> tests/tcg does not support building x32 tests right now, does it?
> 
> We don't have docker support for x32, if that's what you mean.  But if
> you have x32 libraries installed on your host, I would think it would work.
> 
> 
>> What I meant is that, if you're on an x32 host, tests/tcg will now
>> build i386 and
>> x86-64 tests with the native compiler.
> And of course, those multilibs must be installed as well.

Debian still builds it:
https://buildd.debian.org/status/logs.php?pkg=qemu&ver=1%3A6.1%2Bdfsg-8%2Bb2&arch=x32

+=+
| qemu 1:6.1+dfsg-8+b2 (x32)  Wed, 15 Dec 2021 00:23:53 + |
+=+

Package: qemu
Version: 1:6.1+dfsg-8+b2
Source Version: 1:6.1+dfsg-8
Distribution: sid
Machine Architecture: amd64
Host Architecture: x32
Build Architecture: x32
Build Type: any

qemu-user_6.1+dfsg-8+b2_x32.deb
 Package: qemu-user
 Source: qemu (1:6.1+dfsg-8)
 Version: 1:6.1+dfsg-8+b2
 Architecture: x32
 Maintainer: Debian QEMU Team 
 Installed-Size: 91013

qemu-user-static_6.1+dfsg-8+b2_x32.deb
 Package: qemu-user-static
 Source: qemu (1:6.1+dfsg-8)
 Version: 1:6.1+dfsg-8+b2
 Architecture: x32
 Maintainer: Debian QEMU Team 
 Installed-Size: 268968

qemu-system-ppc_6.1+dfsg-8+b2_x32.deb
 Package: qemu-system-ppc
 Source: qemu (1:6.1+dfsg-8)
 Version: 1:6.1+dfsg-8+b2
 Architecture: x32
 Maintainer: Debian QEMU Team 
 Installed-Size: 25187

...

Re: [PATCH qemu] s390x/css: fix PMCW invalid mask

2021-12-20 Thread Halil Pasic

On Mon, 20 Dec 2021 11:44:44 +0100
Pierre Morel  wrote:

> > 
> > The PoP says that the machine shall ignore other fields
> > of the PMCW when an MSCH is performed. I.e. we should not update
> > "our" pmcw.flags bit 5 from 0 to 1 even if 1 was supplied, and
> > thus STSCH should keep storing the bit 5 as 0 even if there was
> > a MSCH with bit 5 set.  
> 
> So I do understand that there is no problem, we do not keep track
> of this bit in our pmcw.flags and stsch keep storing this bit as 0. right?

Right! False alarm by me -- sorry.

Regards,
Halil

[PATCH v4 3/3] target/riscv: Implement the stval/mtval illegal instruction

From: Alistair Francis 

The stval and mtval registers can optionally contain the faulting
instruction on an illegal instruction exception. This patch adds support
for setting the stval and mtval registers.

The RISC-V spec states that "The stval register can optionally also be
used to return the faulting instruction bits on an illegal instruction
exception...". In this case we are always writing the value on an
illegal instruction.

This doesn't match all CPUs (some CPUs won't write the data), but in
QEMU let's just populate the value on illegal instructions. This won't
break any guest software, but will provide more information to guests.

Signed-off-by: Alistair Francis 
---
 target/riscv/cpu.h| 2 ++
 target/riscv/cpu_helper.c | 3 +++
 target/riscv/translate.c  | 3 +++
 3 files changed, 8 insertions(+)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 0760c0af93..3a163b57ed 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -127,6 +127,8 @@ struct CPURISCVState {
 target_ulong frm;
 
 target_ulong badaddr;
+uint32_t bins;
+
 target_ulong guest_phys_fault_addr;
 
 target_ulong priv_ver;
diff --git a/target/riscv/cpu_helper.c b/target/riscv/cpu_helper.c
index 9e1f5ee177..f76ba834e6 100644
--- a/target/riscv/cpu_helper.c
+++ b/target/riscv/cpu_helper.c
@@ -1007,6 +1007,9 @@ void riscv_cpu_do_interrupt(CPUState *cs)
 write_gva = true;
 tval = env->badaddr;
 break;
+case RISCV_EXCP_ILLEGAL_INST:
+tval = env->bins;
+break;
 default:
 break;
 }
diff --git a/target/riscv/translate.c b/target/riscv/translate.c
index 24251bc8cc..921ca06bf9 100644
--- a/target/riscv/translate.c
+++ b/target/riscv/translate.c
@@ -167,6 +167,9 @@ static void generate_exception_mtval(DisasContext *ctx, int 
excp)
 
 static void gen_exception_illegal(DisasContext *ctx)
 {
+tcg_gen_st_i32(tcg_constant_i32(ctx->opcode), cpu_env,
+   offsetof(CPURISCVState, bins));
+
 generate_exception(ctx, RISCV_EXCP_ILLEGAL_INST);
 }
 
-- 
2.31.1

Re: Warnings during the virtio-net-failover test

On 20/12/2021 11:16, Thomas Huth wrote:

Hi Laurent,

today I noticed that there are quite a bunch of warnings during the virtio-net-failover
test:

$ QTEST_QEMU_BINARY=./qemu-system-x86_64 tests/qtest/virtio-net-failover
/x86_64/failover-virtio-net/hotplug_1: qemu-system-x86_64: warning: Primary device not
found
Virtio-net failover will not work. Make sure primary device has parameter
failover_pair_id=standby0

OK
/x86_64/failover-virtio-net/hotplug_1_reverse: OK
/x86_64/failover-virtio-net/hotplug_2: qemu-system-x86_64: warning: Primary device not
found
Virtio-net failover will not work. Make sure primary device has parameter
failover_pair_id=standby0

OK
[...]
/x86_64/failover-virtio-net/migrate/out: qemu-system-x86_64: warning: Primary device not
found
Virtio-net failover will not work. Make sure primary device has parameter
failover_pair_id=standby0

OK
/x86_64/failover-virtio-net/migrate/in: OK
/x86_64/failover-virtio-net/migrate/abort/wait-unplug: qemu-system-x86_64: warning:
Primary device not found
Virtio-net failover will not work. Make sure primary device has parameter
failover_pair_id=standby0

OK
/x86_64/failover-virtio-net/migrate/abort/active: qemu-system-x86_64: warning: Primary
device not found
Virtio-net failover will not work. Make sure primary device has parameter
failover_pair_id=standby0

OK
/x86_64/failover-virtio-net/multi/out: OK
/x86_64/failover-virtio-net/multi/in: OK

I assume they are false positives? If so, could you please come up with a patch to
silence them, since they are quite confusing...?

In fact they are the results of the test itself as we try to plug the standby
device first.

They are produced by a error_setg(), but as the caller is not attached to a user interface
the errp is used with warn_report_err().

In the end it uses error_vprintf() that seems that could be silence using
QTEST_SILENT_ERRORS environment variable.

I'm going to write a patch using that.

Thanks,

Laurent

Re: [PATCH v4 6/7] Add qemu-io Popen constructor wrapper. To be used in the following new test commit.



On 12/13/21 18:32, Vladimir Sementsov-Ogievskiy wrote:


Signed-off-by: Vladimir Sementsov-Ogievskiy


Reviewed-by: Nikita Lapshin

Re: [PULL 00/16] qtest and gitlab-CI improvements


On 18/12/2021 17.33, Philippe Mathieu-Daudé wrote:

Hi,

On 12/15/21 08:33, Thomas Huth wrote:



* Add virtio-net failover test
* Make qtests a little bit more flexible with regards to reduced configs
* Move libssh setup from configure to meson.build
* Run device-crash-test in CI
* Add jobs for NetBSD and OpenBSD to the CI
* Test compilation with MSYS2 in the gitlab-ci, too
* Add new virtio-iommu test





Laurent Vivier (4):
   qtest/libqos: add a function to initialize secondary PCI buses
   tests/qtest: add some tests for virtio-net failover
   tests/libqtest: add some virtio-net failover migration cancelling tests
   tests/libqtest: add a migration test with two couples of failover devices


On my ASan build directory I'm sometime getting:

Running test qtest-i386/virtio-net-failover
(process:1558675): GLib-CRITICAL **: 16:19:12.556: g_rand_int: assertion
'rand != NULL' failed


Weird, since the test is not using that function? Could you get a backtrace?

 Thomas

Re: [PATCH v4 7/7] iotests: add nbd-reconnect-on-open test



On 12/13/21 18:32, Vladimir Sementsov-Ogievskiy wrote:


Signed-off-by: Vladimir Sementsov-Ogievskiy


Reviewed-by: Nikita Lapshin

RE: [PATCH v2 06/12] target/riscv: Support start kernel directly by KVM


> -Original Message-
> From: Anup Patel [mailto:a...@brainfault.org]
> Sent: Monday, December 13, 2021 12:21 PM
> To: Jiangyifei 
> Cc: QEMU Developers ; open list:RISC-V
> ; kvm-ri...@lists.infradead.org; KVM General
> ; libvir-l...@redhat.com; Anup Patel
> ; Palmer Dabbelt ; Alistair
> Francis ; Bin Meng ;
> Fanliang (EulerOS) ; Wubin (H)
> ; Wanghaibin (D) ;
> wanbo (G) ; limingwang (A)
> 
> Subject: Re: [PATCH v2 06/12] target/riscv: Support start kernel directly by 
> KVM
> 
> On Fri, Dec 10, 2021 at 3:37 PM Yifei Jiang  wrote:
> >
> > Get kernel and fdt start address in virt.c, and pass them to KVM when
> > cpu reset. In addition, add kvm_riscv.h to place riscv specific
> > interface.
> >
> > Signed-off-by: Yifei Jiang 
> > Signed-off-by: Mingwang Li 
> > Reviewed-by: Alistair Francis 
> > ---
> >  hw/riscv/boot.c  | 11 
> >  hw/riscv/virt.c  | 54 
> >  include/hw/riscv/boot.h  |  1 +
> >  target/riscv/cpu.c   |  8 ++
> >  target/riscv/cpu.h   |  3 +++
> >  target/riscv/kvm-stub.c  | 25 +++
> >  target/riscv/kvm.c   | 14 +++
> >  target/riscv/kvm_riscv.h | 24 ++
> > target/riscv/meson.build |  2 +-
> >  9 files changed, 125 insertions(+), 17 deletions(-)  create mode
> > 100644 target/riscv/kvm-stub.c  create mode 100644
> > target/riscv/kvm_riscv.h
> >
> > diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c index
> > 519fa455a1..00df6d7810 100644
> > --- a/hw/riscv/boot.c
> > +++ b/hw/riscv/boot.c
> > @@ -317,3 +317,14 @@ void riscv_setup_rom_reset_vec(MachineState
> > *machine, RISCVHartArrayState *harts
> >
> >  return;
> >  }
> > +
> > +void riscv_setup_direct_kernel(hwaddr kernel_addr, hwaddr fdt_addr) {
> > +CPUState *cs;
> > +
> > +for (cs = first_cpu; cs; cs = CPU_NEXT(cs)) {
> > +RISCVCPU *riscv_cpu = RISCV_CPU(cs);
> > +riscv_cpu->env.kernel_addr = kernel_addr;
> > +riscv_cpu->env.fdt_addr = fdt_addr;
> > +}
> > +}
> > diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c index
> > 3af074148e..c8bcd9d9e5 100644
> > --- a/hw/riscv/virt.c
> > +++ b/hw/riscv/virt.c
> > @@ -38,6 +38,7 @@
> >  #include "chardev/char.h"
> >  #include "sysemu/device_tree.h"
> >  #include "sysemu/sysemu.h"
> > +#include "sysemu/kvm.h"
> >  #include "hw/pci/pci.h"
> >  #include "hw/pci-host/gpex.h"
> >  #include "hw/display/ramfb.h"
> > @@ -801,23 +802,25 @@ static void virt_machine_init(MachineState
> *machine)
> >  hart_count, &error_abort);
> >  sysbus_realize(SYS_BUS_DEVICE(&s->soc[i]), &error_abort);
> >
> > -/* Per-socket CLINT */
> > -riscv_aclint_swi_create(
> > -memmap[VIRT_CLINT].base + i * memmap[VIRT_CLINT].size,
> > -base_hartid, hart_count, false);
> > -riscv_aclint_mtimer_create(
> > -memmap[VIRT_CLINT].base + i * memmap[VIRT_CLINT].size
> +
> > -RISCV_ACLINT_SWI_SIZE,
> > -RISCV_ACLINT_DEFAULT_MTIMER_SIZE, base_hartid,
> hart_count,
> > -RISCV_ACLINT_DEFAULT_MTIMECMP,
> RISCV_ACLINT_DEFAULT_MTIME,
> > -RISCV_ACLINT_DEFAULT_TIMEBASE_FREQ, true);
> > -
> > -/* Per-socket ACLINT SSWI */
> > -if (s->have_aclint) {
> > +if (!kvm_enabled()) {
> > +/* Per-socket CLINT */
> >  riscv_aclint_swi_create(
> > -memmap[VIRT_ACLINT_SSWI].base +
> > -i * memmap[VIRT_ACLINT_SSWI].size,
> > -base_hartid, hart_count, true);
> > +memmap[VIRT_CLINT].base + i *
> memmap[VIRT_CLINT].size,
> > +base_hartid, hart_count, false);
> > +riscv_aclint_mtimer_create(
> > +memmap[VIRT_CLINT].base + i *
> memmap[VIRT_CLINT].size +
> > +RISCV_ACLINT_SWI_SIZE,
> > +RISCV_ACLINT_DEFAULT_MTIMER_SIZE, base_hartid,
> hart_count,
> > +RISCV_ACLINT_DEFAULT_MTIMECMP,
> RISCV_ACLINT_DEFAULT_MTIME,
> > +RISCV_ACLINT_DEFAULT_TIMEBASE_FREQ, true);
> > +
> > +/* Per-socket ACLINT SSWI */
> > +if (s->have_aclint) {
> > +riscv_aclint_swi_create(
> > +memmap[VIRT_ACLINT_SSWI].base +
> > +i * memmap[VIRT_ACLINT_SSWI].size,
> > +base_hartid, hart_count, true);
> > +}
> 
> Along with this, we should not generate FDT nodes of ACLINT (or SiFive CLINT)
> when KVM is enabled.
> 

OK, and I will remove M-mode PLIC contexts when kvm is enabled in next series.

Yifei

> >  }
> >
> >  /* Per-socket PLIC hart topology configuration string */ @@
> > -884,6 +887,16 @@ static void virt_machine_init(MachineState *machine)
> >  memory_region_add_subregion(system_memory,
> memmap[VIRT_MROM].base,
> >  mask_rom);
> >
> > +/*
> > + * Only direct boot kernel is currently

Re: Virtio-GPU Xres and Yres seettings

2021-12-20 Thread Pratik Parvati

> > Cc'ing Gerd & Marc-André.
> >
> > On 12/20/21 05:26, Pratik Parvati wrote:
> > > Hi Team,
> > >
> > > I am working on a Virtio-GPU device (backend) for one of our customer
> > > projects - we are using the Virtio-GPU driver (frontend) to drive our
> > > device. Our device code has been written using Qemu virtio-gpu device
> > > code as a reference. Our device is setting the resolution to 1024x768
as
> > > a response to the command received from the driver (i.e,
> > > VIRTIO_GPU_CMD_GET_DISPLAY_INFO) - I also verified that driver is
> > > receiving the response bytes properly, but the next
> > > command (i.e, VIRTIO_GPU_CMD_RESOURCE_CREATE_2D) that device receive
has
> > > a width and height as 4096 and 2160 respectively. The driver is
assuming
> > > a 4k display for some reason and I need your help to understand why
this
> > > is happening.
>
> Wild guess: virtio_gpu_resp_display_info.pmodes[0].enabled is false?

virtio_gpu_resp_display_info.pmodes[0].enabled is true, I have verified
this.

> > > Our display is corrupted for the same Xres and Yres misunderstanding
> > > between the device and the driver
>
> Oh, the VIRTIO_GPU_CMD_GET_DISPLAY_INFO reply is just a hint for the
> driver.  The driver is free to choose whatever it wants, your device
> must be prepared for that.
>
> The linux kms driver specifically returns a long list of standard modes
> (including 4k) to userspace, with the resolution returned by
> VIRTIO_GPU_CMD_GET_DISPLAY_INFO tagged as 'preferred'.  Typically
> userspace (aka display server, aka xorg / wayland / ...) uses the
> preferred resolution by default, but userspace can also pick something
> else and the kernel driver will forward the request to the device.
>
> So, it might also be the software running inside the guest which
> picks 4k ...

Is it possible that EDID bytes are sent wrong to the driver (as a response
to VIRTIO_GPU_CMD_GET_EDID command)?? - I am configuring these bytes the
same way Qemu does.

Thanks for Quick response.

Regards,
Pratik
Regards,
Pratik


On Mon, 20 Dec 2021 at 16:06, Gerd Hoffmann  wrote:

> On Mon, Dec 20, 2021 at 09:55:00AM +0100, Philippe Mathieu-Daudé wrote:
> > Cc'ing Gerd & Marc-André.
> >
> > On 12/20/21 05:26, Pratik Parvati wrote:
> > > Hi Team,
> > >
> > > I am working on a Virtio-GPU device (backend) for one of our customer
> > > projects - we are using the Virtio-GPU driver (frontend) to drive our
> > > device. Our device code has been written using Qemu virtio-gpu device
> > > code as a reference. Our device is setting the resolution to 1024x768
> as
> > > a response to the command received from the driver (i.e,
> > > VIRTIO_GPU_CMD_GET_DISPLAY_INFO) - I also verified that driver is
> > > receiving the response bytes properly, but the next
> > > command (i.e, VIRTIO_GPU_CMD_RESOURCE_CREATE_2D) that device receive
> has
> > > a width and height as 4096 and 2160 respectively. The driver is
> assuming
> > > a 4k display for some reason and I need your help to understand why
> this
> > > is happening.
>
> Wild guess: virtio_gpu_resp_display_info.pmodes[0].enabled is false?
>
> > > Our display is corrupted for the same Xres and Yres misunderstanding
> > > between the device and the driver
>
> Oh, the VIRTIO_GPU_CMD_GET_DISPLAY_INFO reply is just a hint for the
> driver.  The driver is free to choose whatever it wants, your device
> must be prepared for that.
>
> The linux kms driver specifically returns a long list of standard modes
> (including 4k) to userspace, with the resolution returned by
> VIRTIO_GPU_CMD_GET_DISPLAY_INFO tagged as 'preferred'.  Typically
> userspace (aka display server, aka xorg / wayland / ...) uses the
> preferred resolution by default, but userspace can also pick something
> else and the kernel driver will forward the request to the device.
>
> So, it might also be the software running inside the guest which
> picks 4k ...
>
> HTH & take care,
>   Gerd
>
>

[PATCH v2 0/8] migration: Postcopy cleanup on ram disgard

v2:
- add r-bs for Dave
- move mig_cmd_args reference later than index bound check [Dave]
- use chars in tracepoints instead of number of steps [Dave]
- add one patch for postcopy-run tracing

Some queued patches for ram disgard cleanup, and some debug probes.

QEMU's ram disgard logic is probably a bit hard to predict because we send a
bunch of packets to notify the disgarded ranges rather than sending the bitmap.
The packets to send depending on the bitmap layout.

Initially I thought it could be a problem but in reality it's fine so far per
my initial measurement.  So I'm flushing the cleanup/trace patches out because
I think they're still helpful.

Please have a look, thanks.

Peter Xu (8):
  migration: Drop dead code of ram_debug_dump_bitmap()
  migration: Don't return for postcopy_chunk_hostpages()
  migration: Drop postcopy_chunk_hostpages()
  migration: Do chunk page in postcopy_each_ram_send_discard()
  migration: Drop return code for disgard ram process
  migration: Dump sub-cmd name in loadvm_process_command tp
  migration: Finer grained tracepoints for POSTCOPY_LISTEN
  migration: Tracepoint change in postcopy-run bottom half

 migration/migration.c  |   5 +-
 migration/ram.c| 103 ++---
 migration/ram.h|   4 +-
 migration/savevm.c |  24 --
 migration/trace-events |   7 ++-
 5 files changed, 38 insertions(+), 105 deletions(-)

-- 
2.32.0

[PATCH v2] docs: Add measurement calculation details to amd-memory-encryption.txt

2021-12-20 Thread Dov Murik

Add a section explaining how the Guest Owner should calculate the
expected guest launch measurement for SEV and SEV-ES.

Also update the name and link to the SEV API Spec document.

Signed-off-by: Dov Murik 
Suggested-by: Daniel P. Berrangé 

---

v2:
- Explain that firmware must be built without NVRAM store.
---
 docs/amd-memory-encryption.txt | 52 +++---
 1 file changed, 48 insertions(+), 4 deletions(-)

diff --git a/docs/amd-memory-encryption.txt b/docs/amd-memory-encryption.txt
index ffca382b5f..fcb712ee90 100644
--- a/docs/amd-memory-encryption.txt
+++ b/docs/amd-memory-encryption.txt
@@ -43,7 +43,7 @@ The guest policy is passed as plaintext. A hypervisor may 
choose to read it,
 but should not modify it (any modification of the policy bits will result
 in bad measurement). The guest policy is a 4-byte data structure containing
 several flags that restricts what can be done on a running SEV guest.
-See KM Spec section 3 and 6.2 for more details.
+See SEV API Spec [1] section 3 and 6.2 for more details.
 
 The guest policy can be provided via the 'policy' property (see below)
 
@@ -88,7 +88,7 @@ expects.
 LAUNCH_FINISH finalizes the guest launch and destroys the cryptographic
 context.
 
-See SEV KM API Spec [1] 'Launching a guest' usage flow (Appendix A) for the
+See SEV API Spec [1] 'Launching a guest' usage flow (Appendix A) for the
 complete flow chart.
 
 To launch a SEV guest
@@ -113,6 +113,47 @@ a SEV-ES guest:
  - Requires in-kernel irqchip - the burden is placed on the hypervisor to
manage booting APs.
 
+Calculating expected guest launch measurement
+-
+In order to verify the guest launch measurement, The Guest Owner must compute
+it in the exact same way as it is calculated by the AMD-SP.  SEV API Spec [1]
+section 6.5.1 describes the AMD-SP operations:
+
+GCTX.LD is finalized, producing the hash digest of all plaintext data
+imported into the guest.
+
+The launch measurement is calculated as:
+
+HMAC(0x04 || API_MAJOR || API_MINOR || BUILD || GCTX.POLICY || GCTX.LD || 
MNONCE; GCTX.TIK)
+
+where "||" represents concatenation.
+
+The values of API_MAJOR, API_MINOR, BUILD, and GCTX.POLICY can be obtained
+from the 'query-sev' qmp command.
+
+The value of MNONCE is part of the response of 'query-sev-launch-measure': it
+is the last 16 bytes of the base64-decoded data field (see SEV API Spec [1]
+section 6.5.2 Table 52: LAUNCH_MEASURE Measurement Buffer).
+
+The value of GCTX.LD is SHA256(firmware_blob || kernel_hashes_blob || 
vmsas_blob),
+where:
+
+* firmware_blob is the content of the entire firmware flash file (for example,
+  OVMF.fd).  Note that you must build a stateless firmware file which doesn't
+  use an NVRAM store, because the NVRAM area is not measured, and therefore it
+  is not secure to use a firmware which uses state from an NVRAM store.
+* if kernel is used, and kernel-hashes=on, then kernel_hashes_blob is the
+  content of PaddedSevHashTable (including the zero padding), which itself
+  includes the hashes of kernel, initrd, and cmdline that are passed to the
+  guest.  The PaddedSevHashTable struct is defined in target/i386/sev.c .
+* if SEV-ES is enabled (policy & 0x4 != 0), vmsas_blob is the concatenation of
+  all VMSAs of the guest vcpus.  Each VMSA is 4096 bytes long; its content is
+  defined inside Linux kernel code as struct vmcb_save_area, or in AMD APM
+  Volume 2 [2] Table B-2: VMCB Layout, State Save Area.
+
+If kernel hashes are not used, or SEV-ES is disabled, use empty blobs for
+kernel_hashes_blob and vmsas_blob as needed.
+
 Debugging
 ---
 Since the memory contents of a SEV guest are encrypted, hypervisor access to
@@ -134,8 +175,11 @@ References
 AMD Memory Encryption whitepaper:
 
https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
 
-Secure Encrypted Virtualization Key Management:
-[1] 
http://developer.amd.com/wordpress/media/2017/11/55766_SEV-KM-API_Specification.pdf
+Secure Encrypted Virtualization API:
+[1] 
https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf
+
+AMD64 Architecture Programmer's Manual Volume 2: System Programming
+[2] https://www.amd.com/system/files/TechDocs/24593.pdf
 
 KVM Forum slides:
 
http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf

base-commit: 212a33d3b0c65ae2583bb1d06cb140cd0890894c
-- 
2.25.1

Re: [PATCH] schemas: add missing vim modeline

2021-12-20 Thread Markus Armbruster

Victor Toso  writes:

> Similar to f7160f3218 "schemas: Add vim modeline"
>
> Signed-off-by: Victor Toso 

Acked-by: Markus Armbruster

[PATCH] schemas: add missing vim modeline

2021-12-20 Thread Victor Toso

Similar to f7160f3218 "schemas: Add vim modeline"

Signed-off-by: Victor Toso 
---
 qapi/audio.json  | 1 +
 qapi/compat.json | 1 +
 qapi/replay.json | 1 +
 qapi/trace.json  | 1 +
 4 files changed, 4 insertions(+)

diff --git a/qapi/audio.json b/qapi/audio.json
index 9cba0df8a4..fe3b506ec3 100644
--- a/qapi/audio.json
+++ b/qapi/audio.json
@@ -1,4 +1,5 @@
 # -*- mode: python -*-
+# vim: filetype=python
 #
 # Copyright (C) 2015-2019 Zoltán Kővágó 
 #
diff --git a/qapi/compat.json b/qapi/compat.json
index dd7261ae2a..c53b69fe3f 100644
--- a/qapi/compat.json
+++ b/qapi/compat.json
@@ -1,4 +1,5 @@
 # -*- Mode: Python -*-
+# vim: filetype=python
 
 ##
 # = Compatibility policy
diff --git a/qapi/replay.json b/qapi/replay.json
index bfd83d7591..b4d1ba253b 100644
--- a/qapi/replay.json
+++ b/qapi/replay.json
@@ -1,4 +1,5 @@
 # -*- Mode: Python -*-
+# vim: filetype=python
 #
 
 ##
diff --git a/qapi/trace.json b/qapi/trace.json
index eedfded512..119509f565 100644
--- a/qapi/trace.json
+++ b/qapi/trace.json
@@ -1,4 +1,5 @@
 # -*- mode: python -*-
+# vim: filetype=python
 #
 # Copyright (C) 2011-2016 Lluís Vilanova 
 #
-- 
2.33.1

[PATCH v2 1/8] migration: Drop dead code of ram_debug_dump_bitmap()

I planned to add "#ifdef DEBUG_POSTCOPY" around the function too because
otherwise it'll be compiled into qemu binary even if it'll never be used.  Then
I found that maybe it's easier to just drop it for good..

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Peter Xu 
---
 migration/ram.c | 39 ---
 migration/ram.h |  2 --
 2 files changed, 41 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 57efa67f20..7d9c8a508b 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2408,40 +2408,6 @@ static void ram_state_reset(RAMState *rs)
 
 #define MAX_WAIT 50 /* ms, half buffered_file limit */
 
-/*
- * 'expected' is the value you expect the bitmap mostly to be full
- * of; it won't bother printing lines that are all this value.
- * If 'todump' is null the migration bitmap is dumped.
- */
-void ram_debug_dump_bitmap(unsigned long *todump, bool expected,
-   unsigned long pages)
-{
-int64_t cur;
-int64_t linelen = 128;
-char linebuf[129];
-
-for (cur = 0; cur < pages; cur += linelen) {
-int64_t curb;
-bool found = false;
-/*
- * Last line; catch the case where the line length
- * is longer than remaining ram
- */
-if (cur + linelen > pages) {
-linelen = pages - cur;
-}
-for (curb = 0; curb < linelen; curb++) {
-bool thisbit = test_bit(cur + curb, todump);
-linebuf[curb] = thisbit ? '1' : '.';
-found = found || (thisbit != expected);
-}
-if (found) {
-linebuf[curb] = '\0';
-fprintf(stderr,  "0x%08" PRIx64 " : %s\n", cur, linebuf);
-}
-}
-}
-
 /*  functions for postcopy * */
 
 void ram_postcopy_migrated_memory_release(MigrationState *ms)
@@ -2669,11 +2635,6 @@ int ram_postcopy_send_discard_bitmap(MigrationState *ms)
 if (ret) {
 return ret;
 }
-
-#ifdef DEBUG_POSTCOPY
-ram_debug_dump_bitmap(block->bmap, true,
-  block->used_length >> TARGET_PAGE_BITS);
-#endif
 }
 trace_ram_postcopy_send_discard_bitmap();
 
diff --git a/migration/ram.h b/migration/ram.h
index c515396a9a..f543e25765 100644
--- a/migration/ram.h
+++ b/migration/ram.h
@@ -55,8 +55,6 @@ void mig_throttle_counter_reset(void);
 uint64_t ram_pagesize_summary(void);
 int ram_save_queue_pages(const char *rbname, ram_addr_t start, ram_addr_t len);
 void acct_update_position(QEMUFile *f, size_t size, bool zero);
-void ram_debug_dump_bitmap(unsigned long *todump, bool expected,
-   unsigned long pages);
 void ram_postcopy_migrated_memory_release(MigrationState *ms);
 /* For outgoing discard bitmap */
 int ram_postcopy_send_discard_bitmap(MigrationState *ms);
-- 
2.32.0

RE: [PATCH v2 12/12] target/riscv: Support virtual time context synchronization


> -Original Message-
> From: Richard Henderson [mailto:richard.hender...@linaro.org]
> Sent: Monday, December 13, 2021 11:22 PM
> To: Jiangyifei ; qemu-devel@nongnu.org;
> qemu-ri...@nongnu.org
> Cc: kvm-ri...@lists.infradead.org; k...@vger.kernel.org;
> libvir-l...@redhat.com; anup.pa...@wdc.com; pal...@dabbelt.com;
> alistair.fran...@wdc.com; bin.m...@windriver.com; Fanliang (EulerOS)
> ; Wubin (H) ; Wanghaibin (D)
> ; wanbo (G) ;
> limingwang (A) 
> Subject: Re: [PATCH v2 12/12] target/riscv: Support virtual time context
> synchronization
> 
> On 12/10/21 2:07 AM, Yifei Jiang via wrote:
> > +static bool kvmtimer_needed(void *opaque) {
> > +return kvm_enabled();
> > +}
> > +
> > +
> > +static const VMStateDescription vmstate_kvmtimer = {
> > +.name = "cpu/kvmtimer",
> > +.version_id = 1,
> > +.minimum_version_id = 1,
> > +.needed = kvmtimer_needed,
> > +.fields = (VMStateField[]) {
> > +VMSTATE_UINT64(env.kvm_timer_time, RISCVCPU),
> > +VMSTATE_UINT64(env.kvm_timer_compare, RISCVCPU),
> > +VMSTATE_UINT64(env.kvm_timer_state, RISCVCPU),
> > +
> > +VMSTATE_END_OF_LIST()
> > +}
> > +};
> > +
> > +static int cpu_post_load(void *opaque, int version_id) {
> > +RISCVCPU *cpu = opaque;
> > +CPURISCVState *env = &cpu->env;
> > +
> > +if (kvm_enabled()) {
> > +env->kvm_timer_dirty = true;
> > +}
> > +return 0;
> > +}
> 
> This post-load belongs on the vmstate_kvmtimer struct, so that you need not
> re-check kvm_enabled().
> 
> >   const VMStateDescription vmstate_riscv_cpu = {
> >   .name = "cpu",
> > -.version_id = 3,
> > -.minimum_version_id = 3,
> > +.version_id = 4,
> > +.minimum_version_id = 4,
> > +.post_load = cpu_post_load,
> 
> No need for version change.
> 
> 
> r~

Ok, it will be modified in the next series.

Yifei

Re: [PATCH] tests/qtest/virtio-net-failover: Use g_random_int() instead of g_test_rand_int()


On 20/12/2021 11:27, Thomas Huth wrote:

g_test_rand_int() must not be called before g_test_init(), otherwise
the glib will show a "g_rand_int: assertion 'rand != NULL' failed"
message in the log. So we could change the order here, but actually,
g_test_rand_int() seems also the wrong choice here, since we're using
it to create a temporary file name, which certainly should not depend
on the "--seed" CLI option of the g_test suite. Thus let's use the
g_random_int() function instead.

Reported-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
  tests/qtest/virtio-net-failover.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qtest/virtio-net-failover.c 
b/tests/qtest/virtio-net-failover.c
index 4b2ba8a106..70b94bf18f 100644
--- a/tests/qtest/virtio-net-failover.c
+++ b/tests/qtest/virtio-net-failover.c
@@ -1308,7 +1308,7 @@ int main(int argc, char **argv)
  {
  const gchar *tmpdir = g_get_tmp_dir();
  gchar *tmpfile = g_strdup_printf("%s/failover_test_migrate-%u-%u",
- tmpdir, getpid(), g_test_rand_int());
+ tmpdir, getpid(), g_random_int());
  int ret;
  
  g_test_init(&argc, &argv, NULL);


Reviewed-by: Laurent Vivier

Re: [PATCH v2 00/15] hw/nvme: SR-IOV with Virtualization Enhancements

2021-12-20 Thread Klaus Jensen

On Nov 25 15:15, Łukasz Gieryk wrote:
> On Wed, Nov 24, 2021 at 09:03:06AM +0100, Klaus Jensen wrote:
> > Hi Lukasz,
> > 
> > I've been through this. I have a couple of review comments, but overall
> > looks good for inclusion in nvme-next. Would be nice to get this in
> > early in the cycle so it can mature there for 7.0.
> 
> We (I’m speaking on behalf of the other Lukasz) are really happy to
> read that. We will do our best to make it happen.
> 

Keith, do you have any comments on this series - otherwise I'd like to
stage this for nvme-next come January.

> > 
> > I'd like that we mark this support experimental, so we can easily do
> > some changes to how parameters work since I'm not sure we completely
> > agree on that yet.
> > 
> > By the way, in the future, please add me and Keith as CCs on the entire
> > series so we get CC'ed on replies to the cover-letter ;)
> > 
> 
> > > List of known gaps and nice-to-haves:
> > > 
> > > 1) Interaction of secondary controllers with namespaces is not 100%
> > > following the spec
> > > 
> > > The limitation: VF has to be visible on the PCI bus first, and only then
> > > such VF can have a namespace attached.
> > > 
> > 
> > Looking at the spec I'm not even sure what the expected behavior is
> > supposed to be, can you elaborate? I rebased this on latest, and with
> > Hannes changes, shared namespaces will be attached by default, which
> > seems to be reasonable.
> 
> An example flow:
> 
> # Release flexible resources from PF (assuming it’s /dev/nvme0)
> nvme virt-mgmt -c 0 -r 0 -n 0 -a 1 /dev/nvme0
> nvme virt-mgmt -c 0 -r 1 -n 0 -a 1 /dev/nvme0
> echo 1 > /sys/class/nvme/nvme0/reset_controller
> # Bind sane minimums to VF1 (cntlid=1) and set it online
> nvme virt-mgmt -c 1 -r 0 -n 5 -a 8 /dev/nvme0
> nvme virt-mgmt -c 1 -r 1 -n 5 -a 8 /dev/nvme0
> nvme virt-mgmt -c 1 -a 9 /dev/nvme0
> # Enable 2 VFs
> echo 2 > /sys/bus/pci/devices//sriov_numvfs
> # PF, VF1 and VF2 are visible on PCI
> lspci | grep Non-Volatile
> # The NVMe driver is bound to PF and VF1 (the only online VF)
> nvme list -v
> # VFs shall eventually not support Ns Management/Attachment commands,
> # and namespaces should be attached to VFs (i.e., their secondary
> # controllers) through the PF.
> # A namespace can be attached to VF1, VF2
> nvme attach-ns /dev/nvme0 -c 1 -n X
> nvme attach-ns /dev/nvme0 -c 2 -n X
> # According to the spec this should also succeed, but today it won’t
> nvme attach-ns /dev/nvme0 -c 3 -n X
> 
> VF3’s NvmeCtrl object is not yet allocated, so today there’s nothing
> for nvme_subsys_ctrl() to return for cntlid=3, besides NULL (the
> current behavior) or SUBSYS_SLOT_RSVD.
> 
> Relevant use cases:
>  - admin can configure disabled VFs,
>  - information about attached ns persists when VFs are disabled,
> are not that critical, but of course it’s a discrepancy from what a
> real device can handle.
> 
> In my opinion, to handle the cases correctly, information about attached
> namespaces could be moved to subsystem. Could you share your thoughts
> whether such approach would make sense?
> 

Thanks for the explaination.

I actually already had this sort-of conversation with Hannes[1].
Different issue, but same solution (that is, having a per-CNTLID
namespace list maintained in the subsystem).

I have a refactor series coming up that will address this, so for now, I
don't worry about this not being implemented exactly as the spec defines.

  [1]: https://lore.kernel.org/all/20210909094308.122038-1-h...@suse.de/t/#u


signature.asc
Description: PGP signature

Re: [PATCH] hw/nvram: at24 return 0xff if 1 byte address

Hi Patrick,

On 12/20/21 01:32, Patrick Venture wrote:
> The at24 eeproms are 2 byte devices that return 0xff when they are read
> from with a partial (1-byte) address written.  This distinction was
> found comparing model behavior to real hardware testing.
> 
> Tested: `i2ctransfer -f -y 45 w1@85 0 r1` returns 0xff instead of next
> byte
> 
> Signed-off-by: Patrick Venture 
> ---
>  hw/nvram/eeprom_at24c.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c
> index a9e3702b00..184fac9702 100644
> --- a/hw/nvram/eeprom_at24c.c
> +++ b/hw/nvram/eeprom_at24c.c
> @@ -62,7 +62,9 @@ int at24c_eeprom_event(I2CSlave *s, enum i2c_event event)
>  case I2C_START_SEND:
>  case I2C_START_RECV:
>  case I2C_FINISH:
> -ee->haveaddr = 0;
> +if (event != I2C_START_RECV) {
> +ee->haveaddr = 0;
> +}

Alternatively (matter of taste, I find it easier to read):

   case I2C_START_SEND:
   case I2C_FINISH:
   ee->haveaddr = 0;
   /* fallthrough */
   case I2C_START_RECV:

>  DPRINTK("clear\n");
>  if (ee->blk && ee->changed) {
>  int len = blk_pwrite(ee->blk, 0, ee->mem, ee->rsize, 0);
> @@ -86,6 +88,10 @@ uint8_t at24c_eeprom_recv(I2CSlave *s)
>  EEPROMState *ee = AT24C_EE(s);
>  uint8_t ret;
>  
> +if (ee->haveaddr == 1) {
> +return 0xff;

Don't we need to increase ee->haveaddr?

> +}
> +
>  ret = ee->mem[ee->cur];
>  
>  ee->cur = (ee->cur + 1u) % ee->rsize;

Here for parity with send, what about:

if (ee->haveaddr < 2) {
ret = 0xff;
ee->haveaddr++;
} else {
ret = ee->mem[ee->cur];
ee->cur = (ee->cur + 1u) % ee->rsize;
}

?

[PATCH RFC] MAINTAINERS: split out s390x sections

2021-12-20 Thread Cornelia Huck

Split out some more specialized devices etc., so that we can build
smarter lists of people to be put on cc: in the future.

Signed-off-by: Cornelia Huck 
---

As discussed offlist. Some notes:
- The new sections have inherited the maintainers of the sections
  they have been split out of (except where people had already
  volunteered). That's easy to change, obviously, and I hope that
  the cc: list already contains people who might have interest in
  volunteering for some sections.
- I may not have gotten the F: patterns correct, please double check.
- I'm also not sure about where in the MAINTAINERS file the new
  sections should go; if you have a better idea, please speak up.
- Also, if you have better ideas regarding the sections, please
  speak up as well :)
- Pull requests will probably continue the same way as now (i.e.
  patches picked up at the top level and then sent, except for some
  things like tcg which may go separately.) Not sure if it would
  make sense to try out the submaintainer pull request model again,
  I don't think it made life easier in the past, and now we have
  the b4 tool to pick patches easily anyway. It might be a good
  idea to check which of the tree locations should stay, or if we
  want to have new ones.

---
 MAINTAINERS | 86 ++---
 1 file changed, 75 insertions(+), 11 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9a8d1bdf727d..d1916f075386 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -297,7 +297,6 @@ M: David Hildenbrand 
 S: Maintained
 F: target/s390x/
 F: target/s390x/tcg
-F: target/s390x/cpu_models_*.[ch]
 F: hw/s390x/
 F: disas/s390.c
 F: tests/tcg/s390x/
@@ -396,16 +395,10 @@ M: Halil Pasic 
 M: Christian Borntraeger 
 S: Supported
 F: target/s390x/kvm/
-F: target/s390x/ioinst.[ch]
 F: target/s390x/machine.c
 F: target/s390x/sigp.c
-F: target/s390x/cpu_features*.[ch]
-F: target/s390x/cpu_models.[ch]
 F: hw/s390x/pv.c
 F: include/hw/s390x/pv.h
-F: hw/intc/s390_flic.c
-F: hw/intc/s390_flic_kvm.c
-F: include/hw/s390x/s390_flic.h
 F: gdb-xml/s390*.xml
 T: git https://github.com/borntraeger/qemu.git s390-next
 L: qemu-s3...@nongnu.org
@@ -1529,12 +1522,8 @@ S390 Virtio-ccw
 M: Halil Pasic 
 M: Christian Borntraeger 
 S: Supported
-F: hw/char/sclp*.[hc]
-F: hw/char/terminal3270.c
 F: hw/s390x/
 F: include/hw/s390x/
-F: hw/watchdog/wdt_diag288.c
-F: include/hw/watchdog/wdt_diag288.h
 F: configs/devices/s390x-softmmu/default.mak
 F: tests/avocado/machine_s390_ccw_virtio.py
 T: git https://github.com/borntraeger/qemu.git s390-next
@@ -1559,6 +1548,80 @@ F: hw/s390x/s390-pci*
 F: include/hw/s390x/s390-pci*
 L: qemu-s3...@nongnu.org
 
+S390 channel subsystem
+M: Halil Pasic 
+M: Christian Borntraeger 
+S: Supported
+F: hw/s390x/ccw-device.[ch]
+F: hw/s390x/css.c
+F: hw/s390x/css-bridge.c
+F: include/hw/s390x/css.h
+F: include/hw/s390x/css-bridge.h
+F: include/hw/s390x/ioinst.h
+F: target/s390x/ioinst.c
+L: qemu-s3...@nongnu.org
+
+3270 device
+M: Halil Pasic 
+M: Christian Borntraeger 
+S: Odd fixes
+F: include/hw/s390x/3270-ccw.h
+F: hw/char/terminal3270.c
+F: hw/s390x/3270-ccw.c
+L: qemu-s3...@nongnu.org
+
+diag 288 watchdog
+M: Halil Pasic 
+M: Christian Borntraeger 
+S: Supported
+F: hw/watchdog/wdt_diag288.c
+F: include/hw/watchdog/wdt_diag288.h
+L: qemu-s3...@nongnu.org
+
+S390 CPU models
+M: David Hildenbrand 
+S: Maintained
+F: target/s390x/cpu_features*.[ch]
+F: target/s390x/cpu_models.[ch]
+L: qemu-s3...@nongnu.org
+
+S390 storage key device
+M: Halil Pasic 
+M: Christian Borntraeger 
+S: Supported
+F: hw/s390x/storage-keys.h
+F: hw/390x/s390-skeys*.c
+L: qemu-s3...@nongnu.org
+
+S390 storage attribute device
+M: Halil Pasic 
+M: Christian Borntraeger 
+S: Supported
+F: hw/s390x/storage-attributes.h
+F: hw/s390/s390-stattrib*.c
+L: qemu-s3...@nongnu.org
+
+S390 SCLP-backed devices
+M: Halil Pasic 
+M: Christian Borntraeger 
+S: Supported
+F: include/hw/s390x/event-facility.h
+F: include/hw/s390x/sclp.h
+F: hw/char/sclp*.[hc]
+F: hw/s390x/event-facility.c
+F: hw/s390x/sclp*.c
+L: qemu-s3...@nongnu.org
+
+S390 floating interrupt controller
+M: Halil Pasic 
+M: Christian Borntraeger 
+M: David Hildenbrand 
+S: Supported
+F: hw/intc/s390_flic.c
+F: hw/intc/s390_flic_kvm.c
+F: include/hw/s390x/s390_flic.h
+L: qemu-s3...@nongnu.org
+
 X86 Machines
 
 PC
@@ -1957,6 +2020,7 @@ M: Halil Pasic 
 S: Supported
 F: hw/s390x/virtio-ccw*.[hc]
 F: hw/s390x/vhost-vsock-ccw.c
+F: hw/s390x/vhost-user-fs-ccw.c
 T: git https://gitlab.com/cohuck/qemu.git s390-next
 T: git https://github.com/borntraeger/qemu.git s390-next
 L: qemu-s3...@nongnu.org
-- 
2.31.1

[PATCH] failover: Silence warning messages during qtest

virtio-net-failover test tries several device combinations that produces
some expected warnings.
These warning can be confusing, so we disable them during the qtest
sequence.

Reported-by: Thomas Huth 
Signed-off-by: Laurent Vivier 
---
 hw/net/virtio-net.c   | 3 ++-
 migration/migration.c | 4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index f2014d5ea0b3..c64a6b9d1745 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -44,6 +44,7 @@
 #include "hw/pci/pci.h"
 #include "net_rx_pkt.h"
 #include "hw/virtio/vhost.h"
+#include "sysemu/qtest.h"
 
 #define VIRTIO_NET_VM_VERSION11
 
@@ -925,7 +926,7 @@ static void virtio_net_set_features(VirtIODevice *vdev, 
uint64_t features)
 qapi_event_send_failover_negotiated(n->netclient_name);
 qatomic_set(&n->failover_primary_hidden, false);
 failover_add_primary(n, &err);
-if (err) {
+if (err && !qtest_enabled()) {
 warn_report_err(err);
 }
 }
diff --git a/migration/migration.c b/migration/migration.c
index 3de11ae921e0..065216561063 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -60,6 +60,7 @@
 #include "qemu/yank.h"
 #include "sysemu/cpus.h"
 #include "yank_functions.h"
+#include "sysemu/qtest.h"
 
 #define MAX_THROTTLE  (128 << 20)  /* Migration transfer speed throttling 
*/
 
@@ -3766,7 +3767,8 @@ static void qemu_savevm_wait_unplug(MigrationState *s, 
int old_state,
 while (timeout-- && qemu_savevm_state_guest_unplug_pending()) {
 qemu_sem_timedwait(&s->wait_unplug_sem, 250);
 }
-if (qemu_savevm_state_guest_unplug_pending()) {
+if (qemu_savevm_state_guest_unplug_pending() &&
+!qtest_enabled()) {
 warn_report("migration: partially unplugged device on "
 "failure");
 }
-- 
2.33.1

Re: [RFC PATCH v2 05/14] block/mirror.c: use of job helpers in drivers to avoid TOC/TOU

2021-12-20 Thread Vladimir Sementsov-Ogievskiy


20.12.2021 13:34, Emanuele Giuseppe Esposito wrote:



On 18/12/2021 12:53, Vladimir Sementsov-Ogievskiy wrote:

04.11.2021 17:53, Emanuele Giuseppe Esposito wrote:

Once job lock is used and aiocontext is removed, mirror has
to perform job operations under the same critical section,
using the helpers prepared in previous commit.

Note: at this stage, job_{lock/unlock} and job lock guard macros
are *nop*.

Signed-off-by: Emanuele Giuseppe Esposito 
---
  block/mirror.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/block/mirror.c b/block/mirror.c
index 00089e519b..f22fa7da6e 100644
--- a/block/mirror.c
+++ b/block/mirror.c
@@ -653,7 +653,7 @@ static int mirror_exit_common(Job *job)
  BlockDriverState *target_bs;
  BlockDriverState *mirror_top_bs;
  Error *local_err = NULL;
-    bool abort = job->ret < 0;
+    bool abort = job_has_failed(job);
  int ret = 0;
  if (s->prepared) {
@@ -1161,9 +1161,7 @@ static void mirror_complete(Job *job, Error **errp)
  s->should_complete = true;
  /* If the job is paused, it will be re-entered when it is resumed */
-    if (!job->paused) {
-    job_enter(job);
-    }
+    job_enter_not_paused(job);
  }
  static void coroutine_fn mirror_pause(Job *job)
@@ -1182,7 +1180,7 @@ static bool mirror_drained_poll(BlockJob *job)
   * from one of our own drain sections, to avoid a deadlock waiting for
   * ourselves.
   */
-    if (!s->common.job.paused && !job_is_cancelled(&job->job) && !s->in_drain) 
{
+    if (job_not_paused_nor_cancelled(&s->common.job) && !s->in_drain) {
  return true;
  }



Why to introduce a separate API function for every use case?

Could we instead just use WITH_JOB_LOCK_GUARD() ?



This implies making the struct job_mutex public. Is that ok for you?



Yes, I think it's OK.

Alternatively, you can use job_lock() / job_unlock(), or even rewrite 
WITH_JOB_LOCK_GUARD() macro using job_lock/job_unlock, to keep mutex private.. 
But I don't think it really worth it now.

Note that struct Job is already public, so if we'll use per-job mutex in future 
it still is not a problem. Only when we decide to make struct Job private, 
we'll have to decide something about JOB_LOCK_GUARD(), and at this point we'll 
just rewrite it to work through some helper function instead of directly 
touching the mutex.


--
Best regards,
Vladimir

[PATCH v3 09/12] target/riscv: Add host cpu type

'host' type cpu is set isa to RV32 or RV64 simply, more isa info
will obtain from KVM in kvm_arch_init_vcpu()

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Reviewed-by: Alistair Francis 
Reviewed-by: Anup Patel 
---
 target/riscv/cpu.c | 15 +++
 target/riscv/cpu.h |  1 +
 2 files changed, 16 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 3fc3a9c45b..c6d979594b 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -213,6 +213,18 @@ static void rv32_imafcu_nommu_cpu_init(Object *obj)
 }
 #endif
 
+#if defined(CONFIG_KVM)
+static void riscv_host_cpu_init(Object *obj)
+{
+CPURISCVState *env = &RISCV_CPU(obj)->env;
+#if defined(TARGET_RISCV32)
+set_misa(env, MXL_RV32, 0);
+#elif defined(TARGET_RISCV64)
+set_misa(env, MXL_RV64, 0);
+#endif
+}
+#endif
+
 static ObjectClass *riscv_cpu_class_by_name(const char *cpu_model)
 {
 ObjectClass *oc;
@@ -814,6 +826,9 @@ static const TypeInfo riscv_cpu_type_infos[] = {
 .class_init = riscv_cpu_class_init,
 },
 DEFINE_CPU(TYPE_RISCV_CPU_ANY,  riscv_any_cpu_init),
+#if defined(CONFIG_KVM)
+DEFINE_CPU(TYPE_RISCV_CPU_HOST, riscv_host_cpu_init),
+#endif
 #if defined(TARGET_RISCV32)
 DEFINE_CPU(TYPE_RISCV_CPU_BASE32,   rv32_base_cpu_init),
 DEFINE_CPU(TYPE_RISCV_CPU_IBEX, rv32_ibex_cpu_init),
diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index 2807eb1bcb..e7dba35acb 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -45,6 +45,7 @@
 #define TYPE_RISCV_CPU_SIFIVE_E51   RISCV_CPU_TYPE_NAME("sifive-e51")
 #define TYPE_RISCV_CPU_SIFIVE_U34   RISCV_CPU_TYPE_NAME("sifive-u34")
 #define TYPE_RISCV_CPU_SIFIVE_U54   RISCV_CPU_TYPE_NAME("sifive-u54")
+#define TYPE_RISCV_CPU_HOST RISCV_CPU_TYPE_NAME("host")
 
 #if defined(TARGET_RISCV32)
 # define TYPE_RISCV_CPU_BASETYPE_RISCV_CPU_BASE32
-- 
2.19.1

[PATCH v3 12/12] target/riscv: Support virtual time context synchronization

Add virtual time context description to vmstate_kvmtimer. After cpu being
loaded, virtual time context is updated to KVM.

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Reviewed-by: Anup Patel 
---
 target/riscv/machine.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/target/riscv/machine.c b/target/riscv/machine.c
index ad8248ebfd..95eb82792a 100644
--- a/target/riscv/machine.c
+++ b/target/riscv/machine.c
@@ -164,6 +164,35 @@ static const VMStateDescription vmstate_pointermasking = {
 }
 };
 
+static bool kvmtimer_needed(void *opaque)
+{
+return kvm_enabled();
+}
+
+static int cpu_post_load(void *opaque, int version_id)
+{
+RISCVCPU *cpu = opaque;
+CPURISCVState *env = &cpu->env;
+
+env->kvm_timer_dirty = true;
+return 0;
+}
+
+static const VMStateDescription vmstate_kvmtimer = {
+.name = "cpu/kvmtimer",
+.version_id = 1,
+.minimum_version_id = 1,
+.needed = kvmtimer_needed,
+.post_load = cpu_post_load,
+.fields = (VMStateField[]) {
+VMSTATE_UINT64(env.kvm_timer_time, RISCVCPU),
+VMSTATE_UINT64(env.kvm_timer_compare, RISCVCPU),
+VMSTATE_UINT64(env.kvm_timer_state, RISCVCPU),
+
+VMSTATE_END_OF_LIST()
+}
+};
+
 const VMStateDescription vmstate_riscv_cpu = {
 .name = "cpu",
 .version_id = 3,
@@ -218,6 +247,7 @@ const VMStateDescription vmstate_riscv_cpu = {
 &vmstate_hyper,
 &vmstate_vector,
 &vmstate_pointermasking,
+&vmstate_kvmtimer,
 NULL
 }
 };
-- 
2.19.1

[PATCH v2 8/8] migration: Tracepoint change in postcopy-run bottom half

Remove the old two tracepoints and they're even near each other:

trace_loadvm_postcopy_handle_run_cpu_sync()
trace_loadvm_postcopy_handle_run_vmstart()

Add trace_loadvm_postcopy_handle_run_bh() with a finer granule trace.

Signed-off-by: Peter Xu 
---
 migration/savevm.c | 12 +---
 migration/trace-events |  3 +--
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/migration/savevm.c b/migration/savevm.c
index 25face6de0..de2577c251 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2005,13 +2005,19 @@ static void loadvm_postcopy_handle_run_bh(void *opaque)
 Error *local_err = NULL;
 MigrationIncomingState *mis = opaque;
 
+trace_loadvm_postcopy_handle_run_bh("enter");
+
 /* TODO we should move all of this lot into postcopy_ram.c or a shared code
  * in migration.c
  */
 cpu_synchronize_all_post_init();
 
+trace_loadvm_postcopy_handle_run_bh("after cpu sync");
+
 qemu_announce_self(&mis->announce_timer, migrate_announce_params());
 
+trace_loadvm_postcopy_handle_run_bh("after announce");
+
 /* Make sure all file formats flush their mutable metadata.
  * If we get an error here, just don't restart the VM yet. */
 bdrv_invalidate_cache_all(&local_err);
@@ -2021,9 +2027,7 @@ static void loadvm_postcopy_handle_run_bh(void *opaque)
 autostart = false;
 }
 
-trace_loadvm_postcopy_handle_run_cpu_sync();
-
-trace_loadvm_postcopy_handle_run_vmstart();
+trace_loadvm_postcopy_handle_run_bh("after invalidate cache");
 
 dirty_bitmap_mig_before_vm_start();
 
@@ -2036,6 +2040,8 @@ static void loadvm_postcopy_handle_run_bh(void *opaque)
 }
 
 qemu_bh_delete(mis->bh);
+
+trace_loadvm_postcopy_handle_run_bh("exit");
 }
 
 /* After all discards we can start running and asking for pages */
diff --git a/migration/trace-events b/migration/trace-events
index 77d1237d89..e165687af2 100644
--- a/migration/trace-events
+++ b/migration/trace-events
@@ -16,8 +16,7 @@ loadvm_handle_recv_bitmap(char *s) "%s"
 loadvm_postcopy_handle_advise(void) ""
 loadvm_postcopy_handle_listen(const char *str) "%s"
 loadvm_postcopy_handle_run(void) ""
-loadvm_postcopy_handle_run_cpu_sync(void) ""
-loadvm_postcopy_handle_run_vmstart(void) ""
+loadvm_postcopy_handle_run_bh(const char *str) "%s"
 loadvm_postcopy_handle_resume(void) ""
 loadvm_postcopy_ram_handle_discard(void) ""
 loadvm_postcopy_ram_handle_discard_end(void) ""
-- 
2.32.0

Re: [PATCH] hw: m68k: Add virt compat machine type for 7.0


Le 20/12/2021 à 09:17, Cornelia Huck a écrit :

On Sat, Dec 18 2021, Laurent Vivier  wrote:


Signed-off-by: Laurent Vivier 
---
Based-On: <20211217143948.289995-1-coh...@redhat.com>

  hw/m68k/virt.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)


Oh, I didn't realize we do it for m68k as well.


virt-m68k is only a toy and is only used by debian for their m68k buildd.

So there is no problem if you don't manage the update, I will.



Reviewed-by: Cornelia Huck 



Thanks,
Laurent

Re: [PATCH v4 5/7] For qemu_io* functions support --image-opts argument, which conflicts with -f argument from qemu_io_args.



On 12/13/21 18:32, Vladimir Sementsov-Ogievskiy wrote:


For QemuIoInteractive use new wrapper as well, which allows relying on
default format.

Signed-off-by: Vladimir Sementsov-Ogievskiy




Reviewed-by: Nikita Lapshin

Re: [PATCH v5 28/31] block.c: assert BQL lock held in bdrv_co_invalidate_cache

2021-12-20 Thread Emanuele Giuseppe Esposito





On 17/12/2021 17:38, Emanuele Giuseppe Esposito wrote:



On 17/12/2021 12:04, Hanna Reitz wrote:

On 24.11.21 07:44, Emanuele Giuseppe Esposito wrote:

bdrv_co_invalidate_cache is special: it is an I/O function,


I still don’t believe it is, but well.

(Yes, it is called by a test in an iothread, but I believe we’ve seen 
that the tests simply sometimes test things that shouldn’t be allowed.)



but uses the block layer permission API, which is GS.

Because of this, we can assert that either the function is
being called with BQL held, and thus can use the permission API,
or make sure that the permission API is not used, by ensuring that
bs (and parents) .open_flags does not contain BDRV_O_INACTIVE.

Signed-off-by: Emanuele Giuseppe Esposito 
---
  block.c | 26 ++
  1 file changed, 26 insertions(+)

diff --git a/block.c b/block.c
index a0309f827d..805974676b 100644
--- a/block.c
+++ b/block.c
@@ -6574,6 +6574,26 @@ void bdrv_init_with_whitelist(void)
  bdrv_init();
  }
+static bool bdrv_is_active(BlockDriverState *bs)
+{
+    BdrvChild *parent;
+
+    if (bs->open_flags & BDRV_O_INACTIVE) {
+    return false;
+    }
+
+    QLIST_FOREACH(parent, &bs->parents, next_parent) {
+    if (parent->klass->parent_is_bds) {
+    BlockDriverState *parent_bs = parent->opaque;


This looks like a really bad hack to me.  We purposefully have made 
the parent link opaque so that a BDS cannot easily reach its parents.  
All accesses should go through BdrvChildClass methods.


I also don’t understand why we need to query parents at all.  The only 
fact that determines whether the current BDS will have its permissions 
changed is whether the BDS itself is active or inactive.  Sure, we’ll 
invoke bdrv_co_invalidate_cache() on the parents, too, but then we 
could simply let the assertion fail there.



+    if (!bdrv_is_active(parent_bs)) {
+    return false;
+    }
+    }
+    }
+
+   return true;
+}
+
  int coroutine_fn bdrv_co_invalidate_cache(BlockDriverState *bs, 
Error **errp)

  {
  BdrvChild *child, *parent;
@@ -6585,6 +6605,12 @@ int coroutine_fn 
bdrv_co_invalidate_cache(BlockDriverState *bs, Error **errp)

  return -ENOMEDIUM;
  }
+    /*
+ * No need to muck with permissions if bs is active.
+ * TODO: should activation be a separate function?
+ */
+    assert(qemu_in_main_thread() || bdrv_is_active(bs));
+


I don’t understand this, really.  It looks to me like “if you don’t 
call this in the main thread, this better be a no-op”, i.e., you must 
never call this function in an I/O thread if you really want to use 
it.  I.e. what I’d classify as a GS function.


It sounds like this is just a special case for said test, and 
special-casing code for tests sounds like a bad idea.


Ok, but trying to leave just the qemu_in_main_thread() assertion makes 
test 307 (./check 307) fail.
I am actually not sure on why it fails, but I am sure it is because of 
the assertion, since without it it passes.


I tried with gdb (./check -gdb 307 on one terminal and
gdb -iex "target remote localhost:12345"
in another) but it points me to this below, which I think is the ndb 
server getting the socket closed (because on the other side it crashed), 
and not the actual error.



Thread 1 "qemu-system-x86" received signal SIGPIPE, Broken pipe.
0x768af54d in sendmsg () from target:/lib64/libc.so.6
(gdb) bt
#0  0x768af54d in sendmsg () from target:/lib64/libc.so.6
#1  0x55c13cc9 in qio_channel_socket_writev (ioc=out>, iov=0x569a4870, niov=1, fds=0x0, nfds=, errp=0x0)

     at ../io/channel-socket.c:561
#2  0x55c19b18 in qio_channel_writev_full_all 
(ioc=0x5763b800, iov=iov@entry=0x7fffe8dffd80, niov=niov@entry=1, 
fds=fds@entry=0x0,

     nfds=nfds@entry=0, errp=errp@entry=0x0) at ../io/channel.c:240
#3  0x55c19bd2 in qio_channel_writev_all (errp=0x0, niov=1, 
iov=0x7fffe8dffd80, ioc=) at ../io/channel.c:220
#4  qio_channel_write_all (ioc=, 
buf=buf@entry=0x7fffe8dffdd0 "", buflen=buflen@entry=20, 
errp=errp@entry=0x0) at ../io/channel.c:330
#5  0x55c27e75 in nbd_write (errp=0x0, size=20, 
buffer=0x7fffe8dffdd0, ioc=) at ../nbd/nbd-internal.h:71
#6  nbd_negotiate_send_rep_len (client=client@entry=0x56f60930, 
type=type@entry=1, len=len@entry=0, errp=errp@entry=0x0) at 
../nbd/server.c:203
#7  0x55c29db1 in nbd_negotiate_send_rep (errp=0x0, type=1, 
client=0x56f60930) at ../nbd/server.c:211

--Type  for more, q to quit, c to continue without paging--
#8  nbd_negotiate_options (errp=0x7fffe8dffe88, client=) 
at ../nbd/server.c:1224
#9  nbd_negotiate (errp=0x7fffe8dffe88, client=) at 
../nbd/server.c:1340

#10 nbd_co_client_start (opaque=) at ../nbd/server.c:2715
#11 0x55d70423 in coroutine_trampoline (i0=, 
i1=) at ../util/coroutine-ucontext.c:173

#12 0x767f3820 in ?? () from target:/lib64/libc.so.6
#13 0x7fffca80 in ?? ()



Ok the reason for

[PATCH v2 6/8] migration: Dump sub-cmd name in loadvm_process_command tp

It'll be easier to read the name rather than index of sub-cmd when debugging.

Signed-off-by: Peter Xu 
---
 migration/savevm.c | 3 ++-
 migration/trace-events | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/migration/savevm.c b/migration/savevm.c
index 0bef031acb..7f7af6f750 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -2272,12 +2272,13 @@ static int loadvm_process_command(QEMUFile *f)
 return qemu_file_get_error(f);
 }
 
-trace_loadvm_process_command(cmd, len);
 if (cmd >= MIG_CMD_MAX || cmd == MIG_CMD_INVALID) {
 error_report("MIG_CMD 0x%x unknown (len 0x%x)", cmd, len);
 return -EINVAL;
 }
 
+trace_loadvm_process_command(mig_cmd_args[cmd].name, len);
+
 if (mig_cmd_args[cmd].len != -1 && mig_cmd_args[cmd].len != len) {
 error_report("%s received with bad length - expecting %zu, got %d",
  mig_cmd_args[cmd].name,
diff --git a/migration/trace-events b/migration/trace-events
index b48d873b8a..d63a5915f5 100644
--- a/migration/trace-events
+++ b/migration/trace-events
@@ -22,7 +22,7 @@ loadvm_postcopy_handle_resume(void) ""
 loadvm_postcopy_ram_handle_discard(void) ""
 loadvm_postcopy_ram_handle_discard_end(void) ""
 loadvm_postcopy_ram_handle_discard_header(const char *ramid, uint16_t len) 
"%s: %ud"
-loadvm_process_command(uint16_t com, uint16_t len) "com=0x%x len=%d"
+loadvm_process_command(const char *s, uint16_t len) "com=%s len=%d"
 loadvm_process_command_ping(uint32_t val) "0x%x"
 postcopy_ram_listen_thread_exit(void) ""
 postcopy_ram_listen_thread_start(void) ""
-- 
2.32.0

Re: [PATCH] hw/nvram: at24 return 0xff if 1 byte address

2021-12-20 Thread Patrick Venture

On Mon, Dec 20, 2021 at 1:12 AM Philippe Mathieu-Daudé 
wrote:

> Hi Patrick,
>
> On 12/20/21 01:32, Patrick Venture wrote:
> > The at24 eeproms are 2 byte devices that return 0xff when they are read
> > from with a partial (1-byte) address written.  This distinction was
> > found comparing model behavior to real hardware testing.
> >
> > Tested: `i2ctransfer -f -y 45 w1@85 0 r1` returns 0xff instead of next
> > byte
> >
> > Signed-off-by: Patrick Venture 
> > ---
> >  hw/nvram/eeprom_at24c.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/hw/nvram/eeprom_at24c.c b/hw/nvram/eeprom_at24c.c
> > index a9e3702b00..184fac9702 100644
> > --- a/hw/nvram/eeprom_at24c.c
> > +++ b/hw/nvram/eeprom_at24c.c
> > @@ -62,7 +62,9 @@ int at24c_eeprom_event(I2CSlave *s, enum i2c_event
> event)
> >  case I2C_START_SEND:
> >  case I2C_START_RECV:
> >  case I2C_FINISH:
> > -ee->haveaddr = 0;
> > +if (event != I2C_START_RECV) {
> > +ee->haveaddr = 0;
> > +}
>
> Alternatively (matter of taste, I find it easier to read):
>
>case I2C_START_SEND:
>case I2C_FINISH:
>ee->haveaddr = 0;
>/* fallthrough */
>case I2C_START_RECV:
>

That may be easier to read :) I'm not sure, but I'm willing to bend and
change my patch to behave this way.  Sometimes the fallthrough things leads
to compiler annoyances in my experience.  We might  need
__attribute__(fallthrough) or the like to convince the system that's what
we really want.

>
> >  DPRINTK("clear\n");
> >  if (ee->blk && ee->changed) {
> >  int len = blk_pwrite(ee->blk, 0, ee->mem, ee->rsize, 0);
> > @@ -86,6 +88,10 @@ uint8_t at24c_eeprom_recv(I2CSlave *s)
> >  EEPROMState *ee = AT24C_EE(s);
> >  uint8_t ret;
> >
> > +if (ee->haveaddr == 1) {
> > +return 0xff;
>
> Don't we need to increase ee->haveaddr?
>

We don't because the call to recv doesn't set any addr bytes.  This patch
is primarily a behavioral fix to handle the device being treated as 8-bit
addressable.  This is typically tested by writing a 1 byte address and then
trying to read.  The chip itself will not have enough address bytes and
reject this read by returning 0xff.  The haveaddr variable is strictly
updated when they've written another byte to the address, or they've
changed states in such a way that should clear any previously written
address.  You can read from an eeprom by just reading or by setting an
address and then reading.

>
> > +}
> > +
> >  ret = ee->mem[ee->cur];
> >
> >  ee->cur = (ee->cur + 1u) % ee->rsize;
>
> Here for parity with send, what about:
>
> if (ee->haveaddr < 2) {
> ret = 0xff;
> ee->haveaddr++;
> } else {
> ret = ee->mem[ee->cur];
> ee->cur = (ee->cur + 1u) % ee->rsize;
> }
>
> ?
>
>

Re: [RFC PATCH v2 03/14] job.h: define locked functions

2021-12-20 Thread Emanuele Giuseppe Esposito





On 16/12/2021 18:11, Vladimir Sementsov-Ogievskiy wrote:

16.12.2021 19:48, Stefan Hajnoczi wrote:
On Thu, Nov 04, 2021 at 10:53:23AM -0400, Emanuele Giuseppe Esposito 
wrote:

  /** Returns whether the job is ready to be completed. */
  bool job_is_ready(Job *job);
+/** Same as job_is_ready(), but assumes job_lock is held. */
+bool job_is_ready_locked(Job *job);


What I see here is that some functions assume job_lock is held but don't
have _locked in their name (job_ref()), some assume job_lock is held and
have _locked in their name (job_is_ready_locked()), and some assume
job_lock is not held (job_is_ready()).

That means when _locked is not in the name I don't know whether this
function requires job_lock or will deadlock if called under job_lock.

Two ways to it obvious:

1. Always have _locked in the name if the function requires job_lock.
    Functions without _locked must not be called under job_lock.

2. Don't change the name but use the type system instead:

    /*
 * Define a unique type so the compiler warns us. It's just a pointer
 * so it can be efficiently passed by value.
 */
    typedef struct { Job *job; } LockedJob;

    LockedJob job_lock(Job *job);
    Job *job_unlock(LockedJob job);

    Now the compiler catches mistakes:

    bool job_is_completed(LockedJob job);
    bool job_is_ready(Job *job);

    Job *j;
    LockedJob l;
    job_is_completed(j) -> compiler error
    job_is_completed(l) -> ok
    job_is_ready(j) -> ok
    job_is_ready(l) -> compiler error

    This approach assumes per-Job locks but a similar API is possible
    with a global job_mutex too. There just needs to be a function to
    turn Job * into LockedJob and LockedJob back into Job*.

    This is slightly exotic. It's not an approach I've seen used in C, so
    it's not idiomatic and people might find it unfamiliar.


Oh yes. If we need something, I'd prefer function renaming.


Ok, I will go with option 1.





These are just ideas. If you want to keep it the way it is, that's okay
too (although a little confusing).


diff --git a/job.c b/job.c
index 0e4dacf028..e393c1222f 100644
--- a/job.c
+++ b/job.c
@@ -242,7 +242,8 @@ bool job_cancel_requested(Job *job)
  return job->cancelled;
  }
-bool job_is_ready(Job *job)
+/* Called with job_mutex held. */


This information should go with the doc comments (and it's already there
in job.h!). There is no rule on where to put doc comments but in this
case you already added them to job.h, so they are not needed here in
job.c. Leaving them could confuse other people into adding doc comments
into job.c instead of job.h.



Yes, in general I will leave the comment for static functions in job.c 
and make sure the public ones are only documented in job.h.


Thank you,
Emanuele

Re: [RFC] vhost-vdpa-net: add vhost-vdpa-net host device support

On Mon, Dec 20, 2021 at 09:17:40AM +, Longpeng (Mike, Cloud Infrastructure 
Service Product Dept.) wrote:
> > -Original Message-
> > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > Sent: Monday, December 20, 2021 4:11 PM
> > To: Jason Wang 
> > Cc: Michael S. Tsirkin ; Longpeng (Mike, Cloud 
> > Infrastructure
> > Service Product Dept.) ; pa...@nvidia.com;
> > xieyon...@bytedance.com; sgarz...@redhat.com; Yechuan ;
> > Gonglei (Arei) ; qemu-devel@nongnu.org; Dr. David
> > Alan Gilbert 
> > Subject: Re: [RFC] vhost-vdpa-net: add vhost-vdpa-net host device support
> > 
> > On Mon, Dec 20, 2021 at 10:48:09AM +0800, Jason Wang wrote:
> > > On Fri, Dec 17, 2021 at 4:35 PM Stefan Hajnoczi  
> > > wrote:
> > Longpeng: Do you want to generalize this patch into a --device vdpa-host
> > that supports all device types?
> > 
> 
> Yes, I already told Jason that I'll start to develop the device next week :)

That's great!

Stefan


signature.asc
Description: PGP signature

RE: [RFC] vhost-vdpa-net: add vhost-vdpa-net host device support

2021-12-20 Thread longpeng2--- via




> -Original Message-
> From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> Sent: Monday, December 20, 2021 4:11 PM
> To: Jason Wang 
> Cc: Michael S. Tsirkin ; Longpeng (Mike, Cloud Infrastructure
> Service Product Dept.) ; pa...@nvidia.com;
> xieyon...@bytedance.com; sgarz...@redhat.com; Yechuan ;
> Gonglei (Arei) ; qemu-devel@nongnu.org; Dr. David
> Alan Gilbert 
> Subject: Re: [RFC] vhost-vdpa-net: add vhost-vdpa-net host device support
> 
> On Mon, Dec 20, 2021 at 10:48:09AM +0800, Jason Wang wrote:
> > On Fri, Dec 17, 2021 at 4:35 PM Stefan Hajnoczi  wrote:
> > >
> > > On Fri, Dec 17, 2021 at 12:26:53PM +0800, Jason Wang wrote:
> > >
> > > Dave: You created the VIRTIO vmstate infrastructure in QEMU. Please see
> > > the bottom of this email about moving to a standard VIRTIO device
> > > save/load format defined by the VIRTIO spec in the future.
> > >
> > > > On Thu, Dec 16, 2021 at 5:10 PM Stefan Hajnoczi  
> > > > wrote:
> > > > >
> > > > > On Thu, Dec 16, 2021 at 11:01:40AM +0800, Jason Wang wrote:
> > > > > > On Wed, Dec 15, 2021 at 6:07 PM Stefan Hajnoczi 
> > > > > > 
> wrote:
> > > > > > >
> > > > > > > On Wed, Dec 15, 2021 at 11:18:05AM +0800, Jason Wang wrote:
> > > > > > > > On Tue, Dec 14, 2021 at 9:11 PM Stefan Hajnoczi 
> > > > > > > > 
> wrote:
> > > > > > > > >
> > > > > > > > > On Tue, Dec 14, 2021 at 10:22:53AM +0800, Jason Wang wrote:
> > > > > > > > > > On Mon, Dec 13, 2021 at 11:14 PM Stefan Hajnoczi
>  wrote:
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Dec 13, 2021 at 10:47:00AM +0800, Jason Wang 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Sun, Dec 12, 2021 at 5:30 PM Michael S. Tsirkin 
> > > > > > > > > > > > 
> wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Sat, Dec 11, 2021 at 03:00:27AM +, Longpeng 
> > > > > > > > > > > > > (Mike,
> Cloud Infrastructure Service Product Dept.) wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > > > > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > > > > > > > > > > > > > > Sent: Thursday, December 9, 2021 5:17 PM
> > > > > > > > > > > > > > > To: Longpeng (Mike, Cloud Infrastructure Service
> Product Dept.)
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Cc: jasow...@redhat.com; m...@redhat.com;
> pa...@nvidia.com;
> > > > > > > > > > > > > > > xieyon...@bytedance.com; sgarz...@redhat.com; 
> > > > > > > > > > > > > > > Yechuan
> ;
> > > > > > > > > > > > > > > Gonglei (Arei) ;
> qemu-devel@nongnu.org
> > > > > > > > > > > > > > > Subject: Re: [RFC] vhost-vdpa-net: add 
> > > > > > > > > > > > > > > vhost-vdpa-net
> host device support
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Dec 08, 2021 at 01:20:10PM +0800, 
> > > > > > > > > > > > > > > Longpeng(Mike)
> wrote:
> > > > > > > > > > > > > > > > From: Longpeng 
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi guys,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > This patch introduces vhost-vdpa-net device, 
> > > > > > > > > > > > > > > > which
> is inspired
> > > > > > > > > > > > > > > > by vhost-user-blk and the proposal of 
> > > > > > > > > > > > > > > > vhost-vdpa-blk
> device [1].
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > I've tested this patch on Huawei's offload card:
> > > > > > > > > > > > > > > > ./x86_64-softmmu/qemu-system-x86_64 \
> > > > > > > > > > > > > > > > -device
> vhost-vdpa-net-pci,vdpa-dev=/dev/vhost-vdpa-0
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > For virtio hardware offloading, the most 
> > > > > > > > > > > > > > > > important
> requirement for us
> > > > > > > > > > > > > > > > is to support live migration between offloading
> cards from different
> > > > > > > > > > > > > > > > vendors, the combination of netdev and 
> > > > > > > > > > > > > > > > virtio-net
> seems too heavy, we
> > > > > > > > > > > > > > > > prefer a lightweight way.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Maybe we could support both in the future ? Such
> as:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > * Lightweight
> > > > > > > > > > > > > > > >  Net: vhost-vdpa-net
> > > > > > > > > > > > > > > >  Storage: vhost-vdpa-blk
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > * Heavy but more powerful
> > > > > > > > > > > > > > > >  Net: netdev + virtio-net + vhost-vdpa
> > > > > > > > > > > > > > > >  Storage: bdrv + virtio-blk + vhost-vdpa
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > [1]
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg797569.html
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Stefano presented a plan for vdpa-blk at KVM Forum
> 2021:
> > > > > > > > > > > > > > >
> https://kvmforum2021.sched.com/event/ke3a/vdpa-blk-unified-hardware-and-sof
> > > > > > > > > > > > > > > tware-offload-for-virtio-blk-stefano-garzar

[PATCH v3 05/12] target/riscv: Implement kvm_arch_put_registers

Put GPR CSR and FP registers to kvm by KVM_SET_ONE_REG ioctl

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Reviewed-by: Alistair Francis 
Reviewed-by: Anup Patel 
---
 target/riscv/kvm.c | 104 -
 1 file changed, 103 insertions(+), 1 deletion(-)

diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index 6d4df0ef6d..e695b91dc7 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -73,6 +73,14 @@ static uint64_t kvm_riscv_reg_id(CPURISCVState *env, 
uint64_t type, uint64_t idx
 } \
 } while(0)
 
+#define KVM_RISCV_SET_CSR(cs, env, csr, reg) \
+do { \
+int ret = kvm_set_one_reg(cs, RISCV_CSR_REG(env, csr), ®); \
+if (ret) { \
+return ret; \
+} \
+} while(0)
+
 static int kvm_riscv_get_regs_core(CPUState *cs)
 {
 int ret = 0;
@@ -98,6 +106,31 @@ static int kvm_riscv_get_regs_core(CPUState *cs)
 return ret;
 }
 
+static int kvm_riscv_put_regs_core(CPUState *cs)
+{
+int ret = 0;
+int i;
+target_ulong reg;
+CPURISCVState *env = &RISCV_CPU(cs)->env;
+
+reg = env->pc;
+ret = kvm_set_one_reg(cs, RISCV_CORE_REG(env, regs.pc), ®);
+if (ret) {
+return ret;
+}
+
+for (i = 1; i < 32; i++) {
+uint64_t id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CORE, i);
+reg = env->gpr[i];
+ret = kvm_set_one_reg(cs, id, ®);
+if (ret) {
+return ret;
+}
+}
+
+return ret;
+}
+
 static int kvm_riscv_get_regs_csr(CPUState *cs)
 {
 int ret = 0;
@@ -115,6 +148,24 @@ static int kvm_riscv_get_regs_csr(CPUState *cs)
 return ret;
 }
 
+static int kvm_riscv_put_regs_csr(CPUState *cs)
+{
+int ret = 0;
+CPURISCVState *env = &RISCV_CPU(cs)->env;
+
+KVM_RISCV_SET_CSR(cs, env, sstatus, env->mstatus);
+KVM_RISCV_SET_CSR(cs, env, sie, env->mie);
+KVM_RISCV_SET_CSR(cs, env, stvec, env->stvec);
+KVM_RISCV_SET_CSR(cs, env, sscratch, env->sscratch);
+KVM_RISCV_SET_CSR(cs, env, sepc, env->sepc);
+KVM_RISCV_SET_CSR(cs, env, scause, env->scause);
+KVM_RISCV_SET_CSR(cs, env, stval, env->stval);
+KVM_RISCV_SET_CSR(cs, env, sip, env->mip);
+KVM_RISCV_SET_CSR(cs, env, satp, env->satp);
+
+return ret;
+}
+
 static int kvm_riscv_get_regs_fp(CPUState *cs)
 {
 int ret = 0;
@@ -148,6 +199,40 @@ static int kvm_riscv_get_regs_fp(CPUState *cs)
 return ret;
 }
 
+static int kvm_riscv_put_regs_fp(CPUState *cs)
+{
+int ret = 0;
+int i;
+CPURISCVState *env = &RISCV_CPU(cs)->env;
+
+if (riscv_has_ext(env, RVD)) {
+uint64_t reg;
+for (i = 0; i < 32; i++) {
+reg = env->fpr[i];
+ret = kvm_set_one_reg(cs, RISCV_FP_D_REG(env, i), ®);
+if (ret) {
+return ret;
+}
+}
+return ret;
+}
+
+if (riscv_has_ext(env, RVF)) {
+uint32_t reg;
+for (i = 0; i < 32; i++) {
+reg = env->fpr[i];
+ret = kvm_set_one_reg(cs, RISCV_FP_F_REG(env, i), ®);
+if (ret) {
+return ret;
+}
+}
+return ret;
+}
+
+return ret;
+}
+
+
 const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
 KVM_CAP_LAST_INFO
 };
@@ -176,7 +261,24 @@ int kvm_arch_get_registers(CPUState *cs)
 
 int kvm_arch_put_registers(CPUState *cs, int level)
 {
-return 0;
+int ret = 0;
+
+ret = kvm_riscv_put_regs_core(cs);
+if (ret) {
+return ret;
+}
+
+ret = kvm_riscv_put_regs_csr(cs);
+if (ret) {
+return ret;
+}
+
+ret = kvm_riscv_put_regs_fp(cs);
+if (ret) {
+return ret;
+}
+
+return ret;
 }
 
 int kvm_arch_release_virq_post(int virq)
-- 
2.19.1

Re: [PATCH] hw: m68k: Add virt compat machine type for 7.0

2021-12-20 Thread Cornelia Huck

On Mon, Dec 20 2021, Laurent Vivier  wrote:

> Le 20/12/2021 à 09:17, Cornelia Huck a écrit :
>> On Sat, Dec 18 2021, Laurent Vivier  wrote:
>> 
>>> Signed-off-by: Laurent Vivier 
>>> ---
>>> Based-On: <20211217143948.289995-1-coh...@redhat.com>
>>>
>>>   hw/m68k/virt.c | 9 -
>>>   1 file changed, 8 insertions(+), 1 deletion(-)
>> 
>> Oh, I didn't realize we do it for m68k as well.
>
> virt-m68k is only a toy and is only used by debian for their m68k buildd.
>
> So there is no problem if you don't manage the update, I will.

Ok, let's just keep it as a separate patch for this round, and I'll try
to remember to add it when I'm sending machine type patches in the
future.

[PATCH v2 3/8] migration: Drop postcopy_chunk_hostpages()

This function calls three functions:

  - postcopy_discard_send_init(ms, block->idstr);
  - postcopy_chunk_hostpages_pass(ms, block);
  - postcopy_discard_send_finish(ms);

However only the 2nd function call is meaningful.  It's major role is to make
sure dirty bits are applied in host-page-size granule, so there will be no
partial dirty bits set for a whole host page if huge pages are used.

The 1st/3rd call are for latter when we want to send the disgard ranges.
They're mostly no-op here besides some tracepoints (which are misleading!).

Drop them, then we can directly drop postcopy_chunk_hostpages() as a whole
because we can call postcopy_chunk_hostpages_pass() directly.

There're still some nice comments above postcopy_chunk_hostpages() that explain
what it does.  Copy it over to the caller's site.

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Peter Xu 
---
 migration/ram.c | 33 +++--
 1 file changed, 7 insertions(+), 26 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 0ed0f51a09..b22c9e7432 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2571,30 +2571,6 @@ static void postcopy_chunk_hostpages_pass(MigrationState 
*ms, RAMBlock *block)
 }
 }
 
-/**
- * postcopy_chunk_hostpages: discard any partially sent host page
- *
- * Utility for the outgoing postcopy code.
- *
- * Discard any partially sent host-page size chunks, mark any partially
- * dirty host-page size chunks as all dirty.  In this case the host-page
- * is the host-page for the particular RAMBlock, i.e. it might be a huge page
- *
- * @ms: current migration state
- * @block: block we want to work with
- */
-static void postcopy_chunk_hostpages(MigrationState *ms, RAMBlock *block)
-{
-postcopy_discard_send_init(ms, block->idstr);
-
-/*
- * Ensure that all partially dirty host pages are made fully dirty.
- */
-postcopy_chunk_hostpages_pass(ms, block);
-
-postcopy_discard_send_finish(ms);
-}
-
 /**
  * ram_postcopy_send_discard_bitmap: transmit the discard bitmap
  *
@@ -2626,8 +2602,13 @@ int ram_postcopy_send_discard_bitmap(MigrationState *ms)
 rs->last_page = 0;
 
 RAMBLOCK_FOREACH_NOT_IGNORED(block) {
-/* Deal with TPS != HPS and huge pages */
-postcopy_chunk_hostpages(ms, block);
+/*
+ * Deal with TPS != HPS and huge pages.  It discard any partially sent
+ * host-page size chunks, mark any partially dirty host-page size
+ * chunks as all dirty.  In this case the host-page is the host-page
+ * for the particular RAMBlock, i.e. it might be a huge page.
+ */
+postcopy_chunk_hostpages_pass(ms, block);
 }
 trace_ram_postcopy_send_discard_bitmap();
 
-- 
2.32.0

Re: [PULL 00/16] qtest and gitlab-CI improvements

On 12/20/21 10:53, Thomas Huth wrote:
> On 20/12/2021 10.24, Philippe Mathieu-Daudé wrote:
>> +Alex & Paolo
>>
>> On 12/20/21 07:52, Thomas Huth wrote:
>>> On 18/12/2021 17.33, Philippe Mathieu-Daudé wrote:
 Hi,

 On 12/15/21 08:33, Thomas Huth wrote:

> 
> * Add virtio-net failover test
> * Make qtests a little bit more flexible with regards to reduced
> configs
> * Move libssh setup from configure to meson.build
> * Run device-crash-test in CI
> * Add jobs for NetBSD and OpenBSD to the CI
> * Test compilation with MSYS2 in the gitlab-ci, too
> * Add new virtio-iommu test
>
> 

> Laurent Vivier (4):
>     qtest/libqos: add a function to initialize secondary PCI buses
>     tests/qtest: add some tests for virtio-net failover
>     tests/libqtest: add some virtio-net failover migration
> cancelling tests
>     tests/libqtest: add a migration test with two couples of
> failover devices

 On my ASan build directory I'm sometime getting:

 Running test qtest-i386/virtio-net-failover
 (process:1558675): GLib-CRITICAL **: 16:19:12.556: g_rand_int:
 assertion
 'rand != NULL' failed
>>>
>>> Weird, since the test is not using that function?
>>
>> Well it calls g_test_rand_int(), which calls it:
>> https://github.com/GNOME/glib/blob/main/glib/gtestutils.c#L1800
> 
> Ah, right. I think the problem is that g_test_rand_int() must not be
> called before g_test_init().
> 
> But actually, I think in this case we even don't want to use
> g_test_rand_int() since it's about generating a true random temporary
> file name, not a random number for a test case that could be influenced
> with the "--seed" CLI option.
> So I think using g_random_int() might be the better choice instead?

I think you are right.

[PATCH 2/4] tests/qtest: Improve endianness-test to work with missing machines and devices

The users might have built QEMU with less machines or without the
i82378 superio device. Add some checks to the endianess-test so that
it is able to deal with such stripped down QEMU versions, too.

Signed-off-by: Thomas Huth 
---
 tests/qtest/endianness-test.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tests/qtest/endianness-test.c b/tests/qtest/endianness-test.c
index 09ecb531f1..9c03b72dc9 100644
--- a/tests/qtest/endianness-test.c
+++ b/tests/qtest/endianness-test.c
@@ -281,7 +281,10 @@ int main(int argc, char **argv)
 
 for (i = 0; test_cases[i].arch; i++) {
 gchar *path;
-if (strcmp(test_cases[i].arch, arch) != 0) {
+
+if (!g_str_equal(test_cases[i].arch, arch) ||
+!qtest_has_machine(test_cases[i].machine) ||
+(test_cases[i].superio && 
!qtest_has_device(test_cases[i].superio))) {
 continue;
 }
 path = g_strdup_printf("endianness/%s",
-- 
2.27.0

[PATCH v3 00/12] Add riscv kvm accel support

This series adds both riscv32 and riscv64 kvm support, and implements
migration based on riscv.

Because of RISC-V KVM has been merged into the Linux master, so this
series are changed from RFC to patch.

Several steps to use this:
1. Build emulation
$ ./configure --target-list=riscv64-softmmu
$ make -j$(nproc)

2. Build kernel

3. Build QEMU VM
Cross built in riscv toolchain.
$ PKG_CONFIG_LIBDIR=
$ export PKG_CONFIG_SYSROOT_DIR=
$ ./configure --target-list=riscv64-softmmu --enable-kvm \
--cross-prefix=riscv64-linux-gnu- --disable-libiscsi --disable-glusterfs \
--disable-libusb --disable-usb-redir --audio-drv-list= --disable-opengl \
--disable-libxml2
$ make -j$(nproc)

4. Start emulation
$ ./qemu-system-riscv64 -M virt -m 4096M -cpu rv64,x-h=true -nographic \
-name guest=riscv-hyp,debug-threads=on \
-smp 4 \
-bios ./fw_jump.bin \
-kernel ./Image \
-drive file=./hyp.img,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-append "root=/dev/vda rw console=ttyS0 earlycon=sbi"

5. Start kvm-acceled QEMU VM in emulation
$ ./qemu-system-riscv64 -M virt,accel=kvm -m 1024M -cpu host -nographic \
-name guest=riscv-guset \
-smp 2 \
-bios none \
-kernel ./Image \
-drive file=./guest.img,format=raw,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-append "root=/dev/vda rw console=ttyS0 earlycon=sbi"

Changes since patch v2
- Create a macro for get and put timer csr.
- Remove M-mode PLIC contexts when kvm is enabled.
- Add get timer frequency.
- Move cpu_host_load to vmstate_kvmtimer.

Changes since patch v1
- Rebase on recent commit a216e7cf119c91ffdf5931834a1a030ebea40d70
- Sync-up headers with Linux-5.16-rc4.
- Fixbug in kvm_arch_init_vcpu.
- Create a macro for get and put regs csr.
- Start kernel directly when kvm_enabled.
- Use riscv_cpu_set_irq to inject KVM interrupts.
- Use the Semihosting Console API for RISC-V kvm handle sbi.
- Update vmstate_riscv_cpu version id.
  Placing kvm_timer into a subsection.

Changes since RFC v6
- Rebase on recent commit 8627edfb3f1fca24a96a0954148885c3241c10f8
- Sync-up headers with Linux-5.16-rc1

Changes since RFC v5
- Rebase on QEMU v6.1.0-rc1 and kvm-riscv linux v19.
- Move kvm interrupt setting to riscv_cpu_update_mip().
- Replace __u64 with uint64_t.

Changes since RFC v4
- Rebase on QEMU v6.0.0-rc2 and kvm-riscv linux v17.
- Remove time scaling support as software solution is incomplete.
  Because it will cause unacceptable performance degradation. and
  We will post a better solution.
- Revise according to Alistair's review comments.
  - Remove compile time XLEN checks in kvm_riscv_reg_id
  - Surround TYPE_RISCV_CPU_HOST definition by CONFIG_KVM and share
it between RV32 and RV64.
  - Add kvm-stub.c for reduce unnecessary compilation checks.
  - Add riscv_setup_direct_kernel() to direct boot kernel for KVM.

Changes since RFC v3
- Rebase on QEMU v5.2.0-rc2 and kvm-riscv linux v15.
- Add time scaling support(New patches 13, 14 and 15).
- Fix the bug that guest vm can't reboot.

Changes since RFC v2
- Fix checkpatch error at target/riscv/sbi_ecall_interface.h.
- Add riscv migration support.

Changes since RFC v1
- Add separate SBI ecall interface header.
- Add riscv32 kvm accel support.

Yifei Jiang (12):
  update-linux-headers: Add asm-riscv/kvm.h
  target/riscv: Add target/riscv/kvm.c to place the public kvm interface
  target/riscv: Implement function kvm_arch_init_vcpu
  target/riscv: Implement kvm_arch_get_registers
  target/riscv: Implement kvm_arch_put_registers
  target/riscv: Support start kernel directly by KVM
  target/riscv: Support setting external interrupt by KVM
  target/riscv: Handle KVM_EXIT_RISCV_SBI exit
  target/riscv: Add host cpu type
  target/riscv: Add kvm_riscv_get/put_regs_timer
  target/riscv: Implement virtual time adjusting with vm state changing
  target/riscv: Support virtual time context synchronization

 hw/intc/sifive_plic.c  |   8 +-
 hw/riscv/boot.c|  16 +-
 hw/riscv/virt.c|  87 +++--
 include/hw/riscv/boot.h|   1 +
 linux-headers/asm-riscv/kvm.h  | 128 +++
 meson.build|   2 +
 target/riscv/cpu.c |  29 +-
 target/riscv/cpu.h |  11 +
 target/riscv/kvm-stub.c|  30 ++
 target/riscv/kvm.c | 533 +
 target/riscv/kvm_riscv.h   |  25 ++
 target/riscv/machine.c |  30 ++
 target/riscv/meson.build   |   1 +
 target/riscv/sbi_ecall_interface.h |  72 
 14 files changed, 944 insertions(+), 29 deletions(-)
 create mode 100644 linux-headers/asm-riscv/kvm.h
 create mode 100644 target/riscv/kvm-stub.c
 create mode 100644 target/riscv/kvm.c
 create mode 100644 target/riscv/kvm_riscv.h
 create mode 100644 target/riscv/sbi_ecall_interface.h

-- 
2.19.1

[PATCH v2 5/8] migration: Drop return code for disgard ram process

It will just never fail.  Drop those return values where they're constantly
zeros.

A tiny touch-up on the tracepoint so trace_ram_postcopy_send_discard_bitmap()
is called after the logic itself (which sounds more reasonable).

Reviewed-by: Dr. David Alan Gilbert 
Signed-off-by: Peter Xu 
---
 migration/migration.c |  5 +
 migration/ram.c   | 20 +---
 migration/ram.h   |  2 +-
 3 files changed, 7 insertions(+), 20 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index 3de11ae921..beeb162a1a 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -2990,10 +2990,7 @@ static int postcopy_start(MigrationState *ms)
  * that are dirty
  */
 if (migrate_postcopy_ram()) {
-if (ram_postcopy_send_discard_bitmap(ms)) {
-error_report("postcopy send discard bitmap failed");
-goto fail;
-}
+ram_postcopy_send_discard_bitmap(ms);
 }
 
 /*
diff --git a/migration/ram.c b/migration/ram.c
index e7107b9790..5234d1ece1 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2473,8 +2473,6 @@ static void postcopy_chunk_hostpages_pass(MigrationState 
*ms, RAMBlock *block);
 /**
  * postcopy_each_ram_send_discard: discard all RAMBlocks
  *
- * Returns 0 for success or negative for error
- *
  * Utility for the outgoing postcopy code.
  *   Calls postcopy_send_discard_bm_ram for each RAMBlock
  *   passing it bitmap indexes and name.
@@ -2483,10 +2481,9 @@ static void postcopy_chunk_hostpages_pass(MigrationState 
*ms, RAMBlock *block);
  *
  * @ms: current migration state
  */
-static int postcopy_each_ram_send_discard(MigrationState *ms)
+static void postcopy_each_ram_send_discard(MigrationState *ms)
 {
 struct RAMBlock *block;
-int ret;
 
 RAMBLOCK_FOREACH_NOT_IGNORED(block) {
 postcopy_discard_send_init(ms, block->idstr);
@@ -2504,14 +2501,9 @@ static int postcopy_each_ram_send_discard(MigrationState 
*ms)
  * just needs indexes at this point, avoids it having
  * target page specific code.
  */
-ret = postcopy_send_discard_bm_ram(ms, block);
+postcopy_send_discard_bm_ram(ms, block);
 postcopy_discard_send_finish(ms);
-if (ret) {
-return ret;
-}
 }
-
-return 0;
 }
 
 /**
@@ -2584,8 +2576,6 @@ static void postcopy_chunk_hostpages_pass(MigrationState 
*ms, RAMBlock *block)
 /**
  * ram_postcopy_send_discard_bitmap: transmit the discard bitmap
  *
- * Returns zero on success
- *
  * Transmit the set of pages to be discarded after precopy to the target
  * these are pages that:
  * a) Have been previously transmitted but are now dirty again
@@ -2596,7 +2586,7 @@ static void postcopy_chunk_hostpages_pass(MigrationState 
*ms, RAMBlock *block)
  *
  * @ms: current migration state
  */
-int ram_postcopy_send_discard_bitmap(MigrationState *ms)
+void ram_postcopy_send_discard_bitmap(MigrationState *ms)
 {
 RAMState *rs = ram_state;
 
@@ -2610,9 +2600,9 @@ int ram_postcopy_send_discard_bitmap(MigrationState *ms)
 rs->last_sent_block = NULL;
 rs->last_page = 0;
 
-trace_ram_postcopy_send_discard_bitmap();
+postcopy_each_ram_send_discard(ms);
 
-return postcopy_each_ram_send_discard(ms);
+trace_ram_postcopy_send_discard_bitmap();
 }
 
 /**
diff --git a/migration/ram.h b/migration/ram.h
index f543e25765..2c6dc3675d 100644
--- a/migration/ram.h
+++ b/migration/ram.h
@@ -57,7 +57,7 @@ int ram_save_queue_pages(const char *rbname, ram_addr_t 
start, ram_addr_t len);
 void acct_update_position(QEMUFile *f, size_t size, bool zero);
 void ram_postcopy_migrated_memory_release(MigrationState *ms);
 /* For outgoing discard bitmap */
-int ram_postcopy_send_discard_bitmap(MigrationState *ms);
+void ram_postcopy_send_discard_bitmap(MigrationState *ms);
 /* For incoming postcopy discard */
 int ram_discard_range(const char *block_name, uint64_t start, size_t length);
 int ram_postcopy_incoming_init(MigrationIncomingState *mis);
-- 
2.32.0

Re: [PATCH v2] audio: Add sndio backend

2021-12-20 Thread Christian Schoenebeck

On Freitag, 17. Dezember 2021 10:38:32 CET Alexandre Ratchov wrote:
> sndio is the native API used by OpenBSD, although it has been ported to
> other *BSD's and Linux (packages for Ubuntu, Debian, Void, Arch, etc.).
> 
> Signed-off-by: Brad Smith 
> Signed-off-by: Alexandre Ratchov 
> ---
> 
> Thank you for the reviews and all the comments. Here's a second diff
> with all the suggested changes:
> 
> - Replace ISC license by SPDX-License-Identifier header
> - Fix units (milli- vs micro-) in comment about SNDIO_LATENCY_US
> - Drop outdated comment about the "size" argument of sndio_get_buffer_out()
> - Fix AUDIO_FORMAT_U32 handling (missing "break" statement)
> - Set {read,write] methods to audio_generic_{read,write} (fixes craches)
> - Check if backend is enabled in sndio_poll_event()
> - Use https://sndio.org in description
> - Mark options as available after 7.0 release (instead of 6.2)
> - Describe sndio-specific options (dev, latency) in qemu-options.hx
> - Add myself as reviewer to MAINTAINERS
> - Style fixes: no space after function names, use 4-space indent
> - Don't use "return foo()" if foo() returns void
> - Include backend to audio_drivers_priority[]
> 
> Tested on OpenBSD, works as expected!
> 
>  MAINTAINERS|   5 +
>  audio/audio.c  |   1 +
>  audio/audio_template.h |   2 +
>  audio/meson.build  |   1 +
>  audio/sndioaudio.c | 555 +
>  meson.build|   9 +-
>  meson_options.txt  |   4 +-
>  qapi/audio.json|  25 +-
>  qemu-options.hx|  16 ++
>  tests/vm/freebsd   |   3 +
>  10 files changed, 618 insertions(+), 3 deletions(-)
>  create mode 100644 audio/sndioaudio.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 7543eb4d59..76bdad064f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2307,6 +2307,7 @@ X: audio/jackaudio.c
>  X: audio/ossaudio.c
>  X: audio/paaudio.c
>  X: audio/sdlaudio.c
> +X: audio/sndio.c
>  X: audio/spiceaudio.c
>  F: qapi/audio.json
> 
> @@ -2349,6 +2350,10 @@ R: Thomas Huth 
>  S: Odd Fixes
>  F: audio/sdlaudio.c
> 
> +Sndio Audio backend
> +R: Alexandre Ratchov 
> +F: audio/sndio.c
> +

Thanks Alexandre for volunteering as reviewer!

Gerd, would it be OK to set you as maintainer for now until new maintainer(s) 
adopt audio sections? Or should this start with "S: Orphan" instead?

Best regards,
Christian Schoenebeck

Re: [PATCH v2 00/15] hw/nvme: SR-IOV with Virtualization Enhancements

2021-12-20 Thread Łukasz Gieryk

On Mon, Dec 20, 2021 at 08:12:06AM +0100, Klaus Jensen wrote:
> On Nov 25 15:15, Łukasz Gieryk wrote:
> > On Wed, Nov 24, 2021 at 09:03:06AM +0100, Klaus Jensen wrote:
> > > Hi Lukasz,
> > > 
> > > I've been through this. I have a couple of review comments, but overall
> > > looks good for inclusion in nvme-next. Would be nice to get this in
> > > early in the cycle so it can mature there for 7.0.
> > 
> > We (I’m speaking on behalf of the other Lukasz) are really happy to
> > read that. We will do our best to make it happen.
> > 
> 
> Keith, do you have any comments on this series - otherwise I'd like to
> stage this for nvme-next come January.
> 

Please, wait with the staging - we are about to release the v3.

We have few fixes that will make the device more compliant with the NVMe
and SR-IOV Spec.

Re: [PATCH] tests/qtest/virtio-net-failover: Use g_random_int() instead of g_test_rand_int()

On 12/20/21 11:27, Thomas Huth wrote:
> g_test_rand_int() must not be called before g_test_init(), otherwise
> the glib will show a "g_rand_int: assertion 'rand != NULL' failed"
> message in the log. So we could change the order here, but actually,
> g_test_rand_int() seems also the wrong choice here, since we're using
> it to create a temporary file name, which certainly should not depend
> on the "--seed" CLI option of the g_test suite. Thus let's use the
> g_random_int() function instead.
> 
> Reported-by: Philippe Mathieu-Daudé 
> Signed-off-by: Thomas Huth 
> ---
>  tests/qtest/virtio-net-failover.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé

[PATCH 0/2] qapi/ui: add change-vnc-listen

2021-12-20 Thread Vladimir Sementsov-Ogievskiy

Hi all!

Recently our customer requested a possibility to change VNC listen port
dynamically.

Happily in Rhel7-based Qemu we already have this possibility: through
deprecated "change" qmp command.

But since 6.0 "change" qmp command was removed, with recommendation to
use change-vnc-password or blockdev-change-medium instead. Of course,
neither of them allow change VNC listen port.

So, let's reimplement the possibility.

Note: now, reconnecting may trigger existing deadlock, as I described
in my message "Re: [PULL 09/11] ui/vnc: clipboard support":
 <973ddebe-14a9-4ba7-c389-7a97d6017...@virtuozzo.com>

Simple hack helps, but I'm not sure it's safe itself:

diff --git a/ui/vnc.c b/ui/vnc.c
index 69bbf3b6f6..8c6b378e2e 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1354,12 +1354,12 @@ void vnc_disconnect_finish(VncState *vs)
 /* last client gone */
 vnc_update_server_surface(vs->vd);
 }
+vnc_unlock_output(vs);
+
 if (vs->cbpeer.update.notify) {
 qemu_clipboard_peer_unregister(&vs->cbpeer);
 }
 
-vnc_unlock_output(vs);
-
 qemu_mutex_destroy(&vs->output_mutex);
 if (vs->bh != NULL) {
 qemu_bh_delete(vs->bh);


Vladimir Sementsov-Ogievskiy (2):
  ui/vnc: refactor arrays of addresses to SocketAddressList
  qapi/ui: introduce change-vnc-listen

 docs/about/removed-features.rst |   3 +-
 qapi/ui.json|  12 +++
 ui/vnc.c| 155 
 3 files changed, 91 insertions(+), 79 deletions(-)

-- 
2.31.1

[PATCH v2 7/8] migration: Finer grained tracepoints for POSTCOPY_LISTEN

The enablement of postcopy listening has a few steps, add a few tracepoints to
be there ready for some basic measurements for them.

Signed-off-by: Peter Xu 
---
 migration/savevm.c | 9 -
 migration/trace-events | 2 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/migration/savevm.c b/migration/savevm.c
index 7f7af6f750..25face6de0 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -1947,9 +1947,10 @@ static void *postcopy_ram_listen_thread(void *opaque)
 static int loadvm_postcopy_handle_listen(MigrationIncomingState *mis)
 {
 PostcopyState ps = postcopy_state_set(POSTCOPY_INCOMING_LISTENING);
-trace_loadvm_postcopy_handle_listen();
 Error *local_err = NULL;
 
+trace_loadvm_postcopy_handle_listen("enter");
+
 if (ps != POSTCOPY_INCOMING_ADVISE && ps != POSTCOPY_INCOMING_DISCARD) {
 error_report("CMD_POSTCOPY_LISTEN in wrong postcopy state (%d)", ps);
 return -1;
@@ -1964,6 +1965,8 @@ static int 
loadvm_postcopy_handle_listen(MigrationIncomingState *mis)
 }
 }
 
+trace_loadvm_postcopy_handle_listen("after disgard");
+
 /*
  * Sensitise RAM - can now generate requests for blocks that don't exist
  * However, at this point the CPU shouldn't be running, and the IO
@@ -1976,6 +1979,8 @@ static int 
loadvm_postcopy_handle_listen(MigrationIncomingState *mis)
 }
 }
 
+trace_loadvm_postcopy_handle_listen("after uffd");
+
 if (postcopy_notify(POSTCOPY_NOTIFY_INBOUND_LISTEN, &local_err)) {
 error_report_err(local_err);
 return -1;
@@ -1990,6 +1995,8 @@ static int 
loadvm_postcopy_handle_listen(MigrationIncomingState *mis)
 qemu_sem_wait(&mis->listen_thread_sem);
 qemu_sem_destroy(&mis->listen_thread_sem);
 
+trace_loadvm_postcopy_handle_listen("exit");
+
 return 0;
 }
 
diff --git a/migration/trace-events b/migration/trace-events
index d63a5915f5..77d1237d89 100644
--- a/migration/trace-events
+++ b/migration/trace-events
@@ -14,7 +14,7 @@ loadvm_handle_cmd_packaged_main(int ret) "%d"
 loadvm_handle_cmd_packaged_received(int ret) "%d"
 loadvm_handle_recv_bitmap(char *s) "%s"
 loadvm_postcopy_handle_advise(void) ""
-loadvm_postcopy_handle_listen(void) ""
+loadvm_postcopy_handle_listen(const char *str) "%s"
 loadvm_postcopy_handle_run(void) ""
 loadvm_postcopy_handle_run_cpu_sync(void) ""
 loadvm_postcopy_handle_run_vmstart(void) ""
-- 
2.32.0

Re: [RFC PATCH v3 14/27] hw/pci-host: Add ls7a1000 PCIe Host bridge support for Loongson3 Platform

2021-12-20 Thread yangxiaojuan

Hi, Mark

On 12/18/2021 07:39 AM, Mark Cave-Ayland wrote:
> On 04/12/2021 12:07, Xiaojuan Yang wrote:
> 
>> This is a model of the PCIe Host Bridge found on a Loongson-5000
>> processor. It includes a interrupt controller, some interface for
>> pci and nonpci devices. Mainly emulate part of it that is not
>> exactly the same as the host and only use part devices for
>> tcg mode. It support for MSI and MSIX interrupt sources.
>>
>> For more detailed info about ls7a1000 you can see the doc at
>> https://github.com/loongson/LoongArch-Documentation/releases/latest/
>> download/Loongson-7A1000-usermanual-2.00-EN.pdf
>>
>> Signed-off-by: Xiaojuan Yang 
>> Signed-off-by: Song Gao 
>> ---
>>   hw/pci-host/Kconfig|   4 +
>>   hw/pci-host/ls7a.c | 174 +
>>   hw/pci-host/meson.build|   1 +
>>   include/hw/pci-host/ls7a.h |  51 +++
>>   4 files changed, 230 insertions(+)
>>   create mode 100644 hw/pci-host/ls7a.c
>>   create mode 100644 include/hw/pci-host/ls7a.h
>>
>> diff --git a/hw/pci-host/Kconfig b/hw/pci-host/Kconfig
>> index 2b5f7d58cc..b02a9d1454 100644
>> --- a/hw/pci-host/Kconfig
>> +++ b/hw/pci-host/Kconfig
>> @@ -77,3 +77,7 @@ config MV64361
>>   bool
>>   select PCI
>>   select I8259
>> +
>> +config PCI_EXPRESS_7A
>> +bool
>> +select PCI_EXPRESS
>> diff --git a/hw/pci-host/ls7a.c b/hw/pci-host/ls7a.c
>> new file mode 100644
>> index 00..a783fb2eda
>> --- /dev/null
>> +++ b/hw/pci-host/ls7a.c
>> @@ -0,0 +1,174 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>> +/*
>> + * QEMU Loongson 7A1000 North Bridge Emulation
>> + *
>> + * Copyright (C) 2021 Loongson Technology Corporation Limited
>> + */
>> +
>> +#include "qemu/osdep.h"
>> +
>> +#include "hw/pci/pci.h"
>> +#include "hw/pci/pcie_host.h"
>> +#include "hw/qdev-properties.h"
>> +#include "qapi/error.h"
>> +#include "hw/irq.h"
>> +#include "hw/pci/pci_bridge.h"
>> +#include "hw/pci/pci_bus.h"
>> +#include "sysemu/reset.h"
>> +#include "hw/pci-host/ls7a.h"
>> +#include "migration/vmstate.h"
>> +
>> +static const VMStateDescription vmstate_ls7a_pcie = {
>> +.name = "LS7A_PCIE",
>> +.version_id = 1,
>> +.minimum_version_id = 1,
>> +.fields = (VMStateField[]) {
>> +VMSTATE_PCI_DEVICE(parent_obj, LS7APCIState),
>> +VMSTATE_END_OF_LIST()
>> +}
>> +};
>> +
>> +static void pci_ls7a_config_write(void *opaque, hwaddr addr,
>> +  uint64_t val, unsigned size)
>> +{
>> +pci_data_write(opaque, addr, val, size);
>> +}
>> +
>> +static uint64_t pci_ls7a_config_read(void *opaque,
>> + hwaddr addr, unsigned size)
>> +{
>> +uint64_t val;
>> +
>> +val = pci_data_read(opaque, addr, size);
>> +
>> +return val;
>> +}
>> +
>> +static const MemoryRegionOps pci_ls7a_config_ops = {
>> +.read = pci_ls7a_config_read,
>> +.write = pci_ls7a_config_write,
>> +.valid = {
>> +.min_access_size = 1,
>> +.max_access_size = 4,
>> +},
>> +.impl = {
>> +.min_access_size = 1,
>> +.max_access_size = 4,
>> +},
>> +.endianness = DEVICE_LITTLE_ENDIAN,
>> +};
>> +
>> +static void ls7a_pciehost_realize(DeviceState *dev, Error **errp)
>> +{
>> +PCIHostState *pci = PCI_HOST_BRIDGE(dev);
>> +LS7APCIEHost *s = LS7A_HOST_DEVICE(dev);
>> +PCIExpressHost *pex = PCIE_HOST_BRIDGE(dev);
> 
> SysbusDevice *sbd = SYS_BUS_DEVICE(dev) will be needed for later use.
> 
>> +pci->bus = pci_register_root_bus(dev, "pcie.0", NULL, NULL, s,
>> + get_system_memory(), get_system_io(),
>> + PCI_DEVFN(1, 0), 128, TYPE_PCIE_BUS);
> 
> A device shouldn't map itself into an address space: that is the job of the 
> board. To achieve this LS7APCIEHost should have separate mmio and io memory 
> regions defined and pci_register_root_bus() configured to use these i.e.

OK, I get it and have modified all the region map. Thank you

> 
> pci->bus = pci_register_root_bus(dev, "pcie.0", NULL, NULL, s,
>  &s->pci_mmio, &s->pci_io,
>  PCI_DEVFN(1, 0), 128, TYPE_PCIE_BUS);
> 
>> +memory_region_init_io(&s->pci_conf, OBJECT(dev),
>> +  &pci_ls7a_config_ops, pci->bus,
>> +  "ls7a_pci_conf", HT1LO_PCICFG_SIZE);
>> +memory_region_add_subregion(get_system_memory(), HT1LO_PCICFG_BASE,
>> +&s->pci_conf);
> 
> Here add sysbus_init_mmio(sbd, &s->pci_conf) and remove 
> memory_region_add_subregion().
> 
>> +/* Add ls7a pci-io */
>> +memory_region_init_alias(&s->pci_io, OBJECT(dev), "ls7a-pci-io",
>> + get_system_io(), 0, LS7A_PCI_IO_SIZE);
>> +memory_region_add_subregion(get_system_memory(), LS7A_PCI_IO_BASE,
>> +&s->pci_io);
> 
> Remove the alias onto the system

Re: [PATCH v5 30/31] crypto: delegate permission functions to JobDriver .pre_run

2021-12-20 Thread Emanuele Giuseppe Esposito





On 17/12/2021 13:29, Hanna Reitz wrote:

On 24.11.21 07:44, Emanuele Giuseppe Esposito wrote:

block_crypto_amend_options_generic_luks uses the block layer
permission API, therefore it should be called with the BQL held.

However, the same function is being called ib two BlockDriver


s/ ib / by /


callbacks: bdrv_amend_options (under BQL) and bdrv_co_amend (I/O).

The latter is I/O because it is invoked by block/amend.c's
blockdev_amend_run(), a .run callback of the amend JobDriver

Therefore we want to 1) change block_crypto_amend_options_generic_luks
to use the permission API only when the BQL is held, and
2) use the .pre_run JobDriver callback to check for
permissions before switching to the job aiocontext. This has also
the benefit of applying the same permission operation to all
amend implementations, not only luks.

Signed-off-by: Emanuele Giuseppe Esposito 
---
  block/amend.c  | 20 
  block/crypto.c | 18 --
  2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/block/amend.c b/block/amend.c
index 392df9ef83..fba6add51a 100644
--- a/block/amend.c
+++ b/block/amend.c
@@ -53,10 +53,30 @@ static int coroutine_fn blockdev_amend_run(Job 
*job, Error **errp)

  return ret;
  }
+static int blockdev_amend_refresh_perms(Job *job, Error **errp)
+{
+    BlockdevAmendJob *s = container_of(job, BlockdevAmendJob, common);
+
+    return bdrv_child_refresh_perms(s->bs, s->bs->file, errp);
+}


I miss some documentation for this function, why we do it and how it 
works together with the bdrv_co_amend implementation.




I was trying to come up with an example text, but then I wondered – how 
does it actually work?  bdrv_child_refresh_perms() eventually ends up in 
block_crypto_child_perms().  However, that will only return exceptional 
permissions if crypto->updating_keys is true. But that’s set only in 
block_crypto_amend_options_generic_luks() – i.e. when the job runs. 
That’s exactly why that function calls bdrv_child_refresh_perms() only 
after it has modified crypto->updating_keys.


Reproducer (amend on a LUKS image with read-only=true, so it doesn’t 
have the WRITE permission continuously, but needs to take it as an 
exception in block_crypto_child_perms()):


$ qemu-img create \
     -f luks \
     --object secret,id=sec0,data=123456 \
     -o key-secret=sec0 \
     test.luks \
     64M
Formatting 'test.luks', fmt=luks size=67108864 key-secret=sec0

$ ./qemu-system-x86_64 \
     -object secret,id=sec0,data=123456 \
     -object iothread,id=iothr0 \
     -blockdev file,node-name=node0,filename=test.luks \
     -blockdev 
luks,node-name=node1,key-secret=sec0,file=node0,read-only=true \

     -device virtio-blk,drive=node1,iothread=iothr0 -qmp stdio \
     <{"QMP": {"version": {"qemu": {"micro": 93, "minor": 1, "major": 6}, 
"package": "v6.2.0-rc3-50-gdb635fc4e7"}, "capabilities": ["oob"]}}

{"return": {}}
{"timestamp": {"seconds": 1639742600, "microseconds": 574641}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "created", "id": "amend0"}}
{"timestamp": {"seconds": 1639742600, "microseconds": 574919}, "event": 
"JOB_STATUS_CHANGE", "data": {"status": "running", "id": "amend0"}}

{"return": {}}
qemu-system-x86_64: ../block/io.c:2041: bdrv_co_write_req_prepare: 
Assertion `child->perm & BLK_PERM_WRITE' failed.
[1]    55880 IOT instruction (core dumped)  ./qemu-system-x86_64 -object 
secret,id=sec0,data=123456 -object  -blockdev



I believe this means we need some new block driver function to prepare 
for an amendment operation.  If so, another question comes up, which is 
whether this preparatory function should then also call 
bdrv_child_refresh_perms(), and then whether we should have a clean-up 
function for symmetry.




Yes, unfortunately it means that (see at the end of the mail for more).

I think it does not work because of crypto->updating_keys missing in 
blockdev_amend_pre_run(). That is why the permission is not correctly 
set and the example fails.




+
+static int blockdev_amend_pre_run(Job *job, Error **errp)
+{
+    return blockdev_amend_refresh_perms(job, errp);
+}
+
+static void blockdev_amend_clean(Job *job)
+{
+    Error *errp;
+    blockdev_amend_refresh_perms(job, &errp);


Do we really want to ignore this error?  If so, we shouldn’t pass a 
pointer to an unused local variable, but NULL.


If we don’t want to ignore it, we have the option of doing what you do 
here and then at least reporting a potential error with 
error_report_err(), and then freeing it, and we also must initialize 
errp to NULL in this case.


Going with this one above, thanks.


If we expect no error to happen (e.g. because we require the amend 
implementation to only release/share permissions and not acquire/unshare 
them), then I’d expect passing &error_abort here.



+}
+
  static const JobDriver blockdev_amend_job_driver = {
  .instance_size = sizeof(BlockdevAmendJob),
  .job_type  = JOB_TYPE_AMEND,
  .run   = blockdev_amend_run,

RE: [PATCH v2 10/12] target/riscv: Add kvm_riscv_get/put_regs_timer


> -Original Message-
> From: Richard Henderson [mailto:richard.hender...@linaro.org]
> Sent: Monday, December 13, 2021 11:20 PM
> To: Anup Patel ; Jiangyifei 
> Cc: Bin Meng ; open list:RISC-V
> ; limingwang (A) ; KVM
> General ; libvir-l...@redhat.com; Anup Patel
> ; QEMU Developers ;
> wanbo (G) ; Palmer Dabbelt ;
> kvm-ri...@lists.infradead.org; Wanghaibin (D)
> ; Alistair Francis
> ; Fanliang (EulerOS) ;
> Wubin (H) 
> Subject: Re: [PATCH v2 10/12] target/riscv: Add kvm_riscv_get/put_regs_timer
> 
> On 12/12/21 9:05 PM, Anup Patel wrote:
> >> +ret = kvm_get_one_reg(cs, RISCV_TIMER_REG(env, state), ®);
> >> +if (ret) {
> >> +abort();
> >> +}
> >> +env->kvm_timer_state = reg;
> >
> > Please read the timer frequency here.
> 
> Yep.
> 
> >> +
> >> +env->kvm_timer_dirty = true;
> >> +}
> >> +
> >> +static void kvm_riscv_put_regs_timer(CPUState *cs) {
> >> +int ret;
> >> +uint64_t reg;
> >> +CPURISCVState *env = &RISCV_CPU(cs)->env;
> >> +
> >> +if (!env->kvm_timer_dirty) {
> >> +return;
> >> +}
> >
> > Over here, we should get the timer frequency and abort() with an error
> > message if it does not match env->kvm_timer_frequency
> >
> > For now, migration will not work between Hosts with different timer
> > frequency.
> 
> You shouldn't have to do this every "put", only on migration, at which point 
> you
> can actually signal a migration error rather than aborting directly.
> 
> 
> r~

Yes, it will be modified in the next series.

Yifei

RE: [PATCH v2 07/12] target/riscv: Support setting external interrupt by KVM


> -Original Message-
> From: Anup Patel [mailto:a...@brainfault.org]
> Sent: Monday, December 13, 2021 12:33 PM
> To: Jiangyifei 
> Cc: QEMU Developers ; open list:RISC-V
> ; kvm-ri...@lists.infradead.org; KVM General
> ; libvir-l...@redhat.com; Anup Patel
> ; Palmer Dabbelt ; Alistair
> Francis ; Bin Meng ;
> Fanliang (EulerOS) ; Wubin (H)
> ; Wanghaibin (D) ;
> wanbo (G) ; limingwang (A)
> 
> Subject: Re: [PATCH v2 07/12] target/riscv: Support setting external interrupt
> by KVM
> 
> On Fri, Dec 10, 2021 at 3:37 PM Yifei Jiang  wrote:
> >
> > When KVM is enabled, set the S-mode external interrupt through
> > kvm_riscv_set_irq function.
> >
> > Signed-off-by: Yifei Jiang 
> > Signed-off-by: Mingwang Li 
> > Reviewed-by: Alistair Francis 
> > ---
> >  target/riscv/cpu.c   |  6 +-
> >  target/riscv/kvm-stub.c  |  5 +
> >  target/riscv/kvm.c   | 17 +
> >  target/riscv/kvm_riscv.h |  1 +
> >  4 files changed, 28 insertions(+), 1 deletion(-)
> >
> > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c index
> > 1c944872a3..71a7ac6831 100644
> > --- a/target/riscv/cpu.c
> > +++ b/target/riscv/cpu.c
> > @@ -603,7 +603,11 @@ static void riscv_cpu_set_irq(void *opaque, int irq,
> int level)
> >  case IRQ_S_EXT:
> >  case IRQ_VS_EXT:
> >  case IRQ_M_EXT:
> > -riscv_cpu_update_mip(cpu, 1 << irq, BOOL_TO_MASK(level));
> > +if (kvm_enabled() && (irq & IRQ_M_EXT) ) {
> > +kvm_riscv_set_irq(cpu, IRQ_S_EXT, level);
> > +} else {
> > +riscv_cpu_update_mip(cpu, 1 << irq, BOOL_TO_MASK(level));
> > +}
> 
> This does not look right.
> 
> I suggest the following:
> 
> if (kvm_enabled()) {
> kvm_riscv_set_irq(cpu, irq, level);
> } else {
>riscv_cpu_update_mip(cpu, 1 << irq, BOOL_TO_MASK(level)); }
> 

The M-mode PLIC context is not deleted. Therefore, IRQ_M_EXT needs to
be converted to IRQ_S_EXT. The M-mode PLIC contexts will be removed in
the next series, so it will be modified as suggested.

Yifei

> >  break;
> >  default:
> >  g_assert_not_reached();
> > diff --git a/target/riscv/kvm-stub.c b/target/riscv/kvm-stub.c index
> > 39b96fe3f4..4e8fc31a21 100644
> > --- a/target/riscv/kvm-stub.c
> > +++ b/target/riscv/kvm-stub.c
> > @@ -23,3 +23,8 @@ void kvm_riscv_reset_vcpu(RISCVCPU *cpu)  {
> >  abort();
> >  }
> > +
> > +void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level) {
> > +abort();
> > +}
> > diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c index
> > db6d8a5b6e..0027f11f45 100644
> > --- a/target/riscv/kvm.c
> > +++ b/target/riscv/kvm.c
> > @@ -383,6 +383,23 @@ void kvm_riscv_reset_vcpu(RISCVCPU *cpu)
> >  env->satp = 0;
> >  }
> >
> > +void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level) {
> > +int ret;
> > +unsigned virq = level ? KVM_INTERRUPT_SET :
> KVM_INTERRUPT_UNSET;
> > +
> > +if (irq != IRQ_S_EXT) {
> > +perror("kvm riscv set irq != IRQ_S_EXT\n");
> > +abort();
> > +}
> > +
> > +ret = kvm_vcpu_ioctl(CPU(cpu), KVM_INTERRUPT, &virq);
> > +if (ret < 0) {
> > +perror("Set irq failed");
> > +abort();
> > +}
> > +}
> > +
> >  bool kvm_arch_cpu_check_are_resettable(void)
> >  {
> >  return true;
> > diff --git a/target/riscv/kvm_riscv.h b/target/riscv/kvm_riscv.h index
> > f38c82bf59..ed281bdce0 100644
> > --- a/target/riscv/kvm_riscv.h
> > +++ b/target/riscv/kvm_riscv.h
> > @@ -20,5 +20,6 @@
> >  #define QEMU_KVM_RISCV_H
> >
> >  void kvm_riscv_reset_vcpu(RISCVCPU *cpu);
> > +void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level);
> >
> >  #endif
> > --
> > 2.19.1
> >
> 
> Regards,
> Anup

Re: [RFC 1/2] migration: Introduce ram_transferred_add()

On Friday, 2021-12-17 at 20:09:12 +01, Philippe Mathieu-Daudé wrote:

> On 12/16/21 13:34, David Edmondson wrote:
>> ...and use it.
>> 
>> Signed-off-by: David Edmondson 
>> ---
>>  migration/ram.c | 23 ++-
>>  migration/ram.h |  1 +
>>  2 files changed, 15 insertions(+), 9 deletions(-)
>
>> diff --git a/migration/ram.h b/migration/ram.h
>> index c515396a9a..a5b2ffdc18 100644
>> --- a/migration/ram.h
>> +++ b/migration/ram.h
>> @@ -51,6 +51,7 @@ int xbzrle_cache_resize(uint64_t new_size, Error **errp);
>>  uint64_t ram_bytes_remaining(void);
>>  uint64_t ram_bytes_total(void);
>>  void mig_throttle_counter_reset(void);
>> +void ram_transferred_add(uint64_t bytes);
>
> Why make the method public? It seems an internal operation. Do you
> plan to use it elsewhere?

No such plan. Will fix in v2.

dme.
-- 
We wanna wait, but here we go again.

Re: build qemu on Monterey?


On 18/12/2021 15.38, Ani Sinha wrote:

Hi :
Has anyone tried this? Yes, I know about
https://wiki.qemu.org/Hosts/Mac

but I am getting

$ ./configure --target-list=x86_64-softmmu
Using './build' as the directory for build output
Disabling PIE due to missing toolchain support

ERROR: glib-2.56 gthread-2.0 is required to compile QEMU

when glib is already installed using brew.

Any ideas?


1) Check "config.log" to see the exact reason for the failure

2) Check .gitlab-ci.d/cirrus/macos-11.vars to install the same packages on 
your system, maybe that helps...?


 HTH,
  Thomas

[RFC v2 1/2] migration: Introduce ram_transferred_add()

...and use it.

Signed-off-by: David Edmondson 
---
 migration/ram.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 57efa67f20..bd53e50a7f 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -386,6 +386,11 @@ uint64_t ram_bytes_remaining(void)
 
 MigrationStats ram_counters;
 
+static void ram_transferred_add(uint64_t bytes)
+{
+ram_counters.transferred += bytes;
+}
+
 /* used by the search for pages to send */
 struct PageSearchStatus {
 /* Current block being searched */
@@ -767,7 +772,7 @@ static int save_xbzrle_page(RAMState *rs, uint8_t 
**current_data,
  * RAM_SAVE_FLAG_CONTINUE.
  */
 xbzrle_counters.bytes += bytes_xbzrle - 8;
-ram_counters.transferred += bytes_xbzrle;
+ram_transferred_add(bytes_xbzrle);
 
 return 1;
 }
@@ -1198,7 +1203,7 @@ static int save_zero_page(RAMState *rs, RAMBlock *block, 
ram_addr_t offset)
 
 if (len) {
 ram_counters.duplicate++;
-ram_counters.transferred += len;
+ram_transferred_add(len);
 return 1;
 }
 return -1;
@@ -1234,7 +1239,7 @@ static bool control_save_page(RAMState *rs, RAMBlock 
*block, ram_addr_t offset,
 }
 
 if (bytes_xmit) {
-ram_counters.transferred += bytes_xmit;
+ram_transferred_add(bytes_xmit);
 *pages = 1;
 }
 
@@ -1265,8 +1270,8 @@ static bool control_save_page(RAMState *rs, RAMBlock 
*block, ram_addr_t offset,
 static int save_normal_page(RAMState *rs, RAMBlock *block, ram_addr_t offset,
 uint8_t *buf, bool async)
 {
-ram_counters.transferred += save_page_header(rs, rs->f, block,
- offset | RAM_SAVE_FLAG_PAGE);
+ram_transferred_add(save_page_header(rs, rs->f, block,
+ offset | RAM_SAVE_FLAG_PAGE));
 if (async) {
 qemu_put_buffer_async(rs->f, buf, TARGET_PAGE_SIZE,
   migrate_release_ram() &
@@ -1274,7 +1279,7 @@ static int save_normal_page(RAMState *rs, RAMBlock 
*block, ram_addr_t offset,
 } else {
 qemu_put_buffer(rs->f, buf, TARGET_PAGE_SIZE);
 }
-ram_counters.transferred += TARGET_PAGE_SIZE;
+ram_transferred_add(TARGET_PAGE_SIZE);
 ram_counters.normal++;
 return 1;
 }
@@ -1373,7 +1378,7 @@ exit:
 static void
 update_compress_thread_counts(const CompressParam *param, int bytes_xmit)
 {
-ram_counters.transferred += bytes_xmit;
+ram_transferred_add(bytes_xmit);
 
 if (param->zero_page) {
 ram_counters.duplicate++;
@@ -2298,7 +2303,7 @@ void acct_update_position(QEMUFile *f, size_t size, bool 
zero)
 ram_counters.duplicate += pages;
 } else {
 ram_counters.normal += pages;
-ram_counters.transferred += size;
+ram_transferred_add(size);
 qemu_update_position(f, size);
 }
 }
@@ -3133,7 +3138,7 @@ out:
 multifd_send_sync_main(rs->f);
 qemu_put_be64(f, RAM_SAVE_FLAG_EOS);
 qemu_fflush(f);
-ram_counters.transferred += 8;
+ram_transferred_add(8);
 
 ret = qemu_file_get_error(f);
 }
-- 
2.33.0

[PATCH] tests/qtest/virtio-net-failover: Use g_random_int() instead of g_test_rand_int()

g_test_rand_int() must not be called before g_test_init(), otherwise
the glib will show a "g_rand_int: assertion 'rand != NULL' failed"
message in the log. So we could change the order here, but actually,
g_test_rand_int() seems also the wrong choice here, since we're using
it to create a temporary file name, which certainly should not depend
on the "--seed" CLI option of the g_test suite. Thus let's use the
g_random_int() function instead.

Reported-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
 tests/qtest/virtio-net-failover.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/qtest/virtio-net-failover.c 
b/tests/qtest/virtio-net-failover.c
index 4b2ba8a106..70b94bf18f 100644
--- a/tests/qtest/virtio-net-failover.c
+++ b/tests/qtest/virtio-net-failover.c
@@ -1308,7 +1308,7 @@ int main(int argc, char **argv)
 {
 const gchar *tmpdir = g_get_tmp_dir();
 gchar *tmpfile = g_strdup_printf("%s/failover_test_migrate-%u-%u",
- tmpdir, getpid(), g_test_rand_int());
+ tmpdir, getpid(), g_random_int());
 int ret;
 
 g_test_init(&argc, &argv, NULL);
-- 
2.27.0

Re: [PATCH v4 07/14] vfio-user: run vfio-user context

On Fri, Dec 17, 2021 at 05:59:48PM +, Jag Raman wrote:
> 
> 
> > On Dec 16, 2021, at 6:17 AM, Stefan Hajnoczi  wrote:
> > 
> > On Wed, Dec 15, 2021 at 10:35:31AM -0500, Jagannathan Raman wrote:
> >> @@ -114,6 +118,62 @@ static void vfu_object_set_device(Object *obj, const 
> >> char *str, Error **errp)
> >> vfu_object_init_ctx(o, errp);
> >> }
> >> 
> >> +static void vfu_object_ctx_run(void *opaque)
> >> +{
> >> +VfuObject *o = opaque;
> >> +int ret = -1;
> >> +
> >> +while (ret != 0) {
> >> +ret = vfu_run_ctx(o->vfu_ctx);
> >> +if (ret < 0) {
> >> +if (errno == EINTR) {
> >> +continue;
> >> +} else if (errno == ENOTCONN) {
> >> +qemu_set_fd_handler(o->vfu_poll_fd, NULL, NULL, NULL);
> >> +o->vfu_poll_fd = -1;
> >> +object_unparent(OBJECT(o));
> >> +break;
> > 
> > If nothing else logs a message then I think that should be done here so
> > users know why their vfio-user server object disappeared.
> 
> Sure will do.
> 
> Do you prefer a trace, or a message to the console? Trace makes sense to me.
> Presently, the client could unplug the vfio-user device which would trigger 
> the
> deletion of this object. This process could happen quietly.

If there is no way to differentiate graceful disconnect from unexpected
disconnect then logging might be too noisy.

Regarding the automatic deletion of the object, that might not be
desirable for two reasons:
1. It prevents reconnection or another client connecting.
2. Management tools are in the dark about it.

For #2 there are monitor events that QEMU emits to notify management
tools about state changes like disconnections.

It's worth thinking about current and future use cases before baking in
a policy like automatically deleting VfuObject on disconnect because
it's inflexible and would require a QEMU update in the future to support
a different policy.

One approach is to emit a disconnect event but leave the VfuObject in a
disconnected state. The management tool can then restart or clean up,
depending on its policy.

I'm not sure what's best because it depends on the use cases, but maybe
you and others have ideas here.

> >> @@ -208,6 +284,8 @@ static void vfu_object_init(Object *obj)
> >>TYPE_VFU_OBJECT, TYPE_REMOTE_MACHINE);
> >> return;
> >> }
> >> +
> >> +o->vfu_poll_fd = -1;
> >> }
> > 
> > This must call qemu_set_fd_handler(o->vfu_poll_fd, NULL, NULL, NULL)
> > when o->vfu_poll_fd != -1 to avoid leaving a dangling fd handler
> > callback registered.
> 
> This is during the init phase, and the FD handlers are not set. Do you mean
> to add this at finalize?
> 
> I agree it’s good to explicitly add this at finalize. But vfu_destroy_ctx() 
> should
> trigger a ENOTCONN, which would do it anyway.

I'm not sure my comment makes sense since this is the init function, not
finalize.

However, it's not clear to me that the o->vfu_poll_fd fd handler is
unregistered from the event loop when VfuObject is finalized (e.g. by
the object-del monitor command). You say vfu_destroy_ctx() triggers
ENOTCONN, but the VfuObject is freed after finalize returns so when is
the fd handler deregistered?

Stefan

signature.asc
Description: PGP signature

Re: [PATCH v2 4/4] intel_iommu: Fix irqchip / X2APIC configuration checks

On Fri, Dec 17, 2021 at 04:51:20PM +, David Woodhouse wrote:
> On Thu, 2021-12-16 at 16:47 +0800, Peter Xu wrote:
> > Hi, David,
> > 
> > On Thu, Dec 09, 2021 at 10:08:40PM +, David Woodhouse wrote:
> > > We don't need to check kvm_enable_x2apic(). It's perfectly OK to support
> > > interrupt remapping even if we can't address CPUs above 254. Kind of
> > > pointless, but still functional.
> > 
> > We only checks kvm_enable_x2apic() if eim=on is set, right?  I mean, we can
> > still enable IR without x2apic even with current code?
> > 
> > Could you elaborate what's the use scenario for this patch?  Thanks in 
> > advance.
> 
> You can have IR, EIM *and* X2APIC if kvm_enable_x2apic() fails. You
> just can't have any CPUs with an APIC ID > 254.
> 
> But qemu is going to bail out *anyway* if you attempt to have CPUs with
> APIC IDs above 254 without the corresponding kernel-side support, so
> there's no need to check it here.

Ah OK.

> 
> > > The check on kvm_enable_x2apic() needs to happen *anyway* in order to
> > > allow CPUs above 254 even without an IOMMU, so allow that to happen
> > > elsewhere.
> > > 
> > > However, we do require the *split* irqchip in order to rewrite I/OAPIC
> > > destinations. So fix that check while we're here.
> > > 
> > > Signed-off-by: David Woodhouse 
> > > Reviewed-by: Peter Xu 
> > > Acked-by: Jason Wang 
> > 
> > I think the r-b and a-b should be for patch 2 not this one? :)
> > 
> 
> Yes, I think I must have swapped those round. Thanks.
> 
> > > ---
> > >  hw/i386/intel_iommu.c | 7 +--
> > >  1 file changed, 1 insertion(+), 6 deletions(-)
> > > 
> > > diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> > > index bd288d45bb..0d1c72f08e 100644
> > > --- a/hw/i386/intel_iommu.c
> > > +++ b/hw/i386/intel_iommu.c
> > > @@ -3760,15 +3760,10 @@ static bool vtd_decide_config(IntelIOMMUState *s, 
> > > Error **errp)
> > >ON_OFF_AUTO_ON : 
> > > ON_OFF_AUTO_OFF;
> > >  }
> > >  if (s->intr_eim == ON_OFF_AUTO_ON && !s->buggy_eim) {
> > > -if (!kvm_irqchip_in_kernel()) {
> > > +if (!kvm_irqchip_is_split()) {
> > 
> > I think this is okay, but note that we'll already fail if !split in
> > x86_iommu_realize():
> > 
> > bool irq_all_kernel = kvm_irqchip_in_kernel() && 
> > !kvm_irqchip_is_split();
> > 
> > /* Both Intel and AMD IOMMU IR only support 
> > "kernel-irqchip={off|split}" */
> > if (x86_iommu_ir_supported(x86_iommu) && irq_all_kernel) {
> > error_setg(errp, "Interrupt Remapping cannot work with "
> >  "kernel-irqchip=on, please use 'split|off'.");
> > return;
> > }
> 
> OK, then perhaps the entire check is redundant?

Yes, maybe.

It also reminded me that this is the only place that we used the "buggy_eim"
variable.  If we drop this chunk, that flag will become meaningless.

If we look back, it seems to decides whether we should call kvm_enable_x2apic()
at all, so as to be compatible with old qemus.  Please see commit fb506e701e
("intel_iommu: reject broken EIM", 2016-10-17).

hw_compat_2_7 has:

{ "intel-iommu", "x-buggy-eim", "true" },

It means kvm_enable_x2apic() (at least before commit c1bb5418e3 of yours)
should be skipped for 2.7 or older version of QEMU binaries.

Now after commit c1bb5418e3 we'll unconditionally call kvm_enable_x2apic() in
x86_cpu_load_model() anyway, even if x-buggy-eim=on.  IIUC it violates with the
original purpose of commit fb506e701e.

However maybe it's not necessary to maintain that awkward/buggy compatibility
at all for those old qemu binaries.  I can hardly imagine someone uses vIOMMU
2.7- versions for production purposes, and for relying on that buggy behavior
to work.

To summarize: I'm wondering whether we should also drop buggy-eim as a whole..

Thanks,

-- 
Peter Xu

Re: [PATCH v2 2/2] linux-user: call set/getscheduler set/getparam directly


Le 20/12/2021 à 08:21, Tonis Tiigi a écrit :

There seems to be difference in syscall and libc definition of these
methods and therefore musl does not implement them (1e21e78bf7). Call
syscall directly to ensure the behavior of the libc of user application,
not the libc that was used to build QEMU.

Signed-off-by: Tonis Tiigi 
---
  linux-user/syscall.c  | 40 ++-
  linux-user/syscall_defs.h |  4 
  2 files changed, 31 insertions(+), 13 deletions(-)




Reviewed-by: Laurent Vivier

Re: [PATCH v2 1/3] linux-user: Move target_signal.h generic definitions to generic/signal.h


Le 26/11/2021 à 03:23, Song Gao a écrit :

No code change

Suggested-by: Richard Henderson 
Signed-off-by: Song Gao 
Reviewed-by: Laurent Vivier 
---
  linux-user/aarch64/target_signal.h| 18 --
  linux-user/arm/target_signal.h| 18 --
  linux-user/cris/target_signal.h   | 18 --
  linux-user/generic/signal.h   | 16 
  linux-user/hexagon/target_signal.h| 11 ---
  linux-user/i386/target_signal.h   | 18 --
  linux-user/m68k/target_signal.h   | 18 --
  linux-user/microblaze/target_signal.h | 18 --
  linux-user/nios2/target_signal.h  | 16 
  linux-user/openrisc/target_signal.h   | 23 ---
  linux-user/ppc/target_signal.h| 18 --
  linux-user/riscv/target_signal.h  | 12 
  linux-user/s390x/target_signal.h  | 15 ---
  linux-user/sh4/target_signal.h| 18 --
  linux-user/x86_64/target_signal.h | 18 --
  linux-user/xtensa/target_signal.h | 17 -
  16 files changed, 16 insertions(+), 256 deletions(-)

diff --git a/linux-user/aarch64/target_signal.h 
b/linux-user/aarch64/target_signal.h
index 7580d99..40e399d 100644
--- a/linux-user/aarch64/target_signal.h
+++ b/linux-user/aarch64/target_signal.h
@@ -1,24 +1,6 @@
  #ifndef AARCH64_TARGET_SIGNAL_H
  #define AARCH64_TARGET_SIGNAL_H
  
-/* this struct defines a stack used during syscall handling */

-
-typedef struct target_sigaltstack {
-abi_ulong ss_sp;
-abi_int ss_flags;
-abi_ulong ss_size;
-} target_stack_t;
-
-
-/*
- * sigaltstack controls
- */
-#define TARGET_SS_ONSTACK 1
-#define TARGET_SS_DISABLE 2
-
-#define TARGET_MINSIGSTKSZ 2048
-#define TARGET_SIGSTKSZ 8192
-
  #include "../generic/signal.h"
  
  #define TARGET_SEGV_MTEAERR  8  /* Asynchronous ARM MTE error */

diff --git a/linux-user/arm/target_signal.h b/linux-user/arm/target_signal.h
index 1e7fb0c..0e6351d 100644
--- a/linux-user/arm/target_signal.h
+++ b/linux-user/arm/target_signal.h
@@ -1,24 +1,6 @@
  #ifndef ARM_TARGET_SIGNAL_H
  #define ARM_TARGET_SIGNAL_H
  
-/* this struct defines a stack used during syscall handling */

-
-typedef struct target_sigaltstack {
-abi_ulong ss_sp;
-abi_int ss_flags;
-abi_ulong ss_size;
-} target_stack_t;
-
-
-/*
- * sigaltstack controls
- */
-#define TARGET_SS_ONSTACK  1
-#define TARGET_SS_DISABLE  2
-
-#define TARGET_MINSIGSTKSZ 2048
-#define TARGET_SIGSTKSZ8192
-
  #include "../generic/signal.h"
  
  #define TARGET_ARCH_HAS_SETUP_FRAME

diff --git a/linux-user/cris/target_signal.h b/linux-user/cris/target_signal.h
index 83a5155..ab0653f 100644
--- a/linux-user/cris/target_signal.h
+++ b/linux-user/cris/target_signal.h
@@ -1,24 +1,6 @@
  #ifndef CRIS_TARGET_SIGNAL_H
  #define CRIS_TARGET_SIGNAL_H
  
-/* this struct defines a stack used during syscall handling */

-
-typedef struct target_sigaltstack {
-abi_ulong ss_sp;
-abi_int ss_flags;
-abi_ulong ss_size;
-} target_stack_t;
-
-
-/*
- * sigaltstack controls
- */
-#define TARGET_SS_ONSTACK 1
-#define TARGET_SS_DISABLE 2
-
-#define TARGET_MINSIGSTKSZ2048
-#define TARGET_SIGSTKSZ   8192
-
  #include "../generic/signal.h"
  
  #define TARGET_ARCH_HAS_SETUP_FRAME

diff --git a/linux-user/generic/signal.h b/linux-user/generic/signal.h
index 943bc1a..ceaf8a8 100644
--- a/linux-user/generic/signal.h
+++ b/linux-user/generic/signal.h
@@ -55,6 +55,22 @@
  #define TARGET_SIG_UNBLOCK1/* for unblocking signals */
  #define TARGET_SIG_SETMASK2/* for setting the signal mask */
  
+/* this struct defines a stack used during syscall handling */

+typedef struct target_sigaltstack {
+abi_ulong ss_sp;
+abi_int ss_flags;
+abi_ulong ss_size;
+} target_stack_t;
+
+/*
+ * sigaltstack controls
+ */
+#define TARGET_SS_ONSTACK 1
+#define TARGET_SS_DISABLE 2
+
+#define TARGET_MINSIGSTKSZ 2048
+#define TARGET_SIGSTKSZ8192
+
  /* bit-flags */
  #define TARGET_SS_AUTODISARM (1U << 31) /* disable sas during sighandling */
  /* mask for all SS_xxx flags */
diff --git a/linux-user/hexagon/target_signal.h 
b/linux-user/hexagon/target_signal.h
index 9e0223d..193abac 100644
--- a/linux-user/hexagon/target_signal.h
+++ b/linux-user/hexagon/target_signal.h
@@ -18,17 +18,6 @@
  #ifndef HEXAGON_TARGET_SIGNAL_H
  #define HEXAGON_TARGET_SIGNAL_H
  
-typedef struct target_sigaltstack {

-abi_ulong ss_sp;
-abi_int ss_flags;
-abi_ulong ss_size;
-} target_stack_t;
-
-#define TARGET_SS_ONSTACK 1
-#define TARGET_SS_DISABLE 2
-
-#define TARGET_MINSIGSTKSZ 2048
-
  #include "../generic/signal.h"
  
  #define TARGET_ARCH_HAS_SIGTRAMP_PAGE 1

diff --git a/linux-user/i386/target_signal.h b/linux-user/i386/target_signal.h
index 64d09f2..9315cba 100644
--- a/linux-user/i386/target_signal.h
+++ b/linux-user/i386/target_signal.h
@

Re: build qemu on Monterey?

2021-12-20 Thread Ani Sinha

On Mon, Dec 20, 2021 at 12:56 PM Thomas Huth  wrote:
>
> On 18/12/2021 15.38, Ani Sinha wrote:
> > Hi :
> > Has anyone tried this? Yes, I know about
> > https://wiki.qemu.org/Hosts/Mac
> >
> > but I am getting
> >
> > $ ./configure --target-list=x86_64-softmmu
> > Using './build' as the directory for build output
> > Disabling PIE due to missing toolchain support
> >
> > ERROR: glib-2.56 gthread-2.0 is required to compile QEMU
> >
> > when glib is already installed using brew.
> >
> > Any ideas?
>
> 1) Check "config.log" to see the exact reason for the failure

This is what I see :

funcs: do_compiler do_cc compile_prog main
lines: 145 183 1768 0
cc -m64 -mcx16 -std=gnu11 -Wall -DOS_OBJECT_USE_OBJC=0 -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-definition
-Wtype-limits -Wformat-security -Wformat-y2k -Winit-self
-Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels
-Wexpansion-to-defined -Wno-initializer-overrides
-Wno-missing-include-dirs -Wno-shift-negative-value
-Wno-string-plus-int -Wno-typedef-redefinition
-Wno-tautological-type-limit-compare -Wno-psabi
-fstack-protector-strong -o config-temp/qemu-conf.exe
config-temp/qemu-conf.c -fstack-protector-strong -Wl,-z,relro
-Wl,-z,now
ld: unknown option: -z
clang: error: linker command failed with exit code 1 (use -v to see invocation)

funcs: do_compiler do_cc compile_prog main
lines: 145 183 1860 0
cc -m64 -mcx16 -std=gnu11 -Wall -DOS_OBJECT_USE_OBJC=0 -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-definition
-Wtype-limits -Wformat-security -Wformat-y2k -Winit-self
-Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels
-Wexpansion-to-defined -Wno-initializer-overrides
-Wno-missing-include-dirs -Wno-shift-negative-value
-Wno-string-plus-int -Wno-typedef-redefinition
-Wno-tautological-type-limit-compare -Wno-psabi
-fstack-protector-strong -o config-temp/qemu-conf.exe
config-temp/qemu-conf.c -fstack-protector-strong

funcs: do_compiler do_cc compile_prog main
lines: 145 183 1979 0
cc -m64 -mcx16 -std=gnu11 -Wall -DOS_OBJECT_USE_OBJC=0 -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-definition
-Wtype-limits -Wformat-security -Wformat-y2k -Winit-self
-Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels
-Wexpansion-to-defined -Wno-initializer-overrides
-Wno-missing-include-dirs -Wno-shift-negative-value
-Wno-string-plus-int -Wno-typedef-redefinition
-Wno-tautological-type-limit-compare -Wno-psabi
-fstack-protector-strong -o config-temp/qemu-conf.exe
config-temp/qemu-conf.c -fstack-protector-strong -lxenstore -lxenctrl
config-temp/qemu-conf.c:1:10: fatal error: 'xenctrl.h' file not found
#include 
 ^~~
1 error generated.

funcs: do_compiler do_cc compile_prog main
lines: 145 183 2257 0
cc -m64 -mcx16 -std=gnu11 -Wall -DOS_OBJECT_USE_OBJC=0 -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-definition
-Wtype-limits -Wformat-security -Wformat-y2k -Winit-self
-Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels
-Wexpansion-to-defined -Wno-initializer-overrides
-Wno-missing-include-dirs -Wno-shift-negative-value
-Wno-string-plus-int -Wno-typedef-redefinition
-Wno-tautological-type-limit-compare -Wno-psabi
-fstack-protector-strong -o config-temp/qemu-conf.exe
config-temp/qemu-conf.c -fstack-protector-strong -lrdmacm -libverbs
-libumad
config-temp/qemu-conf.c:1:10: fatal error: 'rdma/rdma_cma.h' file not found
#include 
 ^
1 error generated.

funcs: do_compiler do_cc compile_prog main
lines: 145 183 2355 0
cc -m64 -mcx16 -std=gnu11 -Wall -DOS_OBJECT_USE_OBJC=0 -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-definition
-Wtype-limits -Wformat-security -Wformat-y2k -Winit-self
-Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels
-Wexpansion-to-defined -Wno-initializer-overrides
-Wno-missing-include-dirs -Wno-shift-negative-value
-Wno-string-plus-int -Wno-typedef-redefinition
-Wno-tautological-type-limit-compare -Wno-psabi
-fstack-protector-strong -o config-temp/qemu-conf.exe
config-temp/qemu-conf.c -fstack-protector-strong
config-temp/qemu-conf.c:2:10: fatal error: 'xfs/xfs.h' file not found
#include 
 ^~~
1 error generated.

funcs: do_compiler do_cc compile_prog main
lines: 145 183 2396 0
cc -m64 -mcx16 -std=gnu11 -Wall -DOS_OBJECT_USE_OBJC=0 -

Re: [PATCH v2 3/3] linux-user: Remove TARGET_SIGSTKSZ


Le 26/11/2021 à 03:23, Song Gao a écrit :

TARGET_SIGSTKSZ is not used, we should remove it.

Signed-off-by: Song Gao 
---
  linux-user/alpha/target_signal.h  | 1 -
  linux-user/generic/signal.h   | 1 -
  linux-user/hppa/target_signal.h   | 1 -
  linux-user/mips/target_signal.h   | 1 -
  linux-user/mips64/target_signal.h | 1 -
  linux-user/sparc/target_signal.h  | 1 -
  6 files changed, 6 deletions(-)

diff --git a/linux-user/alpha/target_signal.h b/linux-user/alpha/target_signal.h
index 0b6a39d..bbb06e5 100644
--- a/linux-user/alpha/target_signal.h
+++ b/linux-user/alpha/target_signal.h
@@ -62,7 +62,6 @@ typedef struct target_sigaltstack {
  #define TARGET_SA_SIGINFO   0x0040
  
  #define TARGET_MINSIGSTKSZ	4096

-#define TARGET_SIGSTKSZ16384
  
  /* From .  */

  #define TARGET_GEN_INTOVF  -1  /* integer overflow */
diff --git a/linux-user/generic/signal.h b/linux-user/generic/signal.h
index ceaf8a8..6fd05b7 100644
--- a/linux-user/generic/signal.h
+++ b/linux-user/generic/signal.h
@@ -69,7 +69,6 @@ typedef struct target_sigaltstack {
  #define TARGET_SS_DISABLE 2
  
  #define TARGET_MINSIGSTKSZ 2048

-#define TARGET_SIGSTKSZ8192
  
  /* bit-flags */

  #define TARGET_SS_AUTODISARM (1U << 31) /* disable sas during sighandling */
diff --git a/linux-user/hppa/target_signal.h b/linux-user/hppa/target_signal.h
index d558119..af6c2fc 100644
--- a/linux-user/hppa/target_signal.h
+++ b/linux-user/hppa/target_signal.h
@@ -64,7 +64,6 @@ typedef struct target_sigaltstack {
  #define TARGET_SA_NOCLDWAIT 0x0080
  
  #define TARGET_MINSIGSTKSZ	2048

-#define TARGET_SIGSTKSZ8192
  
  /* bit-flags */

  #define TARGET_SS_AUTODISARM (1U << 31) /* disable sas during sighandling */
diff --git a/linux-user/mips/target_signal.h b/linux-user/mips/target_signal.h
index 780a4dd..fa542c1 100644
--- a/linux-user/mips/target_signal.h
+++ b/linux-user/mips/target_signal.h
@@ -67,7 +67,6 @@ typedef struct target_sigaltstack {
  #define TARGET_SA_RESTORER  0x0400  /* Only for O32 */
  
  #define TARGET_MINSIGSTKSZ2048

-#define TARGET_SIGSTKSZ   8192
  
  #if defined(TARGET_ABI_MIPSO32)

  /* compare linux/arch/mips/kernel/signal.c:setup_frame() */
diff --git a/linux-user/mips64/target_signal.h 
b/linux-user/mips64/target_signal.h
index 275e9b7..b05098f 100644
--- a/linux-user/mips64/target_signal.h
+++ b/linux-user/mips64/target_signal.h
@@ -65,7 +65,6 @@ typedef struct target_sigaltstack {
  #define TARGET_SA_RESETHAND 0x8000
  
  #define TARGET_MINSIGSTKSZ2048

-#define TARGET_SIGSTKSZ   8192
  
  /* bit-flags */

  #define TARGET_SS_AUTODISARM (1U << 31) /* disable sas during sighandling */
diff --git a/linux-user/sparc/target_signal.h b/linux-user/sparc/target_signal.h
index e661ddd..87757f0 100644
--- a/linux-user/sparc/target_signal.h
+++ b/linux-user/sparc/target_signal.h
@@ -65,7 +65,6 @@ typedef struct target_sigaltstack {
  #define TARGET_ARCH_HAS_KA_RESTORER 1
  
  #define TARGET_MINSIGSTKSZ	4096

-#define TARGET_SIGSTKSZ16384
  
  #ifdef TARGET_ABI32

  #define TARGET_ARCH_HAS_SETUP_FRAME


Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent

Re: [PATCH v2 2/3] linux-user: target_syscall.h remove definition TARGET_MINSIGSTKSZ


Le 26/11/2021 à 03:23, Song Gao a écrit :

TARGET_MINSIGSTKSZ has been defined in generic/signal.h
or target_signal.h, We don't need to define it again.

Signed-off-by: Song Gao 
Reviewed-by: Laurent Vivier 
Reviewed-by: Philippe Mathieu-Daudé 
---
  linux-user/aarch64/target_syscall.h| 1 -
  linux-user/alpha/target_syscall.h  | 1 -
  linux-user/arm/target_syscall.h| 1 -
  linux-user/cris/target_syscall.h   | 1 -
  linux-user/hppa/target_syscall.h   | 1 -
  linux-user/i386/target_syscall.h   | 1 -
  linux-user/m68k/target_syscall.h   | 1 -
  linux-user/microblaze/target_syscall.h | 1 -
  linux-user/mips/target_syscall.h   | 1 -
  linux-user/mips64/target_syscall.h | 1 -
  linux-user/nios2/target_syscall.h  | 1 -
  linux-user/openrisc/target_syscall.h   | 1 -
  linux-user/ppc/target_syscall.h| 1 -
  linux-user/riscv/target_syscall.h  | 1 -
  linux-user/s390x/target_syscall.h  | 1 -
  linux-user/sh4/target_syscall.h| 1 -
  linux-user/sparc/target_syscall.h  | 1 -
  linux-user/x86_64/target_syscall.h | 1 -
  18 files changed, 18 deletions(-)

diff --git a/linux-user/aarch64/target_syscall.h 
b/linux-user/aarch64/target_syscall.h
index 76f6c33..508219d 100644
--- a/linux-user/aarch64/target_syscall.h
+++ b/linux-user/aarch64/target_syscall.h
@@ -15,7 +15,6 @@ struct target_pt_regs {
  #endif
  #define UNAME_MINIMUM_RELEASE "3.8.0"
  #define TARGET_CLONE_BACKWARDS
-#define TARGET_MINSIGSTKSZ   2048
  #define TARGET_MCL_CURRENT 1
  #define TARGET_MCL_FUTURE  2
  #define TARGET_MCL_ONFAULT 4
diff --git a/linux-user/alpha/target_syscall.h 
b/linux-user/alpha/target_syscall.h
index 03091bf..fda3a49 100644
--- a/linux-user/alpha/target_syscall.h
+++ b/linux-user/alpha/target_syscall.h
@@ -63,7 +63,6 @@ struct target_pt_regs {
  #define TARGET_UAC_NOPRINT1
  #define TARGET_UAC_NOFIX  2
  #define TARGET_UAC_SIGBUS 4
-#define TARGET_MINSIGSTKSZ  4096
  #define TARGET_MCL_CURRENT 0x2000
  #define TARGET_MCL_FUTURE  0x4000
  #define TARGET_MCL_ONFAULT 0x8000
diff --git a/linux-user/arm/target_syscall.h b/linux-user/arm/target_syscall.h
index e870ed7..f04f9c9 100644
--- a/linux-user/arm/target_syscall.h
+++ b/linux-user/arm/target_syscall.h
@@ -27,7 +27,6 @@ struct target_pt_regs {
  
  #define TARGET_CLONE_BACKWARDS
  
-#define TARGET_MINSIGSTKSZ 2048

  #define TARGET_MCL_CURRENT 1
  #define TARGET_MCL_FUTURE  2
  #define TARGET_MCL_ONFAULT 4
diff --git a/linux-user/cris/target_syscall.h b/linux-user/cris/target_syscall.h
index 19e1281..0b5ebf1 100644
--- a/linux-user/cris/target_syscall.h
+++ b/linux-user/cris/target_syscall.h
@@ -39,7 +39,6 @@ struct target_pt_regs {
  };
  
  #define TARGET_CLONE_BACKWARDS2

-#define TARGET_MINSIGSTKSZ 2048
  #define TARGET_MCL_CURRENT 1
  #define TARGET_MCL_FUTURE  2
  #define TARGET_MCL_ONFAULT 4
diff --git a/linux-user/hppa/target_syscall.h b/linux-user/hppa/target_syscall.h
index 0018bcb..4b382c1 100644
--- a/linux-user/hppa/target_syscall.h
+++ b/linux-user/hppa/target_syscall.h
@@ -22,7 +22,6 @@ struct target_pt_regs {
  #define UNAME_MACHINE "parisc"
  #define UNAME_MINIMUM_RELEASE "2.6.32"
  #define TARGET_CLONE_BACKWARDS
-#define TARGET_MINSIGSTKSZ   2048
  #define TARGET_MCL_CURRENT 1
  #define TARGET_MCL_FUTURE  2
  #define TARGET_MCL_ONFAULT 4
diff --git a/linux-user/i386/target_syscall.h b/linux-user/i386/target_syscall.h
index ed356b3..aaade06 100644
--- a/linux-user/i386/target_syscall.h
+++ b/linux-user/i386/target_syscall.h
@@ -150,7 +150,6 @@ struct target_vm86plus_struct {
  #define UNAME_MINIMUM_RELEASE "2.6.32"
  
  #define TARGET_CLONE_BACKWARDS

-#define TARGET_MINSIGSTKSZ 2048
  #define TARGET_MCL_CURRENT 1
  #define TARGET_MCL_FUTURE  2
  #define TARGET_MCL_ONFAULT 4
diff --git a/linux-user/m68k/target_syscall.h b/linux-user/m68k/target_syscall.h
index 23359a6..8d4ddbd 100644
--- a/linux-user/m68k/target_syscall.h
+++ b/linux-user/m68k/target_syscall.h
@@ -20,7 +20,6 @@ struct target_pt_regs {
  #define UNAME_MACHINE "m68k"
  #define UNAME_MINIMUM_RELEASE "2.6.32"
  
-#define TARGET_MINSIGSTKSZ 2048

  #define TARGET_MCL_CURRENT 1
  #define TARGET_MCL_FUTURE  2
  #define TARGET_MCL_ONFAULT 4
diff --git a/linux-user/microblaze/target_syscall.h 
b/linux-user/microblaze/target_syscall.h
index 7f653db..43362a1 100644
--- a/linux-user/microblaze/target_syscall.h
+++ b/linux-user/microblaze/target_syscall.h
@@ -49,7 +49,6 @@ struct target_pt_regs {
  };
  
  #define TARGET_CLONE_BACKWARDS

-#define TARGET_MINSIGSTKSZ  2048
  #define TARGET_MCL_CURRENT 1
  #define TARGET_MCL_FUTURE  2
  #define TARGET_MCL_ONFAULT 4
diff --git a/linux-user/mips/target_syscall.h b/linux-user/mips/target_syscall.h
index f590574..7a82661 100644
--- a/linux-user/mips/target_syscall.h
+++ b/linux-user/mips/target_syscall.h
@@ -24,7 +24,6 @@ struct target_pt_regs {
  #define UNAME_MINIMUM_RELEASE "2.6.32"
  
  #define TARGET_CLONE_BACKWARDS

-

[PATCH v3 10/12] target/riscv: Add kvm_riscv_get/put_regs_timer

Add kvm_riscv_get/put_regs_timer to synchronize virtual time context
from KVM.

To set register of RISCV_TIMER_REG(state) will occur a error from KVM
on kvm_timer_state == 0. It's better to adapt in KVM, but it doesn't matter
that adaping in QEMU.

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
---
 target/riscv/cpu.h |  7 +
 target/riscv/kvm.c | 72 ++
 2 files changed, 79 insertions(+)

diff --git a/target/riscv/cpu.h b/target/riscv/cpu.h
index e7dba35acb..c892a2c8b7 100644
--- a/target/riscv/cpu.h
+++ b/target/riscv/cpu.h
@@ -259,6 +259,13 @@ struct CPURISCVState {
 
 hwaddr kernel_addr;
 hwaddr fdt_addr;
+
+/* kvm timer */
+bool kvm_timer_dirty;
+uint64_t kvm_timer_time;
+uint64_t kvm_timer_compare;
+uint64_t kvm_timer_state;
+uint64_t kvm_timer_frequency;
 };
 
 OBJECT_DECLARE_TYPE(RISCVCPU, RISCVCPUClass,
diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index 4d08669c81..3c20ec5ad3 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -41,6 +41,7 @@
 #include "sbi_ecall_interface.h"
 #include "chardev/char-fe.h"
 #include "semihosting/console.h"
+#include "migration/migration.h"
 
 static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type, uint64_t 
idx)
 {
@@ -65,6 +66,9 @@ static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t 
type, uint64_t idx
 #define RISCV_CSR_REG(env, name)  kvm_riscv_reg_id(env, KVM_REG_RISCV_CSR, \
  KVM_REG_RISCV_CSR_REG(name))
 
+#define RISCV_TIMER_REG(env, name)  kvm_riscv_reg_id(env, KVM_REG_RISCV_TIMER, 
\
+ KVM_REG_RISCV_TIMER_REG(name))
+
 #define RISCV_FP_F_REG(env, idx)  kvm_riscv_reg_id(env, KVM_REG_RISCV_FP_F, 
idx)
 
 #define RISCV_FP_D_REG(env, idx)  kvm_riscv_reg_id(env, KVM_REG_RISCV_FP_D, 
idx)
@@ -85,6 +89,22 @@ static uint64_t kvm_riscv_reg_id(CPURISCVState *env, 
uint64_t type, uint64_t idx
 } \
 } while(0)
 
+#define KVM_RISCV_GET_TIMER(cs, env, name, reg) \
+do { \
+int ret = kvm_get_one_reg(cs, RISCV_TIMER_REG(env, name), ®); \
+if (ret) { \
+abort(); \
+} \
+} while(0)
+
+#define KVM_RISCV_SET_TIMER(cs, env, name, reg) \
+do { \
+int ret = kvm_set_one_reg(cs, RISCV_TIMER_REG(env, time), ®); \
+if (ret) { \
+abort(); \
+} \
+} while (0)
+
 static int kvm_riscv_get_regs_core(CPUState *cs)
 {
 int ret = 0;
@@ -236,6 +256,58 @@ static int kvm_riscv_put_regs_fp(CPUState *cs)
 return ret;
 }
 
+static void kvm_riscv_get_regs_timer(CPUState *cs)
+{
+CPURISCVState *env = &RISCV_CPU(cs)->env;
+
+if (env->kvm_timer_dirty) {
+return;
+}
+
+KVM_RISCV_GET_TIMER(cs, env, time, env->kvm_timer_time);
+KVM_RISCV_GET_TIMER(cs, env, compare, env->kvm_timer_compare);
+KVM_RISCV_GET_TIMER(cs, env, state, env->kvm_timer_state);
+KVM_RISCV_GET_TIMER(cs, env, frequency, env->kvm_timer_frequency);
+
+env->kvm_timer_dirty = true;
+}
+
+static void kvm_riscv_put_regs_timer(CPUState *cs)
+{
+uint64_t reg;
+CPURISCVState *env = &RISCV_CPU(cs)->env;
+
+if (!env->kvm_timer_dirty) {
+return;
+}
+
+KVM_RISCV_SET_TIMER(cs, env, time, env->kvm_timer_time);
+KVM_RISCV_SET_TIMER(cs, env, compare, env->kvm_timer_compare);
+
+/*
+ * To set register of RISCV_TIMER_REG(state) will occur a error from KVM
+ * on env->kvm_timer_state == 0, It's better to adapt in KVM, but it
+ * doesn't matter that adaping in QEMU now.
+ * TODO If KVM changes, adapt here.
+ */
+if (env->kvm_timer_state) {
+KVM_RISCV_SET_TIMER(cs, env, state, env->kvm_timer_state);
+}
+
+/*
+ * For now, migration will not work between Hosts with different timer
+ * frequency. Therefore, we should check whether they are the same here
+ * during the migration.
+ */
+if (migration_is_running(migrate_get_current()->state)) {
+KVM_RISCV_GET_TIMER(cs, env, frequency, reg);
+if (reg != env->kvm_timer_frequency) {
+error_report("Dst Hosts timer frequency != Src Hosts");
+}
+}
+
+env->kvm_timer_dirty = false;
+}
 
 const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
 KVM_CAP_LAST_INFO
-- 
2.19.1

Re: [PATCH v2 8/9] hw/riscv: virt: Allow support for 32 cores

2021-12-20 Thread Bin Meng

On Thu, Dec 16, 2021 at 12:55 PM Alistair Francis
 wrote:
>
> From: Alistair Francis 
>
> Linux supports up to 32 cores for both 32-bit and 64-bit RISC-V, so
> let's set that as the maximum for the virt board.
>
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/435
> Signed-off-by: Alistair Francis 
> ---
>  include/hw/riscv/virt.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng

[PATCH 4/4] tests/qtest/boot-order-test: Check whether machines are available

Machines might not always be compiled into the QEMU binary, so
we should skip the test instead of failing if it is not available.

Signed-off-by: Thomas Huth 
---
 tests/qtest/boot-order-test.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tests/qtest/boot-order-test.c b/tests/qtest/boot-order-test.c
index fac580d6c4..f1f59b1261 100644
--- a/tests/qtest/boot-order-test.c
+++ b/tests/qtest/boot-order-test.c
@@ -34,6 +34,11 @@ static void test_a_boot_order(const char *machine,
 uint64_t actual;
 QTestState *qts;
 
+if (machine && !qtest_has_machine(machine)) {
+g_test_skip("Machine is not available");
+return;
+}
+
 qts = qtest_initf("-nodefaults%s%s %s", machine ? " -M " : "",
   machine ?: "", test_args);
 actual = read_boot_order(qts);
-- 
2.27.0

[PATCH v3 07/12] target/riscv: Support setting external interrupt by KVM

When KVM is enabled, set the S-mode external interrupt through
kvm_riscv_set_irq function.

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Reviewed-by: Alistair Francis 
---
 target/riscv/cpu.c   |  6 +-
 target/riscv/kvm-stub.c  |  5 +
 target/riscv/kvm.c   | 17 +
 target/riscv/kvm_riscv.h |  1 +
 4 files changed, 28 insertions(+), 1 deletion(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 1c944872a3..3fc3a9c45b 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -603,7 +603,11 @@ static void riscv_cpu_set_irq(void *opaque, int irq, int 
level)
 case IRQ_S_EXT:
 case IRQ_VS_EXT:
 case IRQ_M_EXT:
-riscv_cpu_update_mip(cpu, 1 << irq, BOOL_TO_MASK(level));
+if (kvm_enabled()) {
+kvm_riscv_set_irq(cpu, irq, level);
+} else {
+riscv_cpu_update_mip(cpu, 1 << irq, BOOL_TO_MASK(level));
+}
 break;
 default:
 g_assert_not_reached();
diff --git a/target/riscv/kvm-stub.c b/target/riscv/kvm-stub.c
index 39b96fe3f4..4e8fc31a21 100644
--- a/target/riscv/kvm-stub.c
+++ b/target/riscv/kvm-stub.c
@@ -23,3 +23,8 @@ void kvm_riscv_reset_vcpu(RISCVCPU *cpu)
 {
 abort();
 }
+
+void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level)
+{
+abort();
+}
diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index db6d8a5b6e..0027f11f45 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -383,6 +383,23 @@ void kvm_riscv_reset_vcpu(RISCVCPU *cpu)
 env->satp = 0;
 }
 
+void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level)
+{
+int ret;
+unsigned virq = level ? KVM_INTERRUPT_SET : KVM_INTERRUPT_UNSET;
+
+if (irq != IRQ_S_EXT) {
+perror("kvm riscv set irq != IRQ_S_EXT\n");
+abort();
+}
+
+ret = kvm_vcpu_ioctl(CPU(cpu), KVM_INTERRUPT, &virq);
+if (ret < 0) {
+perror("Set irq failed");
+abort();
+}
+}
+
 bool kvm_arch_cpu_check_are_resettable(void)
 {
 return true;
diff --git a/target/riscv/kvm_riscv.h b/target/riscv/kvm_riscv.h
index f38c82bf59..ed281bdce0 100644
--- a/target/riscv/kvm_riscv.h
+++ b/target/riscv/kvm_riscv.h
@@ -20,5 +20,6 @@
 #define QEMU_KVM_RISCV_H
 
 void kvm_riscv_reset_vcpu(RISCVCPU *cpu);
+void kvm_riscv_set_irq(RISCVCPU *cpu, int irq, int level);
 
 #endif
-- 
2.19.1

Re: [PATCH] linux-user: Remove the deprecated ppc64abi32 target


Le 15/12/2021 à 09:49, Thomas Huth a écrit :

It's likely broken, and nobody cared for picking it up again
during the deprecation phase, so let's remove this now.

Since this is the last entry in deprecated_targets_list, remove
the related code in the configure script, too.

Signed-off-by: Thomas Huth 
---
  .gitlab-ci.d/buildtest.yml| 27 -
  configs/targets/ppc64abi32-linux-user.mak |  8 -
  configure | 29 +--
  docs/about/deprecated.rst |  7 -
  docs/about/removed-features.rst   |  8 +
  docs/user/main.rst|  1 -
  linux-user/elfload.c  |  4 +--
  linux-user/ppc/signal.c   | 11 ++-
  linux-user/ppc/target_syscall.h   |  4 +--
  linux-user/syscall_defs.h |  6 ++--
  .../dockerfiles/debian-ppc64el-cross.docker   |  2 +-
  tests/tcg/configure.sh|  2 +-
  12 files changed, 21 insertions(+), 88 deletions(-)
  delete mode 100644 configs/targets/ppc64abi32-linux-user.mak



Applied to my linux-user-for-7.0 branch.

Thanks,
Laurent

[PATCH v3 08/12] target/riscv: Handle KVM_EXIT_RISCV_SBI exit

Use char-fe to handle console sbi call, which implement early
console io while apply 'earlycon=sbi' into kernel parameters.

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Reviewed-by: Anup Patel 
---
 target/riscv/kvm.c | 43 +-
 target/riscv/sbi_ecall_interface.h | 72 ++
 2 files changed, 114 insertions(+), 1 deletion(-)
 create mode 100644 target/riscv/sbi_ecall_interface.h

diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index 0027f11f45..4d08669c81 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -38,6 +38,9 @@
 #include "qemu/log.h"
 #include "hw/loader.h"
 #include "kvm_riscv.h"
+#include "sbi_ecall_interface.h"
+#include "chardev/char-fe.h"
+#include "semihosting/console.h"
 
 static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type, uint64_t 
idx)
 {
@@ -365,9 +368,47 @@ bool kvm_arch_stop_on_emulation_error(CPUState *cs)
 return true;
 }
 
+static int kvm_riscv_handle_sbi(CPUState *cs, struct kvm_run *run)
+{
+int ret = 0;
+unsigned char ch;
+switch (run->riscv_sbi.extension_id) {
+case SBI_EXT_0_1_CONSOLE_PUTCHAR:
+ch = run->riscv_sbi.args[0];
+qemu_semihosting_log_out((const char *)&ch, sizeof(ch));
+break;
+case SBI_EXT_0_1_CONSOLE_GETCHAR:
+ret = qemu_chr_fe_read_all(serial_hd(0)->be, &ch, sizeof(ch));
+if (ret == sizeof(ch)) {
+run->riscv_sbi.args[0] = ch;
+} else {
+run->riscv_sbi.args[0] = -1;
+}
+break;
+default:
+qemu_log_mask(LOG_UNIMP,
+  "%s: un-handled SBI EXIT, specific reasons is %lu\n",
+  __func__, run->riscv_sbi.extension_id);
+ret = -1;
+break;
+}
+return ret;
+}
+
 int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
 {
-return 0;
+int ret = 0;
+switch (run->exit_reason) {
+case KVM_EXIT_RISCV_SBI:
+ret = kvm_riscv_handle_sbi(cs, run);
+break;
+default:
+qemu_log_mask(LOG_UNIMP, "%s: un-handled exit reason %d\n",
+  __func__, run->exit_reason);
+ret = -1;
+break;
+}
+return ret;
 }
 
 void kvm_riscv_reset_vcpu(RISCVCPU *cpu)
diff --git a/target/riscv/sbi_ecall_interface.h 
b/target/riscv/sbi_ecall_interface.h
new file mode 100644
index 00..fb1a3fa8f2
--- /dev/null
+++ b/target/riscv/sbi_ecall_interface.h
@@ -0,0 +1,72 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (c) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ *   Anup Patel 
+ */
+
+#ifndef __SBI_ECALL_INTERFACE_H__
+#define __SBI_ECALL_INTERFACE_H__
+
+/* clang-format off */
+
+/* SBI Extension IDs */
+#define SBI_EXT_0_1_SET_TIMER   0x0
+#define SBI_EXT_0_1_CONSOLE_PUTCHAR 0x1
+#define SBI_EXT_0_1_CONSOLE_GETCHAR 0x2
+#define SBI_EXT_0_1_CLEAR_IPI   0x3
+#define SBI_EXT_0_1_SEND_IPI0x4
+#define SBI_EXT_0_1_REMOTE_FENCE_I  0x5
+#define SBI_EXT_0_1_REMOTE_SFENCE_VMA   0x6
+#define SBI_EXT_0_1_REMOTE_SFENCE_VMA_ASID 0x7
+#define SBI_EXT_0_1_SHUTDOWN0x8
+#define SBI_EXT_BASE0x10
+#define SBI_EXT_TIME0x54494D45
+#define SBI_EXT_IPI 0x735049
+#define SBI_EXT_RFENCE  0x52464E43
+#define SBI_EXT_HSM 0x48534D
+
+/* SBI function IDs for BASE extension*/
+#define SBI_EXT_BASE_GET_SPEC_VERSION   0x0
+#define SBI_EXT_BASE_GET_IMP_ID 0x1
+#define SBI_EXT_BASE_GET_IMP_VERSION0x2
+#define SBI_EXT_BASE_PROBE_EXT  0x3
+#define SBI_EXT_BASE_GET_MVENDORID  0x4
+#define SBI_EXT_BASE_GET_MARCHID0x5
+#define SBI_EXT_BASE_GET_MIMPID 0x6
+
+/* SBI function IDs for TIME extension*/
+#define SBI_EXT_TIME_SET_TIMER  0x0
+
+/* SBI function IDs for IPI extension*/
+#define SBI_EXT_IPI_SEND_IPI0x0
+
+/* SBI function IDs for RFENCE extension*/
+#define SBI_EXT_RFENCE_REMOTE_FENCE_I   0x0
+#define SBI_EXT_RFENCE_REMOTE_SFENCE_VMA0x1
+#define SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID  0x2
+#define SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA   0x3
+#define SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID 0x4
+#define SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA   0x5
+#define SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID 0x6
+
+/* SBI function IDs for HSM extension */
+#define SBI_EXT_HSM_HART_START  0x0
+#define SBI_EXT_HSM_HART_STOP   0x1
+#define SBI_EXT_HSM_HART_GET_STATUS 0x2
+
+#define SBI_HSM_HART_STATUS_STARTED 0x0
+#define SBI_HSM_HART_STATUS_STOPPED 0x1
+#define SBI_HSM_HART_STATUS_START_PENDING   0x2
+#define SBI_HSM_HART_STATUS_STOP_PENDING0x3
+
+#define SBI_SPEC_VERSION_MAJOR_OFFSET   24
+#define SBI_SPEC_VERSION_MAJOR_MASK 0x7f
+#define SBI_SPEC_VERSION_MINOR_MASK 0xff
+#define SBI_EXT_VENDOR_START0x0900
+#define SBI_EXT_VENDOR_END  0x09FF
+/* clang-format on */
+
+#endif
--

Re: [PATCH 00/15] ppc/ppc405: decade cleanup

2021-12-20 Thread Cédric Le Goater



Don't know if this is the reason of our problems but I think there is
something to investigate around timer interrupts:


/ # cat /proc/interrupts
 CPU0
   16: 68   UIC   1 Level serial
LOC:  0   Local timer interrupts for timer event device
LOC:  0   Local timer interrupts for others
SPU:  0   Spurious interrupts
PMI:  0   Performance monitoring interrupts
MCE:  0   Machine check exceptions

Any idea what the problem can be ? How does QEMU generates timer
interrupts ?


I did some archeology and fixed the 405 timer (PIT). Please see commits in :

  https://github.com/legoater/qemu/commits/ppc405

but we are still getting segfaults. At some point /init tries to load from
fe04 which is obviously wrong.

Add -d int,mmu to have more info from QEMU internals.

I have gathered some info on this page :

  https://github.com/legoater/qemu/wiki/ref405ep

Thanks,

C.

[PATCH v3 01/12] update-linux-headers: Add asm-riscv/kvm.h

Add asm-riscv/kvm.h for RISC-V KVM, and update linux/kvm.h

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Acked-by: Alistair Francis 
Reviewed-by: Anup Patel 
---
 linux-headers/asm-riscv/kvm.h | 128 ++
 1 file changed, 128 insertions(+)
 create mode 100644 linux-headers/asm-riscv/kvm.h

diff --git a/linux-headers/asm-riscv/kvm.h b/linux-headers/asm-riscv/kvm.h
new file mode 100644
index 00..f808ad1ce5
--- /dev/null
+++ b/linux-headers/asm-riscv/kvm.h
@@ -0,0 +1,128 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * Copyright (C) 2019 Western Digital Corporation or its affiliates.
+ *
+ * Authors:
+ * Anup Patel 
+ */
+
+#ifndef __LINUX_KVM_RISCV_H
+#define __LINUX_KVM_RISCV_H
+
+#ifndef __ASSEMBLY__
+
+#include 
+#include 
+
+#define __KVM_HAVE_READONLY_MEM
+
+#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
+
+#define KVM_INTERRUPT_SET  -1U
+#define KVM_INTERRUPT_UNSET-2U
+
+/* for KVM_GET_REGS and KVM_SET_REGS */
+struct kvm_regs {
+};
+
+/* for KVM_GET_FPU and KVM_SET_FPU */
+struct kvm_fpu {
+};
+
+/* KVM Debug exit structure */
+struct kvm_debug_exit_arch {
+};
+
+/* for KVM_SET_GUEST_DEBUG */
+struct kvm_guest_debug_arch {
+};
+
+/* definition of registers in kvm_run */
+struct kvm_sync_regs {
+};
+
+/* for KVM_GET_SREGS and KVM_SET_SREGS */
+struct kvm_sregs {
+};
+
+/* CONFIG registers for KVM_GET_ONE_REG and KVM_SET_ONE_REG */
+struct kvm_riscv_config {
+   unsigned long isa;
+};
+
+/* CORE registers for KVM_GET_ONE_REG and KVM_SET_ONE_REG */
+struct kvm_riscv_core {
+   struct user_regs_struct regs;
+   unsigned long mode;
+};
+
+/* Possible privilege modes for kvm_riscv_core */
+#define KVM_RISCV_MODE_S   1
+#define KVM_RISCV_MODE_U   0
+
+/* CSR registers for KVM_GET_ONE_REG and KVM_SET_ONE_REG */
+struct kvm_riscv_csr {
+   unsigned long sstatus;
+   unsigned long sie;
+   unsigned long stvec;
+   unsigned long sscratch;
+   unsigned long sepc;
+   unsigned long scause;
+   unsigned long stval;
+   unsigned long sip;
+   unsigned long satp;
+   unsigned long scounteren;
+};
+
+/* TIMER registers for KVM_GET_ONE_REG and KVM_SET_ONE_REG */
+struct kvm_riscv_timer {
+   __u64 frequency;
+   __u64 time;
+   __u64 compare;
+   __u64 state;
+};
+
+/* Possible states for kvm_riscv_timer */
+#define KVM_RISCV_TIMER_STATE_OFF  0
+#define KVM_RISCV_TIMER_STATE_ON   1
+
+#define KVM_REG_SIZE(id)   \
+   (1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))
+
+/* If you need to interpret the index values, here is the key: */
+#define KVM_REG_RISCV_TYPE_MASK0xFF00
+#define KVM_REG_RISCV_TYPE_SHIFT   24
+
+/* Config registers are mapped as type 1 */
+#define KVM_REG_RISCV_CONFIG   (0x01 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_CONFIG_REG(name) \
+   (offsetof(struct kvm_riscv_config, name) / sizeof(unsigned long))
+
+/* Core registers are mapped as type 2 */
+#define KVM_REG_RISCV_CORE (0x02 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_CORE_REG(name)   \
+   (offsetof(struct kvm_riscv_core, name) / sizeof(unsigned long))
+
+/* Control and status registers are mapped as type 3 */
+#define KVM_REG_RISCV_CSR  (0x03 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_CSR_REG(name)\
+   (offsetof(struct kvm_riscv_csr, name) / sizeof(unsigned long))
+
+/* Timer registers are mapped as type 4 */
+#define KVM_REG_RISCV_TIMER(0x04 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_TIMER_REG(name)  \
+   (offsetof(struct kvm_riscv_timer, name) / sizeof(__u64))
+
+/* F extension registers are mapped as type 5 */
+#define KVM_REG_RISCV_FP_F (0x05 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_FP_F_REG(name)   \
+   (offsetof(struct __riscv_f_ext_state, name) / sizeof(__u32))
+
+/* D extension registers are mapped as type 6 */
+#define KVM_REG_RISCV_FP_D (0x06 << KVM_REG_RISCV_TYPE_SHIFT)
+#define KVM_REG_RISCV_FP_D_REG(name)   \
+   (offsetof(struct __riscv_d_ext_state, name) / sizeof(__u64))
+
+#endif
+
+#endif /* __LINUX_KVM_RISCV_H */
-- 
2.19.1

[RFC v2 2/2] migration: Tally pre-copy, downtime and post-copy bytes independently

Provide information on the number of bytes copied in the pre-copy,
downtime and post-copy phases of migration.

Signed-off-by: David Edmondson 
---
 migration/migration.c |  3 +++
 migration/ram.c   |  7 +++
 monitor/hmp-cmds.c| 12 
 qapi/migration.json   | 13 -
 4 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/migration/migration.c b/migration/migration.c
index 3de11ae921..3950510be7 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -1013,6 +1013,9 @@ static void populate_ram_info(MigrationInfo *info, 
MigrationState *s)
 info->ram->page_size = page_size;
 info->ram->multifd_bytes = ram_counters.multifd_bytes;
 info->ram->pages_per_second = s->pages_per_second;
+info->ram->precopy_bytes = ram_counters.precopy_bytes;
+info->ram->downtime_bytes = ram_counters.downtime_bytes;
+info->ram->postcopy_bytes = ram_counters.postcopy_bytes;
 
 if (migrate_use_xbzrle()) {
 info->has_xbzrle_cache = true;
diff --git a/migration/ram.c b/migration/ram.c
index bd53e50a7f..389868c988 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -388,6 +388,13 @@ MigrationStats ram_counters;
 
 static void ram_transferred_add(uint64_t bytes)
 {
+if (runstate_is_running()) {
+ram_counters.precopy_bytes += bytes;
+} else if (migration_in_postcopy()) {
+ram_counters.postcopy_bytes += bytes;
+} else {
+ram_counters.downtime_bytes += bytes;
+}
 ram_counters.transferred += bytes;
 }
 
diff --git a/monitor/hmp-cmds.c b/monitor/hmp-cmds.c
index 9c91bf93e9..6049772178 100644
--- a/monitor/hmp-cmds.c
+++ b/monitor/hmp-cmds.c
@@ -293,6 +293,18 @@ void hmp_info_migrate(Monitor *mon, const QDict *qdict)
 monitor_printf(mon, "postcopy request count: %" PRIu64 "\n",
info->ram->postcopy_requests);
 }
+if (info->ram->precopy_bytes) {
+monitor_printf(mon, "precopy ram: %" PRIu64 " kbytes\n",
+   info->ram->precopy_bytes >> 10);
+}
+if (info->ram->downtime_bytes) {
+monitor_printf(mon, "downtime ram: %" PRIu64 " kbytes\n",
+   info->ram->downtime_bytes >> 10);
+}
+if (info->ram->postcopy_bytes) {
+monitor_printf(mon, "postcopy ram: %" PRIu64 " kbytes\n",
+   info->ram->postcopy_bytes >> 10);
+}
 }
 
 if (info->has_disk) {
diff --git a/qapi/migration.json b/qapi/migration.json
index bbfd48cf0b..5975a0e104 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -46,6 +46,15 @@
 # @pages-per-second: the number of memory pages transferred per second
 #(Since 4.0)
 #
+# @precopy-bytes: The number of bytes sent in the pre-copy phase
+# (since 7.0).
+#
+# @downtime-bytes: The number of bytes sent while the guest is paused
+#  (since 7.0).
+#
+# @postcopy-bytes: The number of bytes sent during the post-copy phase
+#  (since 7.0).
+#
 # Since: 0.14
 ##
 { 'struct': 'MigrationStats',
@@ -54,7 +63,9 @@
'normal-bytes': 'int', 'dirty-pages-rate' : 'int',
'mbps' : 'number', 'dirty-sync-count' : 'int',
'postcopy-requests' : 'int', 'page-size' : 'int',
-   'multifd-bytes' : 'uint64', 'pages-per-second' : 'uint64' } }
+   'multifd-bytes' : 'uint64', 'pages-per-second' : 'uint64',
+   'precopy-bytes' : 'uint64', 'downtime-bytes' : 'uint64',
+   'postcopy-bytes' : 'uint64' } }
 
 ##
 # @XBZRLECacheStats:
-- 
2.33.0

[PATCH v3 11/12] target/riscv: Implement virtual time adjusting with vm state changing

We hope that virtual time adjusts with vm state changing. When a vm
is stopped, guest virtual time should stop counting and kvm_timer
should be stopped. When the vm is resumed, guest virtual time should
continue to count and kvm_timer should be restored.

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Reviewed-by: Anup Patel 
---
 target/riscv/kvm.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index 3c20ec5ad3..6c0306bd2b 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -42,6 +42,7 @@
 #include "chardev/char-fe.h"
 #include "semihosting/console.h"
 #include "migration/migration.h"
+#include "sysemu/runstate.h"
 
 static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type, uint64_t 
idx)
 {
@@ -378,6 +379,17 @@ unsigned long kvm_arch_vcpu_id(CPUState *cpu)
 return cpu->cpu_index;
 }
 
+static void kvm_riscv_vm_state_change(void *opaque, bool running, RunState 
state)
+{
+CPUState *cs = opaque;
+
+if (running) {
+kvm_riscv_put_regs_timer(cs);
+} else {
+kvm_riscv_get_regs_timer(cs);
+}
+}
+
 void kvm_arch_init_irq_routing(KVMState *s)
 {
 }
@@ -390,6 +402,8 @@ int kvm_arch_init_vcpu(CPUState *cs)
 CPURISCVState *env = &cpu->env;
 uint64_t id;
 
+qemu_add_vm_change_state_handler(kvm_riscv_vm_state_change, cs);
+
 id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG, 
KVM_REG_RISCV_CONFIG_REG(isa));
 ret = kvm_get_one_reg(cs, id, &isa);
 if (ret) {
-- 
2.19.1

[PATCH v3 02/12] target/riscv: Add target/riscv/kvm.c to place the public kvm interface

Add target/riscv/kvm.c to place kvm_arch_* function needed by
kvm/kvm-all.c. Meanwhile, add kvm support in meson.build file.

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Reviewed-by: Alistair Francis 
Reviewed-by: Anup Patel 
---
 meson.build  |   2 +
 target/riscv/kvm.c   | 133 +++
 target/riscv/meson.build |   1 +
 3 files changed, 136 insertions(+)
 create mode 100644 target/riscv/kvm.c

diff --git a/meson.build b/meson.build
index 2495360fd0..e74633b42c 100644
--- a/meson.build
+++ b/meson.build
@@ -85,6 +85,8 @@ elif cpu in ['ppc', 'ppc64']
   kvm_targets = ['ppc-softmmu', 'ppc64-softmmu']
 elif cpu in ['mips', 'mips64']
   kvm_targets = ['mips-softmmu', 'mipsel-softmmu', 'mips64-softmmu', 
'mips64el-softmmu']
+elif cpu in ['riscv']
+  kvm_targets = ['riscv32-softmmu', 'riscv64-softmmu']
 else
   kvm_targets = []
 endif
diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
new file mode 100644
index 00..687dd4b621
--- /dev/null
+++ b/target/riscv/kvm.c
@@ -0,0 +1,133 @@
+/*
+ * RISC-V implementation of KVM hooks
+ *
+ * Copyright (c) 2020 Huawei Technologies Co., Ltd
+ *
+ * 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 
+
+#include 
+
+#include "qemu-common.h"
+#include "qemu/timer.h"
+#include "qemu/error-report.h"
+#include "qemu/main-loop.h"
+#include "sysemu/sysemu.h"
+#include "sysemu/kvm.h"
+#include "sysemu/kvm_int.h"
+#include "cpu.h"
+#include "trace.h"
+#include "hw/pci/pci.h"
+#include "exec/memattrs.h"
+#include "exec/address-spaces.h"
+#include "hw/boards.h"
+#include "hw/irq.h"
+#include "qemu/log.h"
+#include "hw/loader.h"
+
+const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
+KVM_CAP_LAST_INFO
+};
+
+int kvm_arch_get_registers(CPUState *cs)
+{
+return 0;
+}
+
+int kvm_arch_put_registers(CPUState *cs, int level)
+{
+return 0;
+}
+
+int kvm_arch_release_virq_post(int virq)
+{
+return 0;
+}
+
+int kvm_arch_fixup_msi_route(struct kvm_irq_routing_entry *route,
+ uint64_t address, uint32_t data, PCIDevice *dev)
+{
+return 0;
+}
+
+int kvm_arch_destroy_vcpu(CPUState *cs)
+{
+return 0;
+}
+
+unsigned long kvm_arch_vcpu_id(CPUState *cpu)
+{
+return cpu->cpu_index;
+}
+
+void kvm_arch_init_irq_routing(KVMState *s)
+{
+}
+
+int kvm_arch_init_vcpu(CPUState *cs)
+{
+return 0;
+}
+
+int kvm_arch_msi_data_to_gsi(uint32_t data)
+{
+abort();
+}
+
+int kvm_arch_add_msi_route_post(struct kvm_irq_routing_entry *route,
+int vector, PCIDevice *dev)
+{
+return 0;
+}
+
+int kvm_arch_init(MachineState *ms, KVMState *s)
+{
+return 0;
+}
+
+int kvm_arch_irqchip_create(KVMState *s)
+{
+return 0;
+}
+
+int kvm_arch_process_async_events(CPUState *cs)
+{
+return 0;
+}
+
+void kvm_arch_pre_run(CPUState *cs, struct kvm_run *run)
+{
+}
+
+MemTxAttrs kvm_arch_post_run(CPUState *cs, struct kvm_run *run)
+{
+return MEMTXATTRS_UNSPECIFIED;
+}
+
+bool kvm_arch_stop_on_emulation_error(CPUState *cs)
+{
+return true;
+}
+
+int kvm_arch_handle_exit(CPUState *cs, struct kvm_run *run)
+{
+return 0;
+}
+
+bool kvm_arch_cpu_check_are_resettable(void)
+{
+return true;
+}
diff --git a/target/riscv/meson.build b/target/riscv/meson.build
index d5e0bc93ea..2faf08a941 100644
--- a/target/riscv/meson.build
+++ b/target/riscv/meson.build
@@ -19,6 +19,7 @@ riscv_ss.add(files(
   'bitmanip_helper.c',
   'translate.c',
 ))
+riscv_ss.add(when: 'CONFIG_KVM', if_true: files('kvm.c'))
 
 riscv_softmmu_ss = ss.source_set()
 riscv_softmmu_ss.add(files(
-- 
2.19.1

Re: [PATCH v2 7/9] hw/riscv: Use error_fatal for SoC realisation

2021-12-20 Thread Bin Meng

On Thu, Dec 16, 2021 at 12:55 PM Alistair Francis
 wrote:
>
> From: Alistair Francis 
>
> When realising the SoC use error_fatal instead of error_abort as the
> process can fail and report useful information to the user.
>
> Currently a user can see this:
>
>$ ../qemu/bld/qemu-system-riscv64 -M sifive_u -S -monitor stdio -display 
> none -drive if=pflash
> QEMU 6.1.93 monitor - type 'help' for more information
> (qemu) Unexpected error in sifive_u_otp_realize() at 
> ../hw/misc/sifive_u_otp.c:229:
> qemu-system-riscv64: OTP drive size < 16K
> Aborted (core dumped)
>
> Which this patch addresses
>
> Signed-off-by: Alistair Francis 
> Reported-by: Markus Armbruster 
> Reviewed-by: Philippe Mathieu-Daudé 
> Reviewed-by: Markus Armbruster 
> ---
>  hw/riscv/microchip_pfsoc.c | 2 +-
>  hw/riscv/opentitan.c   | 2 +-
>  hw/riscv/sifive_e.c| 2 +-
>  hw/riscv/sifive_u.c| 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
>

Reviewed-by: Bin Meng 
Tested-by: Bin Meng

[PATCH v3 03/12] target/riscv: Implement function kvm_arch_init_vcpu

Get isa info from kvm while kvm init.

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Reviewed-by: Alistair Francis 
Reviewed-by: Anup Patel 
---
 target/riscv/kvm.c | 32 +++-
 1 file changed, 31 insertions(+), 1 deletion(-)

diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index 687dd4b621..ccf3753048 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -38,6 +38,23 @@
 #include "qemu/log.h"
 #include "hw/loader.h"
 
+static uint64_t kvm_riscv_reg_id(CPURISCVState *env, uint64_t type, uint64_t 
idx)
+{
+uint64_t id = KVM_REG_RISCV | type | idx;
+
+switch (riscv_cpu_mxl(env)) {
+case MXL_RV32:
+id |= KVM_REG_SIZE_U32;
+break;
+case MXL_RV64:
+id |= KVM_REG_SIZE_U64;
+break;
+default:
+g_assert_not_reached();
+}
+return id;
+}
+
 const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
 KVM_CAP_LAST_INFO
 };
@@ -79,7 +96,20 @@ void kvm_arch_init_irq_routing(KVMState *s)
 
 int kvm_arch_init_vcpu(CPUState *cs)
 {
-return 0;
+int ret = 0;
+target_ulong isa;
+RISCVCPU *cpu = RISCV_CPU(cs);
+CPURISCVState *env = &cpu->env;
+uint64_t id;
+
+id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CONFIG, 
KVM_REG_RISCV_CONFIG_REG(isa));
+ret = kvm_get_one_reg(cs, id, &isa);
+if (ret) {
+return ret;
+}
+env->misa_ext = isa;
+
+return ret;
 }
 
 int kvm_arch_msi_data_to_gsi(uint32_t data)
-- 
2.19.1

[PATCH v3 06/12] target/riscv: Support start kernel directly by KVM

Get kernel and fdt start address in virt.c, and pass them to KVM
when cpu reset. Add kvm_riscv.h to place riscv specific interface.

In addition, PLIC is created without M-mode PLIC contexts when KVM
is enabled.

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Reviewed-by: Alistair Francis 
---
 hw/intc/sifive_plic.c|  8 +++-
 hw/riscv/boot.c  | 16 +++-
 hw/riscv/virt.c  | 87 
 include/hw/riscv/boot.h  |  1 +
 target/riscv/cpu.c   |  8 
 target/riscv/cpu.h   |  3 ++
 target/riscv/kvm-stub.c  | 25 
 target/riscv/kvm.c   | 14 +++
 target/riscv/kvm_riscv.h | 24 +++
 target/riscv/meson.build |  2 +-
 10 files changed, 159 insertions(+), 29 deletions(-)
 create mode 100644 target/riscv/kvm-stub.c
 create mode 100644 target/riscv/kvm_riscv.h

diff --git a/hw/intc/sifive_plic.c b/hw/intc/sifive_plic.c
index 877e76877c..1b2b4cc25e 100644
--- a/hw/intc/sifive_plic.c
+++ b/hw/intc/sifive_plic.c
@@ -30,6 +30,7 @@
 #include "target/riscv/cpu.h"
 #include "migration/vmstate.h"
 #include "hw/irq.h"
+#include "sysemu/kvm.h"
 
 #define RISCV_DEBUG_PLIC 0
 
@@ -555,8 +556,11 @@ DeviceState *sifive_plic_create(hwaddr addr, char 
*hart_config,
 
 qdev_connect_gpio_out(dev, i,
   qdev_get_gpio_in(DEVICE(cpu), IRQ_S_EXT));
-qdev_connect_gpio_out(dev, num_harts + i,
-  qdev_get_gpio_in(DEVICE(cpu), IRQ_M_EXT));
+
+if (!kvm_enabled()) {
+qdev_connect_gpio_out(dev, num_harts + i,
+  qdev_get_gpio_in(DEVICE(cpu), IRQ_M_EXT));
+}
 }
 
 return dev;
diff --git a/hw/riscv/boot.c b/hw/riscv/boot.c
index 519fa455a1..ccff662d89 100644
--- a/hw/riscv/boot.c
+++ b/hw/riscv/boot.c
@@ -30,6 +30,7 @@
 #include "elf.h"
 #include "sysemu/device_tree.h"
 #include "sysemu/qtest.h"
+#include "sysemu/kvm.h"
 
 #include 
 
@@ -51,7 +52,9 @@ char *riscv_plic_hart_config_string(int hart_count)
 CPUState *cs = qemu_get_cpu(i);
 CPURISCVState *env = &RISCV_CPU(cs)->env;
 
-if (riscv_has_ext(env, RVS)) {
+if (kvm_enabled()) {
+vals[i] = "S";
+} else if (riscv_has_ext(env, RVS)) {
 vals[i] = "MS";
 } else {
 vals[i] = "M";
@@ -317,3 +320,14 @@ void riscv_setup_rom_reset_vec(MachineState *machine, 
RISCVHartArrayState *harts
 
 return;
 }
+
+void riscv_setup_direct_kernel(hwaddr kernel_addr, hwaddr fdt_addr)
+{
+CPUState *cs;
+
+for (cs = first_cpu; cs; cs = CPU_NEXT(cs)) {
+RISCVCPU *riscv_cpu = RISCV_CPU(cs);
+riscv_cpu->env.kernel_addr = kernel_addr;
+riscv_cpu->env.fdt_addr = fdt_addr;
+}
+}
diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index 3af074148e..cc1a03f284 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -38,6 +38,7 @@
 #include "chardev/char.h"
 #include "sysemu/device_tree.h"
 #include "sysemu/sysemu.h"
+#include "sysemu/kvm.h"
 #include "hw/pci/pci.h"
 #include "hw/pci-host/gpex.h"
 #include "hw/display/ramfb.h"
@@ -50,7 +51,11 @@ static const MemMapEntry virt_memmap[] = {
 [VIRT_CLINT] =   {  0x200,   0x1 },
 [VIRT_ACLINT_SSWI] = {  0x2F0,0x4000 },
 [VIRT_PCIE_PIO] ={  0x300,   0x1 },
+#if defined(CONFIG_KVM)
+[VIRT_PLIC] ={  0xc00, VIRT_PLIC_SIZE(VIRT_CPUS_MAX * 1) },
+#else
 [VIRT_PLIC] ={  0xc00, VIRT_PLIC_SIZE(VIRT_CPUS_MAX * 2) },
+#endif
 [VIRT_UART0] =   { 0x1000, 0x100 },
 [VIRT_VIRTIO] =  { 0x10001000,0x1000 },
 [VIRT_FW_CFG] =  { 0x1010,  0x18 },
@@ -372,13 +377,22 @@ static void create_fdt_socket_plic(RISCVVirtState *s,
 "sifive,plic-1.0.0", "riscv,plic0"
 };
 
-plic_cells = g_new0(uint32_t, s->soc[socket].num_harts * 4);
+if (kvm_enabled()) {
+plic_cells = g_new0(uint32_t, s->soc[socket].num_harts * 2);
+} else {
+plic_cells = g_new0(uint32_t, s->soc[socket].num_harts * 4);
+}
 
 for (cpu = 0; cpu < s->soc[socket].num_harts; cpu++) {
-plic_cells[cpu * 4 + 0] = cpu_to_be32(intc_phandles[cpu]);
-plic_cells[cpu * 4 + 1] = cpu_to_be32(IRQ_M_EXT);
-plic_cells[cpu * 4 + 2] = cpu_to_be32(intc_phandles[cpu]);
-plic_cells[cpu * 4 + 3] = cpu_to_be32(IRQ_S_EXT);
+if (kvm_enabled()) {
+plic_cells[cpu * 2 + 0] = cpu_to_be32(intc_phandles[cpu]);
+plic_cells[cpu * 2 + 1] = cpu_to_be32(IRQ_S_EXT);
+} else {
+plic_cells[cpu * 4 + 0] = cpu_to_be32(intc_phandles[cpu]);
+plic_cells[cpu * 4 + 1] = cpu_to_be32(IRQ_M_EXT);
+plic_cells[cpu * 4 + 2] = cpu_to_be32(intc_phandles[cpu]);
+plic_cells[cpu * 4 + 3] = cpu_to_be32(IRQ_S_EXT);
+}
 }
 
 plic_phandles[socket] = (*phandle)++;
@@ -436,10 +450,12 @@ static void create_fdt_sockets(RISCVVirtState *s, const

[PATCH 3/4] tests/qtest/cdrom-test: Check whether devices are available before using them

Downstream users might want to disable legacy devices in their binaries,
so we should not blindly assume that they are available. Add some proper
checks before using them.

Signed-off-by: Thomas Huth 
---
 tests/qtest/cdrom-test.c | 60 ++--
 1 file changed, 39 insertions(+), 21 deletions(-)

diff --git a/tests/qtest/cdrom-test.c b/tests/qtest/cdrom-test.c
index c1fcac5c45..cfca24fa94 100644
--- a/tests/qtest/cdrom-test.c
+++ b/tests/qtest/cdrom-test.c
@@ -142,21 +142,36 @@ static void add_x86_tests(void)
 qtest_add_data_func("cdrom/boot/isapc", "-M isapc "
 "-drive if=ide,media=cdrom,file=", test_cdboot);
 }
-qtest_add_data_func("cdrom/boot/am53c974",
-"-device am53c974 -device scsi-cd,drive=cd1 "
-"-drive if=none,id=cd1,format=raw,file=", test_cdboot);
-qtest_add_data_func("cdrom/boot/dc390",
-"-device dc390 -device scsi-cd,drive=cd1 "
-"-blockdev file,node-name=cd1,filename=", test_cdboot);
-qtest_add_data_func("cdrom/boot/lsi53c895a",
-"-device lsi53c895a -device scsi-cd,drive=cd1 "
-"-blockdev file,node-name=cd1,filename=", test_cdboot);
-qtest_add_data_func("cdrom/boot/megasas", "-M q35 "
-"-device megasas -device scsi-cd,drive=cd1 "
-"-blockdev file,node-name=cd1,filename=", test_cdboot);
-qtest_add_data_func("cdrom/boot/megasas-gen2", "-M q35 "
-"-device megasas-gen2 -device scsi-cd,drive=cd1 "
-"-blockdev file,node-name=cd1,filename=", test_cdboot);
+if (qtest_has_device("am53c974")) {
+qtest_add_data_func("cdrom/boot/am53c974",
+"-device am53c974 -device scsi-cd,drive=cd1 "
+"-drive if=none,id=cd1,format=raw,file=",
+test_cdboot);
+}
+if (qtest_has_device("dc390")) {
+qtest_add_data_func("cdrom/boot/dc390",
+"-device dc390 -device scsi-cd,drive=cd1 "
+"-blockdev file,node-name=cd1,filename=",
+test_cdboot);
+}
+if (qtest_has_device("lsi53c895a")) {
+qtest_add_data_func("cdrom/boot/lsi53c895a",
+"-device lsi53c895a -device scsi-cd,drive=cd1 "
+"-blockdev file,node-name=cd1,filename=",
+test_cdboot);
+}
+if (qtest_has_device("megasas")) {
+qtest_add_data_func("cdrom/boot/megasas", "-M q35 "
+"-device megasas -device scsi-cd,drive=cd1 "
+"-blockdev file,node-name=cd1,filename=",
+test_cdboot);
+}
+if (qtest_has_device("megasas-gen2")) {
+qtest_add_data_func("cdrom/boot/megasas-gen2", "-M q35 "
+"-device megasas-gen2 -device scsi-cd,drive=cd1 "
+"-blockdev file,node-name=cd1,filename=",
+test_cdboot);
+}
 }
 
 static void add_s390x_tests(void)
@@ -171,12 +186,15 @@ static void add_s390x_tests(void)
 "-drive driver=null-co,read-zeroes=on,if=none,id=d1 "
 "-device virtio-blk,drive=d2,bootindex=1 "
 "-drive if=none,id=d2,media=cdrom,file=", test_cdboot);
-qtest_add_data_func("cdrom/boot/without-bootindex",
-"-device virtio-scsi -device virtio-serial "
-"-device x-terminal3270 -device virtio-blk,drive=d1 "
-"-drive driver=null-co,read-zeroes=on,if=none,id=d1 "
-"-device virtio-blk,drive=d2 "
-"-drive if=none,id=d2,media=cdrom,file=", test_cdboot);
+if (qtest_has_device("x-terminal3270")) {
+qtest_add_data_func("cdrom/boot/without-bootindex",
+"-device virtio-scsi -device virtio-serial "
+"-device x-terminal3270 -device 
virtio-blk,drive=d1 "
+"-drive 
driver=null-co,read-zeroes=on,if=none,id=d1 "
+"-device virtio-blk,drive=d2 "
+"-drive if=none,id=d2,media=cdrom,file=",
+test_cdboot);
+}
 }
 
 int main(int argc, char **argv)
-- 
2.27.0

Warnings during the virtio-net-failover test




 Hi Laurent,

today I noticed that there are quite a bunch of warnings during the 
virtio-net-failover test:


$ QTEST_QEMU_BINARY=./qemu-system-x86_64 tests/qtest/virtio-net-failover
/x86_64/failover-virtio-net/hotplug_1: qemu-system-x86_64: warning: Primary 
device not found
Virtio-net failover will not work. Make sure primary device has parameter 
failover_pair_id=standby0

OK
/x86_64/failover-virtio-net/hotplug_1_reverse: OK
/x86_64/failover-virtio-net/hotplug_2: qemu-system-x86_64: warning: Primary 
device not found
Virtio-net failover will not work. Make sure primary device has parameter 
failover_pair_id=standby0

OK
[...]
/x86_64/failover-virtio-net/migrate/out: qemu-system-x86_64: warning: 
Primary device not found
Virtio-net failover will not work. Make sure primary device has parameter 
failover_pair_id=standby0

OK
/x86_64/failover-virtio-net/migrate/in: OK
/x86_64/failover-virtio-net/migrate/abort/wait-unplug: qemu-system-x86_64: 
warning: Primary device not found
Virtio-net failover will not work. Make sure primary device has parameter 
failover_pair_id=standby0

OK
/x86_64/failover-virtio-net/migrate/abort/active: qemu-system-x86_64: 
warning: Primary device not found
Virtio-net failover will not work. Make sure primary device has parameter 
failover_pair_id=standby0

OK
/x86_64/failover-virtio-net/multi/out: OK
/x86_64/failover-virtio-net/multi/in: OK

I assume they are false positives? If so, could you please come up with a 
patch to silence them, since they are quite confusing...?


 Thanks,
  Thomas

Re: [PATCH] failover: Silence warning messages during qtest

On 12/20/21 15:53, Laurent Vivier wrote:
> virtio-net-failover test tries several device combinations that produces
> some expected warnings.
> These warning can be confusing, so we disable them during the qtest

Typo "warnings".

> sequence.
> 
> Reported-by: Thomas Huth 
> Signed-off-by: Laurent Vivier 
> ---
>  hw/net/virtio-net.c   | 3 ++-
>  migration/migration.c | 4 +++-
>  2 files changed, 5 insertions(+), 2 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé

[PATCH v3 04/12] target/riscv: Implement kvm_arch_get_registers

Get GPR CSR and FP registers from kvm by KVM_GET_ONE_REG ioctl.

Signed-off-by: Yifei Jiang 
Signed-off-by: Mingwang Li 
Reviewed-by: Alistair Francis 
Reviewed-by: Anup Patel 
---
 target/riscv/kvm.c | 112 -
 1 file changed, 111 insertions(+), 1 deletion(-)

diff --git a/target/riscv/kvm.c b/target/riscv/kvm.c
index ccf3753048..6d4df0ef6d 100644
--- a/target/riscv/kvm.c
+++ b/target/riscv/kvm.c
@@ -55,13 +55,123 @@ static uint64_t kvm_riscv_reg_id(CPURISCVState *env, 
uint64_t type, uint64_t idx
 return id;
 }
 
+#define RISCV_CORE_REG(env, name)  kvm_riscv_reg_id(env, KVM_REG_RISCV_CORE, \
+ KVM_REG_RISCV_CORE_REG(name))
+
+#define RISCV_CSR_REG(env, name)  kvm_riscv_reg_id(env, KVM_REG_RISCV_CSR, \
+ KVM_REG_RISCV_CSR_REG(name))
+
+#define RISCV_FP_F_REG(env, idx)  kvm_riscv_reg_id(env, KVM_REG_RISCV_FP_F, 
idx)
+
+#define RISCV_FP_D_REG(env, idx)  kvm_riscv_reg_id(env, KVM_REG_RISCV_FP_D, 
idx)
+
+#define KVM_RISCV_GET_CSR(cs, env, csr, reg) \
+do { \
+int ret = kvm_get_one_reg(cs, RISCV_CSR_REG(env, csr), ®); \
+if (ret) { \
+return ret; \
+} \
+} while(0)
+
+static int kvm_riscv_get_regs_core(CPUState *cs)
+{
+int ret = 0;
+int i;
+target_ulong reg;
+CPURISCVState *env = &RISCV_CPU(cs)->env;
+
+ret = kvm_get_one_reg(cs, RISCV_CORE_REG(env, regs.pc), ®);
+if (ret) {
+return ret;
+}
+env->pc = reg;
+
+for (i = 1; i < 32; i++) {
+uint64_t id = kvm_riscv_reg_id(env, KVM_REG_RISCV_CORE, i);
+ret = kvm_get_one_reg(cs, id, ®);
+if (ret) {
+return ret;
+}
+env->gpr[i] = reg;
+}
+
+return ret;
+}
+
+static int kvm_riscv_get_regs_csr(CPUState *cs)
+{
+int ret = 0;
+CPURISCVState *env = &RISCV_CPU(cs)->env;
+
+KVM_RISCV_GET_CSR(cs, env, sstatus, env->mstatus);
+KVM_RISCV_GET_CSR(cs, env, sie, env->mie);
+KVM_RISCV_GET_CSR(cs, env, stvec, env->stvec);
+KVM_RISCV_GET_CSR(cs, env, sscratch, env->sscratch);
+KVM_RISCV_GET_CSR(cs, env, sepc, env->sepc);
+KVM_RISCV_GET_CSR(cs, env, scause, env->scause);
+KVM_RISCV_GET_CSR(cs, env, stval, env->stval);
+KVM_RISCV_GET_CSR(cs, env, sip, env->mip);
+KVM_RISCV_GET_CSR(cs, env, satp, env->satp);
+return ret;
+}
+
+static int kvm_riscv_get_regs_fp(CPUState *cs)
+{
+int ret = 0;
+int i;
+CPURISCVState *env = &RISCV_CPU(cs)->env;
+
+if (riscv_has_ext(env, RVD)) {
+uint64_t reg;
+for (i = 0; i < 32; i++) {
+ret = kvm_get_one_reg(cs, RISCV_FP_D_REG(env, i), ®);
+if (ret) {
+return ret;
+}
+env->fpr[i] = reg;
+}
+return ret;
+}
+
+if (riscv_has_ext(env, RVF)) {
+uint32_t reg;
+for (i = 0; i < 32; i++) {
+ret = kvm_get_one_reg(cs, RISCV_FP_F_REG(env, i), ®);
+if (ret) {
+return ret;
+}
+env->fpr[i] = reg;
+}
+return ret;
+}
+
+return ret;
+}
+
 const KVMCapabilityInfo kvm_arch_required_capabilities[] = {
 KVM_CAP_LAST_INFO
 };
 
 int kvm_arch_get_registers(CPUState *cs)
 {
-return 0;
+int ret = 0;
+
+ret = kvm_riscv_get_regs_core(cs);
+if (ret) {
+return ret;
+}
+
+ret = kvm_riscv_get_regs_csr(cs);
+if (ret) {
+return ret;
+}
+
+ret = kvm_riscv_get_regs_fp(cs);
+if (ret) {
+return ret;
+}
+
+return ret;
 }
 
 int kvm_arch_put_registers(CPUState *cs, int level)
-- 
2.19.1

[PATCH 0/4] tests/qtest: Check for devices and machines before adding tests

Devices might not always be compiled into the QEMU target binaries.
We already have the libqos framework that is good for handling such
situations, but some of the qtests are not a real good fit for the
libqos framework. This patch series adds a new function to check
whether a device is available in the target binary or not, so that
tests can be run or skipped accordingly (also adding some additional
checks for the availability of machines in the target binaries).

Thomas Huth (4):
  tests/qtest: Add a function that checks whether a device is available
  tests/qtest: Improve endianness-test to work with missing machines and
devices
  tests/qtest/cdrom-test: Check whether devices are available before
using them
  tests/qtest/boot-order-test: Check whether machines are available

 tests/qtest/boot-order-test.c |  5 +++
 tests/qtest/cdrom-test.c  | 60 +++
 tests/qtest/endianness-test.c |  5 ++-
 tests/qtest/libqos/libqtest.h |  8 +
 tests/qtest/libqtest.c| 44 +
 5 files changed, 100 insertions(+), 22 deletions(-)

-- 
2.27.0

[RFC v2 0/2] migration: Tally pre-copy, downtime and post-copy bytes independently

When examining a report of poor migration behaviour, it would often be
useful to understand how much data was transferred in different phases
of the migration process.

For example, if the downtime limit is exceeded, to know how much data
was transferred during the downtime.

RFC because the name "ram_transferred_add" doesn't seem great, and I'm
unsure whether the tests to determine the phase in the second patch
are the most appropriate.

v2:
- ram_transferred_add() should be static (Philippe)
- Document the new MigrationStats fields (dme)

David Edmondson (2):
  migration: Introduce ram_transferred_add()
  migration: Tally pre-copy, downtime and post-copy bytes independently

 migration/migration.c |  3 +++
 migration/ram.c   | 30 +-
 monitor/hmp-cmds.c| 12 
 qapi/migration.json   | 13 -
 4 files changed, 48 insertions(+), 10 deletions(-)

-- 
2.33.0

Re: Virtio-GPU Xres and Yres seettings

2021-12-20 Thread Gerd Hoffmann

  Hi,

> Is it possible that EDID bytes are sent wrong to the driver (as a response
> to VIRTIO_GPU_CMD_GET_EDID command)?? - I am configuring these bytes the
> same way Qemu does.

EDID is optional, so you can try disable the EDID feature bit and see
what happens.

You can also check /sys/class/drm/card0-${output}/edid inside the
guest.

take care,
  Gerd

Re: [RFC] vhost-vdpa-net: add vhost-vdpa-net host device support

On Mon, Dec 20, 2021 at 10:48:09AM +0800, Jason Wang wrote:
> On Fri, Dec 17, 2021 at 4:35 PM Stefan Hajnoczi  wrote:
> >
> > On Fri, Dec 17, 2021 at 12:26:53PM +0800, Jason Wang wrote:
> >
> > Dave: You created the VIRTIO vmstate infrastructure in QEMU. Please see
> > the bottom of this email about moving to a standard VIRTIO device
> > save/load format defined by the VIRTIO spec in the future.
> >
> > > On Thu, Dec 16, 2021 at 5:10 PM Stefan Hajnoczi  
> > > wrote:
> > > >
> > > > On Thu, Dec 16, 2021 at 11:01:40AM +0800, Jason Wang wrote:
> > > > > On Wed, Dec 15, 2021 at 6:07 PM Stefan Hajnoczi  
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Dec 15, 2021 at 11:18:05AM +0800, Jason Wang wrote:
> > > > > > > On Tue, Dec 14, 2021 at 9:11 PM Stefan Hajnoczi 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Tue, Dec 14, 2021 at 10:22:53AM +0800, Jason Wang wrote:
> > > > > > > > > On Mon, Dec 13, 2021 at 11:14 PM Stefan Hajnoczi 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > On Mon, Dec 13, 2021 at 10:47:00AM +0800, Jason Wang wrote:
> > > > > > > > > > > On Sun, Dec 12, 2021 at 5:30 PM Michael S. Tsirkin 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Sat, Dec 11, 2021 at 03:00:27AM +, Longpeng 
> > > > > > > > > > > > (Mike, Cloud Infrastructure Service Product Dept.) 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > -Original Message-
> > > > > > > > > > > > > > From: Stefan Hajnoczi [mailto:stefa...@redhat.com]
> > > > > > > > > > > > > > Sent: Thursday, December 9, 2021 5:17 PM
> > > > > > > > > > > > > > To: Longpeng (Mike, Cloud Infrastructure Service 
> > > > > > > > > > > > > > Product Dept.)
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Cc: jasow...@redhat.com; m...@redhat.com; 
> > > > > > > > > > > > > > pa...@nvidia.com;
> > > > > > > > > > > > > > xieyon...@bytedance.com; sgarz...@redhat.com; 
> > > > > > > > > > > > > > Yechuan ;
> > > > > > > > > > > > > > Gonglei (Arei) ; 
> > > > > > > > > > > > > > qemu-devel@nongnu.org
> > > > > > > > > > > > > > Subject: Re: [RFC] vhost-vdpa-net: add 
> > > > > > > > > > > > > > vhost-vdpa-net host device support
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Dec 08, 2021 at 01:20:10PM +0800, 
> > > > > > > > > > > > > > Longpeng(Mike) wrote:
> > > > > > > > > > > > > > > From: Longpeng 
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi guys,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > This patch introduces vhost-vdpa-net device, 
> > > > > > > > > > > > > > > which is inspired
> > > > > > > > > > > > > > > by vhost-user-blk and the proposal of 
> > > > > > > > > > > > > > > vhost-vdpa-blk device [1].
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I've tested this patch on Huawei's offload card:
> > > > > > > > > > > > > > > ./x86_64-softmmu/qemu-system-x86_64 \
> > > > > > > > > > > > > > > -device 
> > > > > > > > > > > > > > > vhost-vdpa-net-pci,vdpa-dev=/dev/vhost-vdpa-0
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > For virtio hardware offloading, the most 
> > > > > > > > > > > > > > > important requirement for us
> > > > > > > > > > > > > > > is to support live migration between offloading 
> > > > > > > > > > > > > > > cards from different
> > > > > > > > > > > > > > > vendors, the combination of netdev and virtio-net 
> > > > > > > > > > > > > > > seems too heavy, we
> > > > > > > > > > > > > > > prefer a lightweight way.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Maybe we could support both in the future ? Such 
> > > > > > > > > > > > > > > as:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > * Lightweight
> > > > > > > > > > > > > > >  Net: vhost-vdpa-net
> > > > > > > > > > > > > > >  Storage: vhost-vdpa-blk
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > * Heavy but more powerful
> > > > > > > > > > > > > > >  Net: netdev + virtio-net + vhost-vdpa
> > > > > > > > > > > > > > >  Storage: bdrv + virtio-blk + vhost-vdpa
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > [1] 
> > > > > > > > > > > > > > > https://www.mail-archive.com/qemu-devel@nongnu.org/msg797569.html
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Stefano presented a plan for vdpa-blk at KVM Forum 
> > > > > > > > > > > > > > 2021:
> > > > > > > > > > > > > > https://kvmforum2021.sched.com/event/ke3a/vdpa-blk-unified-hardware-and-sof
> > > > > > > > > > > > > > tware-offload-for-virtio-blk-stefano-garzarella-red-hat
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > It's closer to today's virtio-net + vhost-net 
> > > > > > > > > > > > > > approach than the
> > > > > > > > > > > > > > vhost-vdpa-blk device you have mentioned. The idea 
> > > > > > > > > > > > > > is to treat vDPA as
> > > > > > > > > > > > > > an offload feature rather than a completely 
> > > > > > > > > > > > > > separate

Re: [PATCH v4 11/14] vfio-user: IOMMU support for remote device

On Fri, Dec 17, 2021 at 08:00:35PM +, Jag Raman wrote:
> > On Dec 16, 2021, at 9:40 AM, Stefan Hajnoczi  wrote:
> > 
> > On Wed, Dec 15, 2021 at 10:35:35AM -0500, Jagannathan Raman wrote:
> >> Assign separate address space for each device in the remote processes.
> > 
> > If I understand correctly this isn't really an IOMMU. It's abusing the
> > IOMMU APIs to create isolated address spaces for each device. This way
> > memory regions added by the vfio-user client do not conflict when there
> > are multiple vfio-user servers.
> 
> Like you already figured out, having isolated DMA address space alone is not
> sufficient for this application, we also needed to isolate the sysmem/RAM 
> address
> space. As such, the available IOMMU APIs alone were not sufficient, so we had
> to improvise.
> 
> > 
> > Calling pci_root_bus_new() and keeping one PCI bus per VfuObject might
> > be a cleaner approach:
> > - Lets you isolate both PCI Memory Space and IO Space.
> > - Isolates the PCIDevices and their addresses on the bus.
> > - Isolates irqs.
> > - No more need to abuse the IOMMU API.
> 
> I believe we would still need to have an IOMMU. It’s because, devices use the
> pci_dma_read()/_write() functions. These functions look up the address in DMA
> address space (via pci_get_address_space() -> PCIDevice->bus_master_as ->
> PCIDevice->bus_master_enable_region -> 
> PCIDevice->bus_master_container_region).
>  bus_master_enable_region and bus_master_container_region are effectively 
> aliases
> to the DMA address space - without an IOMMU, the dma_as would be the shared
> global sysmem/RAM space (address_space_mem, please see pci_init_bus_master())

Good point, that code assumes there is a global address space. Creating
a fake IOMMU works around that assumption but it seems cleaner to
eliminate it:

  AddressSpace *pci_device_iommu_address_space(PCIDevice *dev)
  {
  ...
  if (!pci_bus_bypass_iommu(bus) && iommu_bus && iommu_bus->iommu_fn) {
  return iommu_bus->iommu_fn(bus, iommu_bus->iommu_opaque, devfn);
  }
  return &address_space_memory;

When creating a PCI root bus an AddressSpace argument could be provided,
just like it already does for the address_space_memory and
address_space_io MemoryRegions. Then the hardcoded return can be
changed to something like:

  return bus->dma_address_space;

> >> @@ -332,6 +336,12 @@ static void vfu_object_register_bars(vfu_ctx_t 
> >> *vfu_ctx, PCIDevice *pdev)
> >>  vfu_object_bar_handlers[i],
> >>  VFU_REGION_FLAG_RW, NULL, 0, -1, 0);
> >> 
> >> +if ((o->pci_dev->io_regions[i].type & PCI_BASE_ADDRESS_SPACE) == 
> >> 0) {
> >> +memory_region_unref(o->pci_dev->io_regions[i].address_space);
> >> +o->pci_dev->io_regions[i].address_space =
> >> +remote_iommu_get_ram(o->pci_dev);
> >> +}
> > 
> > This looks hacky. If you create a separate PCIHost for each device
> > instead then the BARs will be created in the MemoryRegion (confusingly
> > named "address_space" in the PCI code) of your choosing.
> 
> I was also not very comfortable with this - added it very grudgingly out of
> necessity. Thank god this can go away with separate bus for each device.

I talked to Kevin Wolf about having separate busses. qdev currently
requires each DeviceState to have a parent bus and each bus must have a
parent DeviceState. There is only one exception: a special check that
allows the global system bus (sysbus_get_default()) to be created
without a parent DeviceState.

This restriction probably needs to be loosened in order to support an
isolated PCIHost for each vfio-user server. The challenge is that
qdev_find_recursive() and monitor commands like device_add currently
only search the global system bus. Maybe new syntax is needed for the
multiple root bus case or the behavior of existing monitor commands
needs to be understood and extended without breaking anything.

> > 
> > Also, why is PCI Memory Space isolated via VFUIOMMU but PCI IO Space is
> > not?
> 
> If I understand correctly, the IO address space translates sysmem address to
> direct device access (such as I2C). Once we are inside a device, we already
> have access to all parts of the device (unlike RAM which sits outside the 
> device).
> So didn’t think device would go via IOMMU to access IO. Also didn’t see any
> other IOMMU translating IO address space accesses.

I reviewed how BARs are configured with VFIO:

1. When the guest writes to the vfio-pci PCIDevice's Configuration Space
   the write is forwarded to the VFIO device (i.e. vfio-user or VFIO
   kernel ioctl).

2. The vfio-user server receives the Configuration Space write and
   forwards it to pci_dev (the PCIDevice we're serving up). BAR mappings
   are updated in the vfio-user server so the BAR MemoryRegions are
   mapped/unmapped at the locations given by the guest.

This applies for both Memory and IO Space accesse

Re: [PATCH] hw: m68k: Add virt compat machine type for 7.0

2021-12-20 Thread Cornelia Huck

On Sat, Dec 18 2021, Laurent Vivier  wrote:

> Signed-off-by: Laurent Vivier 
> ---
> Based-On: <20211217143948.289995-1-coh...@redhat.com>
>
>  hw/m68k/virt.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)

Oh, I didn't realize we do it for m68k as well.

Reviewed-by: Cornelia Huck

Re: [PATCH] hw/nvram: at24 return 0xff if 1 byte address