Re: [RFC 15/52] migration/postcopy-ram: Use generic topology name and helper

[Zhao Liu]

On Mon, Feb 13, 2023 at 11:07:33AM +0100, Juan Quintela wrote:
> Date: Mon, 13 Feb 2023 11:07:33 +0100
> From: Juan Quintela 
> Subject: Re: [RFC 15/52] migration/postcopy-ram: Use generic topology name
>  and helper
> 
> Zhao Liu  wrote:
> > From: Zhao Liu 
> >
> > As the generic code, here we should respect the different topologies:
> > smp or hybrid.
> >
> > So rename PostcopyBlocktimeContext.smp_cpus_down to
> > PostcopyBlocktimeContext.cpus_down, and also rename other local
> > variables from smp_cpus to cpus_num, to decouple with smp topology.
> >
> > And use generic topology helpers to get topology information.
> >
> > Cc: Juan Quintela 
> > Cc: Dr. David Alan Gilbert 
> > Signed-off-by: Zhao Liu 
> 
> Reviewed-by: Juan Quintela 
> 
> but if you ever have to rebase.
> 
> > ---
> >  migration/postcopy-ram.c | 24 
> >  1 file changed, 12 insertions(+), 12 deletions(-)
> >
> > diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
> > index 53299b7a5ebd..1e861e313258 100644
> > --- a/migration/postcopy-ram.c
> > +++ b/migration/postcopy-ram.c
> > @@ -122,7 +122,7 @@ typedef struct PostcopyBlocktimeContext {
> >  /* point in time when last page fault was initiated */
> >  uint32_t last_begin;
> >  /* number of vCPU are suspended */
> > -int smp_cpus_down;
> > +int cpus_down;
> 
> Put the rename of the variable in a single patch.  Trivial to review.
> 
> > +unsigned int cpus_num = machine_topo_get_cpus(ms);
> 
> Put the meat in another patch.  I think you call this function in two
> places instead of the old one.
> 

Thanks Juan! On the next send, I'll do the split.

> 
> Later, Juan.
> 

[PULL 00/10] Net patches

[Jason Wang]

The following changes since commit f670b3eec7f5d1ed8c4573ef244e7b8c6b32001b:

  Merge tag 'migration-20230213-pull-request' of 
https://gitlab.com/juan.quintela/qemu into staging (2023-02-13 11:54:05 +)

are available in the git repository at:

  https://github.com/jasowang/qemu.git tags/net-pull-request

for you to fetch changes up to e4b953a26da11d214f91516cb9b0542eab5afaa0:

  vdpa: fix VHOST_BACKEND_F_IOTLB_ASID flag check (2023-02-14 14:00:30 +0800)




Christian Svensson (1):
  net: Increase L2TPv3 buffer to fit jumboframes

Eugenio Pérez (1):
  vdpa: fix VHOST_BACKEND_F_IOTLB_ASID flag check

Fiona Ebner (1):
  hw/net/vmxnet3: allow VMXNET3_MAX_MTU itself as a value

Joelle van Dyne (1):
  vmnet: stop recieving events when VM is stopped

Laurent Vivier (1):
  net: stream: add a new option to automatically reconnect

Qiang Liu (2):
  hw/net/lan9118: log [read|write]b when mode_16bit is enabled rather than 
abort
  hw/net/can/xlnx-zynqmp-can: fix assertion failures in transfer_fifo()

Thomas Huth (3):
  net: Move the code to collect available NIC models to a separate function
  net: Restore printing of the help text with "-nic help"
  net: Replace "Supported NIC models" with "Available NIC models"

 hw/net/can/xlnx-zynqmp-can.c |   9 +++-
 hw/net/lan9118.c |  17 
 hw/net/vmxnet3.c |   2 +-
 hw/pci/pci.c |  29 +
 include/net/net.h|  14 ++
 net/l2tpv3.c |   2 +-
 net/net.c|  50 +++--
 net/stream.c |  53 ++-
 net/vhost-vdpa.c |   2 +-
 net/vmnet-common.m   |  48 ++--
 net/vmnet_int.h  |   2 +
 qapi/net.json|   7 ++-
 qemu-options.hx  |   6 +--
 tests/qtest/netdev-socket.c  | 101 +++
 14 files changed, 280 insertions(+), 62 deletions(-)

Re: [PATCH] chardev/char-socket: set s->listener = NULL in char_socket_finalize

[Marc-André Lureau]

Hi

On Tue, Feb 14, 2023 at 6:15 AM Yajun Wu  wrote:

> After live migration with virtio block device, qemu crash at:
>
> #0  0x55914f46f795 in object_dynamic_cast_assert
> (obj=0x559151b7b090, typename=0x55914f80fbc4 "qio-channel",
> file=0x55914f80fb90 "/images/testvfe/sw/qemu.gerrit/include/io/channel.h",
> line=30, func=0x55914f80fcb8 <__func__.17257> "QIO_CHANNEL") at
> ../qom/object.c:872
> #1  0x55914f480d68 in QIO_CHANNEL (obj=0x559151b7b090) at
> /images/testvfe/sw/qemu.gerrit/include/io/channel.h:29
> #2  0x55914f4812f8 in qio_net_listener_set_client_func_full
> (listener=0x559151b7a720, func=0x55914f580b97 ,
> data=0x5591519f4ea0, notify=0x0, context=0x0) at ../io/net-listener.c:166
> #3  0x55914f580059 in tcp_chr_update_read_handler
> (chr=0x5591519f4ea0) at ../chardev/char-socket.c:637
> #4  0x55914f583dca in qemu_chr_be_update_read_handlers
> (s=0x5591519f4ea0, context=0x0) at ../chardev/char.c:226
> #5  0x55914f57b7c9 in qemu_chr_fe_set_handlers_full
> (b=0x559152bf23a0, fd_can_read=0x0, fd_read=0x0, fd_event=0x0,
> be_change=0x0, opaque=0x0, context=0x0, set_open=false, sync_state=true) at
> ../chardev/char-fe.c:279
> #6  0x55914f57b86d in qemu_chr_fe_set_handlers
> (b=0x559152bf23a0, fd_can_read=0x0, fd_read=0x0, fd_event=0x0,
> be_change=0x0, opaque=0x0, context=0x0, set_open=false) at
> ../chardev/char-fe.c:304
> #7  0x55914f378caf in vhost_user_async_close
> (d=0x559152bf21a0, chardev=0x559152bf23a0, vhost=0x559152bf2420,
> cb=0x55914f2fb8c1 ) at
> ../hw/virtio/vhost-user.c:2725
> #8  0x55914f2fba40 in vhost_user_blk_event
> (opaque=0x559152bf21a0, event=CHR_EVENT_CLOSED) at
> ../hw/block/vhost-user-blk.c:395
> #9  0x55914f58388c in chr_be_event (s=0x5591519f4ea0,
> event=CHR_EVENT_CLOSED) at ../chardev/char.c:61
> #10 0x55914f583905 in qemu_chr_be_event (s=0x5591519f4ea0,
> event=CHR_EVENT_CLOSED) at ../chardev/char.c:81
> #11 0x55914f581275 in char_socket_finalize
> (obj=0x5591519f4ea0) at ../chardev/char-socket.c:1083
> #12 0x55914f46f073 in object_deinit (obj=0x5591519f4ea0,
> type=0x5591519055c0) at ../qom/object.c:680
> #13 0x55914f46f0e5 in object_finalize (data=0x5591519f4ea0) at
> ../qom/object.c:694
> #14 0x55914f46ff06 in object_unref (objptr=0x5591519f4ea0) at
> ../qom/object.c:1202
> #15 0x55914f4715a4 in object_finalize_child_property
> (obj=0x559151b76c50, name=0x559151b7b250 "char3", opaque=0x5591519f4ea0) at
> ../qom/object.c:1747
> #16 0x55914f46ee86 in object_property_del_all
> (obj=0x559151b76c50) at ../qom/object.c:632
> #17 0x55914f46f0d2 in object_finalize (data=0x559151b76c50) at
> ../qom/object.c:693
> #18 0x55914f46ff06 in object_unref (objptr=0x559151b76c50) at
> ../qom/object.c:1202
> #19 0x55914f4715a4 in object_finalize_child_property
> (obj=0x559151b6b560, name=0x559151b76630 "chardevs", opaque=0x559151b76c50)
> at ../qom/object.c:1747
> #20 0x55914f46ef67 in object_property_del_child
> (obj=0x559151b6b560, child=0x559151b76c50) at ../qom/object.c:654
> #21 0x55914f46f042 in object_unparent (obj=0x559151b76c50) at
> ../qom/object.c:673
> #22 0x55914f58632a in qemu_chr_cleanup () at
> ../chardev/char.c:1189
> #23 0x55914f16c66c in qemu_cleanup () at
> ../softmmu/runstate.c:830
> #24 0x55914eee7b9e in qemu_default_main () at
> ../softmmu/main.c:38
> #25 0x55914eee7bcc in main (argc=86, argv=0x7ffc97cb8d88) at
> ../softmmu/main.c:48
>
> In char_socket_finalize after s->listener freed, event callback function
> vhost_user_blk_event will be called to handle CHR_EVENT_CLOSED.
> vhost_user_blk_event is calling qio_net_listener_set_client_func_full which
> is still using s->listener.
>
> Setting s->listener = NULL after object_unref(OBJECT(s->listener)) can
> solve this issue.
>
> Signed-off-by: Yajun Wu 
> Acked-by: Jiri Pirko 
>

Reviewed-by: Marc-André Lureau 



>
> ---
>  chardev/char-socket.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/chardev/char-socket.c b/chardev/char-socket.c
> index c2265436ac..8c58532171 100644
> --- a/chardev/char-socket.c
> +++ b/chardev/char-socket.c
> @@ -1065,6 +1065,7 @@ static void char_socket_finalize(Object *obj)
>  qio_net_listener_set_client_func_full(s->listener, NULL, NULL,
>NULL, chr->gcontext);
>  object_unref(OBJECT(s->listener));
> +s->listener = NULL;
>  }
>  if (s->tls_creds) {
>  object_unref(OBJECT(s->tls_creds));
> --
> 2.27.0
>
>

Re: [PATCH v3 04/12] tests/qtest: Don't build virtio-serial-test.c if device not present

[Thomas Huth]

On 13/02/2023 22.07, Fabiano Rosas wrote:

The virtconsole device might not be present in the QEMU build that is
being tested.

Signed-off-by: Fabiano Rosas 
---
  tests/qtest/meson.build | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index 5c8b031ce0..84cd07bbb9 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -255,10 +255,14 @@ qos_test_ss.add(
'virtio-net-test.c',
'virtio-rng-test.c',
'virtio-scsi-test.c',
-  'virtio-serial-test.c',
'virtio-iommu-test.c',
'vmxnet3-test.c',
  )
+
+if config_all_devices.has_key('CONFIG_VIRTIO_SERIAL')
+  qos_test_ss.add(files('virtio-serial-test.c'))
+endif
+
  if config_host.has_key('CONFIG_POSIX')
qos_test_ss.add(files('e1000e-test.c'))
  endif


Reviewed-by: Thomas Huth 

Re: [PATCH 04/18] target/riscv: gdbstub: Do not generate CSR XML if Zicsr is disabled

[weiwei]

On 2023/2/14 02:02, Bin Meng wrote:

There is no need to generate the CSR XML if the Zicsr extension
is not enabled.

Signed-off-by: Bin Meng 

Reviewed-by: Weiwei Li 

Regards,
Weiwei Li

---

  target/riscv/gdbstub.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/target/riscv/gdbstub.c b/target/riscv/gdbstub.c
index 704f3d6922..294f0ceb1c 100644
--- a/target/riscv/gdbstub.c
+++ b/target/riscv/gdbstub.c
@@ -406,7 +406,10 @@ void riscv_cpu_register_gdb_regs_for_features(CPUState *cs)
  g_assert_not_reached();
  }
  
-gdb_register_coprocessor(cs, riscv_gdb_get_csr, riscv_gdb_set_csr,

- riscv_gen_dynamic_csr_xml(cs, cs->gdb_num_regs),
- "riscv-csr.xml", 0);
+if (cpu->cfg.ext_icsr) {
+int base_reg = cs->gdb_num_regs;
+gdb_register_coprocessor(cs, riscv_gdb_get_csr, riscv_gdb_set_csr,
+ riscv_gen_dynamic_csr_xml(cs, base_reg),
+ "riscv-csr.xml", 0);
+}
  }

[Patch 09/14] target/riscv: Replace check for F/D to Zve32f/Zve64d in trans_rvv.c.inc

[Weiwei Li]

Check for Zve32f/Zve64d can overlap check for F/D

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/insn_trans/trans_rvv.c.inc | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/target/riscv/insn_trans/trans_rvv.c.inc 
b/target/riscv/insn_trans/trans_rvv.c.inc
index 6f7ecf1a68..9b2711b94b 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -41,9 +41,9 @@ static bool require_rvf(DisasContext *s)
 switch (s->sew) {
 case MO_16:
 case MO_32:
-return has_ext(s, RVF);
+return s->cfg_ptr->ext_zve32f;
 case MO_64:
-return has_ext(s, RVD);
+return s->cfg_ptr->ext_zve64d;
 default:
 return false;
 }
@@ -58,9 +58,9 @@ static bool require_scale_rvf(DisasContext *s)
 switch (s->sew) {
 case MO_8:
 case MO_16:
-return has_ext(s, RVF);
+return s->cfg_ptr->ext_zve32f;
 case MO_32:
-return has_ext(s, RVD);
+return s->cfg_ptr->ext_zve64d;
 default:
 return false;
 }
-- 
2.25.1

[Patch 13/14] target/riscv: Simplify check for EEW = 64 in trans_rvv.c.inc

[Weiwei Li]

Only V extension support EEW = 64 in these case: Zve64* extensions
don't support EEW = 64 as commented

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/insn_trans/trans_rvv.c.inc | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/target/riscv/insn_trans/trans_rvv.c.inc 
b/target/riscv/insn_trans/trans_rvv.c.inc
index 5dbdce073b..fc0d0d60e8 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -1998,8 +1998,7 @@ static bool vmulh_vv_check(DisasContext *s, arg_rmrr *a)
  * are not included for EEW=64 in Zve64*. (Section 18.2)
  */
 return opivv_check(s, a) &&
-   (!has_ext(s, RVV) &&
-s->cfg_ptr->ext_zve64f ? s->sew != MO_64 : true);
+   (!has_ext(s, RVV) ? s->sew != MO_64 : true);
 }
 
 static bool vmulh_vx_check(DisasContext *s, arg_rmrr *a)
@@ -2012,8 +2011,7 @@ static bool vmulh_vx_check(DisasContext *s, arg_rmrr *a)
  * are not included for EEW=64 in Zve64*. (Section 18.2)
  */
 return opivx_check(s, a) &&
-   (!has_ext(s, RVV) &&
-s->cfg_ptr->ext_zve64f ? s->sew != MO_64 : true);
+   (!has_ext(s, RVV) ? s->sew != MO_64 : true);
 }
 
 GEN_OPIVV_GVEC_TRANS(vmul_vv,  mul)
@@ -2230,8 +2228,7 @@ static bool vsmul_vv_check(DisasContext *s, arg_rmrr *a)
  * for EEW=64 in Zve64*. (Section 18.2)
  */
 return opivv_check(s, a) &&
-   (!has_ext(s, RVV) &&
-s->cfg_ptr->ext_zve64f ? s->sew != MO_64 : true);
+   (!has_ext(s, RVV) ? s->sew != MO_64 : true);
 }
 
 static bool vsmul_vx_check(DisasContext *s, arg_rmrr *a)
@@ -2242,8 +2239,7 @@ static bool vsmul_vx_check(DisasContext *s, arg_rmrr *a)
  * for EEW=64 in Zve64*. (Section 18.2)
  */
 return opivx_check(s, a) &&
-   (!has_ext(s, RVV) &&
-s->cfg_ptr->ext_zve64f ? s->sew != MO_64 : true);
+   (!has_ext(s, RVV) ? s->sew != MO_64 : true);
 }
 
 GEN_OPIVV_TRANS(vsmul_vv, vsmul_vv_check)
-- 
2.25.1

[Patch 14/14] target/riscv: Expose properties for Zv* extension

[Weiwei Li]

Expose Zve64d,Zvfh,Zvfhmin properties

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/cpu.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 73711d392d..2c71e22ea9 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -101,6 +101,9 @@ static const struct isa_ext_data isa_edata_arr[] = {
 ISA_EXT_DATA_ENTRY(zkt, true, PRIV_VERSION_1_12_0, ext_zkt),
 ISA_EXT_DATA_ENTRY(zve32f, true, PRIV_VERSION_1_12_0, ext_zve32f),
 ISA_EXT_DATA_ENTRY(zve64f, true, PRIV_VERSION_1_12_0, ext_zve64f),
+ISA_EXT_DATA_ENTRY(zve64d, true, PRIV_VERSION_1_12_0, ext_zve64d),
+ISA_EXT_DATA_ENTRY(zvfh, true, PRIV_VERSION_1_12_0, ext_zvfh),
+ISA_EXT_DATA_ENTRY(zvfhmin, true, PRIV_VERSION_1_12_0, ext_zvfhmin),
 ISA_EXT_DATA_ENTRY(zhinx, true, PRIV_VERSION_1_12_0, ext_zhinx),
 ISA_EXT_DATA_ENTRY(zhinxmin, true, PRIV_VERSION_1_12_0, ext_zhinxmin),
 ISA_EXT_DATA_ENTRY(smaia, true, PRIV_VERSION_1_12_0, ext_smaia),
@@ -1126,6 +1129,7 @@ static Property riscv_cpu_extensions[] = {
 DEFINE_PROP_BOOL("Zfhmin", RISCVCPU, cfg.ext_zfhmin, false),
 DEFINE_PROP_BOOL("Zve32f", RISCVCPU, cfg.ext_zve32f, false),
 DEFINE_PROP_BOOL("Zve64f", RISCVCPU, cfg.ext_zve64f, false),
+DEFINE_PROP_BOOL("Zve64d", RISCVCPU, cfg.ext_zve64d, false),
 DEFINE_PROP_BOOL("mmu", RISCVCPU, cfg.mmu, true),
 DEFINE_PROP_BOOL("pmp", RISCVCPU, cfg.pmp, true),
 DEFINE_PROP_BOOL("sstc", RISCVCPU, cfg.ext_sstc, true),
@@ -1185,6 +1189,9 @@ static Property riscv_cpu_extensions[] = {
 DEFINE_PROP_BOOL("x-smaia", RISCVCPU, cfg.ext_smaia, false),
 DEFINE_PROP_BOOL("x-ssaia", RISCVCPU, cfg.ext_ssaia, false),
 
+DEFINE_PROP_BOOL("x-zvfh", RISCVCPU, cfg.ext_zvfh, false),
+DEFINE_PROP_BOOL("x-zvfhmin", RISCVCPU, cfg.ext_zvfhmin, false),
+
 DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
2.25.1

Re: [PATCH 05/18] target/riscv: Coding style fixes in csr.c

[weiwei]

On 2023/2/14 02:02, Bin Meng wrote:

Fix various places that violate QEMU coding style:

- correct multi-line comment format
- indent to opening parenthesis

Signed-off-by: Bin Meng 

Reviewed-by: Weiwei Li 

Regards,
Weiwei Li

---

  target/riscv/csr.c | 62 --
  1 file changed, 32 insertions(+), 30 deletions(-)

diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index c2dd9d5af0..cc74819759 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -963,7 +963,7 @@ static RISCVException sstc_32(CPURISCVState *env, int csrno)
  }
  
  static RISCVException read_vstimecmp(CPURISCVState *env, int csrno,

-target_ulong *val)
+ target_ulong *val)
  {
  *val = env->vstimecmp;
  
@@ -971,7 +971,7 @@ static RISCVException read_vstimecmp(CPURISCVState *env, int csrno,

  }
  
  static RISCVException read_vstimecmph(CPURISCVState *env, int csrno,

-target_ulong *val)
+  target_ulong *val)
  {
  *val = env->vstimecmp >> 32;
  
@@ -979,7 +979,7 @@ static RISCVException read_vstimecmph(CPURISCVState *env, int csrno,

  }
  
  static RISCVException write_vstimecmp(CPURISCVState *env, int csrno,

-target_ulong val)
+  target_ulong val)
  {
  RISCVCPU *cpu = env_archcpu(env);
  
@@ -996,7 +996,7 @@ static RISCVException write_vstimecmp(CPURISCVState *env, int csrno,

  }
  
  static RISCVException write_vstimecmph(CPURISCVState *env, int csrno,

-target_ulong val)
+   target_ulong val)
  {
  RISCVCPU *cpu = env_archcpu(env);
  
@@ -1020,7 +1020,7 @@ static RISCVException read_stimecmp(CPURISCVState *env, int csrno,

  }
  
  static RISCVException read_stimecmph(CPURISCVState *env, int csrno,

-target_ulong *val)
+ target_ulong *val)
  {
  if (riscv_cpu_virt_enabled(env)) {
  *val = env->vstimecmp >> 32;
@@ -1032,7 +1032,7 @@ static RISCVException read_stimecmph(CPURISCVState *env, 
int csrno,
  }
  
  static RISCVException write_stimecmp(CPURISCVState *env, int csrno,

-target_ulong val)
+ target_ulong val)
  {
  RISCVCPU *cpu = env_archcpu(env);
  
@@ -1055,7 +1055,7 @@ static RISCVException write_stimecmp(CPURISCVState *env, int csrno,

  }
  
  static RISCVException write_stimecmph(CPURISCVState *env, int csrno,

-target_ulong val)
+  target_ulong val)
  {
  RISCVCPU *cpu = env_archcpu(env);
  
@@ -1342,7 +1342,8 @@ static RISCVException write_misa(CPURISCVState *env, int csrno,
  
  /* 'E' excludes all other extensions */

  if (val & RVE) {
-/* when we support 'E' we can do "val = RVE;" however
+/*
+ * when we support 'E' we can do "val = RVE;" however
   * for now we just drop writes if 'E' is present.
   */
  return RISCV_EXCP_NONE;
@@ -1364,7 +1365,8 @@ static RISCVException write_misa(CPURISCVState *env, int 
csrno,
  val &= ~RVD;
  }
  
-/* Suppress 'C' if next instruction is not aligned

+/*
+ * Suppress 'C' if next instruction is not aligned
   * TODO: this should check next_pc
   */
  if ((val & RVC) && (GETPC() & ~3) != 0) {
@@ -1833,28 +1835,28 @@ static RISCVException write_mscratch(CPURISCVState 
*env, int csrno,
  }
  
  static RISCVException read_mepc(CPURISCVState *env, int csrno,

- target_ulong *val)
+target_ulong *val)
  {
  *val = env->mepc;
  return RISCV_EXCP_NONE;
  }
  
  static RISCVException write_mepc(CPURISCVState *env, int csrno,

- target_ulong val)
+ target_ulong val)
  {
  env->mepc = val;
  return RISCV_EXCP_NONE;
  }
  
  static RISCVException read_mcause(CPURISCVState *env, int csrno,

- target_ulong *val)
+  target_ulong *val)
  {
  *val = env->mcause;
  return RISCV_EXCP_NONE;
  }
  
  static RISCVException write_mcause(CPURISCVState *env, int csrno,

- target_ulong val)
+   target_ulong val)
  {
  env->mcause = val;
  return RISCV_EXCP_NONE;
@@ -1876,14 +1878,14 @@ static RISCVException write_mtval(CPURISCVState *env, 
int csrno,
  
  /* Execution environment configuration setup */

  static RISCVException read_menvcfg(CPURISCVState *env, int csrno,
- target_ulong *val)
+   target_ulong *val)
  {
  *val = env->menvcfg;
  return RISCV_EXCP_NO

RE: [RFC 08/52] machine: Add helpers to get cpu topology info from MachineState.topo

[Mi, Dapeng1]

> From: Zhao Liu 
> Sent: Monday, February 13, 2023 5:50 PM
> To: Eduardo Habkost ; Marcel Apfelbaum
> ; Philippe Mathieu-Daudé ;
> Yanan Wang ; Michael S . Tsirkin
> ; Richard Henderson ; Paolo
> Bonzini ; Eric Blake ; Markus
> Armbruster 
> Cc: qemu-devel@nongnu.org; Wang, Zhenyu Z ; Mi,
> Dapeng1 ; Ding, Zhuocheng
> ; Robert Hoo ;
> Christopherson,, Sean ; Like Xu
> ; Liu, Zhao1 
> Subject: [RFC 08/52] machine: Add helpers to get cpu topology info from
> MachineState.topo
> 
> From: Zhao Liu 
> 
> When MachineState.topo is introduced, the topology related structures become
> complicated. In the general case (hybrid or smp topology), accessing the
> topology information needs to determine whether it is currently smp or hybrid
> topology, and then access the corresponding MachineState.topo.smp or
> MachineState.topo.hybrid.
> 
> The best way to do this is to wrap the access to the topology to avoid having 
> to
> check each time it is accessed.
> 
> The following helpers are provided here:
> 
> - General interfaces - no need to worry about whether the underlying
>   topology is smp or hybrid:
> 
> * machine_topo_get_cpus()
> * machine_topo_get_max_cpus()
> * machine_topo_is_smp()
> * machine_topo_get_sockets()
> * machine_topo_get_dies()
> * machine_topo_get_clusters()
> * machine_topo_get_threads();
> * machine_topo_get_cores();
> * machine_topo_get_threads_by_idx()
> * machine_topo_get_cores_by_idx()
> * machine_topo_get_cores_per_socket()
> * machine_topo_get_threads_per_socket()
> 
> - SMP-specific interfaces - provided for the cases that are clearly known to 
> be
> smp topology:
> 
> * machine_topo_get_smp_cores()
> * machine_topo_get_smp_threads()
> 
> Since for hybrid topology, each core may has different threads, if someone
> wants "cpus per core", the cpu_index is need to target a specific core
> (machine_topo_get_threads_by_idx()). But for smp, there is no need to be so
> troublesome, so for this case, we provide smp-specific interfaces.
> 
> Signed-off-by: Zhao Liu 
> ---
>  hw/core/machine-topo.c | 142
> +
>  include/hw/boards.h|  35 ++
>  2 files changed, 177 insertions(+)
> 
> diff --git a/hw/core/machine-topo.c b/hw/core/machine-topo.c index
> 7223f73f99b0..b20160479629 100644
> --- a/hw/core/machine-topo.c
> +++ b/hw/core/machine-topo.c
> @@ -21,6 +21,148 @@
>  #include "hw/boards.h"
>  #include "qapi/error.h"
> 
> +unsigned int machine_topo_get_sockets(const MachineState *ms) {
> +return machine_topo_is_smp(ms) ? ms->topo.smp.sockets :
> + ms->topo.hybrid.sockets; }
> +
> +unsigned int machine_topo_get_dies(const MachineState *ms) {
> +return machine_topo_is_smp(ms) ? ms->topo.smp.dies :
> + ms->topo.hybrid.dies; }
> +
> +unsigned int machine_topo_get_clusters(const MachineState *ms) {
> +return machine_topo_is_smp(ms) ? ms->topo.smp.clusters :
> + ms->topo.hybrid.clusters; }
> +
> +unsigned int machine_topo_get_smp_cores(const MachineState *ms) {
> +g_assert(machine_topo_is_smp(ms));
> +return ms->topo.smp.cores;
> +}
> +
> +unsigned int machine_topo_get_smp_threads(const MachineState *ms) {
> +g_assert(machine_topo_is_smp(ms));
> +return ms->topo.smp.threads;
> +}
> +
> +unsigned int machine_topo_get_threads(const MachineState *ms,
> +  unsigned int cluster_id,
> +  unsigned int core_id) {
> +if (machine_topo_is_smp(ms)) {
> +return ms->topo.smp.threads;
> +} else {
> +return ms->topo.hybrid.cluster_list[cluster_id]
> +   .core_list[core_id].threads;
> +}
> +
> +return 0;
> +}
> +
> +unsigned int machine_topo_get_cores(const MachineState *ms,
> +unsigned int cluster_id) {
> +if (machine_topo_is_smp(ms)) {
> +return ms->topo.smp.cores;
> +} else {
> +return ms->topo.hybrid.cluster_list[cluster_id].cores;
> +}
> +}
> +
> +unsigned int machine_topo_get_threads_by_idx(const MachineState *ms,
> + unsigned int cpu_index) {
> +unsigned cpus_per_die;
> +unsigned tmp_idx;
> +HybridCluster *cluster;
> +HybridCore *core;
> +
> +if (machine_topo_is_smp(ms)) {
> +return ms->topo.smp.threads;
> +}
> +
> +cpus_per_die = ms->topo.max_cpus / (ms->topo.hybrid.sockets *
> +ms->topo.hybrid.dies);
> +tmp_idx = cpu_index % cpus_per_die;
> +
> +for (int i = 0; i < ms->topo.hybrid.clusters; i++) {
> +cluster = &ms->topo.hybrid.cluster_list[i];
> +
> +for (int j = 0; j < cluster->cores; j++) {
> +core = &cluster->core_list[j];
> +
> +if (tmp_idx < core->threads) {
> +return core->threads;
> +} else {
> +tmp_idx -= core->threads;
> +}
> +

[PULL 17/22] tests/qtest: Do not include hexloader-test if loader device is not present

[Thomas Huth]

From: Fabiano Rosas 

Signed-off-by: Fabiano Rosas 
Message-Id: <20230208194700.11035-11-faro...@suse.de>
Reviewed-by: Thomas Huth 
Signed-off-by: Thomas Huth 
---
 tests/qtest/meson.build | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index 5c8b031ce0..e87cb18d8e 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -197,11 +197,11 @@ qtests_arm = \
   (config_all_devices.has_key('CONFIG_PFLASH_CFI02') ? ['pflash-cfi02-test'] : 
[]) + \
   (config_all_devices.has_key('CONFIG_ASPEED_SOC') ? qtests_aspeed : []) + \
   (config_all_devices.has_key('CONFIG_NPCM7XX') ? qtests_npcm7xx : []) + \
+  (config_all_devices.has_key('CONFIG_GENERIC_LOADER') ? ['hexloader-test'] : 
[]) + \
   ['arm-cpu-features',
'microbit-test',
'test-arm-mptimer',
-   'boot-serial-test',
-   'hexloader-test']
+   'boot-serial-test']
 
 # TODO: once aarch64 TCG is fixed on ARM 32 bit host, make bios-tables-test 
unconditional
 qtests_aarch64 = \
-- 
2.31.1

Re: [Patch 14/14] target/riscv: Expose properties for Zv* extension

[Daniel Henrique Barboza]

On 2/14/23 05:38, Weiwei Li wrote:

Expose Zve64d,Zvfh,Zvfhmin properties

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---


Reviewed-by: Daniel Henrique Barboza 



  target/riscv/cpu.c | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 73711d392d..2c71e22ea9 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -101,6 +101,9 @@ static const struct isa_ext_data isa_edata_arr[] = {
  ISA_EXT_DATA_ENTRY(zkt, true, PRIV_VERSION_1_12_0, ext_zkt),
  ISA_EXT_DATA_ENTRY(zve32f, true, PRIV_VERSION_1_12_0, ext_zve32f),
  ISA_EXT_DATA_ENTRY(zve64f, true, PRIV_VERSION_1_12_0, ext_zve64f),
+ISA_EXT_DATA_ENTRY(zve64d, true, PRIV_VERSION_1_12_0, ext_zve64d),
+ISA_EXT_DATA_ENTRY(zvfh, true, PRIV_VERSION_1_12_0, ext_zvfh),
+ISA_EXT_DATA_ENTRY(zvfhmin, true, PRIV_VERSION_1_12_0, ext_zvfhmin),
  ISA_EXT_DATA_ENTRY(zhinx, true, PRIV_VERSION_1_12_0, ext_zhinx),
  ISA_EXT_DATA_ENTRY(zhinxmin, true, PRIV_VERSION_1_12_0, ext_zhinxmin),
  ISA_EXT_DATA_ENTRY(smaia, true, PRIV_VERSION_1_12_0, ext_smaia),
@@ -1126,6 +1129,7 @@ static Property riscv_cpu_extensions[] = {
  DEFINE_PROP_BOOL("Zfhmin", RISCVCPU, cfg.ext_zfhmin, false),
  DEFINE_PROP_BOOL("Zve32f", RISCVCPU, cfg.ext_zve32f, false),
  DEFINE_PROP_BOOL("Zve64f", RISCVCPU, cfg.ext_zve64f, false),
+DEFINE_PROP_BOOL("Zve64d", RISCVCPU, cfg.ext_zve64d, false),
  DEFINE_PROP_BOOL("mmu", RISCVCPU, cfg.mmu, true),
  DEFINE_PROP_BOOL("pmp", RISCVCPU, cfg.pmp, true),
  DEFINE_PROP_BOOL("sstc", RISCVCPU, cfg.ext_sstc, true),
@@ -1185,6 +1189,9 @@ static Property riscv_cpu_extensions[] = {
  DEFINE_PROP_BOOL("x-smaia", RISCVCPU, cfg.ext_smaia, false),
  DEFINE_PROP_BOOL("x-ssaia", RISCVCPU, cfg.ext_ssaia, false),
  
+DEFINE_PROP_BOOL("x-zvfh", RISCVCPU, cfg.ext_zvfh, false),

+DEFINE_PROP_BOOL("x-zvfhmin", RISCVCPU, cfg.ext_zvfhmin, false),
+
  DEFINE_PROP_END_OF_LIST(),
  };
  

Re: [Patch 05/14] target/riscv: Fix relationship between V, Zve*, F and D

[weiwei]

On 2023/2/14 21:21, Daniel Henrique Barboza wrote:



On 2/14/23 05:38, Weiwei Li wrote:

Add dependence chain:
*  V => Zve64d => Zve64f => Zve32f => F
*  V => Zve64d => D

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
  target/riscv/cpu.c | 21 ++---
  1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 9a89bea2a3..4797ef9c42 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -743,12 +743,27 @@ static void 
riscv_cpu_validate_set_extensions(RISCVCPU *cpu, Error **errp)

  return;
  }
  -    if (cpu->cfg.ext_v && !cpu->cfg.ext_d) {
-    error_setg(errp, "V extension requires D extension");
+    /* The V vector extension depends on the Zve64d extension */
+    if (cpu->cfg.ext_v) {
+    cpu->cfg.ext_zve64d = true;
+    }
+
+    /* The Zve64d extension depends on the Zve64f extension */
+    if (cpu->cfg.ext_zve64d) {
+    cpu->cfg.ext_zve64f = true;
+    }
+
+    /* The Zve64f extension depends on the Zve32f extension */
+    if (cpu->cfg.ext_zve64f) {
+    cpu->cfg.ext_zve32f = true;
+    }
+
+    if (cpu->cfg.ext_zve64d && !cpu->cfg.ext_d) {
+    error_setg(errp, "Zve64d extensions require D extension");
  return;


I'll be honest and confess that I wrote a short essay about the 
problems I have
with this code. I gave up because in the end it's all stuff that we've 
been doing
for a long time in riscv_cpu_validate_set_extensions(). I'll see if I 
can work in
a redesign of that function and in how we're setting extensions 
automatically

without checking user input and so on.

For now I'll say that this error message seems weird because Zve64d 
was set to true

without user input. So this ends up happening:

$ ./qemu-system-riscv64 -M virt -cpu rv64,v=true,d=false
qemu-system-riscv64: Zve64d extensions require D extension

It's weird because the user didn't enabled Zve64d but the error 
message is complaining
about it. Given that the root cause is that ext_v was set, and then 
we've set other
extensions under the hood, a saner error message in this case would be 
"V extension

requires D extension".


Thanks,


Daniel


Thanks for your comments.

V extension depends on Zve64d(which is actually parts of V). So Zve64d 
will be enabled when V is enabled.


And in fact, only the instructions in the Zve64d part of V require D 
extension.


To make it more readable, maybe it can be change to :

"Zve64d (or V) extension requires D extension"

Regards,

Weiwei Li






  }
  -    if ((cpu->cfg.ext_zve32f || cpu->cfg.ext_zve64f) && 
!cpu->cfg.ext_f) {

+    if (cpu->cfg.ext_zve32f && !cpu->cfg.ext_f) {
  error_setg(errp, "Zve32f/Zve64f extensions require F 
extension");

  return;
  }

Re: [qemu-web PATCH] add missing tag

[Thomas Huth]

On 14/02/2023 13.24, Paolo Bonzini wrote:

The homepage goes straight from h1 to h3, add the missing tag for use in screen 
readers.

Signed-off-by: Paolo Bonzini 
---
  assets/css/style.css | 12 
  index.html   |  3 +++
  2 files changed, 15 insertions(+)

diff --git a/assets/css/style.css b/assets/css/style.css
index 779b111..2705787 100644
--- a/assets/css/style.css
+++ b/assets/css/style.css
@@ -44,6 +44,18 @@
color: #802400;
}
  
+.visuallyhidden

+   {
+   border: 0;
+   clip: rect(0 0 0 0);
+   height: 1px;
+   margin: -1px;
+   overflow: hidden;
+   padding: 0;
+   position: absolute;
+   width: 1px;
+   }
+
pre,code,samp,tt
{
font-family: 'Roboto Mono', monospace;
diff --git a/index.html b/index.html
index d72750c..676c379 100644
--- a/index.html
+++ b/index.html
@@ -14,6 +14,9 @@ colorbox: True

  
  
+   
+   Features
+   





Reviewed-by: Thomas Huth 

[PATCH 03/12] hw/pci-host/q35: Use memory_region_set_address() also for tseg_blackhole

[Bernhard Beschow]

Deleting from and adding to the parent memory region seems to be the old
way of changing a memory region's address which is superseeded by
memory_region_set_address(). Moreover, memory_region_set_address() is
already used for tseg_window which is tseg_blackhole's counterpart in
SMM space.

Ammends: bafc90bdc594 'q35: implement TSEG'
Signed-off-by: Bernhard Beschow 
---
 hw/pci-host/q35.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 3124cad60f..0384ce4350 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -404,12 +404,11 @@ static void mch_update_smram(MCHPCIState *mch)
 } else {
 tseg_size = 0;
 }
-memory_region_del_subregion(mch->system_memory, &mch->tseg_blackhole);
+
 memory_region_set_enabled(&mch->tseg_blackhole, tseg_size);
 memory_region_set_size(&mch->tseg_blackhole, tseg_size);
-memory_region_add_subregion_overlap(mch->system_memory,
-mch->below_4g_mem_size - tseg_size,
-&mch->tseg_blackhole, 1);
+memory_region_set_address(&mch->tseg_blackhole,
+  mch->below_4g_mem_size - tseg_size);
 
 memory_region_set_enabled(&mch->tseg_window, tseg_size);
 memory_region_set_size(&mch->tseg_window, tseg_size);
-- 
2.39.1

Re: [PATCH] block: temporarily hold the new AioContext of bs_top in bdrv_append()

[Kevin Wolf]

Am 14.02.2023 um 11:51 hat Stefano Garzarella geschrieben:
> bdrv_append() is called with bs_top AioContext held, but
> bdrv_attach_child_noperm() could change the AioContext of bs_top.
> 
> bdrv_replace_node_noperm() calls bdrv_drained_begin() starting from
> commit 2398747128 ("block: Don't poll in bdrv_replace_child_noperm()").
> bdrv_drained_begin() can call BDRV_POLL_WHILE that assumes the new lock
> is taken, so let's temporarily hold the new AioContext to prevent QEMU
> from failing in BDRV_POLL_WHILE when it tries to release the wrong
> AioContext.
> 
> Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2168209
> Reported-by: Aihua Liang 
> Signed-off-by: Stefano Garzarella 
> ---
> I'm not sure whether to use the following Fixes tag. That commit added the
> calls to bdrv_drained_begin() in bdrv_replace_node_noperm(), but maybe the
> problem was pre-existing.
> 
> Fixes: 2398747128 ("block: Don't poll in bdrv_replace_child_noperm()")
> 
> Note: a local reproducer is attached in the BZ, it is based on the Aihua Liang
> report and it hits the issue with a 20% ratio.
> ---
>  block.c | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/block.c b/block.c
> index aa9062f2c1..0e2bc11e0b 100644
> --- a/block.c
> +++ b/block.c
> @@ -5266,6 +5266,8 @@ int bdrv_drop_filter(BlockDriverState *bs, Error **errp)
>   * child.
>   *
>   * This function does not create any image files.
> + *
> + * The caller must hold the AioContext lock for @bs_top.
>   */
>  int bdrv_append(BlockDriverState *bs_new, BlockDriverState *bs_top,
>  Error **errp)
> @@ -5273,11 +5275,14 @@ int bdrv_append(BlockDriverState *bs_new, 
> BlockDriverState *bs_top,
>  int ret;
>  BdrvChild *child;
>  Transaction *tran = tran_new();
> +AioContext *old_context, *new_context;
>  
>  GLOBAL_STATE_CODE();
>  
>  assert(!bs_new->backing);
>  
> +old_context = bdrv_get_aio_context(bs_top);
> +
>  child = bdrv_attach_child_noperm(bs_new, bs_top, "backing",
>   &child_of_bds, 
> bdrv_backing_role(bs_new),
>   tran, errp);
> @@ -5286,11 +5291,29 @@ int bdrv_append(BlockDriverState *bs_new, 
> BlockDriverState *bs_top,
>  goto out;
>  }
>  
> +/*
> + * bdrv_attach_child_noperm could change the AioContext of bs_top.
> + * bdrv_replace_node_noperm calls bdrv_drained_begin, so let's 
> temporarily
> + * hold the new AioContext, since bdrv_drained_begin calls 
> BDRV_POLL_WHILE
> + * that assumes the new lock is taken.
> + */
> +new_context = bdrv_get_aio_context(bs_top);
> +
> +if (old_context != new_context) {
> +aio_context_release(old_context);
> +aio_context_acquire(new_context);
> +}
> +
>  ret = bdrv_replace_node_noperm(bs_top, bs_new, true, tran, errp);
>  if (ret < 0) {
>  goto out;

If we take the error path, we return with new_context locked instead of
old_context now.

>  }
>  
> +if (old_context != new_context) {
> +aio_context_release(new_context);
> +aio_context_acquire(old_context);
> +}
> +
>  ret = bdrv_refresh_perms(bs_new, tran, errp);
>  out:
>  tran_finalize(tran, ret);

Strictly speaking, don't we need to hold the lock across
tran_finalize(), too? It completes the bdrv_replace_node_noperm() call
you covered above.

Maybe bdrv_refresh_perms() and bdrv_refresh_limits(), too, in fact. We
never clearly defined which functions need the lock and which don't, so
hard to tell. It's really time to get rid of it.

Kevin

[PULL 15/22] tests/qtest: drive_del-test: Skip tests that require missing devices

[Thomas Huth]

From: Fabiano Rosas 

Signed-off-by: Fabiano Rosas 
Message-Id: <20230208194700.11035-9-faro...@suse.de>
Reviewed-by: Thomas Huth 
Signed-off-by: Thomas Huth 
---
 tests/qtest/drive_del-test.c | 65 
 1 file changed, 65 insertions(+)

diff --git a/tests/qtest/drive_del-test.c b/tests/qtest/drive_del-test.c
index 9a750395a9..8a6f3ac963 100644
--- a/tests/qtest/drive_del-test.c
+++ b/tests/qtest/drive_del-test.c
@@ -16,6 +16,8 @@
 #include "qapi/qmp/qdict.h"
 #include "qapi/qmp/qlist.h"
 
+static const char *qvirtio_get_dev_type(void);
+
 static bool look_for_drive0(QTestState *qts, const char *command, const char 
*key)
 {
 QDict *response;
@@ -40,6 +42,19 @@ static bool look_for_drive0(QTestState *qts, const char 
*command, const char *ke
 return found;
 }
 
+/*
+ * This covers the possible absence of a device due to QEMU build
+ * options.
+ */
+static bool has_device_builtin(const char *dev)
+{
+gchar *device = g_strdup_printf("%s-%s", dev, qvirtio_get_dev_type());
+bool rc = qtest_has_device(device);
+
+g_free(device);
+return rc;
+}
+
 static bool has_drive(QTestState *qts)
 {
 return look_for_drive0(qts, "query-block", "device");
@@ -208,6 +223,11 @@ static void test_drive_del_device_del(void)
 {
 QTestState *qts;
 
+if (!has_device_builtin("virtio-scsi")) {
+g_test_skip("Device virtio-scsi is not available");
+return;
+}
+
 /* Start with a drive used by a device that unplugs instantaneously */
 qts = qtest_initf("-drive if=none,id=drive0,file=null-co://,"
   "file.read-zeroes=on,format=raw"
@@ -232,6 +252,11 @@ static void test_cli_device_del(void)
 const char *arch = qtest_get_arch();
 const char *machine_addition = "";
 
+if (!has_device_builtin("virtio-blk")) {
+g_test_skip("Device virtio-blk is not available");
+return;
+}
+
 if (strcmp(arch, "i386") == 0 || strcmp(arch, "x86_64") == 0) {
 machine_addition = "-machine pc";
 }
@@ -256,6 +281,11 @@ static void test_cli_device_del_q35(void)
 {
 QTestState *qts;
 
+if (!has_device_builtin("virtio-blk")) {
+g_test_skip("Device virtio-blk is not available");
+return;
+}
+
 /*
  * -drive/-device and device_del.  Start with a drive used by a
  * device that unplugs after reset.
@@ -277,6 +307,11 @@ static void test_empty_device_del(void)
 {
 QTestState *qts;
 
+if (!has_device_builtin("virtio-scsi")) {
+g_test_skip("Device virtio-scsi is not available");
+return;
+}
+
 /* device_del with no drive plugged.  */
 qts = qtest_initf("-device virtio-scsi-%s -device scsi-cd,id=dev0",
   qvirtio_get_dev_type());
@@ -291,6 +326,11 @@ static void test_device_add_and_del(void)
 const char *arch = qtest_get_arch();
 const char *machine_addition = "";
 
+if (!has_device_builtin("virtio-blk")) {
+g_test_skip("Device virtio-blk is not available");
+return;
+}
+
 if (strcmp(arch, "i386") == 0 || strcmp(arch, "x86_64") == 0) {
 machine_addition = "-machine pc";
 }
@@ -330,6 +370,11 @@ static void test_device_add_and_del_q35(void)
 {
 QTestState *qts;
 
+if (!has_device_builtin("virtio-blk")) {
+g_test_skip("Device virtio-blk is not available");
+return;
+}
+
 /*
  * -drive/device_add and device_del.  Start with a drive used by a
  * device that unplugs after reset.
@@ -352,6 +397,11 @@ static void test_drive_add_device_add_and_del(void)
 const char *arch = qtest_get_arch();
 const char *machine_addition = "";
 
+if (!has_device_builtin("virtio-blk")) {
+g_test_skip("Device virtio-blk is not available");
+return;
+}
+
 if (strcmp(arch, "i386") == 0 || strcmp(arch, "x86_64") == 0) {
 machine_addition = "-machine pc";
 }
@@ -374,6 +424,11 @@ static void test_drive_add_device_add_and_del_q35(void)
 {
 QTestState *qts;
 
+if (!has_device_builtin("virtio-blk")) {
+g_test_skip("Device virtio-blk is not available");
+return;
+}
+
 qts = qtest_init("-machine q35 -device pcie-root-port,id=p1 "
  "-device pcie-pci-bridge,bus=p1,id=b1");
 
@@ -395,6 +450,11 @@ static void test_blockdev_add_device_add_and_del(void)
 const char *arch = qtest_get_arch();
 const char *machine_addition = "";
 
+if (!has_device_builtin("virtio-blk")) {
+g_test_skip("Device virtio-blk is not available");
+return;
+}
+
 if (strcmp(arch, "i386") == 0 || strcmp(arch, "x86_64") == 0) {
 machine_addition = "-machine pc";
 }
@@ -417,6 +477,11 @@ static void test_blockdev_add_device_add_and_del_q35(void)
 {
 QTestState *qts;
 
+if (!has_device_builtin("virtio-blk")) {
+g_test_skip("Device virtio-blk is not available");
+return;
+}
+
 qts = qtest_init("-machine q35 -device pcie-root-port,id=p1

[PATCH] chardev/char-socket: set s->listener = NULL in char_socket_finalize

[Yajun Wu]

After live migration with virtio block device, qemu crash at:

#0  0x55914f46f795 in object_dynamic_cast_assert 
(obj=0x559151b7b090, typename=0x55914f80fbc4 "qio-channel", file=0x55914f80fb90 
"/images/testvfe/sw/qemu.gerrit/include/io/channel.h", line=30, 
func=0x55914f80fcb8 <__func__.17257> "QIO_CHANNEL") at ../qom/object.c:872
#1  0x55914f480d68 in QIO_CHANNEL (obj=0x559151b7b090) at 
/images/testvfe/sw/qemu.gerrit/include/io/channel.h:29
#2  0x55914f4812f8 in qio_net_listener_set_client_func_full 
(listener=0x559151b7a720, func=0x55914f580b97 , 
data=0x5591519f4ea0, notify=0x0, context=0x0) at ../io/net-listener.c:166
#3  0x55914f580059 in tcp_chr_update_read_handler 
(chr=0x5591519f4ea0) at ../chardev/char-socket.c:637
#4  0x55914f583dca in qemu_chr_be_update_read_handlers 
(s=0x5591519f4ea0, context=0x0) at ../chardev/char.c:226
#5  0x55914f57b7c9 in qemu_chr_fe_set_handlers_full 
(b=0x559152bf23a0, fd_can_read=0x0, fd_read=0x0, fd_event=0x0, be_change=0x0, 
opaque=0x0, context=0x0, set_open=false, sync_state=true) at 
../chardev/char-fe.c:279
#6  0x55914f57b86d in qemu_chr_fe_set_handlers (b=0x559152bf23a0, 
fd_can_read=0x0, fd_read=0x0, fd_event=0x0, be_change=0x0, opaque=0x0, 
context=0x0, set_open=false) at ../chardev/char-fe.c:304
#7  0x55914f378caf in vhost_user_async_close (d=0x559152bf21a0, 
chardev=0x559152bf23a0, vhost=0x559152bf2420, cb=0x55914f2fb8c1 
) at ../hw/virtio/vhost-user.c:2725
#8  0x55914f2fba40 in vhost_user_blk_event (opaque=0x559152bf21a0, 
event=CHR_EVENT_CLOSED) at ../hw/block/vhost-user-blk.c:395
#9  0x55914f58388c in chr_be_event (s=0x5591519f4ea0, 
event=CHR_EVENT_CLOSED) at ../chardev/char.c:61
#10 0x55914f583905 in qemu_chr_be_event (s=0x5591519f4ea0, 
event=CHR_EVENT_CLOSED) at ../chardev/char.c:81
#11 0x55914f581275 in char_socket_finalize (obj=0x5591519f4ea0) at 
../chardev/char-socket.c:1083
#12 0x55914f46f073 in object_deinit (obj=0x5591519f4ea0, 
type=0x5591519055c0) at ../qom/object.c:680
#13 0x55914f46f0e5 in object_finalize (data=0x5591519f4ea0) at 
../qom/object.c:694
#14 0x55914f46ff06 in object_unref (objptr=0x5591519f4ea0) at 
../qom/object.c:1202
#15 0x55914f4715a4 in object_finalize_child_property 
(obj=0x559151b76c50, name=0x559151b7b250 "char3", opaque=0x5591519f4ea0) at 
../qom/object.c:1747
#16 0x55914f46ee86 in object_property_del_all (obj=0x559151b76c50) 
at ../qom/object.c:632
#17 0x55914f46f0d2 in object_finalize (data=0x559151b76c50) at 
../qom/object.c:693
#18 0x55914f46ff06 in object_unref (objptr=0x559151b76c50) at 
../qom/object.c:1202
#19 0x55914f4715a4 in object_finalize_child_property 
(obj=0x559151b6b560, name=0x559151b76630 "chardevs", opaque=0x559151b76c50) at 
../qom/object.c:1747
#20 0x55914f46ef67 in object_property_del_child 
(obj=0x559151b6b560, child=0x559151b76c50) at ../qom/object.c:654
#21 0x55914f46f042 in object_unparent (obj=0x559151b76c50) at 
../qom/object.c:673
#22 0x55914f58632a in qemu_chr_cleanup () at ../chardev/char.c:1189
#23 0x55914f16c66c in qemu_cleanup () at ../softmmu/runstate.c:830
#24 0x55914eee7b9e in qemu_default_main () at ../softmmu/main.c:38
#25 0x55914eee7bcc in main (argc=86, argv=0x7ffc97cb8d88) at 
../softmmu/main.c:48

In char_socket_finalize after s->listener freed, event callback function
vhost_user_blk_event will be called to handle CHR_EVENT_CLOSED.
vhost_user_blk_event is calling qio_net_listener_set_client_func_full which
is still using s->listener.

Setting s->listener = NULL after object_unref(OBJECT(s->listener)) can
solve this issue.

Signed-off-by: Yajun Wu 
Acked-by: Jiri Pirko 

---
 chardev/char-socket.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/chardev/char-socket.c b/chardev/char-socket.c
index c2265436ac..8c58532171 100644
--- a/chardev/char-socket.c
+++ b/chardev/char-socket.c
@@ -1065,6 +1065,7 @@ static void char_socket_finalize(Object *obj)
 qio_net_listener_set_client_func_full(s->listener, NULL, NULL,
   NULL, chr->gcontext);
 object_unref(OBJECT(s->listener));
+s->listener = NULL;
 }
 if (s->tls_creds) {
 object_unref(OBJECT(s->tls_creds));
-- 
2.27.0

Re: [Patch 13/14] target/riscv: Simplify check for EEW = 64 in trans_rvv.c.inc

[weiwei]

On 2023/2/14 21:37, Daniel Henrique Barboza wrote:



On 2/14/23 05:38, Weiwei Li wrote:

Only V extension support EEW = 64 in these case: Zve64* extensions
don't support EEW = 64 as commented


"as commented" where? In the previous patch?




Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---


The code LGTM.

Reviewed-by: Daniel Henrique Barboza 



  target/riscv/insn_trans/trans_rvv.c.inc | 12 
  1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/target/riscv/insn_trans/trans_rvv.c.inc 
b/target/riscv/insn_trans/trans_rvv.c.inc

index 5dbdce073b..fc0d0d60e8 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -1998,8 +1998,7 @@ static bool vmulh_vv_check(DisasContext *s, 
arg_rmrr *a)

   * are not included for EEW=64 in Zve64*. (Section 18.2)
   */

" are not included for EEW=64 in Zve64*. (Section 18.2) "

The comment is here, and similar comments can be found in following code.

Regards,

Weiwei Li


  return opivv_check(s, a) &&
-   (!has_ext(s, RVV) &&
-    s->cfg_ptr->ext_zve64f ? s->sew != MO_64 : true);
+   (!has_ext(s, RVV) ? s->sew != MO_64 : true);
  }
    static bool vmulh_vx_check(DisasContext *s, arg_rmrr *a)
@@ -2012,8 +2011,7 @@ static bool vmulh_vx_check(DisasContext *s, 
arg_rmrr *a)

   * are not included for EEW=64 in Zve64*. (Section 18.2)
   */
  return opivx_check(s, a) &&
-   (!has_ext(s, RVV) &&
-    s->cfg_ptr->ext_zve64f ? s->sew != MO_64 : true);
+   (!has_ext(s, RVV) ? s->sew != MO_64 : true);
  }
    GEN_OPIVV_GVEC_TRANS(vmul_vv,  mul)
@@ -2230,8 +2228,7 @@ static bool vsmul_vv_check(DisasContext *s, 
arg_rmrr *a)

   * for EEW=64 in Zve64*. (Section 18.2)
   */
  return opivv_check(s, a) &&
-   (!has_ext(s, RVV) &&
-    s->cfg_ptr->ext_zve64f ? s->sew != MO_64 : true);
+   (!has_ext(s, RVV) ? s->sew != MO_64 : true);
  }
    static bool vsmul_vx_check(DisasContext *s, arg_rmrr *a)
@@ -2242,8 +2239,7 @@ static bool vsmul_vx_check(DisasContext *s, 
arg_rmrr *a)

   * for EEW=64 in Zve64*. (Section 18.2)
   */
  return opivx_check(s, a) &&
-   (!has_ext(s, RVV) &&
-    s->cfg_ptr->ext_zve64f ? s->sew != MO_64 : true);
+   (!has_ext(s, RVV) ? s->sew != MO_64 : true);
  }
    GEN_OPIVV_TRANS(vsmul_vv, vsmul_vv_check)

Re: [PATCH v2 6/7] CI: Stop building docs on centos8

[Thomas Huth]

On 14/02/2023 08.40, Markus Armbruster wrote:

Daniel P. Berrangé  writes:

[...]


We don't have to drop python 3.6. It is a choice because
of a desire to be able to use some shiny new python
features without caring about back compat.


I read this on Friday, and decided to let it sit until after the
weekend.  Well, it's now Tuesday, and to be frank, it's still as
offensively flippant as it was on Friday.  It shows either ignorance of
or cavalier disregard for the sheer amount of work some of us have had
to put into keeping old versions of Python viable.


I'm a complete python ignorant, too, so I'm a little bit surprised of the 
amount of pain that these scripts are causing.


No matter of that fact, I think Peter still has a point that we have a real 
conflict here with our current support policy. So this either means that 
Python was the wrong choice for our needs (since it is moving too fast and 
causing too much friction), or we should really rethink our support policy.


I guess we're too deep into the Python rabbit hole already, and I'm not 
aware of any other good solutions (back to Perl scripts? No, thanks!), so 
it's likely quite impossible to tune that knob.


Thus we should maybe really start talking about our support policy now. I 
think the main problem is likely the sentence "Support for the previous 
major version will be dropped 2 years after the new major version is 
released". Maybe we should shorten that time frame to 1 year. The 2 years 
caused some confusions in the past already, since e.g. Debian only supports 
the previous major release for only one more year, and macOS also releases a 
major version each year ... so IMHO we could shorten the time frame for the 
previous major release to 1 year instead. People then could still continue 
building QEMU on CentOS 8, but they have to be aware that they might install 
other software like Sphinx manually if they want to continue using QEMU with 
docs there. What do you think?


 Thomas

[PULL 16/22] tests/qtest: Check for devices in bios-tables-test

[Thomas Huth]

From: Fabiano Rosas 

Do not include tests that require devices that are not available in
the QEMU build.

Signed-off-by: Fabiano Rosas 
Acked-by: Michael S. Tsirkin 
Message-Id: <20230208194700.11035-10-faro...@suse.de>
Signed-off-by: Thomas Huth 
---
 tests/qtest/bios-tables-test.c | 75 --
 1 file changed, 71 insertions(+), 4 deletions(-)

diff --git a/tests/qtest/bios-tables-test.c b/tests/qtest/bios-tables-test.c
index d8c8cda58e..d29a4e47af 100644
--- a/tests/qtest/bios-tables-test.c
+++ b/tests/qtest/bios-tables-test.c
@@ -1008,6 +1008,12 @@ static void test_acpi_q35_multif_bridge(void)
 .machine = MACHINE_Q35,
 .variant = ".multi-bridge",
 };
+
+if (!qtest_has_device("pcie-root-port")) {
+g_test_skip("Device pcie-root-port is not available");
+goto out;
+}
+
 test_vm_prepare("-S"
 " -device virtio-balloon,id=balloon0,addr=0x4.0x2"
 " -device pcie-root-port,id=rp0,multifunction=on,"
@@ -1043,6 +1049,7 @@ static void test_acpi_q35_multif_bridge(void)
 /* check that reboot/reset doesn't change any ACPI tables  */
 qtest_qmp_send(data.qts, "{'execute':'system_reset' }");
 process_acpi_tables(&data);
+out:
 free_test_data(&data);
 }
 
@@ -1396,6 +1403,11 @@ static void test_acpi_tcg_dimm_pxm(const char *machine)
 {
 test_data data;
 
+if (!qtest_has_device("nvdimm")) {
+g_test_skip("Device nvdimm is not available");
+return;
+}
+
 memset(&data, 0, sizeof(data));
 data.machine = machine;
 data.variant = ".dimmpxm";
@@ -1444,6 +1456,11 @@ static void test_acpi_virt_tcg_memhp(void)
 .scan_len = 256ULL * 1024 * 1024,
 };
 
+if (!qtest_has_device("nvdimm")) {
+g_test_skip("Device nvdimm is not available");
+goto out;
+}
+
 data.variant = ".memhp";
 test_acpi_one(" -machine nvdimm=on"
   " -cpu cortex-a57"
@@ -1457,7 +1474,7 @@ static void test_acpi_virt_tcg_memhp(void)
   " -device pc-dimm,id=dimm0,memdev=ram2,node=0"
   " -device nvdimm,id=dimm1,memdev=nvm0,node=1",
   &data);
-
+out:
 free_test_data(&data);
 
 }
@@ -1475,6 +1492,11 @@ static void test_acpi_microvm_tcg(void)
 {
 test_data data;
 
+if (!qtest_has_device("virtio-blk-device")) {
+g_test_skip("Device virtio-blk-device is not available");
+return;
+}
+
 test_acpi_microvm_prepare(&data);
 test_acpi_one(" -machine microvm,acpi=on,ioapic2=off,rtc=off",
   &data);
@@ -1485,6 +1507,11 @@ static void test_acpi_microvm_usb_tcg(void)
 {
 test_data data;
 
+if (!qtest_has_device("virtio-blk-device")) {
+g_test_skip("Device virtio-blk-device is not available");
+return;
+}
+
 test_acpi_microvm_prepare(&data);
 data.variant = ".usb";
 test_acpi_one(" -machine microvm,acpi=on,ioapic2=off,usb=on,rtc=off",
@@ -1496,6 +1523,11 @@ static void test_acpi_microvm_rtc_tcg(void)
 {
 test_data data;
 
+if (!qtest_has_device("virtio-blk-device")) {
+g_test_skip("Device virtio-blk-device is not available");
+return;
+}
+
 test_acpi_microvm_prepare(&data);
 data.variant = ".rtc";
 test_acpi_one(" -machine microvm,acpi=on,ioapic2=off,rtc=on",
@@ -1507,6 +1539,11 @@ static void test_acpi_microvm_pcie_tcg(void)
 {
 test_data data;
 
+if (!qtest_has_device("virtio-blk-device")) {
+g_test_skip("Device virtio-blk-device is not available");
+return;
+}
+
 test_acpi_microvm_prepare(&data);
 data.variant = ".pcie";
 data.tcg_only = true; /* need constant host-phys-bits */
@@ -1519,6 +1556,11 @@ static void test_acpi_microvm_ioapic2_tcg(void)
 {
 test_data data;
 
+if (!qtest_has_device("virtio-blk-device")) {
+g_test_skip("Device virtio-blk-device is not available");
+return;
+}
+
 test_acpi_microvm_prepare(&data);
 data.variant = ".ioapic2";
 test_acpi_one(" -machine microvm,acpi=on,ioapic2=on,rtc=off",
@@ -1558,6 +1600,12 @@ static void test_acpi_virt_tcg_pxb(void)
 .ram_start = 0x4000ULL,
 .scan_len = 128ULL * 1024 * 1024,
 };
+
+if (!qtest_has_device("pcie-root-port")) {
+g_test_skip("Device pcie-root-port is not available");
+goto out;
+}
+
 /*
  * While using -cdrom, the cdrom would auto plugged into pxb-pcie,
  * the reason is the bus of pxb-pcie is also root bus, it would lead
@@ -1576,7 +1624,7 @@ static void test_acpi_virt_tcg_pxb(void)
   " -cpu cortex-a57"
   " -device pxb-pcie,bus_nr=128",
   &data);
-
+out:
 free_test_data(&data);
 }
 
@@ -1764,6 +1812,12 @@ static void test_acpi_microvm_acpi_erst(void)
 gchar *params;
 test_data data;
 
+if (!qtest_has_device("virtio-blk-device")) {
+g_test_skip("Device virtio-blk-device is not available");
+g_free(tmp_path);
+

[PATCH 11/12] hw/pci-host/q35: Merge mch_realize() into q35_host_realize()

[Bernhard Beschow]

This patch prepares movement of the MemoryRegion pointers (which are set
through properties) into the host state. Moreover, it's usually the
parent device which maps the memory regions of its child devices into
its address space. Do the same in q35.

Signed-off-by: Bernhard Beschow 
---
 hw/pci-host/q35.c | 209 ++
 1 file changed, 101 insertions(+), 108 deletions(-)

diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index d517f5622b..3a7f9185a3 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -44,12 +44,40 @@
 
 #define Q35_PCI_HOST_HOLE64_SIZE_DEFAULT (1ULL << 35)
 
+static uint64_t blackhole_read(void *ptr, hwaddr reg, unsigned size)
+{
+return 0x;
+}
+
+static void blackhole_write(void *opaque, hwaddr addr, uint64_t val,
+unsigned width)
+{
+/* nothing */
+}
+
+static const MemoryRegionOps blackhole_ops = {
+.read = blackhole_read,
+.write = blackhole_write,
+.valid.min_access_size = 1,
+.valid.max_access_size = 4,
+.impl.min_access_size = 4,
+.impl.max_access_size = 4,
+.endianness = DEVICE_LITTLE_ENDIAN,
+};
+
 static void q35_host_realize(DeviceState *dev, Error **errp)
 {
 ERRP_GUARD();
 Q35PCIHost *s = Q35_HOST_DEVICE(dev);
 PCIHostState *phb = PCI_HOST_BRIDGE(dev);
 SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
+int i;
+
+if (s->mch.ext_tseg_mbytes > MCH_HOST_BRIDGE_EXT_TSEG_MBYTES_MAX) {
+error_setg(errp, "invalid extended-tseg-mbytes value: %" PRIu16,
+   s->mch.ext_tseg_mbytes);
+return;
+}
 
 memory_region_add_subregion(s->mch.address_space_io,
 MCH_HOST_BRIDGE_CONFIG_ADDR, &phb->conf_mem);
@@ -70,6 +98,79 @@ static void q35_host_realize(DeviceState *dev, Error **errp)
 range_set_bounds(&s->pci_hole, s->mch.below_4g_mem_size,
  IO_APIC_DEFAULT_ADDRESS - 1);
 
+/* setup pci memory mapping */
+pc_pci_as_mapping_init(s->mch.system_memory, s->mch.pci_address_space);
+
+/* if *disabled* show SMRAM to all CPUs */
+memory_region_init_alias(&s->mch.smram_region, OBJECT(s), "smram-region",
+ s->mch.pci_address_space, 
MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ MCH_HOST_BRIDGE_SMRAM_C_SIZE);
+memory_region_add_subregion_overlap(s->mch.system_memory, 
MCH_HOST_BRIDGE_SMRAM_C_BASE,
+&s->mch.smram_region, 1);
+memory_region_set_enabled(&s->mch.smram_region, true);
+
+memory_region_init_alias(&s->mch.open_high_smram, OBJECT(s), 
"smram-open-high",
+ s->mch.ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ MCH_HOST_BRIDGE_SMRAM_C_SIZE);
+memory_region_add_subregion_overlap(s->mch.system_memory, 0xfeda,
+&s->mch.open_high_smram, 1);
+memory_region_set_enabled(&s->mch.open_high_smram, false);
+
+/* smram, as seen by SMM CPUs */
+memory_region_init_alias(&s->mch.low_smram, OBJECT(s), "smram-low",
+ s->mch.ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ MCH_HOST_BRIDGE_SMRAM_C_SIZE);
+memory_region_set_enabled(&s->mch.low_smram, true);
+memory_region_add_subregion(s->mch.smram, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+&s->mch.low_smram);
+memory_region_init_alias(&s->mch.high_smram, OBJECT(s), "smram-high",
+ s->mch.ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ MCH_HOST_BRIDGE_SMRAM_C_SIZE);
+memory_region_set_enabled(&s->mch.high_smram, true);
+memory_region_add_subregion(s->mch.smram, 0xfeda, &s->mch.high_smram);
+
+memory_region_init_io(&s->mch.tseg_blackhole, OBJECT(s),
+  &blackhole_ops, NULL, "tseg-blackhole", 0);
+memory_region_set_enabled(&s->mch.tseg_blackhole, false);
+memory_region_add_subregion_overlap(s->mch.system_memory,
+s->mch.below_4g_mem_size,
+&s->mch.tseg_blackhole, 1);
+
+memory_region_init_alias(&s->mch.tseg_window, OBJECT(s), "tseg-window",
+ s->mch.ram_memory, s->mch.below_4g_mem_size, 0);
+memory_region_set_enabled(&s->mch.tseg_window, false);
+memory_region_add_subregion(s->mch.smram, s->mch.below_4g_mem_size,
+&s->mch.tseg_window);
+
+/*
+ * This is not what hardware does, so it's QEMU specific hack.
+ * See commit message for details.
+ */
+memory_region_init_io(&s->mch.smbase_blackhole, OBJECT(s), &blackhole_ops,
+  NULL, "smbase-blackhole",
+  MCH_HOST_BRIDGE_SMBASE_SIZE);
+memory_region_set_enabled(&s->mch.smbase_blackhole, false);
+memory_region_add_subregion_overlap(s->mch.system_memory,
+   

Re: [PATCH] usb/dev-wacom: fix OOB write in usb_mouse_poll()

[Mauro Matteo Cascella]

Hi Philippe,

On Mon, Feb 13, 2023 at 7:26 PM Philippe Mathieu-Daudé
 wrote:
>
> Hi Mauro,
>
> On 13/2/23 18:41, Mauro Matteo Cascella wrote:
> > The guest can control the size of buf; an OOB write occurs when buf is 1 or 
> > 2
> > bytes long. Only fill in the buffer as long as there is enough space, throw
> > away any data which doesn't fit.
>
> Any reproducer?

No qtest reproducer, we do have a PoC module to compile & load from
within the guest. This is ASAN output:

=
==28803==ERROR: AddressSanitizer: heap-buffer-overflow on address 0
WRITE of size 1 at 0x602000fccdd1 thread T2
#0 0x560f4ebba899 in usb_mouse_poll ../hw/usb/dev-wacom.c:256
#1 0x560f4ebbcaf9 in usb_wacom_handle_data ../hw/usb/dev-wacom6
#2 0x560f4eaef297 in usb_device_handle_data ../hw/usb/bus.c:180
#3 0x560f4eb00bbb in usb_process_one ../hw/usb/core.c:406
#4 0x560f4eb01883 in usb_handle_packet ../hw/usb/core.c:438
#5 0x560f4eb94e0c in xhci_submit ../hw/usb/hcd-xhci.c:1801
#6 0x560f4eb9505f in xhci_fire_transfer ../hw/usb/hcd-xhci.c:10
#7 0x560f4eb9773c in xhci_kick_epctx ../hw/usb/hcd-xhci.c:1969
#8 0x560f4eb953f2 in xhci_kick_ep ../hw/usb/hcd-xhci.c:1835
#9 0x560f4eba416d in xhci_doorbell_write ../hw/usb/hcd-xhci.c:7
#10 0x560f4f5343a8 in memory_region_write_accessor ../softmmu/2
#11 0x560f4f53483f in access_with_adjusted_size ../softmmu/mem4
#12 0x560f4f541e69 in memory_region_dispatch_write ../softmmu/4
#13 0x560f4f57afec in flatview_write_continue ../softmmu/physm5
#14 0x560f4f57b40f in flatview_write ../softmmu/physmem.c:2867
#15 0x560f4f579617 in subpage_write ../softmmu/physmem.c:2501
#16 0x560f4f5346dc in memory_region_write_with_attrs_accessor 3
#17 0x560f4f53483f in access_with_adjusted_size ../softmmu/mem4
#18 0x560f4f542075 in memory_region_dispatch_write ../softmmu/1
#19 0x560f4f727735 in io_writex ../accel/tcg/cputlb.c:1429
#20 0x560f4f72c19d in store_helper ../accel/tcg/cputlb.c:2379
#21 0x560f4f72c5ec in full_le_stl_mmu ../accel/tcg/cputlb.c:247
#22 0x560f4f72c62a in helper_le_stl_mmu ../accel/tcg/cputlb.c:3
#23 0x7fcf063941a3  (/memfd:tcg-jit (deleted)+0x27541a3)


Also forgot to give credits:

Reported-by: ningqiang1 
Reported-by: SorryMybad of Kunlun Lab 

> > Signed-off-by: Mauro Matteo Cascella 
> > ---
> >   hw/usb/dev-wacom.c | 20 +---
> >   1 file changed, 13 insertions(+), 7 deletions(-)
> >
> > diff --git a/hw/usb/dev-wacom.c b/hw/usb/dev-wacom.c
> > index 7177c17f03..ca9e6aa82f 100644
> > --- a/hw/usb/dev-wacom.c
> > +++ b/hw/usb/dev-wacom.c
> > @@ -252,14 +252,20 @@ static int usb_mouse_poll(USBWacomState *s, uint8_t 
> > *buf, int len)
> >   if (s->buttons_state & MOUSE_EVENT_MBUTTON)
> >   b |= 0x04;
> >
> > -buf[0] = b;
> > -buf[1] = dx;
> > -buf[2] = dy;
> > -l = 3;
> > -if (len >= 4) {
> > -buf[3] = dz;
> > -l = 4;
> > +l = 0;
> > +if (len > l) {
> > +buf[l++] = b;
> >   }
> > +if (len > l) {
> > +buf[l++] = dx;
> > +}
>
> else { // the packet is now corrupted... }
>
> > +if (len > l) {
> > +buf[l++] = dy;
> > +}
> > +if (len > l) {
> > +buf[l++] = dz;
> > +}
> > +
> >   return l;
> >   }
>
> Better is to wait for enough data to process:
>
> -- >8 --
> diff --git a/hw/usb/dev-wacom.c b/hw/usb/dev-wacom.c
> index 7177c17f03..2fe2a9220e 100644
> --- a/hw/usb/dev-wacom.c
> +++ b/hw/usb/dev-wacom.c
> @@ -244,6 +244,9 @@ static int usb_mouse_poll(USBWacomState *s, uint8_t
> *buf, int len)
>   s->dy -= dy;
>   s->dz -= dz;
>
> +if (len < 3)
> +return 0;
> +
>   b = 0;
>   if (s->buttons_state & MOUSE_EVENT_LBUTTON)
>   b |= 0x01;
> @@ -274,6 +277,9 @@ static int usb_wacom_poll(USBWacomState *s, uint8_t
> *buf, int len)
>   s->mouse_grabbed = 1;
>   }
>
> +if (len < 7)
> +return 0;
> +
>   b = 0;
>   if (s->buttons_state & MOUSE_EVENT_LBUTTON)
>   b |= 0x01;
> @@ -282,9 +288,6 @@ static int usb_wacom_poll(USBWacomState *s, uint8_t
> *buf, int len)
>   if (s->buttons_state & MOUSE_EVENT_MBUTTON)
>   b |= 0x20; /* eraser */
>
> -if (len < 7)
> -return 0;
> -
>   buf[0] = s->mode;
>   buf[5] = 0x00 | (b & 0xf0);
>   buf[1] = s->x & 0xff;
> ---
>

I took inspiration from hid_pointer_poll() in hw/input/hid.c which
fills in the buffer as much as possible in a similar way, but your
suggestion makes sense to me. Gerd, wdyt?

Thanks,
--
Mauro Matteo Cascella
Red Hat Product Security
PGP-Key ID: BB3410B0

Re: [RFC 34/52] i386: Rename variable topo_info to apicid_topo

[Zhao Liu]

On Mon, Feb 13, 2023 at 02:28:54PM +0100, Philippe Mathieu-Daudé wrote:
> Date: Mon, 13 Feb 2023 14:28:54 +0100
> From: Philippe Mathieu-Daudé 
> Subject: Re: [RFC 34/52] i386: Rename variable topo_info to apicid_topo
> 
> On 13/2/23 10:50, Zhao Liu wrote:
> > From: Zhao Liu 
> > 
> > Since X86ApicidTopoInfo is only used for APIC ID related work, the
> > common variable topo_info of X86ApicidTopoInfo type should be also
> > renamed to better suit its purpose.
> > 
> > Generic topology access should be obtained from MachineState.topo
> > (for the whole machine) or CPUState.topo (for the current CPU), and
> > apicid_topo (X86ApicidTopoInfo type) is only used to collaborate with
> > APIC ID.
> > 
> > Co-Developed-by: Zhuocheng Ding 
> > Signed-off-by: Zhuocheng Ding 
> > Signed-off-by: Zhao Liu 
> > ---
> >   hw/i386/x86.c|  38 -
> >   include/hw/i386/topology.h   |  76 -
> >   include/hw/i386/x86.h|   2 +-
> >   target/i386/cpu.c|  71 
> >   tests/unit/test-x86-apicid.c | 158 +--
> >   5 files changed, 173 insertions(+), 172 deletions(-)
> 
> The 'id' suffix doesn't add a lot of value IMO. Anyway,
> 
> Reviewed-by: Philippe Mathieu-Daudé 
>

Thanks, it makes sense. I'll remove the id suffix.

Zhao

[PULL 21/22] tests/tcg/s390x: Use -nostdlib for softmmu tests

[Thomas Huth]

From: Ilya Leoshkevich 

The code currently uses -nostartfiles, but this does not prevent
linking with libc. On Fedora there is no cross-libc, so the linking
step fails.

Fix by using the more comprehensive -nostdlib (that's also what
probe_target_compiler() checks for as well).

Fixes: 503e549e441e ("tests/tcg/s390x: Test unaligned accesses to lowcore")
Signed-off-by: Ilya Leoshkevich 
Message-Id: <20230131182057.2261614-1-...@linux.ibm.com>
Reviewed-by: Alex Bennée 
Reviewed-by: Richard Henderson 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Huth 
---
 tests/tcg/s390x/Makefile.softmmu-target | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/tcg/s390x/Makefile.softmmu-target 
b/tests/tcg/s390x/Makefile.softmmu-target
index a34fa68473..50c1b88065 100644
--- a/tests/tcg/s390x/Makefile.softmmu-target
+++ b/tests/tcg/s390x/Makefile.softmmu-target
@@ -3,7 +3,7 @@ VPATH+=$(S390X_SRC)
 QEMU_OPTS=-action panic=exit-failure -kernel
 
 %: %.S
-   $(CC) -march=z13 -m64 -nostartfiles -static -Wl,-Ttext=0 \
+   $(CC) -march=z13 -m64 -nostdlib -static -Wl,-Ttext=0 \
-Wl,--build-id=none $< -o $@
 
 TESTS += unaligned-lowcore
-- 
2.31.1

Re: [PATCH v10 45/59] i386/xen: Implement HYPERVISOR_grant_table_op and GNTTABOP_[gs]et_verson

[Paul Durrant]

On 01/02/2023 14:31, David Woodhouse wrote:

From: David Woodhouse 

Signed-off-by: David Woodhouse 
---
  hw/i386/kvm/xen_gnttab.c  | 31 
  hw/i386/kvm/xen_gnttab.h  |  5 
  target/i386/kvm/xen-emu.c | 60 +++
  3 files changed, 96 insertions(+)

diff --git a/hw/i386/kvm/xen_gnttab.c b/hw/i386/kvm/xen_gnttab.c
index cd8c3ae60d..9dfce91f6a 100644
--- a/hw/i386/kvm/xen_gnttab.c
+++ b/hw/i386/kvm/xen_gnttab.c
@@ -181,3 +181,34 @@ int xen_gnttab_map_page(uint64_t idx, uint64_t gfn)
  return 0;
  }
  
+int xen_gnttab_set_version_op(struct gnttab_set_version *set)

+{
+int ret;
+
+switch (set->version) {
+case 1:
+ret = 0;
+break;
+
+case 2:
+/* Behave as before set_version was introduced. */
+ret = -ENOSYS;
+break;
+
+default:
+ret = -EINVAL;
+}
+
+set->version = 1;


Seems like an odd semantic. Only a version of 1 can result in a 
non-error exit. I suspect no harm will come from setting it in the error 
case though so...


Reviewed-by: Paul Durrant 

Re: [PATCH 08/18] target/riscv: Simplify getting RISCVCPU pointer from env

[weiwei]

On 2023/2/14 02:02, Bin Meng wrote:

Use env_archcpu() to get RISCVCPU pointer from env directly.

Signed-off-by: Bin Meng 

Reviewed-by: Weiwei Li 

Regards,
Weiwei Li

---

  target/riscv/csr.c | 36 
  1 file changed, 12 insertions(+), 24 deletions(-)

diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index da3b770894..0a3f2bef6f 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -46,8 +46,7 @@ static RISCVException smstateen_acc_ok(CPURISCVState *env, 
int index,
 uint64_t bit)
  {
  bool virt = riscv_cpu_virt_enabled(env);
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  
  if (env->priv == PRV_M || !cpu->cfg.ext_smstateen) {

  return RISCV_EXCP_NONE;
@@ -90,8 +89,7 @@ static RISCVException fs(CPURISCVState *env, int csrno)
  
  static RISCVException vs(CPURISCVState *env, int csrno)

  {
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  
  if (env->misa_ext & RVV ||

  cpu->cfg.ext_zve32f || cpu->cfg.ext_zve64f) {
@@ -108,8 +106,7 @@ static RISCVException vs(CPURISCVState *env, int csrno)
  static RISCVException ctr(CPURISCVState *env, int csrno)
  {
  #if !defined(CONFIG_USER_ONLY)
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  int ctr_index;
  target_ulong ctr_mask;
  int base_csrno = CSR_CYCLE;
@@ -166,8 +163,7 @@ static RISCVException ctr32(CPURISCVState *env, int csrno)
  #if !defined(CONFIG_USER_ONLY)
  static RISCVException mctr(CPURISCVState *env, int csrno)
  {
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  int ctr_index;
  int base_csrno = CSR_MHPMCOUNTER3;
  
@@ -195,8 +191,7 @@ static RISCVException mctr32(CPURISCVState *env, int csrno)
  
  static RISCVException sscofpmf(CPURISCVState *env, int csrno)

  {
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  
  if (!cpu->cfg.ext_sscofpmf) {

  return RISCV_EXCP_ILLEGAL_INST;
@@ -321,8 +316,7 @@ static RISCVException umode32(CPURISCVState *env, int csrno)
  
  static RISCVException mstateen(CPURISCVState *env, int csrno)

  {
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  
  if (!cpu->cfg.ext_smstateen) {

  return RISCV_EXCP_ILLEGAL_INST;
@@ -333,8 +327,7 @@ static RISCVException mstateen(CPURISCVState *env, int 
csrno)
  
  static RISCVException hstateen_pred(CPURISCVState *env, int csrno, int base)

  {
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  
  if (!cpu->cfg.ext_smstateen) {

  return RISCV_EXCP_ILLEGAL_INST;
@@ -363,8 +356,7 @@ static RISCVException sstateen(CPURISCVState *env, int 
csrno)
  {
  bool virt = riscv_cpu_virt_enabled(env);
  int index = csrno - CSR_SSTATEEN0;
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  
  if (!cpu->cfg.ext_smstateen) {

  return RISCV_EXCP_ILLEGAL_INST;
@@ -918,8 +910,7 @@ static RISCVException read_timeh(CPURISCVState *env, int 
csrno,
  
  static RISCVException sstc(CPURISCVState *env, int csrno)

  {
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  bool hmode_check = false;
  
  if (!cpu->cfg.ext_sstc || !env->rdtime_fn) {

@@ -1152,8 +1143,7 @@ static RISCVException write_ignore(CPURISCVState *env, 
int csrno,
  static RISCVException read_mvendorid(CPURISCVState *env, int csrno,
   target_ulong *val)
  {
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  
  *val = cpu->cfg.mvendorid;

  return RISCV_EXCP_NONE;
@@ -1162,8 +1152,7 @@ static RISCVException read_mvendorid(CPURISCVState *env, 
int csrno,
  static RISCVException read_marchid(CPURISCVState *env, int csrno,
 target_ulong *val)
  {
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  
  *val = cpu->cfg.marchid;

  return RISCV_EXCP_NONE;
@@ -1172,8 +1161,7 @@ static RISCVException read_marchid(CPURISCVState *env, 
int csrno,
  static RISCVException read_mimpid(CPURISCVState *env, int csrno,
target_ulong *val)
  {
-CPUState *cs = env_cpu(env);
-RISCVCPU *cpu = RISCV_CPU(cs);
+RISCVCPU *cpu = env_archcpu(env);
  
  *val = cpu->cfg.mimpid;

  return RISCV_EXCP_NONE;

[PULL 00/22] qtest, s390x and misc patches

[Thomas Huth]

 Hi Peter!

The following changes since commit f670b3eec7f5d1ed8c4573ef244e7b8c6b32001b:

  Merge tag 'migration-20230213-pull-request' of 
https://gitlab.com/juan.quintela/qemu into staging (2023-02-13 11:54:05 +)

are available in the Git repository at:

  https://gitlab.com/thuth/qemu.git tags/pull-request-2023-02-14

for you to fetch changes up to b1d1d468cabfa800950e1ecb6006df619687c269:

  hw/s390x/event-facility: Replace DO_UPCAST(SCLPEvent) by SCLP_EVENT() 
(2023-02-14 09:11:27 +0100)


* Bump minimum Clang version to 10.0
* Improve the handling of the libdw library
* Deprecate --enable-gprof builds and remove them from CI
* Remove the deprecated "sga" device
* Some header #include clean-ups
* Make qtests more flexible with regards to missing devices
* Some small s390x-related fixes/improvements


Alex Bennée (1):
  build: deprecate --enable-gprof builds and remove from CI

Fabiano Rosas (12):
  tests/qtest: Skip PXE tests for missing devices
  tests/qtest: Do not run lsi53c895a test if device is not present
  tests/qtest: Add dependence on PCIE_PORT for virtio-net-failover.c
  tests/qtest: hd-geo-test: Check for missing devices
  test/qtest: Fix coding style in device-plug-test.c
  tests/qtest: Skip unplug tests that use missing devices
  tests/qtest: drive_del-test: Skip tests that require missing devices
  tests/qtest: Check for devices in bios-tables-test
  tests/qtest: Do not include hexloader-test if loader device is not present
  tests/qemu-iotests: Require virtio-scsi-pci
  tests/qtest: bios-tables-test: Skip if missing configs
  tests/qtest: Don't build virtio-serial-test.c if device not present

Ilya Leoshkevich (3):
  meson: Add missing libdw knobs
  meson: Disable libdw for static builds by default
  tests/tcg/s390x: Use -nostdlib for softmmu tests

Peter Maydell (1):
  tests/qtest/npcm7xx_pwm-test: Be less verbose unless V=2

Philippe Mathieu-Daudé (1):
  hw/s390x/event-facility: Replace DO_UPCAST(SCLPEvent) by SCLP_EVENT()

Thomas Huth (4):
  configure: Bump minimum Clang version to 10.0
  hw/misc/sga: Remove the deprecated "sga" device
  include/hw: Do not include "hw/registerfields.h" in headers that don't 
need it
  Do not include "qemu/error-report.h" in headers that do not need it

 MAINTAINERS |   1 -
 docs/about/deprecated.rst   |  23 ++
 docs/about/removed-features.rst |  10 +
 configure   |  25 +++
 meson.build |  19 +---
 include/hw/arm/allwinner-a10.h  |   1 -
 include/hw/arm/smmuv3.h |   1 -
 include/hw/char/ibex_uart.h |   1 -
 include/hw/ssi/ibex_spi_host.h  |   1 -
 include/qemu/vhost-user-server.h|   1 -
 include/ui/console.h|   1 -
 hw/char/ibex_uart.c |   1 +
 hw/display/vhost-user-gpu.c |   1 +
 hw/display/virtio-gpu-udmabuf.c |   1 +
 hw/display/virtio-gpu-virgl.c   |   1 +
 hw/misc/applesmc.c  |   1 +
 hw/misc/sga.c   |  71 --
 hw/s390x/event-facility.c   |   3 +-
 hw/ssi/ibex_spi_host.c  |   1 +
 tests/qtest/bios-tables-test.c  |  75 ++--
 tests/qtest/device-plug-test.c  |  41 +
 tests/qtest/drive_del-test.c|  65 +++
 tests/qtest/fuzz-lsi53c895a-test.c  |   4 ++
 tests/qtest/hd-geo-test.c   |  38 ++--
 tests/qtest/npcm7xx_pwm-test.c  |  27 +---
 tests/qtest/pxe-test.c  |   4 ++
 ui/console.c|   1 +
 ui/dbus-clipboard.c |   1 +
 ui/dbus-console.c   |   1 +
 ui/dbus-listener.c  |   1 +
 ui/dbus.c   |   1 +
 ui/egl-headless.c   |   1 +
 ui/gtk.c|   1 +
 ui/spice-app.c  |   1 +
 ui/spice-display.c  |   1 +
 ui/udmabuf.c|   1 +
 ui/vdagent.c|   1 +
 util/vhost-user-server.c|   1 +
 .gitlab-ci.d/buildtest.yml  |  19 ++--
 .gitmodules |   3 --
 hw/i386/Kconfig |   1 -
 hw/misc/Kconfig |   4 --
 hw/misc/meson.build |   1 -
 meson_options.txt   |   5 ++-
 pc-bios/README  |   6 ---
 pc-bios/meson.build |   1 -
 pc-bios/sgabios.bin | Bin 4096 -> 0 bytes
 roms/Makefile  

[PATCH 00/12] Q35 PCI host fixes and QOM cleanup

[Bernhard Beschow]

This series mostly cleans up QOM-related initialization code. It also performs
some modernization and fixing.

The first patch originates from "PC and ICH9 clanups" series [1] which has been
dropped in v3 in favor of another series [2]. Review comments in [2] suggest it
needs more work, so bring the patch back here.

Patch 2 fixes a clangd warning and patch 3 modernizes usage of the memory API.

Patches 4-9 clean up initialization code.

The last four patches also clean up initialization code with the last patch
doing the actual cleanup.

Based-on: <20230213162004.2797-1-shen...@gmail.com>
 "[PATCH v4 0/9] PC cleanups"

Testing done:
* `make check`
* `make check-avocado`
* `qemu-system-x86_64 -M q35 -m 2G -cdrom \
 manjaro-kde-21.3.2-220704-linux515.iso`

[1] https://lore.kernel.org/qemu-devel/20230131115326.12454-1-shen...@gmail.com/
[2] https://lore.kernel.org/qemu-devel/20230203180914.49112-1-phi...@linaro.org/

Bernhard Beschow (12):
  hw/i386/pc_q35: Resolve redundant q35_host variable
  hw/pci-host/q35: Fix contradicting .endianness assignment
  hw/pci-host/q35: Use memory_region_set_address() also for
tseg_blackhole
  hw/pci-host/q35: Initialize PCMachineState::bus in board code
  hw/pci-host/q35: Initialize "bypass-iommu" property from board code
  hw/pci-host/q35: Initialize properties just once
  hw/pci-host/q35: Initialize PCI hole boundaries just once
  hw/pci-host/q35: Turn PCI hole properties into class properties
  hw/pci-host/q35: Rename local variable to more idiomatic "phb"
  hw/pci-host/q35: Propagate to errp rather than doing error_fatal
  hw/pci-host/q35: Merge mch_realize() into q35_host_realize()
  hw/pci-host/q35: Move MemoryRegion pointers to host device

 include/hw/pci-host/q35.h |  17 +-
 hw/i386/pc_q35.c  |  33 ++--
 hw/pci-host/q35.c | 325 ++
 3 files changed, 178 insertions(+), 197 deletions(-)

-- 
2.39.1

Re: [PATCH v3 06/10] monitor: release the lock before calling close()

[Daniel P . Berrangé]

On Tue, Feb 14, 2023 at 05:36:32PM +0400, Marc-André Lureau wrote:
> Hi
> 
> On Tue, Feb 14, 2023 at 5:34 PM Markus Armbruster  wrote:
> >
> > marcandre.lur...@redhat.com writes:
> >
> > > From: Marc-André Lureau 
> > >
> > > As per comment, presumably to avoid syscall in critical section.
> > >
> > > Fixes: 0210c3b39bef08 ("monitor: Use LOCK_GUARD macros")
> > > Signed-off-by: Marc-André Lureau 
> > > ---
> > >  monitor/fds.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/monitor/fds.c b/monitor/fds.c
> > > index 26b39a0ce6..03c5e97c35 100644
> > > --- a/monitor/fds.c
> > > +++ b/monitor/fds.c
> > > @@ -80,7 +80,7 @@ void qmp_getfd(const char *fdname, Error **errp)
> > >  return;
> > >  }
> > >
> > > -QEMU_LOCK_GUARD(&cur_mon->mon_lock);
> > > +qemu_mutex_lock(&cur_mon->mon_lock);
> > >  QLIST_FOREACH(monfd, &cur_mon->fds, next) {
> > >  if (strcmp(monfd->name, fdname) != 0) {
> > >  continue;
> > > @@ -88,6 +88,7 @@ void qmp_getfd(const char *fdname, Error **errp)
> > >
> > >  tmp_fd = monfd->fd;
> > >  monfd->fd = fd;
> > > +qemu_mutex_unlock(&cur_mon->mon_lock);
> > >  /* Make sure close() is outside critical section */
> > >  close(tmp_fd);
> > >  return;
> > > @@ -98,6 +99,7 @@ void qmp_getfd(const char *fdname, Error **errp)
> > >  monfd->fd = fd;
> > >
> > >  QLIST_INSERT_HEAD(&cur_mon->fds, monfd, next);
> > > +qemu_mutex_unlock(&cur_mon->mon_lock);
> > >  }
> > >
> > >  void qmp_closefd(const char *fdname, Error **errp)
> >
> > This confused me.  I think I understand now, but let's double-check.
> >
> > You're reverting commit 0210c3b39bef08 for qmp_getfd() because it
> > extended the criticial section beyond the close(), invalidating the
> > comment.  Correct?
> 
> Correct
> 
> > Did it actually break anything?
> 
> Not that I know of (David admitted over IRC that this was not intended)

Conceptually the only risk here is that 'close()' blocks for a
prolonged period of time, which prevents another thread from
acquiring the mutex.

First, the chances of close() blocking are incredibly low for
socket FDs which have not yet been used to transmit data. It
would require a malicious mgmt app to pass an unexpected FD
type that could block but that's quite hard, and we consider
the QMP client be a trusted entity anyway.

As for another thread blocking on the mutex I'm not convinced
that'll happen either. The FD set is scoped to the current
monitor. Almost certainly the FD is going to be consumed by
a later QMP device-add/object-add command, in the same thread.
Processing of that later QMP command will be delayed regardless
of whether the close is inside or outside the critical section.

AFAICT keeping close() oujtside the critical section serves
no purpose and we could just stick with the lock guard and
delete the comment.

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

Re: [PATCH v2 2/4] cpus: Make {start,end}_exclusive() recursive

[Alex Bennée]

Ilya Leoshkevich  writes:

> Currently dying to one of the core_dump_signal()s deadlocks, because
> dump_core_and_abort() calls start_exclusive() two times: first via
> stop_all_tasks(), and then via preexit_cleanup() ->
> qemu_plugin_user_exit().
>
> There are a number of ways to solve this: resume after dumping core;
> check cpu_in_exclusive_context() in qemu_plugin_user_exit(); or make
> {start,end}_exclusive() recursive. Pick the last option, since it's
> the most straightforward one.
>
> Fixes: da91c1920242 ("linux-user: Clean up when exiting due to a signal")
> Signed-off-by: Ilya Leoshkevich 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

[PATCH] memory: Optimize replay of guest mapping

[Zhenzhong Duan]

On x86, there are two notifiers registered due to vtd-ir memory region
splitting the whole address space. During replay of the address space
for each notifier, the whole address space is scanned which is
unnecessory.

We only need to scan the space belong to notifier montiored space.

Signed-off-by: Zhenzhong Duan 
---
Tested only on x86 with a net card passed to guest, ping/ssh pass.

 hw/i386/intel_iommu.c | 2 +-
 softmmu/memory.c  | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
index 98a5c304a7d7..6b1de80e8573 100644
--- a/hw/i386/intel_iommu.c
+++ b/hw/i386/intel_iommu.c
@@ -3831,7 +3831,7 @@ static void vtd_iommu_replay(IOMMUMemoryRegion *iommu_mr, 
IOMMUNotifier *n)
 .domain_id = vtd_get_domain_id(s, &ce, vtd_as->pasid),
 };
 
-vtd_page_walk(s, &ce, 0, ~0ULL, &info, vtd_as->pasid);
+vtd_page_walk(s, &ce, n->start, n->end, &info, vtd_as->pasid);
 }
 } else {
 trace_vtd_replay_ce_invalid(bus_n, PCI_SLOT(vtd_as->devfn),
diff --git a/softmmu/memory.c b/softmmu/memory.c
index 9d64efca269b..f096716e6e78 100644
--- a/softmmu/memory.c
+++ b/softmmu/memory.c
@@ -1923,7 +1923,6 @@ uint64_t 
memory_region_iommu_get_min_page_size(IOMMUMemoryRegion *iommu_mr)
 
 void memory_region_iommu_replay(IOMMUMemoryRegion *iommu_mr, IOMMUNotifier *n)
 {
-MemoryRegion *mr = MEMORY_REGION(iommu_mr);
 IOMMUMemoryRegionClass *imrc = IOMMU_MEMORY_REGION_GET_CLASS(iommu_mr);
 hwaddr addr, granularity;
 IOMMUTLBEntry iotlb;
@@ -1936,7 +1935,7 @@ void memory_region_iommu_replay(IOMMUMemoryRegion 
*iommu_mr, IOMMUNotifier *n)
 
 granularity = memory_region_iommu_get_min_page_size(iommu_mr);
 
-for (addr = 0; addr < memory_region_size(mr); addr += granularity) {
+for (addr = n->start; addr < n->end; addr += granularity) {
 iotlb = imrc->translate(iommu_mr, addr, IOMMU_NONE, n->iommu_idx);
 if (iotlb.perm != IOMMU_NONE) {
 n->notify(n, &iotlb);
-- 
2.25.1

Re: [PATCH 2/4] sysemu/os-win32: fix setjmp/longjmp on windows-arm64

[Pierrick Bouvier]

On 2/14/23 08:11, Philippe Mathieu-Daudé wrote:

Hi Pierrick,

On 13/2/23 17:13, Pierrick Bouvier wrote:

Windows implementation of setjmp/longjmp is done in
C:/WINDOWS/system32/ucrtbase.dll. Alas, on arm64, it seems to *always*
perform stack unwinding, which crashes from generated code.

By using alternative implementation built in mingw, we avoid doing stack
unwinding and this fixes crash when calling longjmp.

Signed-off-by: Pierrick Bouvier 
---
   include/sysemu/os-win32.h | 18 --
   1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/sysemu/os-win32.h b/include/sysemu/os-win32.h
index 5b38c7bd04..84f62d0a17 100644
--- a/include/sysemu/os-win32.h
+++ b/include/sysemu/os-win32.h
@@ -51,14 +51,28 @@ typedef struct sockaddr_un {
   extern "C" {
   #endif
   
-#if defined(_WIN64)

+#if defined(__aarch64__)


Shouldn't we check for __MINGW64__?

 #if defined(__aarch64__) && defined(__MINGW64__)



I thought QEMU was only compiled using MinGW under Windows, (from CI, 
that's the case, [1], [2]), but maybe that's a wrong assumption.


[1] 
https://gitlab.com/qemu-project/qemu/-/blob/master/.gitlab-ci.d/windows.yml
[2] 
https://gitlab.com/qemu-project/qemu/-/blob/master/tests/docker/dockerfiles/fedora-win64-cross.docker


For windows-arm64, we need an alternative setjmp/longjmp implementation 
(__builtin_setjmp and __builtin_longjmp in clang are not available), 
thus, that makes MinGW mandatory, at least for this platform.


Would adding this be satisfying? Or better to add this check in Meson?
#ifndef __MINGW64__
#error MinGW must be available for this platform
#endif


+/* On windows-arm64, setjmp is available in only one variant, and longjmp 
always
+ * does stack unwinding. This crash with generated code.
+ * Thus, we use another implementation of setjmp (not windows one), coming from
+ * mingw, which never performs stack unwinding. */
+#undef setjmp
+#undef longjmp
+/* These functions are not declared in setjmp.h because __aarch64__ defines
+ * setjmp to _setjmpex instead. However, they are still defined in 
libmingwex.a,
+ * which gets linked automatically. */


So this is not stable. Better would be to check the symbols availability
at link-time via meson; see for example glusterfs_ftruncate_has_stat
which defines CONFIG_GLUSTERFS_FTRUNCATE_HAS_STAT.

A similar check could define CONFIG_MINGW64_HAS_SETJMP_LONGJMP.



You're right, it's not stable. Checking this using meson sounds a good 
approach.



+extern int __mingw_setjmp(jmp_buf);
+extern void __attribute__((noreturn)) __mingw_longjmp(jmp_buf, int);
+#define setjmp(env) __mingw_setjmp(env)
+#define longjmp(env, val) __mingw_longjmp(env, val)
+#elif defined(_WIN64)
   /* On w64, setjmp is implemented by _setjmp which needs a second parameter.
* If this parameter is NULL, longjump does no stack unwinding.
* That is what we need for QEMU. Passing the value of register rsp (default)
* lets longjmp try a stack unwinding which will crash with generated code. 
*/
   # undef setjmp
   # define setjmp(env) _setjmp(env, NULL)
-#endif
+#endif /* __aarch64__ */
   /* QEMU uses sigsetjmp()/siglongjmp() as the portable way to specify
* "longjmp and don't touch the signal masks". Since we know that the
* savemask parameter will always be zero we can safely define these


Regards,

Phil.

[PULL 01/10] net: Move the code to collect available NIC models to a separate function

[Jason Wang]

From: Thomas Huth 

The code that collects the available NIC models is not really specific
to PCI anymore and will be required in the next patch, too, so let's
move this into a new separate function in net.c instead.

Signed-off-by: Thomas Huth 
Signed-off-by: Jason Wang 
---
 hw/pci/pci.c  | 29 +
 include/net/net.h | 14 ++
 net/net.c | 34 ++
 3 files changed, 49 insertions(+), 28 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 208c16f..cc51f98 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1789,7 +1789,6 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, PCIBus 
*rootbus,
const char *default_devaddr)
 {
 const char *devaddr = nd->devaddr ? nd->devaddr : default_devaddr;
-GSList *list;
 GPtrArray *pci_nic_models;
 PCIBus *bus;
 PCIDevice *pci_dev;
@@ -1804,33 +1803,7 @@ PCIDevice *pci_nic_init_nofail(NICInfo *nd, PCIBus 
*rootbus,
 nd->model = g_strdup("virtio-net-pci");
 }
 
-list = object_class_get_list_sorted(TYPE_PCI_DEVICE, false);
-pci_nic_models = g_ptr_array_new();
-while (list) {
-DeviceClass *dc = OBJECT_CLASS_CHECK(DeviceClass, list->data,
- TYPE_DEVICE);
-GSList *next;
-if (test_bit(DEVICE_CATEGORY_NETWORK, dc->categories) &&
-dc->user_creatable) {
-const char *name = object_class_get_name(list->data);
-/*
- * A network device might also be something else than a NIC, see
- * e.g. the "rocker" device. Thus we have to look for the "netdev"
- * property, too. Unfortunately, some devices like virtio-net only
- * create this property during instance_init, so we have to create
- * a temporary instance here to be able to check it.
- */
-Object *obj = object_new_with_class(OBJECT_CLASS(dc));
-if (object_property_find(obj, "netdev")) {
-g_ptr_array_add(pci_nic_models, (gpointer)name);
-}
-object_unref(obj);
-}
-next = list->next;
-g_slist_free_1(list);
-list = next;
-}
-g_ptr_array_add(pci_nic_models, NULL);
+pci_nic_models = qemu_get_nic_models(TYPE_PCI_DEVICE);
 
 if (qemu_show_nic_models(nd->model, (const char **)pci_nic_models->pdata)) 
{
 exit(0);
diff --git a/include/net/net.h b/include/net/net.h
index fad589c..1d88621 100644
--- a/include/net/net.h
+++ b/include/net/net.h
@@ -203,6 +203,20 @@ void net_socket_rs_init(SocketReadState *rs,
 bool vnet_hdr);
 NetClientState *qemu_get_peer(NetClientState *nc, int queue_index);
 
+/**
+ * qemu_get_nic_models:
+ * @device_type: Defines which devices should be taken into consideration
+ *   (e.g. TYPE_DEVICE for all devices, or TYPE_PCI_DEVICE for PCI)
+ *
+ * Get an array of pointers to names of NIC devices that are available in
+ * the QEMU binary. The array is terminated with a NULL pointer entry.
+ * The caller is responsible for freeing the memory when it is not required
+ * anymore, e.g. with g_ptr_array_free(..., true).
+ *
+ * Returns: Pointer to the array that contains the pointers to the names.
+ */
+GPtrArray *qemu_get_nic_models(const char *device_type);
+
 /* NIC info */
 
 #define MAX_NICS 8
diff --git a/net/net.c b/net/net.c
index 251fc5a..476a4b7 100644
--- a/net/net.c
+++ b/net/net.c
@@ -899,6 +899,40 @@ static int nic_get_free_idx(void)
 return -1;
 }
 
+GPtrArray *qemu_get_nic_models(const char *device_type)
+{
+GPtrArray *nic_models = g_ptr_array_new();
+GSList *list = object_class_get_list_sorted(device_type, false);
+
+while (list) {
+DeviceClass *dc = OBJECT_CLASS_CHECK(DeviceClass, list->data,
+ TYPE_DEVICE);
+GSList *next;
+if (test_bit(DEVICE_CATEGORY_NETWORK, dc->categories) &&
+dc->user_creatable) {
+const char *name = object_class_get_name(list->data);
+/*
+ * A network device might also be something else than a NIC, see
+ * e.g. the "rocker" device. Thus we have to look for the "netdev"
+ * property, too. Unfortunately, some devices like virtio-net only
+ * create this property during instance_init, so we have to create
+ * a temporary instance here to be able to check it.
+ */
+Object *obj = object_new_with_class(OBJECT_CLASS(dc));
+if (object_property_find(obj, "netdev")) {
+g_ptr_array_add(nic_models, (gpointer)name);
+}
+object_unref(obj);
+}
+next = list->next;
+g_slist_free_1(list);
+list = next;
+}
+g_ptr_array_add(nic_models, NULL);
+
+return nic_models;
+}
+
 int qemu_show_nic_models(const char *arg, const char *const *models)
 {

[PATCH] block: temporarily hold the new AioContext of bs_top in bdrv_append()

[Stefano Garzarella]

bdrv_append() is called with bs_top AioContext held, but
bdrv_attach_child_noperm() could change the AioContext of bs_top.

bdrv_replace_node_noperm() calls bdrv_drained_begin() starting from
commit 2398747128 ("block: Don't poll in bdrv_replace_child_noperm()").
bdrv_drained_begin() can call BDRV_POLL_WHILE that assumes the new lock
is taken, so let's temporarily hold the new AioContext to prevent QEMU
from failing in BDRV_POLL_WHILE when it tries to release the wrong
AioContext.

Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2168209
Reported-by: Aihua Liang 
Signed-off-by: Stefano Garzarella 
---
I'm not sure whether to use the following Fixes tag. That commit added the
calls to bdrv_drained_begin() in bdrv_replace_node_noperm(), but maybe the
problem was pre-existing.

Fixes: 2398747128 ("block: Don't poll in bdrv_replace_child_noperm()")

Note: a local reproducer is attached in the BZ, it is based on the Aihua Liang
report and it hits the issue with a 20% ratio.
---
 block.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/block.c b/block.c
index aa9062f2c1..0e2bc11e0b 100644
--- a/block.c
+++ b/block.c
@@ -5266,6 +5266,8 @@ int bdrv_drop_filter(BlockDriverState *bs, Error **errp)
  * child.
  *
  * This function does not create any image files.
+ *
+ * The caller must hold the AioContext lock for @bs_top.
  */
 int bdrv_append(BlockDriverState *bs_new, BlockDriverState *bs_top,
 Error **errp)
@@ -5273,11 +5275,14 @@ int bdrv_append(BlockDriverState *bs_new, 
BlockDriverState *bs_top,
 int ret;
 BdrvChild *child;
 Transaction *tran = tran_new();
+AioContext *old_context, *new_context;
 
 GLOBAL_STATE_CODE();
 
 assert(!bs_new->backing);
 
+old_context = bdrv_get_aio_context(bs_top);
+
 child = bdrv_attach_child_noperm(bs_new, bs_top, "backing",
  &child_of_bds, bdrv_backing_role(bs_new),
  tran, errp);
@@ -5286,11 +5291,29 @@ int bdrv_append(BlockDriverState *bs_new, 
BlockDriverState *bs_top,
 goto out;
 }
 
+/*
+ * bdrv_attach_child_noperm could change the AioContext of bs_top.
+ * bdrv_replace_node_noperm calls bdrv_drained_begin, so let's temporarily
+ * hold the new AioContext, since bdrv_drained_begin calls BDRV_POLL_WHILE
+ * that assumes the new lock is taken.
+ */
+new_context = bdrv_get_aio_context(bs_top);
+
+if (old_context != new_context) {
+aio_context_release(old_context);
+aio_context_acquire(new_context);
+}
+
 ret = bdrv_replace_node_noperm(bs_top, bs_new, true, tran, errp);
 if (ret < 0) {
 goto out;
 }
 
+if (old_context != new_context) {
+aio_context_release(new_context);
+aio_context_acquire(old_context);
+}
+
 ret = bdrv_refresh_perms(bs_new, tran, errp);
 out:
 tran_finalize(tran, ret);
-- 
2.39.1

Re: [PATCH v4 14/16] qapi: deprecate "device" field of DEVICE_* events

[Vladimir Sementsov-Ogievskiy]

On 14.02.23 14:57, Markus Armbruster wrote:

Daniel P. Berrangé  writes:


On Tue, Feb 14, 2023 at 09:54:22AM +0100, Markus Armbruster wrote:

Daniel P. Berrangé  writes:


On Mon, Feb 13, 2023 at 05:01:01PM +0300, Vladimir Sementsov-Ogievskiy wrote:

The device field is redundant, because QOM path always include device
ID when this ID exist.


The flipside to that view is that applications configuring QEMU are
specifying the device ID for -device (CLI) / device_add (QMP) and
not the QOM path. IOW, the device ID is the more interesting field
than QOM path, so feels like the wrong one to be dropping.


QOM path is a reliable way to identify a device.  Device ID isn't:
devices need not have one.  Therefore, dropping the QOM path would be
wrong.


Is there any real benefit to dropping this ?


The device ID is a trap for the unwary: relying on it is fine until you
run into a scenario where you have to deal with devices lacking IDs.


When a mgmt app is configuring QEMU though, it does it exclusively
with device ID values. If I add a device "-device foo,id=dev0",
and then later hot-unplug it "device_del dev0", it is pretty
reasonable to then expect that the DEVICE_DELETED even will then
include the ID value the app has been using elsewhere.


The management application would be well advised to use QOM paths with
device_del, because only that works even for devices created by default
(which have no ID), and devices the user created behind the management
application's back.


If the mgmt app is using IDs everywhere when dealing with a device,
then trap effectively doesn't exist for their usage scenario.




What if we go one step further and deprecate "id" in device_add / device_del as 
well?

So that user will have to use qom path also in device_add. We may return an error if user 
don't specify "machine/peripheral/" prefix.. Or allow to create device with any 
QOM path?

--
Best regards,
Vladimir

Re: [RFC 06/52] hw/cpu: Introduce hybrid CPU topology

[wangyanan (Y)]

在 2023/2/14 18:16, Zhao Liu 写道:

On Mon, Feb 13, 2023 at 09:18:05PM +0800, wangyanan (Y) wrote:

Date: Mon, 13 Feb 2023 21:18:05 +0800
From: "wangyanan (Y)" 
Subject: Re: [RFC 06/52] hw/cpu: Introduce hybrid CPU topology

Hi Zhao,

在 2023/2/13 17:49, Zhao Liu 写道:

From: Zhao Liu 

For smp systems, the parts in one topology level are the same. But now
there are more and more systems with hybrid architectures. Different
parts of the same topology level may have differences. For example,
Intel's Alder Lake series CPU has two types of cores, so the CPU
topology is no longer symmetrical.

The hybrid topology is compatible with the smp topology type, that is,
different parts on the same level of the hybrid topology can set to be
the same, but the hybrid topology will introduce more complexity (need
to allocate more memory, organized with array or linked-list), so the
original smp topology support is retained while introducing the hybrid
topology, and the hybrid topology is only built when the hybrid is
explicitly required.

Therefore, we introduce the definition support of hybrid cpu topology
here. At the same time, in order to unify with the original smp, we
introduce a new cpu topology structure that can support smp topology
or hybrid topology. This structure will replace the CpuTopology type (in
include/hw/boards.h) used by MachineState.smp.

As for now, we only support two hybrid topology levels: core and
cluster.

Signed-off-by: Zhao Liu 
---
   MAINTAINERS   |   1 +
   include/hw/cpu/cpu-topology.h | 117 ++
   qapi/machine.json |  12 
   3 files changed, 130 insertions(+)
   create mode 100644 include/hw/cpu/cpu-topology.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 58794885ced3..918a9418d98e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1742,6 +1742,7 @@ F: qapi/machine-target.json
   F: include/hw/boards.h
   F: include/hw/core/cpu.h
   F: include/hw/cpu/cluster.h
+F: include/hw/cpu/cpu-topology.h

Should't it be in include/hw/core/* directory？

Yes, I'll move it to the correct place.


   F: include/sysemu/numa.h
   F: tests/unit/test-smp-parse.c
   T: git https://gitlab.com/ehabkost/qemu.git machine-next
diff --git a/include/hw/cpu/cpu-topology.h b/include/hw/cpu/cpu-topology.h
new file mode 100644
index ..8268ea3a8569
--- /dev/null
+++ b/include/hw/cpu/cpu-topology.h
@@ -0,0 +1,117 @@
+/*
+ * CPU topology defination for Machine core
+ *
+ * Copyright (c) 2023 Intel Corporation
+ * Author: Zhao Liu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License,
+ * or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+
+#ifndef CPU_TOPOLOGY_H
+#define CPU_TOPOLOGY_H
+
+#include "qemu/queue.h"
+
+/**
+ * SmpCpuTopology - smp cpu topology defination.
+ *
+ * For smp system, the parts in one topology level are the same.
+ *
+ * @sockets: the number of sockets on the machine
+ * @dies: the number of dies in one socket
+ * @clusters: the number of clusters in one die
+ * @cores: the number of cores in one cluster
+ * @threads: the number of threads in one core
+ */
+typedef struct SmpCpuTopology {
+unsigned int sockets;
+unsigned int dies;
+unsigned int clusters;
+unsigned int cores;
+unsigned int threads;
+} SmpCpuTopology;
+
+/**
+ * HybridCore - hybrid core topology defination:
+ * @threads: the number of threads in one core.
+ */
+typedef struct HybridCore {
+unsigned int threads;
+} HybridCore;
+
+/**
+ * HybridCluster - hybrid cluster topology defination:
+ * @cores: the number of cores in current cluster.
+ * @core_list: the array includes all the cores that belong to current
+ * cluster.
+ */
+typedef struct HybridCluster {
+unsigned int cores;
+HybridCore *core_list;
+} HybridCluster;
+
+/**
+ * HybridCpuTopology - hybrid cpu topology defination.
+ *
+ * At present we only support two heterogeneous topology levels: core
+ * and cluster. For heterogeneous levels, we need additional structs
+ * to define their custom internal topology. So here we defines
+ * symmetric topology levels, and use a list to point to heterogeneous
+ * levels.
+ *
+ * @sockets: the number of sockets on the machine. All sockets are the
+ *   same.
+ * @dies: the number of dies in one socket. All dies are the same.
+ * @clusters: the number of clusters in one die. Cluster may be
+ *different. This field indicates the length of
+ *cluster

[PATCH 01/12] hw/i386/pc_q35: Resolve redundant q35_host variable

[Bernhard Beschow]

The variable is redundant to "phb" and is never used by its real type.

Signed-off-by: Bernhard Beschow 
Reviewed-by: Thomas Huth 
---
 hw/i386/pc_q35.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index a5ffb77ed8..1ce9b16c53 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -118,8 +118,7 @@ static void pc_q35_init(MachineState *machine)
 PCMachineState *pcms = PC_MACHINE(machine);
 PCMachineClass *pcmc = PC_MACHINE_GET_CLASS(pcms);
 X86MachineState *x86ms = X86_MACHINE(machine);
-Q35PCIHost *q35_host;
-PCIHostState *phb;
+Object *phb;
 PCIBus *host_bus;
 PCIDevice *lpc;
 DeviceState *lpc_dev;
@@ -206,10 +205,10 @@ static void pc_q35_init(MachineState *machine)
 }
 
 /* create pci host bus */
-q35_host = Q35_HOST_DEVICE(qdev_new(TYPE_Q35_HOST_DEVICE));
+phb = OBJECT(qdev_new(TYPE_Q35_HOST_DEVICE));
 
 if (pcmc->pci_enabled) {
-pci_hole64_size = object_property_get_uint(OBJECT(q35_host),
+pci_hole64_size = object_property_get_uint(phb,

PCI_HOST_PROP_PCI_HOLE64_SIZE,
&error_abort);
 }
@@ -217,25 +216,25 @@ static void pc_q35_init(MachineState *machine)
 /* allocate ram and load rom/bios */
 pc_memory_init(pcms, system_memory, rom_memory, pci_hole64_size);
 
-object_property_add_child(OBJECT(machine), "q35", OBJECT(q35_host));
-object_property_set_link(OBJECT(q35_host), MCH_HOST_PROP_RAM_MEM,
+object_property_add_child(OBJECT(machine), "q35", phb);
+object_property_set_link(phb, MCH_HOST_PROP_RAM_MEM,
  OBJECT(machine->ram), NULL);
-object_property_set_link(OBJECT(q35_host), MCH_HOST_PROP_SMRAM_MEM,
+object_property_set_link(phb, MCH_HOST_PROP_SMRAM_MEM,
  OBJECT(&x86ms->smram), NULL);
-object_property_set_link(OBJECT(q35_host), MCH_HOST_PROP_PCI_MEM,
+object_property_set_link(phb, MCH_HOST_PROP_PCI_MEM,
  OBJECT(pci_memory), NULL);
-object_property_set_link(OBJECT(q35_host), MCH_HOST_PROP_SYSTEM_MEM,
+object_property_set_link(phb, MCH_HOST_PROP_SYSTEM_MEM,
  OBJECT(system_memory), NULL);
-object_property_set_link(OBJECT(q35_host), MCH_HOST_PROP_IO_MEM,
+object_property_set_link(phb, MCH_HOST_PROP_IO_MEM,
  OBJECT(system_io), NULL);
-object_property_set_int(OBJECT(q35_host), PCI_HOST_BELOW_4G_MEM_SIZE,
+object_property_set_int(phb, PCI_HOST_BELOW_4G_MEM_SIZE,
 x86ms->below_4g_mem_size, NULL);
-object_property_set_int(OBJECT(q35_host), PCI_HOST_ABOVE_4G_MEM_SIZE,
+object_property_set_int(phb, PCI_HOST_ABOVE_4G_MEM_SIZE,
 x86ms->above_4g_mem_size, NULL);
+
 /* pci */
-sysbus_realize_and_unref(SYS_BUS_DEVICE(q35_host), &error_fatal);
-phb = PCI_HOST_BRIDGE(q35_host);
-host_bus = phb->bus;
+sysbus_realize_and_unref(SYS_BUS_DEVICE(phb), &error_fatal);
+host_bus = PCI_BUS(qdev_get_child_bus(DEVICE(phb), "pcie.0"));
 /* create ISA bus */
 lpc = pci_create_simple_multifunction(host_bus, PCI_DEVFN(ICH9_LPC_DEV,
   ICH9_LPC_FUNC), true,
-- 
2.39.1

[qemu-web PATCH] add missing tag

[Paolo Bonzini]

The homepage goes straight from h1 to h3, add the missing tag for use in screen 
readers.

Signed-off-by: Paolo Bonzini 
---
 assets/css/style.css | 12 
 index.html   |  3 +++
 2 files changed, 15 insertions(+)

diff --git a/assets/css/style.css b/assets/css/style.css
index 779b111..2705787 100644
--- a/assets/css/style.css
+++ b/assets/css/style.css
@@ -44,6 +44,18 @@
color: #802400;
}
 
+.visuallyhidden
+   {
+   border: 0;
+   clip: rect(0 0 0 0);
+   height: 1px;
+   margin: -1px;
+   overflow: hidden;
+   padding: 0;
+   position: absolute;
+   width: 1px;
+   }
+
pre,code,samp,tt
{
font-family: 'Roboto Mono', monospace;
diff --git a/index.html b/index.html
index d72750c..676c379 100644
--- a/index.html
+++ b/index.html
@@ -14,6 +14,9 @@ colorbox: True

 
 
+   
+   Features
+   



-- 
2.39.1

Re: [PATCH 11/18] target/riscv: gdbstub: Drop the vector CSRs in riscv-vector.xml

[weiwei]

On 2023/2/14 02:02, Bin Meng wrote:

It's worth noting that the vector CSR predicate() has a similar
run-time check logic to the FPU CSR. With the previous patch our
gdbstub can correctly report these vector CSRs via the CSR xml.

Commit 719d3561b269 ("target/riscv: gdb: support vector registers for rv64 & 
rv32")
inserted these vector CSRs in an ad-hoc, non-standard way in the
riscv-vector.xml. Now we can treat these CSRs no different from
other CSRs.

Signed-off-by: Bin Meng 

Reviewed-by: Weiwei Li 

Regards,
Weiwei Li

---

  target/riscv/gdbstub.c | 75 --
  1 file changed, 75 deletions(-)

diff --git a/target/riscv/gdbstub.c b/target/riscv/gdbstub.c
index ef52f41460..6048541606 100644
--- a/target/riscv/gdbstub.c
+++ b/target/riscv/gdbstub.c
@@ -127,40 +127,6 @@ static int riscv_gdb_set_fpu(CPURISCVState *env, uint8_t 
*mem_buf, int n)
  return 0;
  }
  
-/*

- * Convert register index number passed by GDB to the correspond
- * vector CSR number. Vector CSRs are defined after vector registers
- * in dynamic generated riscv-vector.xml, thus the starting register index
- * of vector CSRs is 32.
- * Return 0 if register index number is out of range.
- */
-static int riscv_gdb_vector_csrno(int num_regs)
-{
-/*
- * The order of vector CSRs in the switch case
- * should match with the order defined in csr_ops[].
- */
-switch (num_regs) {
-case 32:
-return CSR_VSTART;
-case 33:
-return CSR_VXSAT;
-case 34:
-return CSR_VXRM;
-case 35:
-return CSR_VCSR;
-case 36:
-return CSR_VL;
-case 37:
-return CSR_VTYPE;
-case 38:
-return CSR_VLENB;
-default:
-/* Unknown register. */
-return 0;
-}
-}
-
  static int riscv_gdb_get_vector(CPURISCVState *env, GByteArray *buf, int n)
  {
  uint16_t vlenb = env_archcpu(env)->cfg.vlen >> 3;
@@ -174,19 +140,6 @@ static int riscv_gdb_get_vector(CPURISCVState *env, 
GByteArray *buf, int n)
  return cnt;
  }
  
-int csrno = riscv_gdb_vector_csrno(n);

-
-if (!csrno) {
-return 0;
-}
-
-target_ulong val = 0;
-int result = riscv_csrrw_debug(env, csrno, &val, 0, 0);
-
-if (result == RISCV_EXCP_NONE) {
-return gdb_get_regl(buf, val);
-}
-
  return 0;
  }
  
@@ -201,19 +154,6 @@ static int riscv_gdb_set_vector(CPURISCVState *env, uint8_t *mem_buf, int n)

  return vlenb;
  }
  
-int csrno = riscv_gdb_vector_csrno(n);

-
-if (!csrno) {
-return 0;
-}
-
-target_ulong val = ldtul_p(mem_buf);
-int result = riscv_csrrw_debug(env, csrno, NULL, val, -1);
-
-if (result == RISCV_EXCP_NONE) {
-return sizeof(target_ulong);
-}
-
  return 0;
  }
  
@@ -361,21 +301,6 @@ static int ricsv_gen_dynamic_vector_xml(CPUState *cs, int base_reg)

  num_regs++;
  }
  
-/* Define vector CSRs */

-const char *vector_csrs[7] = {
-"vstart", "vxsat", "vxrm", "vcsr",
-"vl", "vtype", "vlenb"
-};
-
-for (i = 0; i < 7; i++) {
-g_string_append_printf(s,
-   "",
-   vector_csrs[i], TARGET_LONG_BITS, base_reg++);
-num_regs++;
-}
-
  g_string_append_printf(s, "");
  
  cpu->dyn_vreg_xml = g_string_free(s, false);

Re: [Patch 11/14] target/riscv: Add support for Zvfh/zvfhmin extensions

[Daniel Henrique Barboza]

On 2/14/23 05:38, Weiwei Li wrote:

Zvfh supports vector float point instuctions with SEW = 16


s/instuctions/instructions


and supports conversions between 8-bit integers adn binary16 values


s/adn/and



Zvfhmin supports vfwcvt.f.f.v and vfncvt.f.f.w instructions

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---



Reviewed-by: Daniel Henrique Barboza 



  target/riscv/insn_trans/trans_rvv.c.inc | 31 +++--
  1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/target/riscv/insn_trans/trans_rvv.c.inc 
b/target/riscv/insn_trans/trans_rvv.c.inc
index 9053759546..9b2c5c9ac0 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -40,6 +40,7 @@ static bool require_rvf(DisasContext *s)
  
  switch (s->sew) {

  case MO_16:
+return s->cfg_ptr->ext_zvfh;
  case MO_32:
  return s->cfg_ptr->ext_zve32f;
  case MO_64:
@@ -57,6 +58,25 @@ static bool require_scale_rvf(DisasContext *s)
  
  switch (s->sew) {

  case MO_8:
+return s->cfg_ptr->ext_zvfh;
+case MO_16:
+return s->cfg_ptr->ext_zve32f;
+case MO_32:
+return s->cfg_ptr->ext_zve64d;
+default:
+return false;
+}
+}
+
+static bool require_scale_rvfmin(DisasContext *s)
+{
+if (s->mstatus_fs == 0) {
+return false;
+}
+
+switch (s->sew) {
+case MO_8:
+return s->cfg_ptr->ext_zvfhmin;
  case MO_16:
  return s->cfg_ptr->ext_zve32f;
  case MO_32:
@@ -2798,7 +2818,7 @@ static bool opxfv_widen_check(DisasContext *s, arg_rmr *a)
  static bool opffv_widen_check(DisasContext *s, arg_rmr *a)
  {
  return opfv_widen_check(s, a) &&
-   require_scale_rvf(s) &&
+   require_scale_rvfmin(s) &&
 (s->sew != MO_8);
  }
  
@@ -2909,6 +2929,13 @@ static bool opfxv_narrow_check(DisasContext *s, arg_rmr *a)

  }
  
  static bool opffv_narrow_check(DisasContext *s, arg_rmr *a)

+{
+return opfv_narrow_check(s, a) &&
+   require_scale_rvfmin(s) &&
+   (s->sew != MO_8);
+}
+
+static bool opffv_rod_narrow_check(DisasContext *s, arg_rmr *a)
  {
  return opfv_narrow_check(s, a) &&
 require_scale_rvf(s) &&
@@ -2952,7 +2979,7 @@ GEN_OPFV_NARROW_TRANS(vfncvt_f_x_w, opfxv_narrow_check, 
vfncvt_f_x_w,
  GEN_OPFV_NARROW_TRANS(vfncvt_f_f_w, opffv_narrow_check, vfncvt_f_f_w,
RISCV_FRM_DYN)
  /* Reuse the helper function from vfncvt.f.f.w */
-GEN_OPFV_NARROW_TRANS(vfncvt_rod_f_f_w, opffv_narrow_check, vfncvt_f_f_w,
+GEN_OPFV_NARROW_TRANS(vfncvt_rod_f_f_w, opffv_rod_narrow_check, vfncvt_f_f_w,
RISCV_FRM_ROD)
  
  static bool opxfv_narrow_check(DisasContext *s, arg_rmr *a)

Re: [Patch 02/14] target/riscv: Fix the relationship between Zhinxmin and Zhinx

[Daniel Henrique Barboza]

On 2/14/23 05:38, Weiwei Li wrote:

Just like zfh and zfhmin, Zhinxmin is part of Zhinx so Zhinxmin
will be enabled when Zhinx is enabled

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---


Reviewed-by: Daniel Henrique Barboza 


  target/riscv/cpu.c | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index eb0cd12a6a..9a89bea2a3 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -754,8 +754,11 @@ static void riscv_cpu_validate_set_extensions(RISCVCPU 
*cpu, Error **errp)
  }
  
  /* Set the ISA extensions, checks should have happened above */

-if (cpu->cfg.ext_zdinx || cpu->cfg.ext_zhinx ||
-cpu->cfg.ext_zhinxmin) {
+if (cpu->cfg.ext_zhinx) {
+cpu->cfg.ext_zhinxmin = true;
+}
+
+if (cpu->cfg.ext_zdinx || cpu->cfg.ext_zhinxmin) {
  cpu->cfg.ext_zfinx = true;
  }
  

Re: [PATCH] virtio-net: clear guest_announce feature if no cvq backend

[Lei Yang]

QE uses the sim_vdpa device to test this patch and add "ctrl_vq=off"
in the qemu command line. Guest can find this device, there are no any
error messages in guest dmesg, and can migrate successfully.

Tested-by: Lei Yang 

Eugenio Perez Martin  于2023年2月14日周二 14:53写道：
>
> On Tue, Jan 24, 2023 at 5:32 PM Eugenio Pérez  wrote:
> >
> > Since GUEST_ANNOUNCE is emulated the feature bit could be set without
> > backend support.  This happens in the vDPA case.
> >
> > However, backend vDPA parent may not have CVQ support.  This causes an
> > incoherent feature set, and the driver may refuse to start.  This
> > happens in virtio-net Linux driver.
> >
> > This may be solved differently in the future.  Qemu is able to emulate a
> > CVQ just for guest_announce purposes, helping guest to notify the new
> > location with vDPA devices that does not support it.  However, this is
> > left as a TODO as it is way more complex to backport.
> >
> > Tested with vdpa_net_sim, toggling manually VIRTIO_NET_F_CTRL_VQ in the
> > driver and migrating it with x-svq=on.
> >
>
> Friendly ping about this patch, as it fell through the cracks if I'm not 
> wrong.
>
> Thanks!
>
> > Fixes: 980003debddd ("vdpa: do not handle VIRTIO_NET_F_GUEST_ANNOUNCE in 
> > vhost-vdpa")
> > Reported-by: Dawar, Gautam 
> > Signed-off-by: Eugenio Pérez 
> > ---
> >  hw/net/virtio-net.c | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> > index 3ae909041a..09d5c7a664 100644
> > --- a/hw/net/virtio-net.c
> > +++ b/hw/net/virtio-net.c
> > @@ -820,6 +820,21 @@ static uint64_t virtio_net_get_features(VirtIODevice 
> > *vdev, uint64_t features,
> >  features |= (1ULL << VIRTIO_NET_F_MTU);
> >  }
> >
> > +/*
> > + * Since GUEST_ANNOUNCE is emulated the feature bit could be set 
> > without
> > + * enabled. This happens in the vDPA case.
> > + *
> > + * Make sure the feature set is not incoherent, as the driver could 
> > refuse
> > + * to start.
> > + *
> > + * TODO: QEMU is able to emulate a CVQ just for guest_announce 
> > purposes,
> > + * helping guest to notify the new location with vDPA devices that 
> > does not
> > + * support it.
> > + */
> > +if (!virtio_has_feature(vdev->backend_features, VIRTIO_NET_F_CTRL_VQ)) 
> > {
> > +virtio_clear_feature(&features, VIRTIO_NET_F_GUEST_ANNOUNCE);
> > +}
> > +
> >  return features;
> >  }
> >
> > --
> > 2.31.1
> >
> >
>

Re: [PATCH v2 6/7] CI: Stop building docs on centos8

[Daniel P . Berrangé]

On Tue, Feb 14, 2023 at 08:40:20AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé  writes:
> 
> [...]
> 
> > We don't have to drop python 3.6. It is a choice because
> > of a desire to be able to use some shiny new python
> > features without caring about back compat.
> 
> I read this on Friday, and decided to let it sit until after the
> weekend.  Well, it's now Tuesday, and to be frank, it's still as
> offensively flippant as it was on Friday.  It shows either ignorance of
> or cavalier disregard for the sheer amount of work some of us have had
> to put into keeping old versions of Python viable.
> 
> The latter would be quite unlike you, so it must be the former.

I'm sorry, I don't mean it to be offensive. I'm genuinely not seeing
from the descriptions in the series what the functional benefits are
from dropping 3.6.

> John has sunk *man-months* into keeping old versions of Python viable.
> I've put in a lot less myself, but still enough to be painfully aware of
> it.  I figure Cleber and Beraldo are somewhere in between
> 
> Insinuating John's proposal is motivated by "a desire to be able to use
> some shiny new python features without caring about back compat"
> disrespects all this work.

I'm writing my comments based on what is described in the cover letter
as the motivations for the change:

[quote]
The motivation for this series is that Python 3.6 was EOL at the end of
2021; upstream tools are beginning to drop support for it, including
setuptools, pylint, mypy, etc. As time goes by, it becomes more
difficult to support and test against the full range of Python versions
that QEMU supports. The closer we get to Python 3.12, the harder it will
be to cover that full spread of versions.
[/quote]

this is all about new/eol versions of software upstream, and I don't
think that's a justification. QEMU explicitly aims to use distro provided
versions and upstream EOL status is not relevant in that context. Even
if using "pip" to install it is possible to limit yourself to upstream
releases which still support 3.6.

There is the separate issue of Meson dropping python 3.6 which motivates
Paolo's series. Again though, we don't have to increase our minimum meson
version, because meson is working today. It is our choice to to increase
it to use latest available meson features. At some point we can decide
what we have is good enough and we don't have to keep chasing the latest
features. Maybe we're not there yet, but we should think about when that
would be.

[quote]
The qemu.qmp library and the avocado testing framework both have
motivations for dropping 3.6 support, but are committed to not doing so
until QEMU drops support.
[/quote]

I suspect that this is more of a driver for the drop of 3.6, but I
don't see any details.

IOW overall justification come across as wanting to use new features,
and follow upstream EOL, without any real detail of what we're going
to gain from a functional POV.

> We should have a sober discussion on which versions of Python to work
> with, and the tradeoffs involved.  But before I engage in that, I insist
> on resetting the frame: no, this is not about shiny, new Python
> features.  It is about stopping the bleeding.  It is about reducing what
> feels more and more like bullshit work to me, so we can actually
> accomplish stuff that matters.

Every applications developer chooses an arbitrary cut off points for
minimum software versions, depending on their particular needs. With
our support policy we tried to express a reasonable tradeoff between
keeping back compat, and being able to adopt new features.

Obviously that tradeoff is not currently looking acceptable on the
python side, but it is not clear why that is ?

Can someone simply explain what we wil see as the benefit from dropping
3.6 / adopting 3.7 as the baseline ? 

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

[PULL 07/10] vmnet: stop recieving events when VM is stopped

[Jason Wang]

From: Joelle van Dyne 

When the VM is stopped using the HMP command "stop", soon the handler will
stop reading from the vmnet interface. This causes a flood of
`VMNET_INTERFACE_PACKETS_AVAILABLE` events to arrive and puts the host CPU
at 100%. We fix this by removing the event handler from vmnet when the VM
is no longer in a running state and restore it when we return to a running
state.

Signed-off-by: Joelle van Dyne 
Signed-off-by: Jason Wang 
---
 net/vmnet-common.m | 48 +++-
 net/vmnet_int.h|  2 ++
 2 files changed, 37 insertions(+), 13 deletions(-)

diff --git a/net/vmnet-common.m b/net/vmnet-common.m
index 2cb60b9..2958283 100644
--- a/net/vmnet-common.m
+++ b/net/vmnet-common.m
@@ -17,6 +17,7 @@
 #include "clients.h"
 #include "qemu/error-report.h"
 #include "qapi/error.h"
+#include "sysemu/runstate.h"
 
 #include 
 #include 
@@ -242,6 +243,35 @@ static void vmnet_bufs_init(VmnetState *s)
 }
 }
 
+/**
+ * Called on state change to un-register/re-register handlers
+ */
+static void vmnet_vm_state_change_cb(void *opaque, bool running, RunState 
state)
+{
+VmnetState *s = opaque;
+
+if (running) {
+vmnet_interface_set_event_callback(
+s->vmnet_if,
+VMNET_INTERFACE_PACKETS_AVAILABLE,
+s->if_queue,
+^(interface_event_t event_id, xpc_object_t event) {
+assert(event_id == VMNET_INTERFACE_PACKETS_AVAILABLE);
+/*
+ * This function is being called from a non qemu thread, so
+ * we only schedule a BH, and do the rest of the io completion
+ * handling from vmnet_send_bh() which runs in a qemu context.
+ */
+qemu_bh_schedule(s->send_bh);
+});
+} else {
+vmnet_interface_set_event_callback(
+s->vmnet_if,
+VMNET_INTERFACE_PACKETS_AVAILABLE,
+NULL,
+NULL);
+}
+}
 
 int vmnet_if_create(NetClientState *nc,
 xpc_object_t if_desc,
@@ -329,19 +359,9 @@ int vmnet_if_create(NetClientState *nc,
 s->packets_send_current_pos = 0;
 s->packets_send_end_pos = 0;
 
-vmnet_interface_set_event_callback(
-s->vmnet_if,
-VMNET_INTERFACE_PACKETS_AVAILABLE,
-s->if_queue,
-^(interface_event_t event_id, xpc_object_t event) {
-assert(event_id == VMNET_INTERFACE_PACKETS_AVAILABLE);
-/*
- * This function is being called from a non qemu thread, so
- * we only schedule a BH, and do the rest of the io completion
- * handling from vmnet_send_bh() which runs in a qemu context.
- */
-qemu_bh_schedule(s->send_bh);
-});
+vmnet_vm_state_change_cb(s, 1, RUN_STATE_RUNNING);
+
+s->change = qemu_add_vm_change_state_handler(vmnet_vm_state_change_cb, s);
 
 return 0;
 }
@@ -356,6 +376,8 @@ void vmnet_cleanup_common(NetClientState *nc)
 return;
 }
 
+vmnet_vm_state_change_cb(s, 0, RUN_STATE_SHUTDOWN);
+qemu_del_vm_change_state_handler(s->change);
 if_stopped_sem = dispatch_semaphore_create(0);
 vmnet_stop_interface(
 s->vmnet_if,
diff --git a/net/vmnet_int.h b/net/vmnet_int.h
index d0b9059..a8a033d 100644
--- a/net/vmnet_int.h
+++ b/net/vmnet_int.h
@@ -45,6 +45,8 @@ typedef struct VmnetState {
 int packets_send_end_pos;
 
 struct iovec iov_buf[VMNET_PACKETS_LIMIT];
+
+VMChangeStateEntry *change;
 } VmnetState;
 
 const char *vmnet_status_map_str(vmnet_return_t status);
-- 
2.7.4

Re: [Patch 01/14] target/riscv: Fix the relationship between Zfhmin and Zfh

[Daniel Henrique Barboza]

On 2/14/23 05:38, Weiwei Li wrote:

Zfhmin is part of Zfh, so Zfhmin will be enabled when Zfh is enabled

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---


Reviewed-by: Daniel Henrique Barboza 


  target/riscv/cpu.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 0dd2f0c753..eb0cd12a6a 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -729,7 +729,11 @@ static void riscv_cpu_validate_set_extensions(RISCVCPU 
*cpu, Error **errp)
  return;
  }
  
-if ((cpu->cfg.ext_zfh || cpu->cfg.ext_zfhmin) && !cpu->cfg.ext_f) {

+if (cpu->cfg.ext_zfh) {
+cpu->cfg.ext_zfhmin = true;
+}
+
+if (cpu->cfg.ext_zfhmin && !cpu->cfg.ext_f) {
  error_setg(errp, "Zfh/Zfhmin extensions require F extension");
  return;
  }

[Patch 01/14] target/riscv: Fix the relationship between Zfhmin and Zfh

[Weiwei Li]

Zfhmin is part of Zfh, so Zfhmin will be enabled when Zfh is enabled

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/cpu.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 0dd2f0c753..eb0cd12a6a 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -729,7 +729,11 @@ static void riscv_cpu_validate_set_extensions(RISCVCPU 
*cpu, Error **errp)
 return;
 }
 
-if ((cpu->cfg.ext_zfh || cpu->cfg.ext_zfhmin) && !cpu->cfg.ext_f) {
+if (cpu->cfg.ext_zfh) {
+cpu->cfg.ext_zfhmin = true;
+}
+
+if (cpu->cfg.ext_zfhmin && !cpu->cfg.ext_f) {
 error_setg(errp, "Zfh/Zfhmin extensions require F extension");
 return;
 }
-- 
2.25.1

Re: [PATCH 06/18] target/riscv: Use 'bool' type for read_only

[weiwei]

On 2023/2/14 02:02, Bin Meng wrote:

The read_only variable is currently declared as an 'int', but it
should really be a 'bool'.

Signed-off-by: Bin Meng 

Reviewed-by: Weiwei Li 

Regards,
Weiwei Li

---

  target/riscv/csr.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index cc74819759..8bbc75cbfa 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -3778,7 +3778,7 @@ static inline RISCVException 
riscv_csrrw_check(CPURISCVState *env,
 RISCVCPU *cpu)
  {
  /* check privileges and return RISCV_EXCP_ILLEGAL_INST if check fails */
-int read_only = get_field(csrno, 0xC00) == 3;
+bool read_only = get_field(csrno, 0xC00) == 3;
  int csr_min_priv = csr_ops[csrno].min_priv_ver;
  
  /* ensure the CSR extension is enabled. */

[PATCH v2 01/12] bsd-user: Don't truncate the return value from freebsd_syscall

[Warner Losh]

From: Doug Rabson 

System call return values on FreeBSD are in a register (which is spelled
abi_long in qemu). This was being assigned into an int variable which
causes problems for 64bit targets.

Resolves: https://github.com/qemu-bsd-user/qemu-bsd-user/issues/40
Signed-off-by: Doug Rabson 
Reviewed-by: Warner Losh 
[ Edited commit message for upstreaming into qemu-project ]
Signed-off-by: Warner Losh 
Reviewed-by: Richard Henderson 
---
 bsd-user/freebsd/os-syscall.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsd-user/freebsd/os-syscall.c b/bsd-user/freebsd/os-syscall.c
index 57996cad8ae..b4a663fc021 100644
--- a/bsd-user/freebsd/os-syscall.c
+++ b/bsd-user/freebsd/os-syscall.c
@@ -512,7 +512,7 @@ abi_long do_freebsd_syscall(void *cpu_env, int num, 
abi_long arg1,
 abi_long arg8)
 {
 CPUState *cpu = env_cpu(cpu_env);
-int ret;
+abi_long ret;
 
 trace_guest_user_syscall(cpu, num, arg1, arg2, arg3, arg4, arg5, arg6, 
arg7, arg8);
 if (do_strace) {
-- 
2.39.1

[PULL 04/10] hw/net/lan9118: log [read|write]b when mode_16bit is enabled rather than abort

[Jason Wang]

From: Qiang Liu 

This patch replaces hw_error to guest error log for [read|write]b
accesses when mode_16bit is enabled. This avoids aborting qemu.

Fixes: 1248f8d4cbc3 ("hw/lan9118: Add basic 16-bit mode support.")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1433
Reported-by: Qiang Liu 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Qiang Liu 
Suggested-by: Philippe Mathieu-Daudé 
Signed-off-by: Jason Wang 
---
 hw/net/lan9118.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/hw/net/lan9118.c b/hw/net/lan9118.c
index f1cba55..e5c4af1 100644
--- a/hw/net/lan9118.c
+++ b/hw/net/lan9118.c
@@ -15,7 +15,6 @@
 #include "migration/vmstate.h"
 #include "net/net.h"
 #include "net/eth.h"
-#include "hw/hw.h"
 #include "hw/irq.h"
 #include "hw/net/lan9118.h"
 #include "hw/ptimer.h"
@@ -32,12 +31,8 @@
 #ifdef DEBUG_LAN9118
 #define DPRINTF(fmt, ...) \
 do { printf("lan9118: " fmt , ## __VA_ARGS__); } while (0)
-#define BADF(fmt, ...) \
-do { hw_error("lan9118: error: " fmt , ## __VA_ARGS__);} while (0)
 #else
 #define DPRINTF(fmt, ...) do {} while(0)
-#define BADF(fmt, ...) \
-do { fprintf(stderr, "lan9118: error: " fmt , ## __VA_ARGS__);} while (0)
 #endif
 
 /* The tx and rx fifo ports are a range of aliased 32-bit registers */
@@ -848,7 +843,8 @@ static uint32_t do_phy_read(lan9118_state *s, int reg)
 case 30: /* Interrupt mask */
 return s->phy_int_mask;
 default:
-BADF("PHY read reg %d\n", reg);
+qemu_log_mask(LOG_GUEST_ERROR,
+  "do_phy_read: PHY read reg %d\n", reg);
 return 0;
 }
 }
@@ -876,7 +872,8 @@ static void do_phy_write(lan9118_state *s, int reg, 
uint32_t val)
 phy_update_irq(s);
 break;
 default:
-BADF("PHY write reg %d = 0x%04x\n", reg, val);
+qemu_log_mask(LOG_GUEST_ERROR,
+  "do_phy_write: PHY write reg %d = 0x%04x\n", reg, val);
 }
 }
 
@@ -1209,7 +1206,8 @@ static void lan9118_16bit_mode_write(void *opaque, hwaddr 
offset,
 return;
 }
 
-hw_error("lan9118_write: Bad size 0x%x\n", size);
+qemu_log_mask(LOG_GUEST_ERROR,
+  "lan9118_16bit_mode_write: Bad size 0x%x\n", size);
 }
 
 static uint64_t lan9118_readl(void *opaque, hwaddr offset,
@@ -1324,7 +1322,8 @@ static uint64_t lan9118_16bit_mode_read(void *opaque, 
hwaddr offset,
 return lan9118_readl(opaque, offset, size);
 }
 
-hw_error("lan9118_read: Bad size 0x%x\n", size);
+qemu_log_mask(LOG_GUEST_ERROR,
+  "lan9118_16bit_mode_read: Bad size 0x%x\n", size);
 return 0;
 }
 
-- 
2.7.4

Re: [PATCH] vhost: accept VIRTIO_F_ORDER_PLATFORM as a valid SVQ feature

[Eugenio Perez Martin]

On Tue, Feb 14, 2023 at 7:31 AM Jason Wang  wrote:
>
> On Tue, Feb 14, 2023 at 3:19 AM Eugenio Pérez  wrote:
> >
> > VIRTIO_F_ORDER_PLATFORM indicates that memory accesses by the driver and
> > the device are ordered in a way described by the platform.  Since vDPA
> > devices may be backed by a hardware devices, let's allow
> > VIRTIO_F_ORDER_PLATFORM.
> >
> > Signed-off-by: Eugenio Pérez 
> > ---
> >  hw/virtio/vhost-shadow-virtqueue.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
> > b/hw/virtio/vhost-shadow-virtqueue.c
> > index 4307296358..6bb1998f12 100644
> > --- a/hw/virtio/vhost-shadow-virtqueue.c
> > +++ b/hw/virtio/vhost-shadow-virtqueue.c
> > @@ -34,6 +34,7 @@ bool vhost_svq_valid_features(uint64_t features, Error 
> > **errp)
> >  switch (b) {
> >  case VIRTIO_F_ANY_LAYOUT:
> >  case VIRTIO_RING_F_EVENT_IDX:
> > +case VIRTIO_F_ORDER_PLATFORM:
>
> Do we need to add this bit to vdpa_feature_bits[] as well?
>

If we want to pass it to the guest, yes we should. I'll send another
patch for it.

But I think that should be done on top / in parallel actually.

Open question: Should all vdpa hardware devices offer it? Or this is
only needed on specific archs?

Thanks!

[PATCH 17/18] target/riscv: Group all predicate() routines together

[Bin Meng]

Move sstc()/sstc32() to where all predicate() routines live.

Signed-off-by: Bin Meng 
---

 target/riscv/csr.c | 108 ++---
 1 file changed, 54 insertions(+), 54 deletions(-)

diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 40aae9e7b3..37350b8a6d 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -399,6 +399,60 @@ static RISCVException sstateen(CPURISCVState *env, int 
csrno)
 return RISCV_EXCP_NONE;
 }
 
+static RISCVException sstc(CPURISCVState *env, int csrno)
+{
+RISCVCPU *cpu = env_archcpu(env);
+bool hmode_check = false;
+
+if (!cpu->cfg.ext_sstc || !env->rdtime_fn) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+if ((csrno == CSR_VSTIMECMP) || (csrno == CSR_VSTIMECMPH)) {
+hmode_check = true;
+}
+
+RISCVException ret = hmode_check ? hmode(env, csrno) : smode(env, csrno);
+if (ret != RISCV_EXCP_NONE) {
+return ret;
+}
+
+if (env->debugger) {
+return RISCV_EXCP_NONE;
+}
+
+if (env->priv == PRV_M) {
+return RISCV_EXCP_NONE;
+}
+
+/*
+ * No need of separate function for rv32 as menvcfg stores both menvcfg
+ * menvcfgh for RV32.
+ */
+if (!(get_field(env->mcounteren, COUNTEREN_TM) &&
+  get_field(env->menvcfg, MENVCFG_STCE))) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+if (riscv_cpu_virt_enabled(env)) {
+if (!(get_field(env->hcounteren, COUNTEREN_TM) &&
+  get_field(env->henvcfg, HENVCFG_STCE))) {
+return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
+}
+}
+
+return RISCV_EXCP_NONE;
+}
+
+static RISCVException sstc_32(CPURISCVState *env, int csrno)
+{
+if (riscv_cpu_mxl(env) != MXL_RV32) {
+return RISCV_EXCP_ILLEGAL_INST;
+}
+
+return sstc(env, csrno);
+}
+
 /* Checks if PointerMasking registers could be accessed */
 static RISCVException pointer_masking(CPURISCVState *env, int csrno)
 {
@@ -942,60 +996,6 @@ static RISCVException read_timeh(CPURISCVState *env, int 
csrno,
 return RISCV_EXCP_NONE;
 }
 
-static RISCVException sstc(CPURISCVState *env, int csrno)
-{
-RISCVCPU *cpu = env_archcpu(env);
-bool hmode_check = false;
-
-if (!cpu->cfg.ext_sstc || !env->rdtime_fn) {
-return RISCV_EXCP_ILLEGAL_INST;
-}
-
-if ((csrno == CSR_VSTIMECMP) || (csrno == CSR_VSTIMECMPH)) {
-hmode_check = true;
-}
-
-RISCVException ret = hmode_check ? hmode(env, csrno) : smode(env, csrno);
-if (ret != RISCV_EXCP_NONE) {
-return ret;
-}
-
-if (env->debugger) {
-return RISCV_EXCP_NONE;
-}
-
-if (env->priv == PRV_M) {
-return RISCV_EXCP_NONE;
-}
-
-/*
- * No need of separate function for rv32 as menvcfg stores both menvcfg
- * menvcfgh for RV32.
- */
-if (!(get_field(env->mcounteren, COUNTEREN_TM) &&
-  get_field(env->menvcfg, MENVCFG_STCE))) {
-return RISCV_EXCP_ILLEGAL_INST;
-}
-
-if (riscv_cpu_virt_enabled(env)) {
-if (!(get_field(env->hcounteren, COUNTEREN_TM) &&
-  get_field(env->henvcfg, HENVCFG_STCE))) {
-return RISCV_EXCP_VIRT_INSTRUCTION_FAULT;
-}
-}
-
-return RISCV_EXCP_NONE;
-}
-
-static RISCVException sstc_32(CPURISCVState *env, int csrno)
-{
-if (riscv_cpu_mxl(env) != MXL_RV32) {
-return RISCV_EXCP_ILLEGAL_INST;
-}
-
-return sstc(env, csrno);
-}
-
 static RISCVException read_vstimecmp(CPURISCVState *env, int csrno,
  target_ulong *val)
 {
-- 
2.25.1

Re: [PATCH v4 14/16] qapi: deprecate "device" field of DEVICE_* events

[Philippe Mathieu-Daudé]

On 14/2/23 13:17, Markus Armbruster wrote:

Philippe Mathieu-Daudé  writes:


On 14/2/23 12:49, Markus Armbruster wrote:

Daniel P. Berrangé  writes:


[...]


What's the documented way to construct a QOM path, given only an ID  as
input ?


QOM paths a gap in our documentation, even though the composition tree
structure has been stable since day one, and is de facto ABI.

Short answer: "/machine/peripheral/ID".

Long answer follows.

We have three "containers" under /machine that serve as parents for
devices:

* /machine/peripheral/

   Parent of user-created devices with ID.  Children are named "ID".

   Put there by qdev_set_id(), called from qdev_device_add_from_qdict().

   On "user-created": Nothing stops board code to abuse qdev_set_id() for
   onboard devices, directly or indirectly, but it really, really
   shouldn't.

* /machine/peripheral-anon/

   Parent of user-created devices without ID.  Children are named
   "device[N]", where N counts up from zero.

   Put there by qdev_set_id(), called from qdev_device_add_from_qdict().

   Again, abuse by board code is possible, but would be wrong.

   Beware: a particular device's N changes when the set of devices
   created before it grows or shrinks.  Messing with the machine type can
   change it (different onboard devices).

* /machine/unattached/

   Surrogate parent of onboard devices created without a parent.

   Put there by device_set_realized() (general case),
   qdev_connect_gpio_out_named() (input pins) , memory_region_do_init()
   (memory regions), qemu_create_machine() (the main sysbus).

   I believe this container was created as a convenience, so we don't
   have to retrofit parents to existing code.  Probably abused ever
   since.


Are you suggesting this is a stable interface and we can not move
devices (like from /machine/unattached/ to /machine/peripheral/)
without going thru the deprecation process?


Difficult question!

The point of not changing interfaces incompatibly without a grace period
/ deprecation process is not breaking users of the interface.

When an interface has always worked a certain way, its users may well
depend on it, whether it's documented or not.

The question to ask is always "will this break users?"

For documented aspects, we generally assume it will.  Doesn't mean we
can simply assume "won't" for undocumented aspects.

Does this make sense?


Yes, but I never considered the QOM paths as a stable interface...
I'm very surprised.

"Automatically assigned to /machine/unattached/" doesn't seem
quite stable...

[PULL 12/22] tests/qtest: hd-geo-test: Check for missing devices

[Thomas Huth]

From: Fabiano Rosas 

Don't include tests that require devices not available in the QEMU
binary.

Signed-off-by: Fabiano Rosas 
Reviewed-by: Thomas Huth 
Message-Id: <20230208194700.11035-6-faro...@suse.de>
Signed-off-by: Thomas Huth 
---
 tests/qtest/hd-geo-test.c | 38 +-
 1 file changed, 25 insertions(+), 13 deletions(-)

diff --git a/tests/qtest/hd-geo-test.c b/tests/qtest/hd-geo-test.c
index 4a7628077b..5aa258a2b3 100644
--- a/tests/qtest/hd-geo-test.c
+++ b/tests/qtest/hd-geo-test.c
@@ -1090,30 +1090,42 @@ int main(int argc, char **argv)
 qtest_add_func("hd-geo/override/ide", test_override_ide);
 if (qtest_has_device("lsi53c895a")) {
 qtest_add_func("hd-geo/override/scsi", test_override_scsi);
-qtest_add_func("hd-geo/override/scsi_2_controllers",
-   test_override_scsi_2_controllers);
+if (qtest_has_device("virtio-scsi-pci")) {
+qtest_add_func("hd-geo/override/scsi_2_controllers",
+   test_override_scsi_2_controllers);
+}
 }
-qtest_add_func("hd-geo/override/virtio_blk", test_override_virtio_blk);
 qtest_add_func("hd-geo/override/zero_chs", test_override_zero_chs);
-qtest_add_func("hd-geo/override/scsi_hot_unplug",
-   test_override_scsi_hot_unplug);
-qtest_add_func("hd-geo/override/virtio_hot_unplug",
-   test_override_virtio_hot_unplug);
+if (qtest_has_device("virtio-scsi-pci")) {
+qtest_add_func("hd-geo/override/scsi_hot_unplug",
+   test_override_scsi_hot_unplug);
+}
+if (qtest_has_device("virtio-blk-pci")) {
+qtest_add_func("hd-geo/override/virtio_hot_unplug",
+   test_override_virtio_hot_unplug);
+qtest_add_func("hd-geo/override/virtio_blk",
+   test_override_virtio_blk);
+}
 
 if (qtest_has_machine("q35")) {
 qtest_add_func("hd-geo/override/sata", test_override_sata);
-qtest_add_func("hd-geo/override/virtio_blk_q35",
-   test_override_virtio_blk_q35);
 qtest_add_func("hd-geo/override/zero_chs_q35",
test_override_zero_chs_q35);
 if (qtest_has_device("lsi53c895a")) {
 qtest_add_func("hd-geo/override/scsi_q35",
test_override_scsi_q35);
 }
-qtest_add_func("hd-geo/override/scsi_hot_unplug_q35",
-   test_override_scsi_hot_unplug_q35);
-qtest_add_func("hd-geo/override/virtio_hot_unplug_q35",
-   test_override_virtio_hot_unplug_q35);
+if (qtest_has_device("virtio-scsi-pci")) {
+qtest_add_func("hd-geo/override/scsi_hot_unplug_q35",
+   test_override_scsi_hot_unplug_q35);
+}
+if (qtest_has_device("virtio-blk-pci")) {
+qtest_add_func("hd-geo/override/virtio_hot_unplug_q35",
+   test_override_virtio_hot_unplug_q35);
+qtest_add_func("hd-geo/override/virtio_blk_q35",
+   test_override_virtio_blk_q35);
+}
+
 }
 } else {
 g_test_message("QTEST_QEMU_IMG not set or qemu-img missing; "
-- 
2.31.1

Re: [PATCH v2 01/13] vdpa net: move iova tree creation from init to start

[Si-Wei Liu]

On 2/13/2023 3:14 AM, Eugenio Perez Martin wrote:

On Mon, Feb 13, 2023 at 7:51 AM Si-Wei Liu  wrote:



On 2/8/2023 1:42 AM, Eugenio Pérez wrote:

Only create iova_tree if and when it is needed.

The cleanup keeps being responsible of last VQ but this change allows it
to merge both cleanup functions.

Signed-off-by: Eugenio Pérez 
Acked-by: Jason Wang 
---
   net/vhost-vdpa.c | 99 ++--
   1 file changed, 71 insertions(+), 28 deletions(-)

diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
index de5ed8ff22..a9e6c8f28e 100644
--- a/net/vhost-vdpa.c
+++ b/net/vhost-vdpa.c
@@ -178,13 +178,9 @@ err_init:
   static void vhost_vdpa_cleanup(NetClientState *nc)
   {
   VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
-struct vhost_dev *dev = &s->vhost_net->dev;

   qemu_vfree(s->cvq_cmd_out_buffer);
   qemu_vfree(s->status);
-if (dev->vq_index + dev->nvqs == dev->vq_index_end) {
-g_clear_pointer(&s->vhost_vdpa.iova_tree, vhost_iova_tree_delete);
-}
   if (s->vhost_net) {
   vhost_net_cleanup(s->vhost_net);
   g_free(s->vhost_net);
@@ -234,10 +230,64 @@ static ssize_t vhost_vdpa_receive(NetClientState *nc, 
const uint8_t *buf,
   return size;
   }

+/** From any vdpa net client, get the netclient of first queue pair */
+static VhostVDPAState *vhost_vdpa_net_first_nc_vdpa(VhostVDPAState *s)
+{
+NICState *nic = qemu_get_nic(s->nc.peer);
+NetClientState *nc0 = qemu_get_peer(nic->ncs, 0);
+
+return DO_UPCAST(VhostVDPAState, nc, nc0);
+}
+
+static void vhost_vdpa_net_data_start_first(VhostVDPAState *s)
+{
+struct vhost_vdpa *v = &s->vhost_vdpa;
+
+if (v->shadow_vqs_enabled) {
+v->iova_tree = vhost_iova_tree_new(v->iova_range.first,
+   v->iova_range.last);
+}
+}
+
+static int vhost_vdpa_net_data_start(NetClientState *nc)
+{
+VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
+struct vhost_vdpa *v = &s->vhost_vdpa;
+
+assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
+
+if (v->index == 0) {
+vhost_vdpa_net_data_start_first(s);
+return 0;
+}
+
+if (v->shadow_vqs_enabled) {
+VhostVDPAState *s0 = vhost_vdpa_net_first_nc_vdpa(s);
+v->iova_tree = s0->vhost_vdpa.iova_tree;
+}
+
+return 0;
+}
+
+static void vhost_vdpa_net_client_stop(NetClientState *nc)
+{
+VhostVDPAState *s = DO_UPCAST(VhostVDPAState, nc, nc);
+struct vhost_dev *dev;
+
+assert(nc->info->type == NET_CLIENT_DRIVER_VHOST_VDPA);
+
+dev = s->vhost_vdpa.dev;
+if (dev->vq_index + dev->nvqs == dev->vq_index_end) {
+g_clear_pointer(&s->vhost_vdpa.iova_tree, vhost_iova_tree_delete);
+}
+}
+
   static NetClientInfo net_vhost_vdpa_info = {
   .type = NET_CLIENT_DRIVER_VHOST_VDPA,
   .size = sizeof(VhostVDPAState),
   .receive = vhost_vdpa_receive,
+.start = vhost_vdpa_net_data_start,
+.stop = vhost_vdpa_net_client_stop,
   .cleanup = vhost_vdpa_cleanup,
   .has_vnet_hdr = vhost_vdpa_has_vnet_hdr,
   .has_ufo = vhost_vdpa_has_ufo,
@@ -351,7 +401,7 @@ dma_map_err:

   static int vhost_vdpa_net_cvq_start(NetClientState *nc)
   {
-VhostVDPAState *s;
+VhostVDPAState *s, *s0;
   struct vhost_vdpa *v;
   uint64_t backend_features;
   int64_t cvq_group;
@@ -425,6 +475,15 @@ out:
   return 0;
   }

+s0 = vhost_vdpa_net_first_nc_vdpa(s);
+if (s0->vhost_vdpa.iova_tree) {
+/* SVQ is already configured for all virtqueues */
+v->iova_tree = s0->vhost_vdpa.iova_tree;
+} else {
+v->iova_tree = vhost_iova_tree_new(v->iova_range.first,
+   v->iova_range.last);

I wonder how this case could happen, vhost_vdpa_net_data_start_first()
should've allocated an iova tree on the first data vq. Is zero data vq
ever possible on net vhost-vdpa?


It's the case of the current qemu master when only CVQ is being
shadowed. It's not that "there are no data vq": If that case were
possible, CVQ vhost-vdpa state would be s0.

The case is that since only CVQ vhost-vdpa is the one being migrated,
only CVQ has an iova tree.
OK, so this corresponds to the case where live migration is not started 
and CVQ starts in its own address space of VHOST_VDPA_NET_CVQ_ASID. 
Thanks for explaining it!




With this series applied and with no migration running, the case is
the same as before: only SVQ gets shadowed. When migration starts, all
vqs are migrated, and share iova tree.
I wonder what is the reason to share the iova tree when migration 
starts, I think CVQ may stay on its own VHOST_VDPA_NET_CVQ_ASID still?


Actually there's discrepancy in vhost_vdpa_net_log_global_enable(), I 
don't see explicit code to switch from VHOST_VDPA_NET_CVQ_ASID to 
VHOST_VDPA_GUEST_PA_ASID for the CVQ. This is the address space I 
collision I mentioned earlier:


9585@1676093788.259201:vh

[PATCH v2 03/12] bsd-user: Add sysarch syscall

[Warner Losh]

From: Stacey Son 

Connect up the sysarch system call.

Signed-off-by: Juergen Lock 
Co-authored-by: Juergen Lock 
Signed-off-by: Stacey Son 
Reviewed-by: Warner Losh 
Signed-off-by: Warner Losh 
Reviewed-by: Richard Henderson 
---
 bsd-user/freebsd/os-syscall.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/bsd-user/freebsd/os-syscall.c b/bsd-user/freebsd/os-syscall.c
index b4a663fc021..e00997a818c 100644
--- a/bsd-user/freebsd/os-syscall.c
+++ b/bsd-user/freebsd/os-syscall.c
@@ -491,6 +491,13 @@ static abi_long freebsd_syscall(void *cpu_env, int num, 
abi_long arg1,
 ret = do_bsd_undelete(arg1);
 break;
 
+/*
+ * sys{ctl, arch, call}
+ */
+case TARGET_FREEBSD_NR_sysarch: /* sysarch(2) */
+ret = do_freebsd_sysarch(cpu_env, arg1, arg2);
+break;
+
 default:
 qemu_log_mask(LOG_UNIMP, "Unsupported syscall: %d\n", num);
 ret = -TARGET_ENOSYS;
-- 
2.39.1

[Patch 08/14] target/riscv: Simplify check for Zve32f and Zve64f

[Weiwei Li]

Zve64f depends on Zve32f, so we can only check Zve32f
in these cases

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---
 target/riscv/insn_trans/trans_rvv.c.inc | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/target/riscv/insn_trans/trans_rvv.c.inc 
b/target/riscv/insn_trans/trans_rvv.c.inc
index bbb5c3a7b5..6f7ecf1a68 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -173,9 +173,7 @@ static bool do_vsetvl(DisasContext *s, int rd, int rs1, 
TCGv s2)
 {
 TCGv s1, dst;
 
-if (!require_rvv(s) ||
-!(has_ext(s, RVV) || s->cfg_ptr->ext_zve32f ||
-  s->cfg_ptr->ext_zve64f)) {
+if (!require_rvv(s) || !s->cfg_ptr->ext_zve32f) {
 return false;
 }
 
@@ -210,9 +208,7 @@ static bool do_vsetivli(DisasContext *s, int rd, TCGv s1, 
TCGv s2)
 {
 TCGv dst;
 
-if (!require_rvv(s) ||
-!(has_ext(s, RVV) || s->cfg_ptr->ext_zve32f ||
-  s->cfg_ptr->ext_zve64f)) {
+if (!require_rvv(s) || !s->cfg_ptr->ext_zve32f) {
 return false;
 }
 
-- 
2.25.1

Re: [PATCH] block: temporarily hold the new AioContext of bs_top in bdrv_append()

[Stefano Garzarella]

On Tue, Feb 14, 2023 at 12:56 PM Kevin Wolf  wrote:
>
> Am 14.02.2023 um 11:51 hat Stefano Garzarella geschrieben:
> > bdrv_append() is called with bs_top AioContext held, but
> > bdrv_attach_child_noperm() could change the AioContext of bs_top.
> >
> > bdrv_replace_node_noperm() calls bdrv_drained_begin() starting from
> > commit 2398747128 ("block: Don't poll in bdrv_replace_child_noperm()").
> > bdrv_drained_begin() can call BDRV_POLL_WHILE that assumes the new lock
> > is taken, so let's temporarily hold the new AioContext to prevent QEMU
> > from failing in BDRV_POLL_WHILE when it tries to release the wrong
> > AioContext.
> >
> > Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=2168209
> > Reported-by: Aihua Liang 
> > Signed-off-by: Stefano Garzarella 
> > ---
> > I'm not sure whether to use the following Fixes tag. That commit added the
> > calls to bdrv_drained_begin() in bdrv_replace_node_noperm(), but maybe the
> > problem was pre-existing.
> >
> > Fixes: 2398747128 ("block: Don't poll in bdrv_replace_child_noperm()")
> >
> > Note: a local reproducer is attached in the BZ, it is based on the Aihua 
> > Liang
> > report and it hits the issue with a 20% ratio.
> > ---
> >  block.c | 23 +++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/block.c b/block.c
> > index aa9062f2c1..0e2bc11e0b 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -5266,6 +5266,8 @@ int bdrv_drop_filter(BlockDriverState *bs, Error 
> > **errp)
> >   * child.
> >   *
> >   * This function does not create any image files.
> > + *
> > + * The caller must hold the AioContext lock for @bs_top.
> >   */
> >  int bdrv_append(BlockDriverState *bs_new, BlockDriverState *bs_top,
> >  Error **errp)
> > @@ -5273,11 +5275,14 @@ int bdrv_append(BlockDriverState *bs_new, 
> > BlockDriverState *bs_top,
> >  int ret;
> >  BdrvChild *child;
> >  Transaction *tran = tran_new();
> > +AioContext *old_context, *new_context;
> >
> >  GLOBAL_STATE_CODE();
> >
> >  assert(!bs_new->backing);
> >
> > +old_context = bdrv_get_aio_context(bs_top);
> > +
> >  child = bdrv_attach_child_noperm(bs_new, bs_top, "backing",
> >   &child_of_bds, 
> > bdrv_backing_role(bs_new),
> >   tran, errp);
> > @@ -5286,11 +5291,29 @@ int bdrv_append(BlockDriverState *bs_new, 
> > BlockDriverState *bs_top,
> >  goto out;
> >  }
> >
> > +/*
> > + * bdrv_attach_child_noperm could change the AioContext of bs_top.
> > + * bdrv_replace_node_noperm calls bdrv_drained_begin, so let's 
> > temporarily
> > + * hold the new AioContext, since bdrv_drained_begin calls 
> > BDRV_POLL_WHILE
> > + * that assumes the new lock is taken.
> > + */
> > +new_context = bdrv_get_aio_context(bs_top);
> > +
> > +if (old_context != new_context) {
> > +aio_context_release(old_context);
> > +aio_context_acquire(new_context);
> > +}
> > +
> >  ret = bdrv_replace_node_noperm(bs_top, bs_new, true, tran, errp);
> >  if (ret < 0) {
> >  goto out;
>
> If we take the error path, we return with new_context locked instead of
> old_context now.

Grr, I'm blind...

>
> >  }
> >
> > +if (old_context != new_context) {
> > +aio_context_release(new_context);
> > +aio_context_acquire(old_context);
> > +}
> > +
> >  ret = bdrv_refresh_perms(bs_new, tran, errp);
> >  out:
> >  tran_finalize(tran, ret);
>
> Strictly speaking, don't we need to hold the lock across
> tran_finalize(), too? It completes the bdrv_replace_node_noperm() call
> you covered above.

Right!

>
> Maybe bdrv_refresh_perms() and bdrv_refresh_limits(), too, in fact. We
> never clearly defined which functions need the lock and which don't, so
> hard to tell.

Okay, so to be on the safe side, I'll switch them back just before return.

> It's really time to get rid of it.

How could one disagree? :-)

What about the Fixes tag? Should I include it?

Thanks,
Stefano

Re: [PATCH 4/4] target/ppc: fix warning with clang-15

[Pierrick Bouvier]

On 2/14/23 08:14, Philippe Mathieu-Daudé wrote:

On 13/2/23 17:13, Pierrick Bouvier wrote:

When compiling for windows-arm64 using clang-15, it reports a sometimes
uninitialized variable. This seems to be a false positive, as a default
case guards switch expressions, preventing to return an uninitialized
value, but clang seems unhappy with assert definition.

Setting the rnd variable to zero does not hurt anyway.

../target/ppc/dfp_helper.c:141:13: error: variable 'rnd' is used uninitialized 
whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] 
 assert(0); /* 
cannot get here */  

  ^
../include/qemu/osdep.h:229:20: note: expanded from macro 'assert'  

  #define assert(x)  g_assert(x)


 ^~~
/clangarm64/bin/../include/glib-2.0/glib/gtestutils.h:235:49: note: expanded 
from macro 'g_assert'   
if G_LIKELY 
(expr) ; else \
  ^~~
/clangarm64/bin/../include/glib-2.0/glib/gmacros.h:1186:25: note: expanded from 
macro 'G_LIKELY'
  ^~~
../target/ppc/dfp_helper.c:144:42: note: uninitialized use occurs here
  decContextSetRounding(&dfp->context, rnd);

Signed-off-by: Pierrick Bouvier 
---
   target/ppc/dfp_helper.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/ppc/dfp_helper.c b/target/ppc/dfp_helper.c
index cc024316d5..0b4b280683 100644
--- a/target/ppc/dfp_helper.c
+++ b/target/ppc/dfp_helper.c
@@ -69,7 +69,7 @@ struct PPC_DFP {
   
   static void dfp_prepare_rounding_mode(decContext *context, uint64_t fpscr)

   {
-enum rounding rnd;
+enum rounding rnd = 0;
   
   switch ((fpscr & FP_DRN) >> FPSCR_DRN0) {

   case 0:
@@ -106,7 +106,7 @@ static void dfp_prepare_rounding_mode(decContext *context, 
uint64_t fpscr)
   static void dfp_set_round_mode_from_immediate(uint8_t r, uint8_t rmc,
 struct PPC_DFP *dfp)
   {
-enum rounding rnd;
+enum rounding rnd = 0;


Could DEC_ROUND_DEFAULT be clearer?



I missed that macro definition, and that seems like a good default 
value. I'll change to this.

Re: [PATCH 2/4] sysemu/os-win32: fix setjmp/longjmp on windows-arm64

[Philippe Mathieu-Daudé]

Hi Pierrick,

On 13/2/23 17:13, Pierrick Bouvier wrote:

Windows implementation of setjmp/longjmp is done in
C:/WINDOWS/system32/ucrtbase.dll. Alas, on arm64, it seems to *always*
perform stack unwinding, which crashes from generated code.

By using alternative implementation built in mingw, we avoid doing stack
unwinding and this fixes crash when calling longjmp.

Signed-off-by: Pierrick Bouvier 
---
  include/sysemu/os-win32.h | 18 --
  1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/sysemu/os-win32.h b/include/sysemu/os-win32.h
index 5b38c7bd04..84f62d0a17 100644
--- a/include/sysemu/os-win32.h
+++ b/include/sysemu/os-win32.h
@@ -51,14 +51,28 @@ typedef struct sockaddr_un {
  extern "C" {
  #endif
  
-#if defined(_WIN64)

+#if defined(__aarch64__)


Shouldn't we check for __MINGW64__?

   #if defined(__aarch64__) && defined(__MINGW64__)


+/* On windows-arm64, setjmp is available in only one variant, and longjmp 
always
+ * does stack unwinding. This crash with generated code.
+ * Thus, we use another implementation of setjmp (not windows one), coming from
+ * mingw, which never performs stack unwinding. */
+#undef setjmp
+#undef longjmp
+/* These functions are not declared in setjmp.h because __aarch64__ defines
+ * setjmp to _setjmpex instead. However, they are still defined in 
libmingwex.a,
+ * which gets linked automatically. */


So this is not stable. Better would be to check the symbols availability
at link-time via meson; see for example glusterfs_ftruncate_has_stat
which defines CONFIG_GLUSTERFS_FTRUNCATE_HAS_STAT.

A similar check could define CONFIG_MINGW64_HAS_SETJMP_LONGJMP.


+extern int __mingw_setjmp(jmp_buf);
+extern void __attribute__((noreturn)) __mingw_longjmp(jmp_buf, int);
+#define setjmp(env) __mingw_setjmp(env)
+#define longjmp(env, val) __mingw_longjmp(env, val)
+#elif defined(_WIN64)
  /* On w64, setjmp is implemented by _setjmp which needs a second parameter.
   * If this parameter is NULL, longjump does no stack unwinding.
   * That is what we need for QEMU. Passing the value of register rsp (default)
   * lets longjmp try a stack unwinding which will crash with generated code. */
  # undef setjmp
  # define setjmp(env) _setjmp(env, NULL)
-#endif
+#endif /* __aarch64__ */
  /* QEMU uses sigsetjmp()/siglongjmp() as the portable way to specify
   * "longjmp and don't touch the signal masks". Since we know that the
   * savemask parameter will always be zero we can safely define these


Regards,

Phil.

Re: [PATCH 10/18] target/riscv: gdbstub: Turn on debugger mode before calling CSR predicate()

[weiwei]

On 2023/2/14 02:02, Bin Meng wrote:

Since commit 94452ac4cf26 ("target/riscv: remove fflags, frm, and fcsr from 
riscv-*-fpu.xml")
the 3 FPU CSRs are removed from the XML target decription. The
original intent of that commit was based on the assumption that
the 3 FPU CSRs will show up in the riscv-csr.xml so the ones in
riscv-*-fpu.xml are redundant. But unforuantely that is not ture.


typo here -> true

otherwise, Reviewed-by: Weiwei Li 

Regards,
Weiwei Li


As the FPU CSR predicate() has a run-time check on MSTATUS.FS,
at the time when CSR XML is generated MSTATUS.FS is unset, hence
no FPU CSRs will be reported.

The FPU CSR predicate() already considered such a case of being
accessed by a debugger. All we need to do is to turn on debugger
mode before calling predicate().

Signed-off-by: Bin Meng 
---

  target/riscv/gdbstub.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/target/riscv/gdbstub.c b/target/riscv/gdbstub.c
index 294f0ceb1c..ef52f41460 100644
--- a/target/riscv/gdbstub.c
+++ b/target/riscv/gdbstub.c
@@ -280,6 +280,10 @@ static int riscv_gen_dynamic_csr_xml(CPUState *cs, int 
base_reg)
  int bitsize = 16 << env->misa_mxl_max;
  int i;
  
+#if !defined(CONFIG_USER_ONLY)

+env->debugger = true;
+#endif
+
  /* Until gdb knows about 128-bit registers */
  if (bitsize > 64) {
  bitsize = 64;
@@ -308,6 +312,11 @@ static int riscv_gen_dynamic_csr_xml(CPUState *cs, int 
base_reg)
  g_string_append_printf(s, "");
  
  cpu->dyn_csr_xml = g_string_free(s, false);

+
+#if !defined(CONFIG_USER_ONLY)
+env->debugger = false;
+#endif
+
  return CSR_TABLE_SIZE;
  }
  

Re: [PATCH 3/4] hw: Use qdev_get_parent_bus() in qdev_get_own_fw_dev_path_from_handler()

[Philippe Mathieu-Daudé]

On 14/2/23 00:29, Richard Henderson wrote:

On 2/12/23 12:47, Philippe Mathieu-Daudé wrote:
-static char *qdev_get_fw_dev_path_from_handler(BusState *bus, 
DeviceState *dev)

+static char *qdev_get_fw_dev_path_from_handler(DeviceState *dev)
  {
  Object *obj = OBJECT(dev);
+    BusState *bus = qdev_get_parent_bus(dev);
  char *d = NULL;
  while (!d && obj->parent) {


This is a separate change from...

-char *qdev_get_own_fw_dev_path_from_handler(BusState *bus, 
DeviceState *dev)

+char *qdev_get_own_fw_dev_path_from_handler(DeviceState *dev)
  {
  Object *obj = OBJECT(dev);
-    return fw_path_provider_try_get_dev_path(obj, bus, dev);
+    return fw_path_provider_try_get_dev_path(obj, 
qdev_get_parent_bus(dev), dev);


... this, which is what $SUBJECT says.

@@ -67,7 +68,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState 
*dev, char *p, int size)

  if (dev && dev->parent_bus) {
  char *d;
  l = qdev_get_fw_dev_path_helper(dev->parent_bus->parent, p, 
size);

-    d = qdev_get_fw_dev_path_from_handler(dev->parent_bus, dev);
+    d = qdev_get_fw_dev_path_from_handler(dev);


We've already accessed parent_bus just above


  if (!d) {
  d = bus_get_fw_dev_path(dev->parent_bus, dev);


... and just below.  So, what's the cleanup?


qdev_get_own_fw_dev_path_from_handler() being a public API, I wanted to
clean it to avoid a funny case when it is called with
bus != qdev_get_parent_bus(dev). Maybe I merged 2 patches in one, I'll
revisit. Or I can just add assert(bus == qdev_get_parent_bus(dev)) to
prove the API is convoluted. I'll reword on before respin.

[PATCH 12/12] hw/pci-host/q35: Move MemoryRegion pointers to host device

[Bernhard Beschow]

The pointers are set through the host device's properties and are only
used during its realization phase.

Signed-off-by: Bernhard Beschow 
---
 include/hw/pci-host/q35.h | 10 +++
 hw/pci-host/q35.c | 56 +++
 2 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index a04d5f1a17..9b9ce48ca8 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -40,11 +40,6 @@ struct MCHPCIState {
 PCIDevice parent_obj;
 /*< public >*/
 
-MemoryRegion *ram_memory;
-MemoryRegion *pci_address_space;
-MemoryRegion *system_memory;
-MemoryRegion *address_space_io;
-MemoryRegion *smram;
 PAMMemoryRegion pam_regions[PAM_REGIONS_COUNT];
 MemoryRegion smram_region, open_high_smram;
 MemoryRegion low_smram, high_smram;
@@ -61,6 +56,11 @@ struct Q35PCIHost {
 PCIExpressHost parent_obj;
 /*< public >*/
 
+MemoryRegion *ram_memory;
+MemoryRegion *pci_address_space;
+MemoryRegion *system_memory;
+MemoryRegion *address_space_io;
+MemoryRegion *smram;
 Range pci_hole;
 uint64_t pci_hole64_size;
 uint32_t short_root_bus;
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 3a7f9185a3..cb8ea58c25 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -79,11 +79,11 @@ static void q35_host_realize(DeviceState *dev, Error **errp)
 return;
 }
 
-memory_region_add_subregion(s->mch.address_space_io,
+memory_region_add_subregion(s->address_space_io,
 MCH_HOST_BRIDGE_CONFIG_ADDR, &phb->conf_mem);
 sysbus_init_ioports(sbd, MCH_HOST_BRIDGE_CONFIG_ADDR, 4);
 
-memory_region_add_subregion(s->mch.address_space_io,
+memory_region_add_subregion(s->address_space_io,
 MCH_HOST_BRIDGE_CONFIG_DATA, &phb->data_mem);
 sysbus_init_ioports(sbd, MCH_HOST_BRIDGE_CONFIG_DATA, 4);
 
@@ -99,47 +99,47 @@ static void q35_host_realize(DeviceState *dev, Error **errp)
  IO_APIC_DEFAULT_ADDRESS - 1);
 
 /* setup pci memory mapping */
-pc_pci_as_mapping_init(s->mch.system_memory, s->mch.pci_address_space);
+pc_pci_as_mapping_init(s->system_memory, s->pci_address_space);
 
 /* if *disabled* show SMRAM to all CPUs */
 memory_region_init_alias(&s->mch.smram_region, OBJECT(s), "smram-region",
- s->mch.pci_address_space, 
MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ s->pci_address_space, 
MCH_HOST_BRIDGE_SMRAM_C_BASE,
  MCH_HOST_BRIDGE_SMRAM_C_SIZE);
-memory_region_add_subregion_overlap(s->mch.system_memory, 
MCH_HOST_BRIDGE_SMRAM_C_BASE,
+memory_region_add_subregion_overlap(s->system_memory, 
MCH_HOST_BRIDGE_SMRAM_C_BASE,
 &s->mch.smram_region, 1);
 memory_region_set_enabled(&s->mch.smram_region, true);
 
 memory_region_init_alias(&s->mch.open_high_smram, OBJECT(s), 
"smram-open-high",
- s->mch.ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ s->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
  MCH_HOST_BRIDGE_SMRAM_C_SIZE);
-memory_region_add_subregion_overlap(s->mch.system_memory, 0xfeda,
+memory_region_add_subregion_overlap(s->system_memory, 0xfeda,
 &s->mch.open_high_smram, 1);
 memory_region_set_enabled(&s->mch.open_high_smram, false);
 
 /* smram, as seen by SMM CPUs */
 memory_region_init_alias(&s->mch.low_smram, OBJECT(s), "smram-low",
- s->mch.ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ s->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
  MCH_HOST_BRIDGE_SMRAM_C_SIZE);
 memory_region_set_enabled(&s->mch.low_smram, true);
-memory_region_add_subregion(s->mch.smram, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+memory_region_add_subregion(s->smram, MCH_HOST_BRIDGE_SMRAM_C_BASE,
 &s->mch.low_smram);
 memory_region_init_alias(&s->mch.high_smram, OBJECT(s), "smram-high",
- s->mch.ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
+ s->ram_memory, MCH_HOST_BRIDGE_SMRAM_C_BASE,
  MCH_HOST_BRIDGE_SMRAM_C_SIZE);
 memory_region_set_enabled(&s->mch.high_smram, true);
-memory_region_add_subregion(s->mch.smram, 0xfeda, &s->mch.high_smram);
+memory_region_add_subregion(s->smram, 0xfeda, &s->mch.high_smram);
 
 memory_region_init_io(&s->mch.tseg_blackhole, OBJECT(s),
   &blackhole_ops, NULL, "tseg-blackhole", 0);
 memory_region_set_enabled(&s->mch.tseg_blackhole, false);
-memory_region_add_subregion_overlap(s->mch.system_memory,
+memory_region_add_subregion_overlap(s->system_memory,
 s->mch

Re: [PATCH] memory: Optimize replay of guest mapping

[Jason Wang]

On Tue, Feb 14, 2023 at 11:43 AM Zhenzhong Duan
 wrote:
>
> On x86, there are two notifiers registered due to vtd-ir memory region
> splitting the whole address space. During replay of the address space
> for each notifier, the whole address space is scanned which is
> unnecessory.
>
> We only need to scan the space belong to notifier montiored space.
>
> Signed-off-by: Zhenzhong Duan 
> ---
> Tested only on x86 with a net card passed to guest, ping/ssh pass.
>
>  hw/i386/intel_iommu.c | 2 +-
>  softmmu/memory.c  | 3 +--
>  2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/hw/i386/intel_iommu.c b/hw/i386/intel_iommu.c
> index 98a5c304a7d7..6b1de80e8573 100644
> --- a/hw/i386/intel_iommu.c
> +++ b/hw/i386/intel_iommu.c
> @@ -3831,7 +3831,7 @@ static void vtd_iommu_replay(IOMMUMemoryRegion 
> *iommu_mr, IOMMUNotifier *n)
>  .domain_id = vtd_get_domain_id(s, &ce, vtd_as->pasid),
>  };
>
> -vtd_page_walk(s, &ce, 0, ~0ULL, &info, vtd_as->pasid);
> +vtd_page_walk(s, &ce, n->start, n->end, &info, vtd_as->pasid);
>  }
>  } else {
>  trace_vtd_replay_ce_invalid(bus_n, PCI_SLOT(vtd_as->devfn),
> diff --git a/softmmu/memory.c b/softmmu/memory.c
> index 9d64efca269b..f096716e6e78 100644
> --- a/softmmu/memory.c
> +++ b/softmmu/memory.c
> @@ -1923,7 +1923,6 @@ uint64_t 
> memory_region_iommu_get_min_page_size(IOMMUMemoryRegion *iommu_mr)
>
>  void memory_region_iommu_replay(IOMMUMemoryRegion *iommu_mr, IOMMUNotifier 
> *n)
>  {
> -MemoryRegion *mr = MEMORY_REGION(iommu_mr);
>  IOMMUMemoryRegionClass *imrc = IOMMU_MEMORY_REGION_GET_CLASS(iommu_mr);
>  hwaddr addr, granularity;
>  IOMMUTLBEntry iotlb;
> @@ -1936,7 +1935,7 @@ void memory_region_iommu_replay(IOMMUMemoryRegion 
> *iommu_mr, IOMMUNotifier *n)
>
>  granularity = memory_region_iommu_get_min_page_size(iommu_mr);
>
> -for (addr = 0; addr < memory_region_size(mr); addr += granularity) {
> +for (addr = n->start; addr < n->end; addr += granularity) {

Is [n->start, n->end] guaranteed to be the subset of memory_region_size(mr)?

Thanks

>  iotlb = imrc->translate(iommu_mr, addr, IOMMU_NONE, n->iommu_idx);
>  if (iotlb.perm != IOMMU_NONE) {
>  n->notify(n, &iotlb);
> --
> 2.25.1
>
>

Re: [PATCH v4 14/16] qapi: deprecate "device" field of DEVICE_* events

[Markus Armbruster]

Daniel P. Berrangé  writes:

> On Mon, Feb 13, 2023 at 05:01:01PM +0300, Vladimir Sementsov-Ogievskiy wrote:
>> The device field is redundant, because QOM path always include device
>> ID when this ID exist.
>
> The flipside to that view is that applications configuring QEMU are
> specifying the device ID for -device (CLI) / device_add (QMP) and
> not the QOM path. IOW, the device ID is the more interesting field
> than QOM path, so feels like the wrong one to be dropping.

QOM path is a reliable way to identify a device.  Device ID isn't:
devices need not have one.  Therefore, dropping the QOM path would be
wrong.

> Is there any real benefit to dropping this ? 

The device ID is a trap for the unwary: relying on it is fine until you
run into a scenario where you have to deal with devices lacking IDs.

I suggested to deprecate it in review of "[PATCH v3 14/15] qapi:
introduce DEVICE_ON event" (Message-ID: <873579x67l@pond.sub.org>).
Quote:

We commonly send both device ID and QOM path, mostly for historical
reasons: the former precede the latter.

There are exceptions, such as query-cpus-fast.  Can't say offhand
whether CPUs can be created with IDs.

[...]

I'd be in favour of deprecating and deleting redundant device IDs in QMP
output.

Re: [PATCH v2 6/7] CI: Stop building docs on centos8

[Daniel P . Berrangé]

On Tue, Feb 14, 2023 at 09:35:44AM +0100, Thomas Huth wrote:
> On 14/02/2023 08.40, Markus Armbruster wrote:
> > Daniel P. Berrangé  writes:
> > 
> > [...]
> > 
> > > We don't have to drop python 3.6. It is a choice because
> > > of a desire to be able to use some shiny new python
> > > features without caring about back compat.
> > 
> > I read this on Friday, and decided to let it sit until after the
> > weekend.  Well, it's now Tuesday, and to be frank, it's still as
> > offensively flippant as it was on Friday.  It shows either ignorance of
> > or cavalier disregard for the sheer amount of work some of us have had
> > to put into keeping old versions of Python viable.
> 
> I'm a complete python ignorant, too, so I'm a little bit surprised of the
> amount of pain that these scripts are causing.
> 
> No matter of that fact, I think Peter still has a point that we have a real
> conflict here with our current support policy. So this either means that
> Python was the wrong choice for our needs (since it is moving too fast and
> causing too much friction), or we should really rethink our support policy.
> 
> I guess we're too deep into the Python rabbit hole already, and I'm not
> aware of any other good solutions (back to Perl scripts? No, thanks!), so
> it's likely quite impossible to tune that knob.

I still believe python is a probably the best thing for what we're using
it for. Certainly would not suggest shell or perl, and using a compiled
language would add its own complications for cross compilation.

> Thus we should maybe really start talking about our support policy now. I
> think the main problem is likely the sentence "Support for the previous
> major version will be dropped 2 years after the new major version is
> released". Maybe we should shorten that time frame to 1 year. The 2 years
> caused some confusions in the past already, since e.g. Debian only supports
> the previous major release for only one more year, and macOS also releases a
> major version each year ... so IMHO we could shorten the time frame for the
> previous major release to 1 year instead. People then could still continue
> building QEMU on CentOS 8, but they have to be aware that they might install
> other software like Sphinx manually if they want to continue using QEMU with
> docs there. What do you think?


I think perhaps the problem is not in the length of time defined by
our support policy, but rather that we're facing a rather different
reality to the one we've historically been used it, where distros
are no longer critical dependancies and our support policy does not
reflect that.


For any C/C++ application, wanting to target the versions shipped in a
distro has been pretty much normal practice. C has not ever come with
a standard package manager toolset, the distros service that role. The
distros also aren't generally a fan of shipping multiple versions of
C libs in parallel.


Pretty much every non-C library though is different. They all have
their own package manager service / tools (perl has cpan, pytyhon has
PyPi/pip, ruby has gems. With latest compiled languages like Go/Rust,
this has gone one step further and is natively integrated into the
compiler toolchain as standard.


IOW, for everything except C, it has become increasingly normal
practice to ignore the distro and dynamically download all the deps
your application needs into a self contained local environment.
Now, the distros aren't especially a fan of this new world, since
they still prefer to unbundle all these deps, but I think that
approach is increasingly difficult for them to achieve because the
majority of upstreams don't care for the distro versions.


Thus what we're experiancing is a clash between the traditional
way that C applications/libraries deal with their deps, vs the
way pretty much every other language deals with their deps in
the modern world. It has come up now because we're making much
more use of python now, than we did in the past.


Our support policy is written from the POV of the C world, and
merely reducing the length of time we support a distro does not
address the different world view of Python.

Should we instead try to be more explicit about the different
needs of the non-C dependencies ?

We could for example say

 * For native library/application dependancies we aim to
   support the two most recent distro versions, for 2 years
   overlap

 * For non-native library/applications dependancies we aim
   to support only the most recent distro version. Users
   of older distros may need to dynamically fetch newer
   deps.

The python 3.8 runtime would be considered a native dep, so fall
under the 2 distro versions rule. This is fine with CentOS 8,
since it provides newer python runtime versions.

The python libraries, or tools written in python (meson), would
fall under the second rule, and so only need to target one distro
version. This would be compatible with CentOS 8, as the users would
be expected to download extra p

[PULL 14/22] tests/qtest: Skip unplug tests that use missing devices

[Thomas Huth]

From: Fabiano Rosas 

Signed-off-by: Fabiano Rosas 
Message-Id: <20230208194700.11035-8-faro...@suse.de>
Reviewed-by: Thomas Huth 
Signed-off-by: Thomas Huth 
---
 tests/qtest/device-plug-test.c | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/tests/qtest/device-plug-test.c b/tests/qtest/device-plug-test.c
index 4f92617335..01cecd6e20 100644
--- a/tests/qtest/device-plug-test.c
+++ b/tests/qtest/device-plug-test.c
@@ -68,6 +68,11 @@ static void test_pci_unplug_request(void)
 const char *arch = qtest_get_arch();
 const char *machine_addition = "";
 
+if (!qtest_has_device("virtio-mouse-pci")) {
+g_test_skip("Device virtio-mouse-pci not available");
+return;
+}
+
 if (strcmp(arch, "i386") == 0 || strcmp(arch, "x86_64") == 0) {
 machine_addition = "-machine pc";
 }
@@ -82,11 +87,17 @@ static void test_pci_unplug_request(void)
 
 static void test_q35_pci_unplug_request(void)
 {
+QTestState *qtest;
+
+if (!qtest_has_device("virtio-mouse-pci")) {
+g_test_skip("Device virtio-mouse-pci not available");
+return;
+}
 
-QTestState *qtest = qtest_initf("-machine q35 "
-"-device pcie-root-port,id=p1 "
-"-device pcie-pci-bridge,bus=p1,id=b1 "
-"-device virtio-mouse-pci,bus=b1,id=dev0");
+qtest = qtest_initf("-machine q35 "
+"-device pcie-root-port,id=p1 "
+"-device pcie-pci-bridge,bus=p1,id=b1 "
+"-device virtio-mouse-pci,bus=b1,id=dev0");
 
 process_device_remove(qtest, "dev0");
 
@@ -99,6 +110,11 @@ static void test_pci_unplug_json_request(void)
 const char *arch = qtest_get_arch();
 const char *machine_addition = "";
 
+if (!qtest_has_device("virtio-mouse-pci")) {
+g_test_skip("Device virtio-mouse-pci not available");
+return;
+}
+
 if (strcmp(arch, "i386") == 0 || strcmp(arch, "x86_64") == 0) {
 machine_addition = "-machine pc";
 }
@@ -114,6 +130,7 @@ static void test_pci_unplug_json_request(void)
 
 static void test_q35_pci_unplug_json_request(void)
 {
+QTestState *qtest;
 const char *port = "-device \"{'driver': 'pcie-root-port', "
   "'id': 'p1'}\"";
 
@@ -125,8 +142,12 @@ static void test_q35_pci_unplug_json_request(void)
 "'bus': 'b1', "
 "'id': 'dev0'}\"";
 
-QTestState *qtest = qtest_initf("-machine q35 %s %s %s",
-port, bridge, device);
+if (!qtest_has_device("virtio-mouse-pci")) {
+g_test_skip("Device virtio-mouse-pci not available");
+return;
+}
+
+qtest = qtest_initf("-machine q35 %s %s %s", port, bridge, device);
 
 process_device_remove(qtest, "dev0");
 
-- 
2.31.1

[PATCH 10/12] hw/pci-host/q35: Propagate to errp rather than doing error_fatal

[Bernhard Beschow]

q35_host_realize() has an errp parameter. Use that to be able to
propagate the error instead of terminating abruptly.

Signed-off-by: Bernhard Beschow 
---
 hw/pci-host/q35.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 8f81debfa5..d517f5622b 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -46,6 +46,7 @@
 
 static void q35_host_realize(DeviceState *dev, Error **errp)
 {
+ERRP_GUARD();
 Q35PCIHost *s = Q35_HOST_DEVICE(dev);
 PCIHostState *phb = PCI_HOST_BRIDGE(dev);
 SysBusDevice *sbd = SYS_BUS_DEVICE(dev);
@@ -74,7 +75,7 @@ static void q35_host_realize(DeviceState *dev, Error **errp)
 s->mch.address_space_io,
 0, TYPE_PCIE_BUS);
 
-qdev_realize(DEVICE(&s->mch), BUS(phb->bus), &error_fatal);
+qdev_realize(DEVICE(&s->mch), BUS(phb->bus), errp);
 }
 
 static const char *q35_host_root_bus_path(PCIHostState *host_bridge,
-- 
2.39.1

[PATCH 07/12] hw/pci-host/q35: Initialize PCI hole boundaries just once

[Bernhard Beschow]

The boundaries of the PCI hole depend on a property only which doesn't
change at runtime. There is no need to reevaluate the boundaries
whenever the PCI configuration space changes.

While at it, move the pci_hole attribute into the host device since it
is only used there.

Signed-off-by: Bernhard Beschow 
---
 include/hw/pci-host/q35.h |  2 +-
 hw/pci-host/q35.c | 21 +
 2 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index 93e41ffbee..a04d5f1a17 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -51,7 +51,6 @@ struct MCHPCIState {
 MemoryRegion tseg_blackhole, tseg_window;
 MemoryRegion smbase_blackhole, smbase_window;
 bool has_smram_at_smbase;
-Range pci_hole;
 uint64_t below_4g_mem_size;
 uint64_t above_4g_mem_size;
 uint16_t ext_tseg_mbytes;
@@ -62,6 +61,7 @@ struct Q35PCIHost {
 PCIExpressHost parent_obj;
 /*< public >*/
 
+Range pci_hole;
 uint64_t pci_hole64_size;
 uint32_t short_root_bus;
 bool pci_hole64_fix;
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 03aa08dae5..468bbfde51 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -62,6 +62,13 @@ static void q35_host_realize(DeviceState *dev, Error **errp)
 memory_region_set_flush_coalesced(&pci->data_mem);
 memory_region_add_coalescing(&pci->conf_mem, 0, 4);
 
+/*
+ * pci hole goes from end-of-low-ram to io-apic.
+ * mmconfig will be excluded by the dsdt builder.
+ */
+range_set_bounds(&s->pci_hole, s->mch.below_4g_mem_size,
+ IO_APIC_DEFAULT_ADDRESS - 1);
+
 pci->bus = pci_root_bus_new(DEVICE(s), "pcie.0",
 s->mch.pci_address_space,
 s->mch.address_space_io,
@@ -90,8 +97,7 @@ static void q35_host_get_pci_hole_start(Object *obj, Visitor 
*v,
 uint64_t val64;
 uint32_t value;
 
-val64 = range_is_empty(&s->mch.pci_hole)
-? 0 : range_lob(&s->mch.pci_hole);
+val64 = range_is_empty(&s->pci_hole) ? 0 : range_lob(&s->pci_hole);
 value = val64;
 assert(value == val64);
 visit_type_uint32(v, name, &value, errp);
@@ -105,8 +111,7 @@ static void q35_host_get_pci_hole_end(Object *obj, Visitor 
*v,
 uint64_t val64;
 uint32_t value;
 
-val64 = range_is_empty(&s->mch.pci_hole)
-? 0 : range_upb(&s->mch.pci_hole) + 1;
+val64 = range_is_empty(&s->pci_hole) ? 0 : range_upb(&s->pci_hole) + 1;
 value = val64;
 assert(value == val64);
 visit_type_uint32(v, name, &value, errp);
@@ -498,14 +503,6 @@ static void mch_update(MCHPCIState *mch)
 mch_update_smram(mch);
 mch_update_ext_tseg_mbytes(mch);
 mch_update_smbase_smram(mch);
-
-/*
- * pci hole goes from end-of-low-ram to io-apic.
- * mmconfig will be excluded by the dsdt builder.
- */
-range_set_bounds(&mch->pci_hole,
- mch->below_4g_mem_size,
- IO_APIC_DEFAULT_ADDRESS - 1);
 }
 
 static int mch_post_load(void *opaque, int version_id)
-- 
2.39.1

[PATCH 06/12] hw/pci-host/q35: Initialize properties just once

[Bernhard Beschow]

Although not used there, the attributes for Q35's "pci-hole64-size" and
"short_root_bus" properties currently reside in its child device. This
causes the default values to be overwritten during the child's
object_initialize() phase. Avoid this by moving both attributes into the
host device.

Signed-off-by: Bernhard Beschow 
---
 include/hw/pci-host/q35.h |  5 +++--
 hw/pci-host/q35.c | 20 +---
 2 files changed, 8 insertions(+), 17 deletions(-)

diff --git a/include/hw/pci-host/q35.h b/include/hw/pci-host/q35.h
index fcbe57b42d..93e41ffbee 100644
--- a/include/hw/pci-host/q35.h
+++ b/include/hw/pci-host/q35.h
@@ -54,8 +54,6 @@ struct MCHPCIState {
 Range pci_hole;
 uint64_t below_4g_mem_size;
 uint64_t above_4g_mem_size;
-uint64_t pci_hole64_size;
-uint32_t short_root_bus;
 uint16_t ext_tseg_mbytes;
 };
 
@@ -64,7 +62,10 @@ struct Q35PCIHost {
 PCIExpressHost parent_obj;
 /*< public >*/
 
+uint64_t pci_hole64_size;
+uint32_t short_root_bus;
 bool pci_hole64_fix;
+
 MCHPCIState mch;
 };
 
diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c
index 0e198f97a7..03aa08dae5 100644
--- a/hw/pci-host/q35.c
+++ b/hw/pci-host/q35.c
@@ -76,7 +76,7 @@ static const char *q35_host_root_bus_path(PCIHostState 
*host_bridge,
 Q35PCIHost *s = Q35_HOST_DEVICE(host_bridge);
 
  /* For backwards compat with old device paths */
-if (s->mch.short_root_bus) {
+if (s->short_root_bus) {
 return "";
 }
 return ":00";
@@ -161,27 +161,19 @@ static void q35_host_get_pci_hole64_end(Object *obj, 
Visitor *v,
 
 pci_bus_get_w64_range(h->bus, &w64);
 value = range_is_empty(&w64) ? 0 : range_upb(&w64) + 1;
-hole64_end = ROUND_UP(hole64_start + s->mch.pci_hole64_size, 1ULL << 30);
+hole64_end = ROUND_UP(hole64_start + s->pci_hole64_size, 1ULL << 30);
 if (s->pci_hole64_fix && value < hole64_end) {
 value = hole64_end;
 }
 visit_type_uint64(v, name, &value, errp);
 }
 
-/*
- * NOTE: setting defaults for the mch.* fields in this table
- * doesn't work, because mch is a separate QOM object that is
- * zeroed by the object_initialize(&s->mch, ...) call inside
- * q35_host_initfn().  The default values for those
- * properties need to be initialized manually by
- * q35_host_initfn() after the object_initialize() call.
- */
 static Property q35_host_props[] = {
 DEFINE_PROP_UINT64(PCIE_HOST_MCFG_BASE, Q35PCIHost, parent_obj.base_addr,
 MCH_HOST_BRIDGE_PCIEXBAR_DEFAULT),
 DEFINE_PROP_SIZE(PCI_HOST_PROP_PCI_HOLE64_SIZE, Q35PCIHost,
- mch.pci_hole64_size, Q35_PCI_HOST_HOLE64_SIZE_DEFAULT),
-DEFINE_PROP_UINT32("short_root_bus", Q35PCIHost, mch.short_root_bus, 0),
+ pci_hole64_size, Q35_PCI_HOST_HOLE64_SIZE_DEFAULT),
+DEFINE_PROP_UINT32("short_root_bus", Q35PCIHost, short_root_bus, 0),
 DEFINE_PROP_SIZE(PCI_HOST_BELOW_4G_MEM_SIZE, Q35PCIHost,
  mch.below_4g_mem_size, 0),
 DEFINE_PROP_SIZE(PCI_HOST_ABOVE_4G_MEM_SIZE, Q35PCIHost,
@@ -218,9 +210,7 @@ static void q35_host_initfn(Object *obj)
 object_initialize_child(OBJECT(s), "mch", &s->mch, TYPE_MCH_PCI_DEVICE);
 qdev_prop_set_int32(DEVICE(&s->mch), "addr", PCI_DEVFN(0, 0));
 qdev_prop_set_bit(DEVICE(&s->mch), "multifunction", false);
-/* mch's object_initialize resets the default value, set it again */
-qdev_prop_set_uint64(DEVICE(s), PCI_HOST_PROP_PCI_HOLE64_SIZE,
- Q35_PCI_HOST_HOLE64_SIZE_DEFAULT);
+
 object_property_add(obj, PCI_HOST_PROP_PCI_HOLE_START, "uint32",
 q35_host_get_pci_hole_start,
 NULL, NULL, NULL);
-- 
2.39.1

[qemu-web PATCH] revamp sponsorship page

[Paolo Bonzini]

Fosshost is mostly dead and can be removed from the page, but lately QEMU
has received important sponsorships from GNOME and Azure, so mention them.
OSUOSL also provides OpenStack virtual machines to QEMU.

Our CI resources are sponsored by WorksOnArm, the IBM LinuxOne community
cloud and GitLab.

Finally, include directions for people that want to sponsor QEMU or
donate money to the project.

Signed-off-by: Paolo Bonzini 
---
 sponsors.md | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/sponsors.md b/sponsors.md
index 6db5e2f..efbec97 100644
--- a/sponsors.md
+++ b/sponsors.md
@@ -5,5 +5,21 @@ permalink: /sponsors/
 
 QEMU has sponsors!
 
-[Fosshost](https://fosshost.org/) has provided QEMU access to a dedicated
-physical compute host.
+The [Azure credits for open source 
projects](https://opensource.microsoft.com/azure-credits/)
+program provides QEMU and [Patchew](https://patchew.org) with virtual machines 
and
+other cloud resources.
+
+[Equinix](https://www.arm.com/markets/computing-infrastructure/works-on-arm?#Equinix),
+[IBM LinuxONE Community 
Cloud](https://developer.ibm.com/articles/get-started-with-ibm-linuxone/)
+and the [Oregon State University Open Source Labs](https://www.osuosl.org)
+also provide QEMU with access to compute hosts.
+
+Downloads are hosted by [GNOME](https://gnome.org/).
+
+QEMU is a member of the [GitLab for Open 
Source](https://about.gitlab.com/solutions/open-source/)
+program.
+
+You too can sponsor QEMU and be listed on this page; please contact the
+maintainers on the [QEMU mailing list](mailto:qemu-devel@nongnu.org).
+You can also 
[donate](https://paypal.com/donate/?hosted_button_id=YN74TZRMBBM6U)
+to the project via PayPal.
-- 
2.39.1

[PULL 19/22] tests/qtest: bios-tables-test: Skip if missing configs

[Thomas Huth]

From: Fabiano Rosas 

If we build with --without-default-devices, CONFIG_HPET and
CONFIG_PARALLEL are set to N, which makes the respective devices go
missing from acpi tables.

Signed-off-by: Fabiano Rosas 
Reviewed-by: Thomas Huth 
Message-Id: <20230208194700.11035-13-faro...@suse.de>
Signed-off-by: Thomas Huth 
---
 tests/qtest/meson.build | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index e87cb18d8e..4110f8afc2 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -78,7 +78,9 @@ qtests_i386 = \
config_all_devices.has_key('CONFIG_Q35') and
 \
config_all_devices.has_key('CONFIG_VIRTIO_PCI') and 
 \
slirp.found() ? ['virtio-net-failover'] : []) + 
 \
-  (unpack_edk2_blobs ? ['bios-tables-test'] : []) +
 \
+  (unpack_edk2_blobs and   
 \
+   config_all_devices.has_key('CONFIG_HPET') and   
 \
+   config_all_devices.has_key('CONFIG_PARALLEL') ? ['bios-tables-test'] : []) 
+ \
   qtests_pci + 
 \
   qtests_cxl + 
 \
   ['fdc-test',
-- 
2.31.1

[PULL 09/10] net: stream: add a new option to automatically reconnect

[Jason Wang]

From: Laurent Vivier 

In stream mode, if the server shuts down there is currently
no way to reconnect the client to a new server without removing
the NIC device and the netdev backend (or to reboot).

This patch introduces a reconnect option that specifies a delay
to try to reconnect with the same parameters.

Add a new test in qtest to test the reconnect option and the
connect/disconnect events.

Signed-off-by: Laurent Vivier 
Signed-off-by: Jason Wang 
---
 net/stream.c|  53 ++-
 qapi/net.json   |   7 ++-
 qemu-options.hx |   6 +--
 tests/qtest/netdev-socket.c | 101 
 4 files changed, 162 insertions(+), 5 deletions(-)

diff --git a/net/stream.c b/net/stream.c
index 37ff727..9204b4c 100644
--- a/net/stream.c
+++ b/net/stream.c
@@ -39,6 +39,8 @@
 #include "io/channel-socket.h"
 #include "io/net-listener.h"
 #include "qapi/qapi-events-net.h"
+#include "qapi/qapi-visit-sockets.h"
+#include "qapi/clone-visitor.h"
 
 typedef struct NetStreamState {
 NetClientState nc;
@@ -49,11 +51,15 @@ typedef struct NetStreamState {
 guint ioc_write_tag;
 SocketReadState rs;
 unsigned int send_index;  /* number of bytes sent*/
+uint32_t reconnect;
+guint timer_tag;
+SocketAddress *addr;
 } NetStreamState;
 
 static void net_stream_listen(QIONetListener *listener,
   QIOChannelSocket *cioc,
   void *opaque);
+static void net_stream_arm_reconnect(NetStreamState *s);
 
 static gboolean net_stream_writable(QIOChannel *ioc,
 GIOCondition condition,
@@ -170,6 +176,7 @@ static gboolean net_stream_send(QIOChannel *ioc,
 qemu_set_info_str(&s->nc, "%s", "");
 
 qapi_event_send_netdev_stream_disconnected(s->nc.name);
+net_stream_arm_reconnect(s);
 
 return G_SOURCE_REMOVE;
 }
@@ -187,6 +194,14 @@ static gboolean net_stream_send(QIOChannel *ioc,
 static void net_stream_cleanup(NetClientState *nc)
 {
 NetStreamState *s = DO_UPCAST(NetStreamState, nc, nc);
+if (s->timer_tag) {
+g_source_remove(s->timer_tag);
+s->timer_tag = 0;
+}
+if (s->addr) {
+qapi_free_SocketAddress(s->addr);
+s->addr = NULL;
+}
 if (s->ioc) {
 if (QIO_CHANNEL_SOCKET(s->ioc)->fd != -1) {
 if (s->ioc_read_tag) {
@@ -346,12 +361,37 @@ static void net_stream_client_connected(QIOTask *task, 
gpointer opaque)
 error:
 object_unref(OBJECT(s->ioc));
 s->ioc = NULL;
+net_stream_arm_reconnect(s);
+}
+
+static gboolean net_stream_reconnect(gpointer data)
+{
+NetStreamState *s = data;
+QIOChannelSocket *sioc;
+
+s->timer_tag = 0;
+
+sioc = qio_channel_socket_new();
+s->ioc = QIO_CHANNEL(sioc);
+qio_channel_socket_connect_async(sioc, s->addr,
+ net_stream_client_connected, s,
+ NULL, NULL);
+return G_SOURCE_REMOVE;
+}
+
+static void net_stream_arm_reconnect(NetStreamState *s)
+{
+if (s->reconnect && s->timer_tag == 0) {
+s->timer_tag = g_timeout_add_seconds(s->reconnect,
+ net_stream_reconnect, s);
+}
 }
 
 static int net_stream_client_init(NetClientState *peer,
   const char *model,
   const char *name,
   SocketAddress *addr,
+  uint32_t reconnect,
   Error **errp)
 {
 NetStreamState *s;
@@ -364,6 +404,10 @@ static int net_stream_client_init(NetClientState *peer,
 s->ioc = QIO_CHANNEL(sioc);
 s->nc.link_down = true;
 
+s->reconnect = reconnect;
+if (reconnect) {
+s->addr = QAPI_CLONE(SocketAddress, addr);
+}
 qio_channel_socket_connect_async(sioc, addr,
  net_stream_client_connected, s,
  NULL, NULL);
@@ -380,7 +424,14 @@ int net_init_stream(const Netdev *netdev, const char *name,
 sock = &netdev->u.stream;
 
 if (!sock->has_server || !sock->server) {
-return net_stream_client_init(peer, "stream", name, sock->addr, errp);
+return net_stream_client_init(peer, "stream", name, sock->addr,
+  sock->has_reconnect ? sock->reconnect : 
0,
+  errp);
+}
+if (sock->has_reconnect) {
+error_setg(errp, "'reconnect' option is incompatible with "
+ "socket in server mode");
+return -1;
 }
 return net_stream_server_init(peer, "stream", name, sock->addr, errp);
 }
diff --git a/qapi/net.json b/qapi/net.json
index 522ac58..d6eb300 100644
--- a/qapi/net.json
+++ b/qapi/net.json
@@ -585,6 +585,10 @@
 # @addr: socket address to listen on (server=true)
 #or connect to (server=

Re: [PATCH 15/18] target/riscv: Allow debugger to access sstc CSRs

[weiwei]

On 2023/2/14 12:12, Bin Meng wrote:

At present with a debugger attached sstc CSRs can only be accssed
when CPU is in M-mode, or configured correctly.

Fix it by adjusting their predicate() routine logic so that the
static config check comes before the run-time check, as well as
addding a debugger check.

Signed-off-by: Bin Meng 


Similar typo, otherwise Reviewed-by: Weiwei Li 

Regards,
Weiwei Li

---

  target/riscv/csr.c | 19 ++-
  1 file changed, 14 insertions(+), 5 deletions(-)

diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index d6bcb7f275..c6a7745cb2 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -951,6 +951,19 @@ static RISCVException sstc(CPURISCVState *env, int csrno)
  return RISCV_EXCP_ILLEGAL_INST;
  }
  
+if ((csrno == CSR_VSTIMECMP) || (csrno == CSR_VSTIMECMPH)) {

+hmode_check = true;
+}
+
+RISCVException ret = hmode_check ? hmode(env, csrno) : smode(env, csrno);
+if (ret != RISCV_EXCP_NONE) {
+return ret;
+}
+
+if (env->debugger) {
+return RISCV_EXCP_NONE;
+}
+
  if (env->priv == PRV_M) {
  return RISCV_EXCP_NONE;
  }
@@ -971,11 +984,7 @@ static RISCVException sstc(CPURISCVState *env, int csrno)
  }
  }
  
-if ((csrno == CSR_VSTIMECMP) || (csrno == CSR_VSTIMECMPH)) {

-hmode_check = true;
-}
-
-return hmode_check ? hmode(env, csrno) : smode(env, csrno);
+return RISCV_EXCP_NONE;
  }
  
  static RISCVException sstc_32(CPURISCVState *env, int csrno)

Re: [RFC 33/52] i386: Rename init_topo_info() to init_apic_topo_info()

[Zhao Liu]

On Mon, Feb 13, 2023 at 02:27:18PM +0100, Philippe Mathieu-Daudé wrote:
> Date: Mon, 13 Feb 2023 14:27:18 +0100
> From: Philippe Mathieu-Daudé 
> Subject: Re: [RFC 33/52] i386: Rename init_topo_info() to
>  init_apic_topo_info()
> 
> On 13/2/23 10:50, Zhao Liu wrote:
> > From: Zhao Liu 
> > 
> > Rename init_topo_info() to init_apic_topo_info() to adapt
> > X86ApicidTopoInfo.
> > 
> > Co-Developed-by: Zhuocheng Ding 
> > Signed-off-by: Zhuocheng Ding 
> > Signed-off-by: Zhao Liu 
> > ---
> >   hw/i386/x86.c | 12 ++--
> >   include/hw/i386/x86.h |  3 ++-
> >   2 files changed, 8 insertions(+), 7 deletions(-)
> 
> 
> > diff --git a/include/hw/i386/x86.h b/include/hw/i386/x86.h
> > index ac6f1e4a74af..d84f7717900c 100644
> > --- a/include/hw/i386/x86.h
> > +++ b/include/hw/i386/x86.h
> > @@ -98,7 +98,8 @@ struct X86MachineState {
> >   #define TYPE_X86_MACHINE   MACHINE_TYPE_NAME("x86")
> >   OBJECT_DECLARE_TYPE(X86MachineState, X86MachineClass, X86_MACHINE)
> > -void init_topo_info(X86ApicidTopoInfo *topo_info, const X86MachineState 
> > *x86ms);
> > +void init_apicid_topo_info(X86ApicidTopoInfo *topo_info,
> > +   const X86MachineState *x86ms);
> 
> Maybe s/init_apicid_topo_info/init_apic_topo_info/?
> 
> Otherwise,
> 
> Reviewed-by: Philippe Mathieu-Daudé 
> 
Will remove the "id" suffix. Thanks!

Zhao

Re: [PATCH RESEND 09/18] i386: Fix comment style in topology.h

[wangyanan (Y)]

在 2023/2/13 17:36, Zhao Liu 写道:

From: Zhao Liu 

For function comments in this file, keep the comment style consistent
with other places.

Signed-off-by: Zhao Liu 
---
  include/hw/i386/topology.h | 33 +
  1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/include/hw/i386/topology.h b/include/hw/i386/topology.h
index b0174c18b7bd..5de905dc00d3 100644
--- a/include/hw/i386/topology.h
+++ b/include/hw/i386/topology.h
@@ -24,7 +24,8 @@
  #ifndef HW_I386_TOPOLOGY_H
  #define HW_I386_TOPOLOGY_H
  
-/* This file implements the APIC-ID-based CPU topology enumeration logic,

+/*
+ * This file implements the APIC-ID-based CPU topology enumeration logic,
   * documented at the following document:
   *   Intel® 64 Architecture Processor Topology Enumeration
   *   
http://software.intel.com/en-us/articles/intel-64-architecture-processor-topology-enumeration/
@@ -41,7 +42,8 @@
  
  #include "qemu/bitops.h"
  
-/* APIC IDs can be 32-bit, but beware: APIC IDs > 255 require x2APIC support

+/*
+ * APIC IDs can be 32-bit, but beware: APIC IDs > 255 require x2APIC support
   */
  typedef uint32_t apic_id_t;
  
@@ -60,8 +62,7 @@ typedef struct X86CPUTopoInfo {

  unsigned threads_per_core;
  } X86CPUTopoInfo;
  
-/* Return the bit width needed for 'count' IDs

- */
+/* Return the bit width needed for 'count' IDs */
  static unsigned apicid_bitwidth_for_count(unsigned count)
  {
  g_assert(count >= 1);
@@ -69,15 +70,13 @@ static unsigned apicid_bitwidth_for_count(unsigned count)
  return count ? 32 - clz32(count) : 0;
  }
  
-/* Bit width of the SMT_ID (thread ID) field on the APIC ID

- */
+/* Bit width of the SMT_ID (thread ID) field on the APIC ID */
  static inline unsigned apicid_smt_width(X86CPUTopoInfo *topo_info)
  {
  return apicid_bitwidth_for_count(topo_info->threads_per_core);
  }
  
-/* Bit width of the Core_ID field

- */
+/* Bit width of the Core_ID field */
  static inline unsigned apicid_core_width(X86CPUTopoInfo *topo_info)
  {
  /*
@@ -94,8 +93,7 @@ static inline unsigned apicid_die_width(X86CPUTopoInfo 
*topo_info)
  return apicid_bitwidth_for_count(topo_info->dies_per_pkg);
  }
  
-/* Bit offset of the Core_ID field

- */
+/* Bit offset of the Core_ID field */
  static inline unsigned apicid_core_offset(X86CPUTopoInfo *topo_info)
  {
  return apicid_smt_width(topo_info);
@@ -107,14 +105,14 @@ static inline unsigned apicid_die_offset(X86CPUTopoInfo 
*topo_info)
  return apicid_core_offset(topo_info) + apicid_core_width(topo_info);
  }
  
-/* Bit offset of the Pkg_ID (socket ID) field

- */
+/* Bit offset of the Pkg_ID (socket ID) field */
  static inline unsigned apicid_pkg_offset(X86CPUTopoInfo *topo_info)
  {
  return apicid_die_offset(topo_info) + apicid_die_width(topo_info);
  }
  
-/* Make APIC ID for the CPU based on Pkg_ID, Core_ID, SMT_ID

+/*
+ * Make APIC ID for the CPU based on Pkg_ID, Core_ID, SMT_ID
   *
   * The caller must make sure core_id < nr_cores and smt_id < nr_threads.
   */
@@ -127,7 +125,8 @@ static inline apic_id_t 
x86_apicid_from_topo_ids(X86CPUTopoInfo *topo_info,
 topo_ids->smt_id;
  }
  
-/* Calculate thread/core/package IDs for a specific topology,

+/*
+ * Calculate thread/core/package IDs for a specific topology,
   * based on (contiguous) CPU index
   */
  static inline void x86_topo_ids_from_idx(X86CPUTopoInfo *topo_info,
@@ -154,7 +153,8 @@ static inline void x86_topo_ids_from_idx(X86CPUTopoInfo 
*topo_info,
  topo_ids->smt_id = cpu_index % nr_threads;
  }
  
-/* Calculate thread/core/package IDs for a specific topology,

+/*
+ * Calculate thread/core/package IDs for a specific topology,
   * based on APIC ID
   */
  static inline void x86_topo_ids_from_apicid(apic_id_t apicid,
@@ -178,7 +178,8 @@ static inline void x86_topo_ids_from_apicid(apic_id_t 
apicid,
  topo_ids->pkg_id = apicid >> apicid_pkg_offset(topo_info);
  }
  
-/* Make APIC ID for the CPU 'cpu_index'

+/*
+ * Make APIC ID for the CPU 'cpu_index'
   *
   * 'cpu_index' is a sequential, contiguous ID for the CPU.
   */

Reviewed-by: Yanan Wang 

Thanks,
Yanan

Re: [PATCH V2 04/10] hw/riscv/virt: virt-acpi-build.c: Add basic ACPI tables

[Daniel Henrique Barboza]

On 2/14/23 00:43, Sunil V L wrote:

On Mon, Feb 13, 2023 at 03:48:04PM -0300, Daniel Henrique Barboza wrote:

Sunil,

This patch is a bit confusing to me. You're using functions that doesn't exist
in the code base yet (build_madt and build_rhct) because they are introduced
in later patches. This also means that this patch is not being compiled tested,
because otherwise it would throw a compile error. And the build of the file only
happens after patch 8.


My intention was to add the caller also in the same patch where the
function is added. I think I missed it when I split. Thanks!


Now, there is no hard rule in QEMU that dictates that every patch must be 
compile
tested, but nevertheless this is a good rule to follow that makes our lives 
easier
when bisecting and cherry-pick individual patches.

My suggestion for this patch is:

- squash both patches 7 and 8 into this patch to allow the file to be built;


Sure.


- remove the code that is referring to stuff that you haven't add yet:

$ git diff
diff --git a/hw/riscv/virt-acpi-build.c b/hw/riscv/virt-acpi-build.c
index 3c4da6c385..eb17029b64 100644
--- a/hw/riscv/virt-acpi-build.c
+++ b/hw/riscv/virt-acpi-build.c
@@ -156,12 +156,6 @@ virt_acpi_build(RISCVVirtState *s, AcpiBuildTables *tables)
  acpi_add_table(table_offsets, tables_blob);
  build_fadt_rev6(tables_blob, tables->linker, s, dsdt);
-acpi_add_table(table_offsets, tables_blob);
-build_madt(tables_blob, tables->linker, s);
-
-acpi_add_table(table_offsets, tables_blob);
-build_rhct(tables_blob, tables->linker, s);
-
  /* XSDT is pointed to by RSDP */
  xsdt = tables_blob->len;
  build_xsdt(tables_blob, tables->linker, table_offsets, s->oem_id,


- in patch 5, add back the lines in virt_acpi_build() that uses build_madt();

- in patch 6, add back the lines in virt_acpi_build() that uses build_rhct();


This will make this patch to be compiled and built right away without 
interfering with
the end result of the series.


Thanks!
  


One more suggestion:


On 2/13/23 11:40, Sunil V L wrote:

Add few basic ACPI tables and DSDT with few devices in a
new file virt-acpi-build.c.

These are mostly leveraged from arm64.


Quick rant that you've already heard: I don't really understand why there is so
much ACPI code duplication everywhere. I really don't. E.g. acpi_align_size() is
copied verbatim in hw/arm/virt-acpi-build.c, hw/i386/acpi-build.c and
hw/loongarch/acpi-build.c. I don't see why we can't have a common file in 
hw/acpi
with helpers and so on that every ACPI architecture can use, and then the
individual drivers for each arch can have its own magic sauce.


I completely agree that we better avoid duplication But I am bit
hesitant in this case because,
1) Low level functions which help in creating the namespace/static
tables are already common (ex: aml_append)

2) Using these basic routines, individual platforms can create the
namespace with appropriate devices and the methods.

ACPI name space is tightly coupled with a platform. While there may be
common devices like processors, uart etc, there can be difference in the
ACPI methods for each of those devices. For ex: CPU objects for one
platform may support _LPI method. uart may support _DSD for one platform
and other may use totally different UART. If we have to create common routines,
we will have to decide on all parameters the common function would need for
different platforms. Same concern with fw_cfg/virtio etc which look same
now but in future one platform can add a new method for these devices.

IMHO, even though it looks like we have the same function in each architecture
currently, this model allows us to have platforms with different devices with
different methods/features. Creating common routines now would probably make
them difficult to use in future.

acpi_align_size() is a simple wrapper. We don't need it if we directly
use the common function.

Since I see insistence let me try moving few functions like fw_cfg (virtio, pci 
in
future) to a common file in hw/acpi.


Nah. Doing that now will make this series rely on acks for every other ACPI 
arch to
push the RISC-V side.

Let's make this happen as is now to get ACPI in RISC-V working. We can think 
about
reducing overall ACPI duplication later. IMO it's enough for now to, mention in 
this
commit msg, which bits of the arm64 virt-acpi-build.c you changed for this 
RISC-V
version.


Thanks,

Daniel

  

All this said, instead of mentioning "this is mostly leveraged from arm64", you
can make a brief summary of the changes you've done from the arm64 version. This
will help guide the review into focusing on the novel code you're adding and
ignore the copied bits.


Sure.

Thanks!
Sunil

Re: [PATCH v4 14/16] qapi: deprecate "device" field of DEVICE_* events

[Daniel P . Berrangé]

On Tue, Feb 14, 2023 at 09:54:22AM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé  writes:
> 
> > On Mon, Feb 13, 2023 at 05:01:01PM +0300, Vladimir Sementsov-Ogievskiy 
> > wrote:
> >> The device field is redundant, because QOM path always include device
> >> ID when this ID exist.
> >
> > The flipside to that view is that applications configuring QEMU are
> > specifying the device ID for -device (CLI) / device_add (QMP) and
> > not the QOM path. IOW, the device ID is the more interesting field
> > than QOM path, so feels like the wrong one to be dropping.
> 
> QOM path is a reliable way to identify a device.  Device ID isn't:
> devices need not have one.  Therefore, dropping the QOM path would be
> wrong.
> 
> > Is there any real benefit to dropping this ? 
> 
> The device ID is a trap for the unwary: relying on it is fine until you
> run into a scenario where you have to deal with devices lacking IDs.

When a mgmt app is configuring QEMU though, it does it exclusively
with device ID values. If I add a device "-device foo,id=dev0",
and then later hot-unplug it "device_del dev0", it is pretty
reasonable to then expect that the DEVICE_DELETED even will then
include the ID value the app has been using elsewhere.

If the mgmt app is using IDs everywhere when dealing with a device,
then trap effectively doesn't exist for their usage scenario.

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

Re: [PATCH 0/3] qga/win/vss: add VSS backup type options

[Marc-André Lureau]

Hi

On Mon, Feb 13, 2023 at 8:20 PM Konstantin Kostiuk 
wrote:

> Hi Marc-André,
>
> Can you please review this patch set?
>
> Best Regards,
> Konstantin Kostiuk.
>
>
> On Thu, Feb 9, 2023 at 10:50 AM Kfir Manor  wrote:
>
>> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/775
>>
>> The problem, VSS backup type VSS-FULL (the only available VSS backup type
>> currently) can break other backups that use VSS-FULL(for example,
>> Bareos-Fullbackup).
>>
>> Fix, add other backup types.
>>
>> Implementation, put the desired backup type number inside Regkey value
>> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS
>> Provider\VssOption, so that the program can query the desired backup type.
>>
>> VSS backup types:
>> number   type
>> 1VSS_BT_FULL
>> 2VSS_BT_INCREMENTAL
>> 3VSS_BT_DIFFERENTIAL
>> 4VSS_BT_LOG
>> 5VSS_BT_COPY
>>
>> for more information about the different backup types
>> https://learn.microsoft.com/en-us/windows/win32/vss/vss-backup-state
>>
>> Additionally, the program would work as before with VSS-FULL in cases
>> where VssOption doesn't exist, or VssOption value isn't a known backup type.
>>
>
The patch series looks ok (just minor stylistic changes could be made), but
I do not fully understand the way qga-vss.dll works in details for
freeze/thaw.

My understanding is that FIFREEZE do not exist on win32, so we call VSS to
tell (some) apps to flush/freeze pretending a backup is going on, then we
get notified on completion by our own provider (CommitSnapshots) and wait
there for thaw (1 min while VM is suspended?).

But I don't understand how this interacts with other providers (real backup
solutions), and why they are involved/conflict as described in
https://gitlab.com/qemu-project/qemu/-/issues/775.




>
>> Kfir Manor (3):
>>   add VssOption to installer
>>   query VSS backup type
>>   requester_freeze changes
>>
>>  qga/installer/qemu-ga.wxs   |  4 
>>  qga/vss-win32/requester.cpp | 41 -
>>  qga/vss-win32/vss-handles.h |  3 +++
>>  3 files changed, 47 insertions(+), 1 deletion(-)
>>
>> --
>> 2.38.1
>>
>>

Re: [PATCH 4/4] target/ppc: fix warning with clang-15

[Philippe Mathieu-Daudé]

On 13/2/23 17:13, Pierrick Bouvier wrote:

When compiling for windows-arm64 using clang-15, it reports a sometimes
uninitialized variable. This seems to be a false positive, as a default
case guards switch expressions, preventing to return an uninitialized
value, but clang seems unhappy with assert definition.

Setting the rnd variable to zero does not hurt anyway.

../target/ppc/dfp_helper.c:141:13: error: variable 'rnd' is used uninitialized 
whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] 
 assert(0); /* 
cannot get here */  

  ^
../include/qemu/osdep.h:229:20: note: expanded from macro 'assert'  

  #define assert(x)  g_assert(x)


 ^~~
/clangarm64/bin/../include/glib-2.0/glib/gtestutils.h:235:49: note: expanded 
from macro 'g_assert'   
if G_LIKELY 
(expr) ; else \
 ^~~
/clangarm64/bin/../include/glib-2.0/glib/gmacros.h:1186:25: note: expanded from 
macro 'G_LIKELY'
 ^~~
../target/ppc/dfp_helper.c:144:42: note: uninitialized use occurs here
 decContextSetRounding(&dfp->context, rnd);

Signed-off-by: Pierrick Bouvier 
---
  target/ppc/dfp_helper.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/ppc/dfp_helper.c b/target/ppc/dfp_helper.c
index cc024316d5..0b4b280683 100644
--- a/target/ppc/dfp_helper.c
+++ b/target/ppc/dfp_helper.c
@@ -69,7 +69,7 @@ struct PPC_DFP {
  
  static void dfp_prepare_rounding_mode(decContext *context, uint64_t fpscr)

  {
-enum rounding rnd;
+enum rounding rnd = 0;
  
  switch ((fpscr & FP_DRN) >> FPSCR_DRN0) {

  case 0:
@@ -106,7 +106,7 @@ static void dfp_prepare_rounding_mode(decContext *context, 
uint64_t fpscr)
  static void dfp_set_round_mode_from_immediate(uint8_t r, uint8_t rmc,
struct PPC_DFP *dfp)
  {
-enum rounding rnd;
+enum rounding rnd = 0;


Could DEC_ROUND_DEFAULT be clearer?

Re: [PATCH v4 14/16] qapi: deprecate "device" field of DEVICE_* events

[Daniel P . Berrangé]

On Tue, Feb 14, 2023 at 12:57:28PM +0100, Markus Armbruster wrote:
> Daniel P. Berrangé  writes:
> 
> > On Tue, Feb 14, 2023 at 09:54:22AM +0100, Markus Armbruster wrote:
> >> Daniel P. Berrangé  writes:
> >> 
> >> > On Mon, Feb 13, 2023 at 05:01:01PM +0300, Vladimir Sementsov-Ogievskiy 
> >> > wrote:
> >> >> The device field is redundant, because QOM path always include device
> >> >> ID when this ID exist.
> >> >
> >> > The flipside to that view is that applications configuring QEMU are
> >> > specifying the device ID for -device (CLI) / device_add (QMP) and
> >> > not the QOM path. IOW, the device ID is the more interesting field
> >> > than QOM path, so feels like the wrong one to be dropping.
> >> 
> >> QOM path is a reliable way to identify a device.  Device ID isn't:
> >> devices need not have one.  Therefore, dropping the QOM path would be
> >> wrong.
> >> 
> >> > Is there any real benefit to dropping this ? 
> >> 
> >> The device ID is a trap for the unwary: relying on it is fine until you
> >> run into a scenario where you have to deal with devices lacking IDs.
> >
> > When a mgmt app is configuring QEMU though, it does it exclusively
> > with device ID values. If I add a device "-device foo,id=dev0",
> > and then later hot-unplug it "device_del dev0", it is pretty
> > reasonable to then expect that the DEVICE_DELETED even will then
> > include the ID value the app has been using elsewhere.
> 
> The management application would be well advised to use QOM paths with
> device_del, because only that works even for devices created by default
> (which have no ID), and devices the user created behind the management
> application's back.

If an application is using -nodefaults, then the only devices which
exist will be those which are hardwired into the machine, and they
can't be used with device_del anyway as they're hardwired.

So the only reason is to cope with devices created secretly by
the users, and that's a hairy enough problem that most apps won't
even try to cope with it.

At least in terms of the device hotplug area, it feels like we're
adding an extra hurdle for apps to solve a problem that they don't
actually face in practice.

QOM paths are needed in some other QMP commands though, where
there is definite need to refer to devices that are hardwired,
most obviously qom-set/qom-get.

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

[PATCH v2 11/12] bsd-user: implement sysctlbyname(2)

[Warner Losh]

From: Kyle Evans 

do_freebsd_sysctlbyname needs to translate the 'name' back down to a OID
so we can intercept the special ones. Do that and call the common wrapper
do_freebsd_sysctl_oid.

Signed-off-by: Kyle Evans 
Reviewed-by: Warner Losh 
Signed-off-by: Warner Losh 
---
 bsd-user/freebsd/os-sys.c | 67 +++
 bsd-user/freebsd/os-syscall.c |  4 +++
 bsd-user/qemu.h   |  3 ++
 3 files changed, 74 insertions(+)

diff --git a/bsd-user/freebsd/os-sys.c b/bsd-user/freebsd/os-sys.c
index e70f8f21c52..33720ddbb38 100644
--- a/bsd-user/freebsd/os-sys.c
+++ b/bsd-user/freebsd/os-sys.c
@@ -481,6 +481,73 @@ out:
 return ret;
 }
 
+/*
+ * This syscall was created to make sysctlbyname(3) more efficient, but we 
can't
+ * really provide it in bsd-user.  Notably, we must always translate the names
+ * independently since some sysctl values have to be faked for the target
+ * environment, so it still has to break down to two syscalls for the 
underlying
+ * implementation.
+ */
+abi_long do_freebsd_sysctlbyname(CPUArchState *env, abi_ulong namep,
+int32_t namelen, abi_ulong oldp, abi_ulong oldlenp, abi_ulong newp,
+abi_ulong newlen)
+{
+abi_long ret = -TARGET_EFAULT;
+void *holdp = NULL, *hnewp = NULL;
+char *snamep = NULL;
+int oid[CTL_MAXNAME + 2];
+size_t holdlen, oidplen;
+abi_ulong oldlen = 0;
+
+/* oldlenp is read/write, pre-check here for write */
+if (oldlenp) {
+if (!access_ok(VERIFY_WRITE, oldlenp, sizeof(abi_ulong)) ||
+get_user_ual(oldlen, oldlenp)) {
+goto out;
+}
+}
+snamep = lock_user_string(namep);
+if (snamep == NULL) {
+goto out;
+}
+if (newp) {
+hnewp = lock_user(VERIFY_READ, newp, newlen, 1);
+if (hnewp == NULL) {
+goto out;
+}
+}
+if (oldp) {
+holdp = lock_user(VERIFY_WRITE, oldp, oldlen, 0);
+if (holdp == NULL) {
+goto out;
+}
+}
+holdlen = oldlen;
+
+oidplen = sizeof(oid) / sizeof(int);
+if (sysctlnametomib(snamep, oid, &oidplen) != 0) {
+ret = -TARGET_EINVAL;
+goto out;
+}
+
+ret = do_freebsd_sysctl_oid(env, oid, oidplen, holdp, &holdlen, hnewp,
+newlen);
+
+/*
+ * writeability pre-checked above. __sysctl(2) returns ENOMEM and updates
+ * oldlenp for the proper size to use.
+ */
+if (oldlenp && (ret == 0 || ret == -TARGET_ENOMEM)) {
+put_user_ual(holdlen, oldlenp);
+}
+out:
+unlock_user(snamep, namep, 0);
+unlock_user(holdp, oldp, ret == 0 ? holdlen : 0);
+unlock_user(hnewp, newp, 0);
+
+return ret;
+}
+
 abi_long do_freebsd_sysctl(CPUArchState *env, abi_ulong namep, int32_t namelen,
 abi_ulong oldp, abi_ulong oldlenp, abi_ulong newp, abi_ulong newlen)
 {
diff --git a/bsd-user/freebsd/os-syscall.c b/bsd-user/freebsd/os-syscall.c
index 20ab3d4d9a1..179a20c304b 100644
--- a/bsd-user/freebsd/os-syscall.c
+++ b/bsd-user/freebsd/os-syscall.c
@@ -498,6 +498,10 @@ static abi_long freebsd_syscall(void *cpu_env, int num, 
abi_long arg1,
 ret = do_freebsd_sysctl(cpu_env, arg1, arg2, arg3, arg4, arg5, arg6);
 break;
 
+case TARGET_FREEBSD_NR___sysctlbyname: /* sysctlbyname(2) */
+ret = do_freebsd_sysctlbyname(cpu_env, arg1, arg2, arg3, arg4, arg5, 
arg6);
+break;
+
 case TARGET_FREEBSD_NR_sysarch: /* sysarch(2) */
 ret = do_freebsd_sysarch(cpu_env, arg1, arg2);
 break;
diff --git a/bsd-user/qemu.h b/bsd-user/qemu.h
index c7248cfde6f..e24a8cfcfb1 100644
--- a/bsd-user/qemu.h
+++ b/bsd-user/qemu.h
@@ -254,6 +254,9 @@ int host_to_target_errno(int err);
 /* os-sys.c */
 abi_long do_freebsd_sysctl(CPUArchState *env, abi_ulong namep, int32_t namelen,
 abi_ulong oldp, abi_ulong oldlenp, abi_ulong newp, abi_ulong newlen);
+abi_long do_freebsd_sysctlbyname(CPUArchState *env, abi_ulong namep,
+int32_t namelen, abi_ulong oldp, abi_ulong oldlenp, abi_ulong newp,
+abi_ulong newlen);
 abi_long do_freebsd_sysarch(void *cpu_env, abi_long arg1, abi_long arg2);
 
 /* user access */
-- 
2.39.1

Re: [PATCH 2/4] hw: Replace dev->parent_bus by qdev_get_parent_bus(dev)

[Philippe Mathieu-Daudé]

On 14/2/23 00:19, Richard Henderson wrote:

On 2/12/23 13:03, Philippe Mathieu-Daudé wrote:

On 12/2/23 23:47, Philippe Mathieu-Daudé wrote:

DeviceState::parent_bus is an internal field and should be
accessed by the qdev_get_parent_bus() helper. Replace all
uses in hw/ except the QDev uses in hw/core/.

Signed-off-by: Philippe Mathieu-Daudé 
---
  hw/audio/intel-hda.c    |  2 +-
  hw/block/fdc.c  |  2 +-
  hw/block/swim.c |  2 +-
  hw/ide/qdev.c   |  4 ++--
  hw/net/virtio-net.c |  2 +-
  hw/pci-bridge/pci_expander_bridge.c |  2 +-
  hw/scsi/scsi-bus.c  |  2 +-
  hw/usb/bus.c    |  2 +-
  hw/usb/desc.c   |  2 +-
  hw/usb/dev-smartcard-reader.c   | 16 
  10 files changed, 18 insertions(+), 18 deletions(-)


I missed:


Did you use a temporary rename of the field to catch all the uses?


No, git-grep. Good idea.

  void hda_codec_response(HDACodecDevice *dev, bool solicited, 
uint32_t response)

  {
-    HDACodecBus *bus = HDA_BUS(dev->qdev.parent_bus);
+    HDACodecBus *bus = HDA_BUS(qdev_get_parent_bus(DEVICE(dev)));


I'm never sure the cast is clearer than &dev->qdev.


Maybe this one isn't obvious, but see for QOM macros use:
https://lore.kernel.org/qemu-devel/20230213170145.45666-3-phi...@linaro.org/:

-vcdev->vdev.dev = &vcdev->cdev.parent_obj.parent_obj;
+vcdev->vdev.dev = DEVICE(vcdev);

We should agree on how we want to use this API. If the
DeviceState::parent_bus field isn't considered internal,
the we should remove the qdev_get_parent_bus() helper which
is simply:

hw/core/qdev.c:333:BusState *qdev_get_parent_bus(DeviceState *dev)
hw/core/qdev.c-334-{
hw/core/qdev.c-335-return dev->parent_bus;
hw/core/qdev.c-336-}

Note the alternate series expanding QDev macros:
https://lore.kernel.org/qemu-devel/20230213105609.6173-1-phi...@linaro.org/


But it seems the normal way in qemu...

Acked-by: Richard Henderson 


Thanks!

Re: [PATCH v3 06/10] monitor: release the lock before calling close()

[Markus Armbruster]

marcandre.lur...@redhat.com writes:

> From: Marc-André Lureau 
>
> As per comment, presumably to avoid syscall in critical section.
>
> Fixes: 0210c3b39bef08 ("monitor: Use LOCK_GUARD macros")
> Signed-off-by: Marc-André Lureau 
> ---
>  monitor/fds.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/monitor/fds.c b/monitor/fds.c
> index 26b39a0ce6..03c5e97c35 100644
> --- a/monitor/fds.c
> +++ b/monitor/fds.c
> @@ -80,7 +80,7 @@ void qmp_getfd(const char *fdname, Error **errp)
>  return;
>  }
>  
> -QEMU_LOCK_GUARD(&cur_mon->mon_lock);
> +qemu_mutex_lock(&cur_mon->mon_lock);
>  QLIST_FOREACH(monfd, &cur_mon->fds, next) {
>  if (strcmp(monfd->name, fdname) != 0) {
>  continue;
> @@ -88,6 +88,7 @@ void qmp_getfd(const char *fdname, Error **errp)
>  
>  tmp_fd = monfd->fd;
>  monfd->fd = fd;
> +qemu_mutex_unlock(&cur_mon->mon_lock);
>  /* Make sure close() is outside critical section */
>  close(tmp_fd);
>  return;
> @@ -98,6 +99,7 @@ void qmp_getfd(const char *fdname, Error **errp)
>  monfd->fd = fd;
>  
>  QLIST_INSERT_HEAD(&cur_mon->fds, monfd, next);
> +qemu_mutex_unlock(&cur_mon->mon_lock);
>  }
>  
>  void qmp_closefd(const char *fdname, Error **errp)

This confused me.  I think I understand now, but let's double-check.

You're reverting commit 0210c3b39bef08 for qmp_getfd() because it
extended the criticial section beyond the close(), invalidating the
comment.  Correct?

Did it actually break anything?

[PULL 20/22] tests/qtest: Don't build virtio-serial-test.c if device not present

[Thomas Huth]

From: Fabiano Rosas 

The virtconsole device might not be present in the QEMU build that is
being tested.

Signed-off-by: Fabiano Rosas 
Message-Id: <20230213210738.9719-5-faro...@suse.de>
Reviewed-by: Thomas Huth 
Signed-off-by: Thomas Huth 
---
 tests/qtest/meson.build | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index 4110f8afc2..222e1892fb 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -257,10 +257,14 @@ qos_test_ss.add(
   'virtio-net-test.c',
   'virtio-rng-test.c',
   'virtio-scsi-test.c',
-  'virtio-serial-test.c',
   'virtio-iommu-test.c',
   'vmxnet3-test.c',
 )
+
+if config_all_devices.has_key('CONFIG_VIRTIO_SERIAL')
+  qos_test_ss.add(files('virtio-serial-test.c'))
+endif
+
 if config_host.has_key('CONFIG_POSIX')
   qos_test_ss.add(files('e1000e-test.c'))
 endif
-- 
2.31.1

[PATCH 13/18] target/riscv: Allow debugger to access seed CSR

[Bin Meng]

At present seed CSR is not reported in the CSR XML hence gdb cannot
access it.

Fix it by addding a debugger check in its predicate() routine.

Signed-off-by: Bin Meng 
---

 target/riscv/csr.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/target/riscv/csr.c b/target/riscv/csr.c
index 515b05348b..f1075b5728 100644
--- a/target/riscv/csr.c
+++ b/target/riscv/csr.c
@@ -458,6 +458,10 @@ static RISCVException seed(CPURISCVState *env, int csrno)
 }
 
 #if !defined(CONFIG_USER_ONLY)
+if (env->debugger) {
+return RISCV_EXCP_NONE;
+}
+
 /*
  * With a CSR read-write instruction:
  * 1) The seed CSR is always available in machine mode as normal.
-- 
2.25.1

Re: [PATCH] vhost: accept VIRTIO_F_ORDER_PLATFORM as a valid SVQ feature

[Michael S. Tsirkin]

On Tue, Feb 14, 2023 at 08:02:08AM +0100, Eugenio Perez Martin wrote:
> On Tue, Feb 14, 2023 at 7:31 AM Jason Wang  wrote:
> >
> > On Tue, Feb 14, 2023 at 3:19 AM Eugenio Pérez  wrote:
> > >
> > > VIRTIO_F_ORDER_PLATFORM indicates that memory accesses by the driver and
> > > the device are ordered in a way described by the platform.  Since vDPA
> > > devices may be backed by a hardware devices, let's allow
> > > VIRTIO_F_ORDER_PLATFORM.
> > >
> > > Signed-off-by: Eugenio Pérez 
> > > ---
> > >  hw/virtio/vhost-shadow-virtqueue.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/hw/virtio/vhost-shadow-virtqueue.c 
> > > b/hw/virtio/vhost-shadow-virtqueue.c
> > > index 4307296358..6bb1998f12 100644
> > > --- a/hw/virtio/vhost-shadow-virtqueue.c
> > > +++ b/hw/virtio/vhost-shadow-virtqueue.c
> > > @@ -34,6 +34,7 @@ bool vhost_svq_valid_features(uint64_t features, Error 
> > > **errp)
> > >  switch (b) {
> > >  case VIRTIO_F_ANY_LAYOUT:
> > >  case VIRTIO_RING_F_EVENT_IDX:
> > > +case VIRTIO_F_ORDER_PLATFORM:
> >
> > Do we need to add this bit to vdpa_feature_bits[] as well?
> >
> 
> If we want to pass it to the guest, yes we should. I'll send another
> patch for it.
> 
> But I think that should be done on top / in parallel actually.
> 
> Open question: Should all vdpa hardware devices offer it? Or this is
> only needed on specific archs?
> 
> Thanks!

I don't get what this is doing at all frankly. vdpa has to
pass VIRTIO_F_ORDER_PLATFORM to guest at all times - unless
- it's a x86 host where it kind of works anyway
- it's vduse which frankly is so slow we can do VIRTIO_F_ORDER_PLATFORM anyway.
In short VIRTIO_F_ORDER_PLATFORM has nothing to do with the device
and everything with qemu itself.

Yea we can allow VIRTIO_F_ORDER_PLATFORM from kernel but given
we never did at this point it will need a protocol feature bit.
I don't think it's worth it ..


-- 
MST

Re: [RFC 06/52] hw/cpu: Introduce hybrid CPU topology

[Zhao Liu]

On Mon, Feb 13, 2023 at 09:18:05PM +0800, wangyanan (Y) wrote:
> Date: Mon, 13 Feb 2023 21:18:05 +0800
> From: "wangyanan (Y)" 
> Subject: Re: [RFC 06/52] hw/cpu: Introduce hybrid CPU topology
> 
> Hi Zhao,
> 
> 在 2023/2/13 17:49, Zhao Liu 写道:
> > From: Zhao Liu 
> > 
> > For smp systems, the parts in one topology level are the same. But now
> > there are more and more systems with hybrid architectures. Different
> > parts of the same topology level may have differences. For example,
> > Intel's Alder Lake series CPU has two types of cores, so the CPU
> > topology is no longer symmetrical.
> > 
> > The hybrid topology is compatible with the smp topology type, that is,
> > different parts on the same level of the hybrid topology can set to be
> > the same, but the hybrid topology will introduce more complexity (need
> > to allocate more memory, organized with array or linked-list), so the
> > original smp topology support is retained while introducing the hybrid
> > topology, and the hybrid topology is only built when the hybrid is
> > explicitly required.
> > 
> > Therefore, we introduce the definition support of hybrid cpu topology
> > here. At the same time, in order to unify with the original smp, we
> > introduce a new cpu topology structure that can support smp topology
> > or hybrid topology. This structure will replace the CpuTopology type (in
> > include/hw/boards.h) used by MachineState.smp.
> > 
> > As for now, we only support two hybrid topology levels: core and
> > cluster.
> > 
> > Signed-off-by: Zhao Liu 
> > ---
> >   MAINTAINERS   |   1 +
> >   include/hw/cpu/cpu-topology.h | 117 ++
> >   qapi/machine.json |  12 
> >   3 files changed, 130 insertions(+)
> >   create mode 100644 include/hw/cpu/cpu-topology.h
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 58794885ced3..918a9418d98e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1742,6 +1742,7 @@ F: qapi/machine-target.json
> >   F: include/hw/boards.h
> >   F: include/hw/core/cpu.h
> >   F: include/hw/cpu/cluster.h
> > +F: include/hw/cpu/cpu-topology.h
> Should't it be in include/hw/core/* directory？

Yes, I'll move it to the correct place.

> >   F: include/sysemu/numa.h
> >   F: tests/unit/test-smp-parse.c
> >   T: git https://gitlab.com/ehabkost/qemu.git machine-next
> > diff --git a/include/hw/cpu/cpu-topology.h b/include/hw/cpu/cpu-topology.h
> > new file mode 100644
> > index ..8268ea3a8569
> > --- /dev/null
> > +++ b/include/hw/cpu/cpu-topology.h
> > @@ -0,0 +1,117 @@
> > +/*
> > + * CPU topology defination for Machine core
> > + *
> > + * Copyright (c) 2023 Intel Corporation
> > + * Author: Zhao Liu 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License,
> > + * or (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU General Public License
> > + * along with this program; if not, see .
> > + */
> > +
> > +#ifndef CPU_TOPOLOGY_H
> > +#define CPU_TOPOLOGY_H
> > +
> > +#include "qemu/queue.h"
> > +
> > +/**
> > + * SmpCpuTopology - smp cpu topology defination.
> > + *
> > + * For smp system, the parts in one topology level are the same.
> > + *
> > + * @sockets: the number of sockets on the machine
> > + * @dies: the number of dies in one socket
> > + * @clusters: the number of clusters in one die
> > + * @cores: the number of cores in one cluster
> > + * @threads: the number of threads in one core
> > + */
> > +typedef struct SmpCpuTopology {
> > +unsigned int sockets;
> > +unsigned int dies;
> > +unsigned int clusters;
> > +unsigned int cores;
> > +unsigned int threads;
> > +} SmpCpuTopology;
> > +
> > +/**
> > + * HybridCore - hybrid core topology defination:
> > + * @threads: the number of threads in one core.
> > + */
> > +typedef struct HybridCore {
> > +unsigned int threads;
> > +} HybridCore;
> > +
> > +/**
> > + * HybridCluster - hybrid cluster topology defination:
> > + * @cores: the number of cores in current cluster.
> > + * @core_list: the array includes all the cores that belong to current
> > + * cluster.
> > + */
> > +typedef struct HybridCluster {
> > +unsigned int cores;
> > +HybridCore *core_list;
> > +} HybridCluster;
> > +
> > +/**
> > + * HybridCpuTopology - hybrid cpu topology defination.
> > + *
> > + * At present we only support two heterogeneous topology levels: core
> > + * and cluster. For heterogeneous levels, we need additional structs
> > + * to define 

Re: [Patch 07/14] target/riscv: Indent fixes in cpu.c

[Daniel Henrique Barboza]

On 2/14/23 05:38, Weiwei Li wrote:

Fix indent problems in vector related check

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---



Reviewed-by: Daniel Henrique Barboza 


  target/riscv/cpu.c | 44 ++--
  1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
index 8fe76707a0..73711d392d 100644
--- a/target/riscv/cpu.c
+++ b/target/riscv/cpu.c
@@ -798,7 +798,7 @@ static void riscv_cpu_validate_set_extensions(RISCVCPU 
*cpu, Error **errp)
  }
  if (cpu->cfg.ext_f) {
  error_setg(errp,
-"Zfinx cannot be supported together with F extension");
+   "Zfinx cannot be supported together with F extension");
  return;
  }
  }
@@ -861,40 +861,40 @@ static void riscv_cpu_validate_set_extensions(RISCVCPU 
*cpu, Error **errp)
  ext |= RVV;
  if (!is_power_of_2(cpu->cfg.vlen)) {
  error_setg(errp,
-"Vector extension VLEN must be power of 2");
+   "Vector extension VLEN must be power of 2");
  return;
  }
  if (cpu->cfg.vlen > RV_VLEN_MAX || cpu->cfg.vlen < 128) {
  error_setg(errp,
-"Vector extension implementation only supports VLEN "
-"in the range [128, %d]", RV_VLEN_MAX);
+   "Vector extension implementation only supports VLEN "
+   "in the range [128, %d]", RV_VLEN_MAX);
  return;
  }
  if (!is_power_of_2(cpu->cfg.elen)) {
  error_setg(errp,
-"Vector extension ELEN must be power of 2");
+   "Vector extension ELEN must be power of 2");
  return;
  }
-if (cpu->cfg.elen > 64 || cpu->cfg.elen < 8) {
-error_setg(errp,
-"Vector extension implementation only supports ELEN "
-"in the range [8, 64]");
-return;
-}
-if (cpu->cfg.vext_spec) {
-if (!g_strcmp0(cpu->cfg.vext_spec, "v1.0")) {
-vext_version = VEXT_VERSION_1_00_0;
-} else {
+if (cpu->cfg.elen > 64 || cpu->cfg.elen < 8) {
  error_setg(errp,
-   "Unsupported vector spec version '%s'",
-   cpu->cfg.vext_spec);
+   "Vector extension implementation only supports ELEN "
+   "in the range [8, 64]");
  return;
  }
-} else {
-qemu_log("vector version is not specified, "
- "use the default value v1.0\n");
-}
-set_vext_version(env, vext_version);
+if (cpu->cfg.vext_spec) {
+if (!g_strcmp0(cpu->cfg.vext_spec, "v1.0")) {
+vext_version = VEXT_VERSION_1_00_0;
+} else {
+error_setg(errp,
+   "Unsupported vector spec version '%s'",
+   cpu->cfg.vext_spec);
+return;
+}
+} else {
+qemu_log("vector version is not specified, "
+ "use the default value v1.0\n");
+}
+set_vext_version(env, vext_version);
  }
  if (cpu->cfg.ext_j) {
  ext |= RVJ;

[PULL 10/10] vdpa: fix VHOST_BACKEND_F_IOTLB_ASID flag check

[Jason Wang]

From: Eugenio Pérez 

VHOST_BACKEND_F_IOTLB_ASID is the feature bit, not the bitmask. Since
the device under test also provided VHOST_BACKEND_F_IOTLB_MSG_V2 and
VHOST_BACKEND_F_IOTLB_BATCH, this went unnoticed.

Fixes: c1a1008685 ("vdpa: always start CVQ in SVQ mode if possible")
Signed-off-by: Eugenio Pérez 
Reviewed-by: Michael S. Tsirkin 
Acked-by: Jason Wang 
Signed-off-by: Jason Wang 
---
 net/vhost-vdpa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/vhost-vdpa.c b/net/vhost-vdpa.c
index 1a13a34..de5ed8f 100644
--- a/net/vhost-vdpa.c
+++ b/net/vhost-vdpa.c
@@ -384,7 +384,7 @@ static int vhost_vdpa_net_cvq_start(NetClientState *nc)
 g_strerror(errno), errno);
 return -1;
 }
-if (!(backend_features & VHOST_BACKEND_F_IOTLB_ASID) ||
+if (!(backend_features & BIT_ULL(VHOST_BACKEND_F_IOTLB_ASID)) ||
 !vhost_vdpa_net_valid_svq_features(v->dev->features, NULL)) {
 return 0;
 }
-- 
2.7.4

Re: [PATCH 6/7] hw/isa: Assert isa_register_portio_list() gets non-NULL ISA device

[Philippe Mathieu-Daudé]

On 8/2/23 20:47, Richard Henderson wrote:

On 2/7/23 14:07, Philippe Mathieu-Daudé wrote:

The previous commit removed the single call to
isa_register_portio_list() with dev=NULL. To be
sure we won't reintroduce such weird (ab)use,
add an assertion.

Signed-off-by: Philippe Mathieu-Daudé 


Reviewed-by: Richard Henderson 

I wonder how much use of __attribute__((nonnull)) we should be making.


__attribute__((nonnull)) is compile-time, but seems weaker than the
good old runtime assert():

 void a0(void *ptr)
 {
   assert(ptr);
 }

 __attribute__((nonnull)) void a1(void *ptr)
 {
   // can no use assert(ptr) because compiler warning
 }

 void b0(void *x)
 {
   a(NULL); // runtime assertion
 }

 void b(void *x)
 {
   a1(NULL); // compile error
 }

 void c0(void *x)
 {
   a0(x);
 }

 void c1(void *x)
 {
   a1(x);
 }

 void d0(void *x)
 {
   c0(NULL); // runtime assertion
 }

 void d1(void *x)
 {
   c1(NULL); // no compile error, no assertion!
 }

I realize we'd probably want to add -fno-delete-null-pointer-checks if 
we make too much use of that.

[PULL 01/22] configure: Bump minimum Clang version to 10.0

[Thomas Huth]

Anthony Perard recently reported some problems with Clang v6.0 from
Ubuntu Bionic (with regards to the -Wmissing-braces configure test).
Since we're not officially supporting that version of Ubuntu anymore,
we should better bump our minimum version check in the configure script
instead of using our time to fix problems of unsupported compilers.
According to repology.org, our supported distros ship these versions
of Clang (looking at the highest version only):

  Fedora 36: 14.0.5
  CentOS 8 (RHEL-8): 12.0.1
  Debian 11: 13.0.1
 OpenSUSE Leap 15.4: 13.0.1
   Ubuntu LTS 20.04: 12.0.0
  FreeBSD Ports: 15.0.7
  NetBSD pkgsrc: 15.0.7
   Homebrew: 15.0.7
MSYS2 mingw: 15.0.7
Haiku ports: 12.0.1

While it seems like we could update to v12.0.0 from that point of view,
the default version on Ubuntu 20.04 is still v10.0, and we use that for
our CI tests based via the tests/docker/dockerfiles/ubuntu2004.docker
file.

Thus let's make v10.0 our minimum version now (which corresponds to
Apple Clang version v12.0). The -Wmissing-braces check can then be
removed, too, since both our minimum GCC and our minimum Clang version
now handle this correctly.

Message-Id: <20230131180239.1582302-1-th...@redhat.com>
Reviewed-by: Alex Bennée 
Reviewed-by: Richard Henderson 
Signed-off-by: Thomas Huth 
---
 configure | 25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/configure b/configure
index 64960c6000..00415f0b48 100755
--- a/configure
+++ b/configure
@@ -1018,7 +1018,7 @@ cat << EOF
   debug-tcg   TCG debugging (default is disabled)
   debug-info  debugging information
   safe-stack  SafeStack Stack Smash Protection. Depends on
-  clang/llvm >= 3.7 and requires coroutine backend ucontext.
+  clang/llvm and requires coroutine backend ucontext.
 
 NOTE: The object files are built at the place where configure is launched
 EOF
@@ -1138,12 +1138,12 @@ fi
 cat > $TMPC << EOF
 #if defined(__clang_major__) && defined(__clang_minor__)
 # ifdef __apple_build_version__
-#  if __clang_major__ < 10 || (__clang_major__ == 10 && __clang_minor__ < 0)
-#   error You need at least XCode Clang v10.0 to compile QEMU
+#  if __clang_major__ < 12 || (__clang_major__ == 12 && __clang_minor__ < 0)
+#   error You need at least XCode Clang v12.0 to compile QEMU
 #  endif
 # else
-#  if __clang_major__ < 6 || (__clang_major__ == 6 && __clang_minor__ < 0)
-#   error You need at least Clang v6.0 to compile QEMU
+#  if __clang_major__ < 10 || (__clang_major__ == 10 && __clang_minor__ < 0)
+#   error You need at least Clang v10.0 to compile QEMU
 #  endif
 # endif
 #elif defined(__GNUC__) && defined(__GNUC_MINOR__)
@@ -1156,7 +1156,7 @@ cat > $TMPC << EOF
 int main (void) { return 0; }
 EOF
 if ! compile_prog "" "" ; then
-error_exit "You need at least GCC v7.4 or Clang v6.0 (or XCode Clang 
v10.0)"
+error_exit "You need at least GCC v7.4 or Clang v10.0 (or XCode Clang 
v12.0)"
 fi
 
 # Accumulate -Wfoo and -Wno-bar separately.
@@ -1261,19 +1261,6 @@ EOF
   fi
 fi
 
-# Disable -Wmissing-braces on older compilers that warn even for
-# the "universal" C zero initializer {0}.
-cat > $TMPC << EOF
-struct {
-  int a[2];
-} x = {0};
-EOF
-if compile_object "-Werror" "" ; then
-  :
-else
-  QEMU_CFLAGS="$QEMU_CFLAGS -Wno-missing-braces"
-fi
-
 # Our module code doesn't support Windows
 if test "$modules" = "yes" && test "$mingw32" = "yes" ; then
   error_exit "Modules are not available for Windows"
-- 
2.31.1

[PULL 03/22] meson: Disable libdw for static builds by default

[Thomas Huth]

From: Ilya Leoshkevich 

Static QEMU build fails on Debian Bullseye:

/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libdw.a(debuginfod-client.o): in 
function `__libdwfl_debuginfod_init':
(.text.startup+0x17): undefined reference to `dlopen'

The reason is that pkg-config does not suggest -ldl for libdw, and
adding --extra-ldflags="-ldl" resolves the issue. However, static
linking with libdw is an unclear topic:

* Linux perf does it.
* Debian's libdw-dev description says:

  Only link to the static version for special cases and when you
  don't need anything from the ebl backends.

* As the error message above indicates, -ldl is also needed for
  debuginfod support.

The functionality provided by libdw is needed for analyzing performance
of JITed code, which is mostly useful to developers and researchers.
Therefore, in order to avoid unpleasant surprises for people who don't
need this, simply disable libdw for static builds by default. It can
still be enabled explicitly if needed.

Reported-by: John Paul Adrian Glaubitz 
Signed-off-by: Ilya Leoshkevich 
Message-Id: <20230210005208.438142-2-...@linux.ibm.com>
Signed-off-by: Thomas Huth 
---
 meson.build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 50eb670511..0026bba0ce 100644
--- a/meson.build
+++ b/meson.build
@@ -1650,7 +1650,8 @@ endif
 
 # libdw
 libdw = not_found
-if not get_option('libdw').auto() or have_system or have_user
+if not get_option('libdw').auto() or \
+(not enable_static and (have_system or have_user))
 libdw = dependency('libdw',
method: 'pkg-config',
kwargs: static_kwargs,
-- 
2.31.1

[PULL 06/10] net: Increase L2TPv3 buffer to fit jumboframes

[Jason Wang]

From: Christian Svensson 

Increase the allocated buffer size to fit larger packets.
Given that jumboframes can commonly be up to 9000 bytes the closest suitable
value seems to be 16 KiB.

Tested by running qemu towards a Linux L2TPv3 endpoint and pushing
jumboframe traffic through the interfaces.

Signed-off-by: Christian Svensson 
Signed-off-by: Jason Wang 
---
 net/l2tpv3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/l2tpv3.c b/net/l2tpv3.c
index 53b2d32..b5547cb 100644
--- a/net/l2tpv3.c
+++ b/net/l2tpv3.c
@@ -42,7 +42,7 @@
  */
 
 #define BUFFER_ALIGN sysconf(_SC_PAGESIZE)
-#define BUFFER_SIZE 2048
+#define BUFFER_SIZE 16384
 #define IOVSIZE 2
 #define MAX_L2TPV3_MSGCNT 64
 #define MAX_L2TPV3_IOVCNT (MAX_L2TPV3_MSGCNT * IOVSIZE)
-- 
2.7.4

[PULL 11/22] tests/qtest: Add dependence on PCIE_PORT for virtio-net-failover.c

[Thomas Huth]

From: Fabiano Rosas 

This test depends on the presence of the pcie-root-port device. Add a
build time dependency.

Signed-off-by: Fabiano Rosas 
Message-Id: <20230208194700.11035-4-faro...@suse.de>
Reviewed-by: Thomas Huth 
Signed-off-by: Thomas Huth 
---
 tests/qtest/meson.build | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index e97616d327..5c8b031ce0 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -73,7 +73,8 @@ qtests_i386 = \
   (config_all_devices.has_key('CONFIG_ESP_PCI') ? ['am53c974-test'] : []) +
 \
   (config_host.has_key('CONFIG_POSIX') and 
 \
config_all_devices.has_key('CONFIG_ACPI_ERST') ? ['erst-test'] : []) +  
 \
-  (config_all_devices.has_key('CONFIG_VIRTIO_NET') and 
 \
+  (config_all_devices.has_key('CONFIG_PCIE_PORT') and  
 \
+   config_all_devices.has_key('CONFIG_VIRTIO_NET') and 
 \
config_all_devices.has_key('CONFIG_Q35') and
 \
config_all_devices.has_key('CONFIG_VIRTIO_PCI') and 
 \
slirp.found() ? ['virtio-net-failover'] : []) + 
 \
-- 
2.31.1

Re: [Patch 10/14] target/riscv: Remove rebundunt check for zve32f and zve64f

[Daniel Henrique Barboza]

Nit: I believe you mean "redundant" in the title ^

On 2/14/23 05:38, Weiwei Li wrote:

Require_zve32/64f have been overlapped by require_rvf/require_scale_rvf

Signed-off-by: Weiwei Li 
Signed-off-by: Junqiang Wang 
---



Reviewed-by: Daniel Henrique Barboza 


  target/riscv/insn_trans/trans_rvv.c.inc | 128 
  1 file changed, 21 insertions(+), 107 deletions(-)

diff --git a/target/riscv/insn_trans/trans_rvv.c.inc 
b/target/riscv/insn_trans/trans_rvv.c.inc
index 9b2711b94b..9053759546 100644
--- a/target/riscv/insn_trans/trans_rvv.c.inc
+++ b/target/riscv/insn_trans/trans_rvv.c.inc
@@ -66,50 +66,6 @@ static bool require_scale_rvf(DisasContext *s)
  }
  }
  
-static bool require_zve32f(DisasContext *s)

-{
-/* RVV + Zve32f = RVV. */
-if (has_ext(s, RVV)) {
-return true;
-}
-
-/* Zve32f doesn't support FP64. (Section 18.2) */
-return s->cfg_ptr->ext_zve32f ? s->sew <= MO_32 : true;
-}
-
-static bool require_scale_zve32f(DisasContext *s)
-{
-/* RVV + Zve32f = RVV. */
-if (has_ext(s, RVV)) {
-return true;
-}
-
-/* Zve32f doesn't support FP64. (Section 18.2) */
-return s->cfg_ptr->ext_zve64f ? s->sew <= MO_16 : true;
-}
-
-static bool require_zve64f(DisasContext *s)
-{
-/* RVV + Zve64f = RVV. */
-if (has_ext(s, RVV)) {
-return true;
-}
-
-/* Zve64f doesn't support FP64. (Section 18.2) */
-return s->cfg_ptr->ext_zve64f ? s->sew <= MO_32 : true;
-}
-
-static bool require_scale_zve64f(DisasContext *s)
-{
-/* RVV + Zve64f = RVV. */
-if (has_ext(s, RVV)) {
-return true;
-}
-
-/* Zve64f doesn't support FP64. (Section 18.2) */
-return s->cfg_ptr->ext_zve64f ? s->sew <= MO_16 : true;
-}
-
  /* Destination vector register group cannot overlap source mask register. */
  static bool require_vm(int vm, int vd)
  {
@@ -2331,9 +2287,7 @@ static bool opfvv_check(DisasContext *s, arg_rmrr *a)
  return require_rvv(s) &&
 require_rvf(s) &&
 vext_check_isa_ill(s) &&
-   vext_check_sss(s, a->rd, a->rs1, a->rs2, a->vm) &&
-   require_zve32f(s) &&
-   require_zve64f(s);
+   vext_check_sss(s, a->rd, a->rs1, a->rs2, a->vm);
  }
  
  /* OPFVV without GVEC IR */

@@ -2421,9 +2375,7 @@ static bool opfvf_check(DisasContext *s, arg_rmrr *a)
  return require_rvv(s) &&
 require_rvf(s) &&
 vext_check_isa_ill(s) &&
-   vext_check_ss(s, a->rd, a->rs2, a->vm) &&
-   require_zve32f(s) &&
-   require_zve64f(s);
+   vext_check_ss(s, a->rd, a->rs2, a->vm);
  }
  
  /* OPFVF without GVEC IR */

@@ -2461,9 +2413,7 @@ static bool opfvv_widen_check(DisasContext *s, arg_rmrr 
*a)
 require_scale_rvf(s) &&
 (s->sew != MO_8) &&
 vext_check_isa_ill(s) &&
-   vext_check_dss(s, a->rd, a->rs1, a->rs2, a->vm) &&
-   require_scale_zve32f(s) &&
-   require_scale_zve64f(s);
+   vext_check_dss(s, a->rd, a->rs1, a->rs2, a->vm);
  }
  
  /* OPFVV with WIDEN */

@@ -2506,9 +2456,7 @@ static bool opfvf_widen_check(DisasContext *s, arg_rmrr 
*a)
 require_scale_rvf(s) &&
 (s->sew != MO_8) &&
 vext_check_isa_ill(s) &&
-   vext_check_ds(s, a->rd, a->rs2, a->vm) &&
-   require_scale_zve32f(s) &&
-   require_scale_zve64f(s);
+   vext_check_ds(s, a->rd, a->rs2, a->vm);
  }
  
  /* OPFVF with WIDEN */

@@ -2540,9 +2488,7 @@ static bool opfwv_widen_check(DisasContext *s, arg_rmrr 
*a)
 require_scale_rvf(s) &&
 (s->sew != MO_8) &&
 vext_check_isa_ill(s) &&
-   vext_check_dds(s, a->rd, a->rs1, a->rs2, a->vm) &&
-   require_scale_zve32f(s) &&
-   require_scale_zve64f(s);
+   vext_check_dds(s, a->rd, a->rs1, a->rs2, a->vm);
  }
  
  /* WIDEN OPFVV with WIDEN */

@@ -2585,9 +2531,7 @@ static bool opfwf_widen_check(DisasContext *s, arg_rmrr 
*a)
 require_scale_rvf(s) &&
 (s->sew != MO_8) &&
 vext_check_isa_ill(s) &&
-   vext_check_dd(s, a->rd, a->rs2, a->vm) &&
-   require_scale_zve32f(s) &&
-   require_scale_zve64f(s);
+   vext_check_dd(s, a->rd, a->rs2, a->vm);
  }
  
  /* WIDEN OPFVF with WIDEN */

@@ -2664,9 +2608,7 @@ static bool opfv_check(DisasContext *s, arg_rmr *a)
 require_rvf(s) &&
 vext_check_isa_ill(s) &&
 /* OPFV instructions ignore vs1 check */
-   vext_check_ss(s, a->rd, a->rs2, a->vm) &&
-   require_zve32f(s) &&
-   require_zve64f(s);
+   vext_check_ss(s, a->rd, a->rs2, a->vm);
  }
  
  static bool do_opfv(DisasContext *s, arg_rmr *a,

@@ -2731,9 +2673,7 @@ static bool opfvv_cmp_check(DisasContext *s, arg_rmrr *a)
  return require_rvv(s) &&
 require_rvf(s) &&
 vext_check_isa_ill(s) &&
-   vext_check_mss(s, a->rd, a->rs1, a->rs2) &&
-

Re: [PATCH v5 1/3] multifd: Create property multifd-sync-after-each-section

[Markus Armbruster]

Juan Quintela  writes:

> We used to synchronize all channels at the end of each RAM section
> sent.  That is not needed, so preparing to only synchronize once every
> full round in latests patches.
>
> Notice that we initialize the property as true.  We will change the
> default when we introduce the new mechanism.
>
> Signed-off-by: Juan Quintela 
> Reviewed-by: Dr. David Alan Gilbert 
> Signed-off-by: Juan Quintela 
>
> ---
>
> Rename each-iteration to after-each-section
>
> Signed-off-by: Juan Quintela 
> ---
>  qapi/migration.json   | 10 +-
>  migration/migration.h |  1 +
>  hw/core/machine.c |  1 +
>  migration/migration.c | 15 +--
>  4 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/qapi/migration.json b/qapi/migration.json
> index c84fa10e86..2907241b9c 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -478,6 +478,13 @@
>  #should not affect the correctness of postcopy migration.
>  #(since 7.1)
>  #
> +# @multifd-sync-after-each-section: Synchronize channels after each
> +#   section is sent.

What does it mean to synchronize channels?

When would I want to, and why?

> +# We used to do
> +#   that in the past, but it is
> +#   suboptimal.

This isn't particularly helpful, I'm afraid.

> +#   Default value is true until all code is 
> in.

As far as I can tell, it's actually *unused* for now, and a later patch
will put it to use ...

> +#   (since 8.0)
> +#
>  # Features:
>  # @unstable: Members @x-colo and @x-ignore-shared are experimental.
>  #
> @@ -492,7 +499,8 @@
> 'dirty-bitmaps', 'postcopy-blocktime', 'late-block-activate',
> { 'name': 'x-ignore-shared', 'features': [ 'unstable' ] },
> 'validate-uuid', 'background-snapshot',
> -   'zero-copy-send', 'postcopy-preempt'] }
> +   'zero-copy-send', 'postcopy-preempt',
> +   'multifd-sync-after-each-section'] }
>  
>  ##
>  # @MigrationCapabilityStatus:
> diff --git a/migration/migration.h b/migration/migration.h
> index 2da2f8a164..cf84520196 100644
> --- a/migration/migration.h
> +++ b/migration/migration.h
> @@ -424,6 +424,7 @@ int migrate_multifd_channels(void);
>  MultiFDCompression migrate_multifd_compression(void);
>  int migrate_multifd_zlib_level(void);
>  int migrate_multifd_zstd_level(void);
> +bool migrate_multifd_sync_after_each_section(void);
>  
>  #ifdef CONFIG_LINUX
>  bool migrate_use_zero_copy_send(void);
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index f73fc4c45c..dc86849402 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -54,6 +54,7 @@ const size_t hw_compat_7_1_len = 
> G_N_ELEMENTS(hw_compat_7_1);
>  GlobalProperty hw_compat_7_0[] = {
>  { "arm-gicv3-common", "force-8-bit-prio", "on" },
>  { "nvme-ns", "eui64-default", "on"},
> +{ "migration", "multifd-sync-after-each-section", "on"},
>  };
>  const size_t hw_compat_7_0_len = G_N_ELEMENTS(hw_compat_7_0);
>  
> diff --git a/migration/migration.c b/migration/migration.c
> index 90fca70cb7..406c27bc82 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -167,7 +167,8 @@ 
> INITIALIZE_MIGRATE_CAPS_SET(check_caps_background_snapshot,
>  MIGRATION_CAPABILITY_XBZRLE,
>  MIGRATION_CAPABILITY_X_COLO,
>  MIGRATION_CAPABILITY_VALIDATE_UUID,
> -MIGRATION_CAPABILITY_ZERO_COPY_SEND);
> +MIGRATION_CAPABILITY_ZERO_COPY_SEND,
> +MIGRATION_CAPABILITY_MULTIFD_SYNC_AFTER_EACH_SECTION);
>  
>  /* When we add fault tolerance, we could have several
> migrations at once.  For now we don't need to add
> @@ -2701,6 +2702,15 @@ bool migrate_use_multifd(void)
>  return s->enabled_capabilities[MIGRATION_CAPABILITY_MULTIFD];
>  }
>  
> +bool migrate_multifd_sync_after_each_section(void)
> +{
> +MigrationState *s = migrate_get_current();
> +
> +return true;
> +// We will change this when code gets in.
> +return 
> s->enabled_capabilities[MIGRATION_CAPABILITY_MULTIFD_SYNC_AFTER_EACH_SECTION];

... here.

No warning about unreachable code?  Checking... nope, gcc seems to not
to care.

> +}
> +
>  bool migrate_pause_before_switchover(void)
>  {
>  MigrationState *s;
> @@ -4535,7 +4545,8 @@ static Property migration_properties[] = {
>  DEFINE_PROP_MIG_CAP("x-zero-copy-send",
>  MIGRATION_CAPABILITY_ZERO_COPY_SEND),
>  #endif
> -
> +DEFINE_PROP_MIG_CAP("multifd-sync-after-each-section",
> +
> MIGRATION_CAPABILITY_MULTIFD_SYNC_AFTER_EACH_SECTION),
>  DEFINE_PROP_END_OF_LIST(),
>  };

Re: [PATCH v3 06/10] monitor: release the lock before calling close()

[Marc-André Lureau]

Hi

On Tue, Feb 14, 2023 at 5:34 PM Markus Armbruster  wrote:
>
> marcandre.lur...@redhat.com writes:
>
> > From: Marc-André Lureau 
> >
> > As per comment, presumably to avoid syscall in critical section.
> >
> > Fixes: 0210c3b39bef08 ("monitor: Use LOCK_GUARD macros")
> > Signed-off-by: Marc-André Lureau 
> > ---
> >  monitor/fds.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/monitor/fds.c b/monitor/fds.c
> > index 26b39a0ce6..03c5e97c35 100644
> > --- a/monitor/fds.c
> > +++ b/monitor/fds.c
> > @@ -80,7 +80,7 @@ void qmp_getfd(const char *fdname, Error **errp)
> >  return;
> >  }
> >
> > -QEMU_LOCK_GUARD(&cur_mon->mon_lock);
> > +qemu_mutex_lock(&cur_mon->mon_lock);
> >  QLIST_FOREACH(monfd, &cur_mon->fds, next) {
> >  if (strcmp(monfd->name, fdname) != 0) {
> >  continue;
> > @@ -88,6 +88,7 @@ void qmp_getfd(const char *fdname, Error **errp)
> >
> >  tmp_fd = monfd->fd;
> >  monfd->fd = fd;
> > +qemu_mutex_unlock(&cur_mon->mon_lock);
> >  /* Make sure close() is outside critical section */
> >  close(tmp_fd);
> >  return;
> > @@ -98,6 +99,7 @@ void qmp_getfd(const char *fdname, Error **errp)
> >  monfd->fd = fd;
> >
> >  QLIST_INSERT_HEAD(&cur_mon->fds, monfd, next);
> > +qemu_mutex_unlock(&cur_mon->mon_lock);
> >  }
> >
> >  void qmp_closefd(const char *fdname, Error **errp)
>
> This confused me.  I think I understand now, but let's double-check.
>
> You're reverting commit 0210c3b39bef08 for qmp_getfd() because it
> extended the criticial section beyond the close(), invalidating the
> comment.  Correct?

Correct

>
> Did it actually break anything?

Not that I know of (David admitted over IRC that this was not intended)

-- 
Marc-André Lureau

Re: [PATCH v2 1/4] linux-user: Always exit from exclusive state in fork_end()

[Alex Bennée]

Ilya Leoshkevich  writes:

> fork()ed processes currently start with
> current_cpu->in_exclusive_context set, which is, strictly speaking, not
> correct, but does not cause problems (even assertion failures).
>
> With one of the next patches, the code begins to rely on this value, so
> fix it by always calling end_exclusive() in fork_end().
>
> Signed-off-by: Ilya Leoshkevich 

Reviewed-by: Alex Bennée 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH] virtio-net: clear guest_announce feature if no cvq backend

[Eugenio Perez Martin]

On Tue, Jan 24, 2023 at 5:32 PM Eugenio Pérez  wrote:
>
> Since GUEST_ANNOUNCE is emulated the feature bit could be set without
> backend support.  This happens in the vDPA case.
>
> However, backend vDPA parent may not have CVQ support.  This causes an
> incoherent feature set, and the driver may refuse to start.  This
> happens in virtio-net Linux driver.
>
> This may be solved differently in the future.  Qemu is able to emulate a
> CVQ just for guest_announce purposes, helping guest to notify the new
> location with vDPA devices that does not support it.  However, this is
> left as a TODO as it is way more complex to backport.
>
> Tested with vdpa_net_sim, toggling manually VIRTIO_NET_F_CTRL_VQ in the
> driver and migrating it with x-svq=on.
>

Friendly ping about this patch, as it fell through the cracks if I'm not wrong.

Thanks!

> Fixes: 980003debddd ("vdpa: do not handle VIRTIO_NET_F_GUEST_ANNOUNCE in 
> vhost-vdpa")
> Reported-by: Dawar, Gautam 
> Signed-off-by: Eugenio Pérez 
> ---
>  hw/net/virtio-net.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
> index 3ae909041a..09d5c7a664 100644
> --- a/hw/net/virtio-net.c
> +++ b/hw/net/virtio-net.c
> @@ -820,6 +820,21 @@ static uint64_t virtio_net_get_features(VirtIODevice 
> *vdev, uint64_t features,
>  features |= (1ULL << VIRTIO_NET_F_MTU);
>  }
>
> +/*
> + * Since GUEST_ANNOUNCE is emulated the feature bit could be set without
> + * enabled. This happens in the vDPA case.
> + *
> + * Make sure the feature set is not incoherent, as the driver could 
> refuse
> + * to start.
> + *
> + * TODO: QEMU is able to emulate a CVQ just for guest_announce purposes,
> + * helping guest to notify the new location with vDPA devices that does 
> not
> + * support it.
> + */
> +if (!virtio_has_feature(vdev->backend_features, VIRTIO_NET_F_CTRL_VQ)) {
> +virtio_clear_feature(&features, VIRTIO_NET_F_GUEST_ANNOUNCE);
> +}
> +
>  return features;
>  }
>
> --
> 2.31.1
>
>