Hello,

This series looks scary but it's mostly trivial and mechanical work.

It is yet another attempt at fixing --disable-tcg.  We have a recent
work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
Phil's work didn't get merged and it's now too hard to rebase and
revive, the most recent attempt got misled into the 'what is common code
between TCG and KVM' dungeon.

After reviewing [1] I went ahead and look what other targets were doing
w.r.t their directory structure and comparing to RISC-V.  In our case we
have a log going on in target/riscv:

$ ls target/riscv
Kconfig                 cpu_cfg.h             fpu_helper.c   machine.c         sbi_ecall_interface.h  vector_internals.c
XVentanaCondOps.decode  cpu_cfg_fields.h.inc  gdbstub.c      meson.build       tcg                    vector_internals.h
arch_dump.c             cpu_helper.c          helper.h       mips_csr.c        th_csr.c               xlrbr.decode
bitmanip_helper.c       cpu_user.h            insn16.decode  monitor.c         time_helper.c          xmips.decode
common-semi-target.c    cpu_vendorid.h        insn32.decode  op_helper.c       time_helper.h          xthead.decode
cpu-param.h             crypto_helper.c       insn_trans     pmp.c             trace-events           zce_helper.c
cpu-qom.h               csr.c                 instmap.h      pmp.h             trace.h
cpu.c                   csr.h                 internals.h    pmu.c             translate.c
cpu.h                   debug.c               kvm            pmu.h             vcrypto_helper.c
cpu_bits.h              debug.h               m128_helper.c  riscv-qmp-cmds.c  vector_helper.c


It is non-trivial to realize that most of this stuff is TCG specific.
Meanwhile our 'tcg' subdir is mostly empty:

$ ls target/riscv/tcg
meson.build  tcg-cpu.c  tcg-cpu.h

If we compare it with other targets, let's say loongarch:

$ ls target/loongarch/
Kconfig      cpu-csr.h    cpu-qom.h  cpu_helper.c  disas.c    insns.decode  loongarch-qmp-cmds.c  tcg           translate.h
README       cpu-mmu.h    cpu.c      csr.c         gdbstub.c  internals.h   machine.c             trace-events  vec.h
arch_dump.c  cpu-param.h  cpu.h      csr.h         helper.h   kvm           meson.build           trace.h
$
$ ls target/loongarch/tcg
constant_timer.c  fpu_helper.c  insn_trans      meson.build  tcg_cpu.c        tlb_helper.c  vec_helper.c
csr_helper.c      helper.h      iocsr_helper.c  op_helper.c  tcg_loongarch.h  translate.c

It is straightforward to see which files are TCG exclusive and which
files are common to all accels.

And this is what we did here.  The patches goes mostly as follows:

- move stuff to 'tcg' subdir.  Most stuff is straighforward and is
  manageable with a single patch.  Other things required some logic to
  go to either cpu.c or tcg-cpu;
- move TCG stuff to tcg-cpu.c;
- move common accel stuff to cpu.c.  Usually from cpu_helper.c;
- filter TCG specific code in cpu.c and other files;
- trivial/assorted fixes in misc files that were needed to make
  --disable-tcg work.

Patch 24 is taken from Zephyr Li to enable the CI for --disable-tcg.
Hopefully we won't break it anytime soon.

After this series we have --disable-tcg working and the following dir
structure:

$ ls target/riscv
Kconfig                 cpu.c                 cpu_vendorid.h  internals.h       sbi_ecall_interface.h  xlrbr.decode
XVentanaCondOps.decode  cpu.h                 gdbstub.c       kvm               tcg                    xmips.decode
arch_dump.c             cpu_bits.h            helper.h        machine.c         time_helper.c          xthead.decode
common-semi-target.c    cpu_cfg.h             insn16.decode   meson.build       time_helper.h
cpu-param.h             cpu_cfg_fields.h.inc  insn32.decode   monitor.c         trace-events
cpu-qom.h               cpu_user.h            instmap.h       riscv-qmp-cmds.c  trace.h
$
$ ls target/riscv/tcg
bitmanip_helper.c  csr.h         insn_trans     op_helper.c  pmu.h      translate.c         vector_internals.h
cpu_helper.c       debug.c       m128_helper.c  pmp.c        tcg-cpu.c  vcrypto_helper.c    zce_helper.c
crypto_helper.c    debug.h       meson.build    pmp.h        tcg-cpu.h  vector_helper.c
csr.c              fpu_helper.c  mips_csr.c     pmu.c        th_csr.c   vector_internals.c


[1] https://lore.kernel.org/qemu-devel/20260602091753.3209261-1-fritchleybohrer@gmail.com/
[2] https://lore.kernel.org/qemu-devel/20230711121453.59138-1-philmd@linaro.org/


Daniel Henrique Barboza (22):
  target/riscv: move TCG only files to tcg subdir
  target/riscv/machine.c: do not migrate pmp state with kvm
  target/riscv: move pmp files to tcg subdir
  target/riscv: make some riscv_sysemu_ops TCG only
  target/riscv: move pmu.h to tcg subdir
  target/riscv: move debug.h to tcg subdir
  target/riscv: remove csr.h from kvm-cpu.c
  target/riscv: move csr.h to tcg subdir
  target/riscv: move custom_csrs logic to tcg-cpu.c
  target/riscv: move riscv_cpu_set_nmi() to tcg-cpu.c
  target/riscv: move valid_vm_* satp arrays to cpu.c
  target/riscv: move some irq helpers to cpu.c
  target/riscv: move riscv_cpu_claim_interrupts to cpu.c
  target/riscv/cpu.c: handle TCG bits of riscv_cpu_dump_state
  target/riscv: gate riscv_cpu_update_mip with tcg_enabled()
  target/riscv/cpu.c: filter TCG only bits in riscv_cpu_reset_hold()
  hw/riscv/riscv_hart.c isolate tcg only bits
  target/riscv/gdbstub.c: isolate TCG only checks
  target/riscv: move riscv_cpu_set_rdtime_fn to riscv_aclint
  target/riscv/tcg: remove unused riscv_cpu_get_geilen()
  target/riscv: move riscv_cpu_set_geilen() to riscv-imsic
  target/riscv: move riscv_cpu_set_aia_ireg_rmw_cb() to riscv_imsic

Zephyr Li (2):
  target/riscv: Remove unused tcg/tcg.h include
  gitlab-ci.d/crossbuilds: add riscv64 KVM-only build job

 .gitlab-ci.d/crossbuilds.yml                  |   8 +
 hw/intc/riscv_aclint.c                        |   8 +
 hw/intc/riscv_imsic.c                         |  24 ++
 hw/riscv/fdt-common.c                         |  52 +++
 hw/riscv/riscv_hart.c                         |   4 +-
 hw/riscv/virt.c                               |   1 -
 include/hw/riscv/fdt-common.h                 |   1 +
 target/riscv/cpu.c                            | 316 +++++++++++++++---
 target/riscv/cpu.h                            |  19 +-
 target/riscv/gdbstub.c                        |  10 +-
 target/riscv/kvm/kvm-cpu.c                    |   1 -
 target/riscv/machine.c                        |  15 +-
 target/riscv/meson.build                      |  17 -
 target/riscv/monitor.c                        |   4 +-
 target/riscv/riscv-qmp-cmds.c                 |   2 +-
 target/riscv/{ => tcg}/bitmanip_helper.c      |   0
 target/riscv/{ => tcg}/cpu_helper.c           | 239 +------------
 target/riscv/{ => tcg}/crypto_helper.c        |   0
 target/riscv/{ => tcg}/csr.c                  |  45 +--
 target/riscv/{ => tcg}/csr.h                  |   6 +-
 target/riscv/{ => tcg}/debug.c                |   2 +-
 target/riscv/{ => tcg}/debug.h                |   0
 target/riscv/{ => tcg}/fpu_helper.c           |   0
 .../insn_trans/trans_privileged.c.inc         |   0
 .../{ => tcg}/insn_trans/trans_rva.c.inc      |   0
 .../{ => tcg}/insn_trans/trans_rvb.c.inc      |   0
 .../{ => tcg}/insn_trans/trans_rvbf16.c.inc   |   0
 .../{ => tcg}/insn_trans/trans_rvd.c.inc      |   0
 .../{ => tcg}/insn_trans/trans_rvf.c.inc      |   0
 .../{ => tcg}/insn_trans/trans_rvh.c.inc      |   0
 .../{ => tcg}/insn_trans/trans_rvi.c.inc      |   0
 .../{ => tcg}/insn_trans/trans_rvk.c.inc      |   0
 .../{ => tcg}/insn_trans/trans_rvm.c.inc      |   0
 .../{ => tcg}/insn_trans/trans_rvv.c.inc      |   0
 .../{ => tcg}/insn_trans/trans_rvvk.c.inc     |   0
 .../{ => tcg}/insn_trans/trans_rvzabha.c.inc  |   0
 .../{ => tcg}/insn_trans/trans_rvzacas.c.inc  |   0
 .../{ => tcg}/insn_trans/trans_rvzalasr.c.inc |   0
 .../{ => tcg}/insn_trans/trans_rvzawrs.c.inc  |   0
 .../{ => tcg}/insn_trans/trans_rvzce.c.inc    |   0
 .../{ => tcg}/insn_trans/trans_rvzcmop.c.inc  |   0
 .../{ => tcg}/insn_trans/trans_rvzfa.c.inc    |   0
 .../{ => tcg}/insn_trans/trans_rvzfh.c.inc    |   0
 .../{ => tcg}/insn_trans/trans_rvzicbo.c.inc  |   0
 .../insn_trans/trans_rvzicfiss.c.inc          |   0
 .../{ => tcg}/insn_trans/trans_rvzicond.c.inc |   0
 .../{ => tcg}/insn_trans/trans_rvzimop.c.inc  |   0
 .../{ => tcg}/insn_trans/trans_svinval.c.inc  |   0
 .../{ => tcg}/insn_trans/trans_xlrbr.c.inc    |   0
 .../{ => tcg}/insn_trans/trans_xmips.c.inc    |   0
 .../{ => tcg}/insn_trans/trans_xthead.c.inc   |   0
 .../insn_trans/trans_xventanacondops.c.inc    |   0
 .../{ => tcg}/insn_trans/trans_zilsd.c.inc    |   0
 target/riscv/{ => tcg}/m128_helper.c          |   0
 target/riscv/tcg/meson.build                  |  31 +-
 target/riscv/{ => tcg}/mips_csr.c             |   2 +-
 target/riscv/{ => tcg}/op_helper.c            |   2 +-
 target/riscv/{ => tcg}/pmp.c                  |   2 +-
 target/riscv/{ => tcg}/pmp.h                  |   0
 target/riscv/{ => tcg}/pmu.c                  |  52 ---
 target/riscv/{ => tcg}/pmu.h                  |   1 -
 target/riscv/tcg/tcg-cpu.c                    |  30 +-
 target/riscv/{ => tcg}/th_csr.c               |   2 +-
 target/riscv/{ => tcg}/translate.c            |   0
 target/riscv/{ => tcg}/vcrypto_helper.c       |   0
 target/riscv/{ => tcg}/vector_helper.c        |   0
 target/riscv/{ => tcg}/vector_internals.c     |   0
 target/riscv/{ => tcg}/vector_internals.h     |   0
 target/riscv/{ => tcg}/zce_helper.c           |   0
 target/riscv/time_helper.c                    |  33 +-
 70 files changed, 495 insertions(+), 434 deletions(-)
 rename target/riscv/{ => tcg}/bitmanip_helper.c (100%)
 rename target/riscv/{ => tcg}/cpu_helper.c (92%)
 rename target/riscv/{ => tcg}/crypto_helper.c (100%)
 rename target/riscv/{ => tcg}/csr.c (99%)
 rename target/riscv/{ => tcg}/csr.h (96%)
 rename target/riscv/{ => tcg}/debug.c (99%)
 rename target/riscv/{ => tcg}/debug.h (100%)
 rename target/riscv/{ => tcg}/fpu_helper.c (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_privileged.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rva.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvb.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvbf16.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvd.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvf.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvh.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvi.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvk.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvm.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvv.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvvk.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzabha.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzacas.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzalasr.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzawrs.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzce.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzcmop.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzfa.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzfh.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzicbo.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzicfiss.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzicond.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_rvzimop.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_svinval.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_xlrbr.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_xmips.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_xthead.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_xventanacondops.c.inc (100%)
 rename target/riscv/{ => tcg}/insn_trans/trans_zilsd.c.inc (100%)
 rename target/riscv/{ => tcg}/m128_helper.c (100%)
 rename target/riscv/{ => tcg}/mips_csr.c (99%)
 rename target/riscv/{ => tcg}/op_helper.c (99%)
 rename target/riscv/{ => tcg}/pmp.c (99%)
 rename target/riscv/{ => tcg}/pmp.h (100%)
 rename target/riscv/{ => tcg}/pmu.c (86%)
 rename target/riscv/{ => tcg}/pmu.h (95%)
 rename target/riscv/{ => tcg}/th_csr.c (99%)
 rename target/riscv/{ => tcg}/translate.c (100%)
 rename target/riscv/{ => tcg}/vcrypto_helper.c (100%)
 rename target/riscv/{ => tcg}/vector_helper.c (100%)
 rename target/riscv/{ => tcg}/vector_internals.c (100%)
 rename target/riscv/{ => tcg}/vector_internals.h (100%)
 rename target/riscv/{ => tcg}/zce_helper.c (100%)

-- 
2.43.0

On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
> Hello,
> 
> This series looks scary but it's mostly trivial and mechanical work.
> 
> It is yet another attempt at fixing --disable-tcg.  We have a recent
> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
> Phil's work didn't get merged and it's now too hard to rebase and
> revive, the most recent attempt got misled into the 'what is common code
> between TCG and KVM' dungeon.
> 
> After reviewing [1] I went ahead and look what other targets were doing
> w.r.t their directory structure and comparing to RISC-V.  In our case we
> have a log going on in target/riscv:
> 
> $ ls target/riscv
> Kconfig                 cpu_cfg.h             fpu_helper.c   machine.c         sbi_ecall_interface.h  vector_internals.c
> XVentanaCondOps.decode  cpu_cfg_fields.h.inc  gdbstub.c      meson.build       tcg                    vector_internals.h
> arch_dump.c             cpu_helper.c          helper.h       mips_csr.c        th_csr.c               xlrbr.decode
> bitmanip_helper.c       cpu_user.h            insn16.decode  monitor.c         time_helper.c          xmips.decode
> common-semi-target.c    cpu_vendorid.h        insn32.decode  op_helper.c       time_helper.h          xthead.decode
> cpu-param.h             crypto_helper.c       insn_trans     pmp.c             trace-events           zce_helper.c
> cpu-qom.h               csr.c                 instmap.h      pmp.h             trace.h
> cpu.c                   csr.h                 internals.h    pmu.c             translate.c
> cpu.h                   debug.c               kvm            pmu.h             vcrypto_helper.c
> cpu_bits.h              debug.h               m128_helper.c  riscv-qmp-cmds.c  vector_helper.c
> 
> 
> It is non-trivial to realize that most of this stuff is TCG specific.
> Meanwhile our 'tcg' subdir is mostly empty:
> 
> $ ls target/riscv/tcg
> meson.build  tcg-cpu.c  tcg-cpu.h
> 
> If we compare it with other targets, let's say loongarch:
> 
> $ ls target/loongarch/
> Kconfig      cpu-csr.h    cpu-qom.h  cpu_helper.c  disas.c    insns.decode  loongarch-qmp-cmds.c  tcg           translate.h
> README       cpu-mmu.h    cpu.c      csr.c         gdbstub.c  internals.h   machine.c             trace-events  vec.h
> arch_dump.c  cpu-param.h  cpu.h      csr.h         helper.h   kvm           meson.build           trace.h
> $
> $ ls target/loongarch/tcg
> constant_timer.c  fpu_helper.c  insn_trans      meson.build  tcg_cpu.c        tlb_helper.c  vec_helper.c
> csr_helper.c      helper.h      iocsr_helper.c  op_helper.c  tcg_loongarch.h  translate.c
> 
> It is straightforward to see which files are TCG exclusive and which
> files are common to all accels.
> 
> And this is what we did here.  The patches goes mostly as follows:
> 
> - move stuff to 'tcg' subdir.  Most stuff is straighforward and is
>   manageable with a single patch.  Other things required some logic to
>   go to either cpu.c or tcg-cpu;
> - move TCG stuff to tcg-cpu.c;
> - move common accel stuff to cpu.c.  Usually from cpu_helper.c;
> - filter TCG specific code in cpu.c and other files;
> - trivial/assorted fixes in misc files that were needed to make
>   --disable-tcg work.
> 
> Patch 24 is taken from Zephyr Li to enable the CI for --disable-tcg.
> Hopefully we won't break it anytime soon.
> 
> After this series we have --disable-tcg working and the following dir
> structure:
> 
> $ ls target/riscv
> Kconfig                 cpu.c                 cpu_vendorid.h  internals.h       sbi_ecall_interface.h  xlrbr.decode
> XVentanaCondOps.decode  cpu.h                 gdbstub.c       kvm               tcg                    xmips.decode
> arch_dump.c             cpu_bits.h            helper.h        machine.c         time_helper.c          xthead.decode
> common-semi-target.c    cpu_cfg.h             insn16.decode   meson.build       time_helper.h
> cpu-param.h             cpu_cfg_fields.h.inc  insn32.decode   monitor.c         trace-events
> cpu-qom.h               cpu_user.h            instmap.h       riscv-qmp-cmds.c  trace.h
> $
> $ ls target/riscv/tcg
> bitmanip_helper.c  csr.h         insn_trans     op_helper.c  pmu.h      translate.c         vector_internals.h
> cpu_helper.c       debug.c       m128_helper.c  pmp.c        tcg-cpu.c  vcrypto_helper.c    zce_helper.c
> crypto_helper.c    debug.h       meson.build    pmp.h        tcg-cpu.h  vector_helper.c
> csr.c              fpu_helper.c  mips_csr.c     pmu.c        th_csr.c   vector_internals.c
> 
> 
> [1] https://lore.kernel.org/qemu-devel/20260602091753.3209261-1-fritchleybohrer@gmail.com/
> [2] https://lore.kernel.org/qemu-devel/20230711121453.59138-1-philmd@linaro.org/
> 
> 
> Daniel Henrique Barboza (22):
>   target/riscv: move TCG only files to tcg subdir
>   target/riscv/machine.c: do not migrate pmp state with kvm
>   target/riscv: move pmp files to tcg subdir
>   target/riscv: make some riscv_sysemu_ops TCG only
>   target/riscv: move pmu.h to tcg subdir
>   target/riscv: move debug.h to tcg subdir
>   target/riscv: remove csr.h from kvm-cpu.c
>   target/riscv: move csr.h to tcg subdir
>   target/riscv: move custom_csrs logic to tcg-cpu.c
>   target/riscv: move riscv_cpu_set_nmi() to tcg-cpu.c
>   target/riscv: move valid_vm_* satp arrays to cpu.c
>   target/riscv: move some irq helpers to cpu.c
>   target/riscv: move riscv_cpu_claim_interrupts to cpu.c
>   target/riscv/cpu.c: handle TCG bits of riscv_cpu_dump_state
>   target/riscv: gate riscv_cpu_update_mip with tcg_enabled()
>   target/riscv/cpu.c: filter TCG only bits in riscv_cpu_reset_hold()
>   hw/riscv/riscv_hart.c isolate tcg only bits
>   target/riscv/gdbstub.c: isolate TCG only checks
>   target/riscv: move riscv_cpu_set_rdtime_fn to riscv_aclint
>   target/riscv/tcg: remove unused riscv_cpu_get_geilen()
>   target/riscv: move riscv_cpu_set_geilen() to riscv-imsic
>   target/riscv: move riscv_cpu_set_aia_ireg_rmw_cb() to riscv_imsic
> 
> Zephyr Li (2):
>   target/riscv: Remove unused tcg/tcg.h include
>   gitlab-ci.d/crossbuilds: add riscv64 KVM-only build job
> 
>  .gitlab-ci.d/crossbuilds.yml                  |   8 +
>  hw/intc/riscv_aclint.c                        |   8 +
>  hw/intc/riscv_imsic.c                         |  24 ++
>  hw/riscv/fdt-common.c                         |  52 +++
>  hw/riscv/riscv_hart.c                         |   4 +-
>  hw/riscv/virt.c                               |   1 -
>  include/hw/riscv/fdt-common.h                 |   1 +
>  target/riscv/cpu.c                            | 316 +++++++++++++++---
>  target/riscv/cpu.h                            |  19 +-
>  target/riscv/gdbstub.c                        |  10 +-
>  target/riscv/kvm/kvm-cpu.c                    |   1 -
>  target/riscv/machine.c                        |  15 +-
>  target/riscv/meson.build                      |  17 -
>  target/riscv/monitor.c                        |   4 +-
>  target/riscv/riscv-qmp-cmds.c                 |   2 +-
>  target/riscv/{ => tcg}/bitmanip_helper.c      |   0
>  target/riscv/{ => tcg}/cpu_helper.c           | 239 +------------
>  target/riscv/{ => tcg}/crypto_helper.c        |   0
>  target/riscv/{ => tcg}/csr.c                  |  45 +--
>  target/riscv/{ => tcg}/csr.h                  |   6 +-
>  target/riscv/{ => tcg}/debug.c                |   2 +-
>  target/riscv/{ => tcg}/debug.h                |   0
>  target/riscv/{ => tcg}/fpu_helper.c           |   0
>  .../insn_trans/trans_privileged.c.inc         |   0
>  .../{ => tcg}/insn_trans/trans_rva.c.inc      |   0
>  .../{ => tcg}/insn_trans/trans_rvb.c.inc      |   0
>  .../{ => tcg}/insn_trans/trans_rvbf16.c.inc   |   0
>  .../{ => tcg}/insn_trans/trans_rvd.c.inc      |   0
>  .../{ => tcg}/insn_trans/trans_rvf.c.inc      |   0
>  .../{ => tcg}/insn_trans/trans_rvh.c.inc      |   0
>  .../{ => tcg}/insn_trans/trans_rvi.c.inc      |   0
>  .../{ => tcg}/insn_trans/trans_rvk.c.inc      |   0
>  .../{ => tcg}/insn_trans/trans_rvm.c.inc      |   0
>  .../{ => tcg}/insn_trans/trans_rvv.c.inc      |   0
>  .../{ => tcg}/insn_trans/trans_rvvk.c.inc     |   0
>  .../{ => tcg}/insn_trans/trans_rvzabha.c.inc  |   0
>  .../{ => tcg}/insn_trans/trans_rvzacas.c.inc  |   0
>  .../{ => tcg}/insn_trans/trans_rvzalasr.c.inc |   0
>  .../{ => tcg}/insn_trans/trans_rvzawrs.c.inc  |   0
>  .../{ => tcg}/insn_trans/trans_rvzce.c.inc    |   0
>  .../{ => tcg}/insn_trans/trans_rvzcmop.c.inc  |   0
>  .../{ => tcg}/insn_trans/trans_rvzfa.c.inc    |   0
>  .../{ => tcg}/insn_trans/trans_rvzfh.c.inc    |   0
>  .../{ => tcg}/insn_trans/trans_rvzicbo.c.inc  |   0
>  .../insn_trans/trans_rvzicfiss.c.inc          |   0
>  .../{ => tcg}/insn_trans/trans_rvzicond.c.inc |   0
>  .../{ => tcg}/insn_trans/trans_rvzimop.c.inc  |   0
>  .../{ => tcg}/insn_trans/trans_svinval.c.inc  |   0
>  .../{ => tcg}/insn_trans/trans_xlrbr.c.inc    |   0
>  .../{ => tcg}/insn_trans/trans_xmips.c.inc    |   0
>  .../{ => tcg}/insn_trans/trans_xthead.c.inc   |   0
>  .../insn_trans/trans_xventanacondops.c.inc    |   0
>  .../{ => tcg}/insn_trans/trans_zilsd.c.inc    |   0
>  target/riscv/{ => tcg}/m128_helper.c          |   0
>  target/riscv/tcg/meson.build                  |  31 +-
>  target/riscv/{ => tcg}/mips_csr.c             |   2 +-
>  target/riscv/{ => tcg}/op_helper.c            |   2 +-
>  target/riscv/{ => tcg}/pmp.c                  |   2 +-
>  target/riscv/{ => tcg}/pmp.h                  |   0
>  target/riscv/{ => tcg}/pmu.c                  |  52 ---
>  target/riscv/{ => tcg}/pmu.h                  |   1 -
>  target/riscv/tcg/tcg-cpu.c                    |  30 +-
>  target/riscv/{ => tcg}/th_csr.c               |   2 +-
>  target/riscv/{ => tcg}/translate.c            |   0
>  target/riscv/{ => tcg}/vcrypto_helper.c       |   0
>  target/riscv/{ => tcg}/vector_helper.c        |   0
>  target/riscv/{ => tcg}/vector_internals.c     |   0
>  target/riscv/{ => tcg}/vector_internals.h     |   0
>  target/riscv/{ => tcg}/zce_helper.c           |   0
>  target/riscv/time_helper.c                    |  33 +-
>  70 files changed, 495 insertions(+), 434 deletions(-)
>  rename target/riscv/{ => tcg}/bitmanip_helper.c (100%)
>  rename target/riscv/{ => tcg}/cpu_helper.c (92%)
>  rename target/riscv/{ => tcg}/crypto_helper.c (100%)
>  rename target/riscv/{ => tcg}/csr.c (99%)
>  rename target/riscv/{ => tcg}/csr.h (96%)
>  rename target/riscv/{ => tcg}/debug.c (99%)
>  rename target/riscv/{ => tcg}/debug.h (100%)
>  rename target/riscv/{ => tcg}/fpu_helper.c (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_privileged.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rva.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvb.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvbf16.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvd.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvf.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvh.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvi.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvk.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvm.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvv.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvvk.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzabha.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzacas.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzalasr.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzawrs.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzce.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzcmop.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzfa.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzfh.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzicbo.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzicfiss.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzicond.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_rvzimop.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_svinval.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_xlrbr.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_xmips.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_xthead.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_xventanacondops.c.inc (100%)
>  rename target/riscv/{ => tcg}/insn_trans/trans_zilsd.c.inc (100%)
>  rename target/riscv/{ => tcg}/m128_helper.c (100%)
>  rename target/riscv/{ => tcg}/mips_csr.c (99%)
>  rename target/riscv/{ => tcg}/op_helper.c (99%)
>  rename target/riscv/{ => tcg}/pmp.c (99%)
>  rename target/riscv/{ => tcg}/pmp.h (100%)
>  rename target/riscv/{ => tcg}/pmu.c (86%)
>  rename target/riscv/{ => tcg}/pmu.h (95%)
>  rename target/riscv/{ => tcg}/th_csr.c (99%)
>  rename target/riscv/{ => tcg}/translate.c (100%)
>  rename target/riscv/{ => tcg}/vcrypto_helper.c (100%)
>  rename target/riscv/{ => tcg}/vector_helper.c (100%)
>  rename target/riscv/{ => tcg}/vector_internals.c (100%)
>  rename target/riscv/{ => tcg}/vector_internals.h (100%)
>  rename target/riscv/{ => tcg}/zce_helper.c (100%)
> 

It seems like series does not apply on top of master, would that be
possible to rebase it?

Regards,
Pierrick

On 22/6/26 22:52, Pierrick Bouvier wrote:
> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>> Hello,
>>
>> This series looks scary but it's mostly trivial and mechanical work.
>>
>> It is yet another attempt at fixing --disable-tcg.  We have a recent
>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
>> Phil's work didn't get merged and it's now too hard to rebase and
>> revive, the most recent attempt got misled into the 'what is common code
>> between TCG and KVM' dungeon.


> It seems like series does not apply on top of master, would that be
> possible to rebase it?

For some reason the RISC-V series are handled distinctly than the
rest of QEMU, Alistair queues work on his repository and developers
are custome to base their series on top of it (otherwise Alistair
can not apply them on his tree and asks for reposts), see the
riscv-to-apply.next branch on https://github.com/alistair23/qemu.

On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
> On 22/6/26 22:52, Pierrick Bouvier wrote:
>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>>> Hello,
>>>
>>> This series looks scary but it's mostly trivial and mechanical work.
>>>
>>> It is yet another attempt at fixing --disable-tcg.  We have a recent
>>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
>>> Phil's work didn't get merged and it's now too hard to rebase and
>>> revive, the most recent attempt got misled into the 'what is common code
>>> between TCG and KVM' dungeon.
> 
> 
>> It seems like series does not apply on top of master, would that be
>> possible to rebase it?
> 
> For some reason the RISC-V series are handled distinctly than the
> rest of QEMU, Alistair queues work on his repository and developers
> are custome to base their series on top of it (otherwise Alistair
> can not apply them on his tree and asks for reposts), see the
> riscv-to-apply.next branch on https://github.com/alistair23/qemu.

Unfortunately, it makes it hard to run any kind of automated testing,
especially for series like this that target specific configs.

On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
>> On 22/6/26 22:52, Pierrick Bouvier wrote:
>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>>>> Hello,
>>>>
>>>> This series looks scary but it's mostly trivial and mechanical work.
>>>>
>>>> It is yet another attempt at fixing --disable-tcg.  We have a recent
>>>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
>>>> Phil's work didn't get merged and it's now too hard to rebase and
>>>> revive, the most recent attempt got misled into the 'what is common code
>>>> between TCG and KVM' dungeon.
>>
>>
>>> It seems like series does not apply on top of master, would that be
>>> possible to rebase it?
>>
>> For some reason the RISC-V series are handled distinctly than the
>> rest of QEMU, Alistair queues work on his repository and developers
>> are custome to base their series on top of it (otherwise Alistair
>> can not apply them on his tree and asks for reposts), see the
>> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
> 
> Unfortunately, it makes it hard to run any kind of automated testing,
> especially for series like this that target specific configs.

Don't we have ways of saying in the commit message "these patches applies
on top of these other patches" and then the tooling would deal with it?
I remember patchew doing stuff like that with that "Based-on: <message-id>"
tag.

At this point I would expect automatic tooling being able to understand
some form of "this gitlab/github branch contains the patches" and do their
thing.  Maybe there's stuff out there to help us out.


Thanks,
Daniel

On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza
<daniel.barboza@oss.qualcomm.com> wrote:
>
>
>
> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
> > On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
> >> On 22/6/26 22:52, Pierrick Bouvier wrote:
> >>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
> >>>> Hello,
> >>>>
> >>>> This series looks scary but it's mostly trivial and mechanical work.
> >>>>
> >>>> It is yet another attempt at fixing --disable-tcg.  We have a recent
> >>>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
> >>>> Phil's work didn't get merged and it's now too hard to rebase and
> >>>> revive, the most recent attempt got misled into the 'what is common code
> >>>> between TCG and KVM' dungeon.
> >>
> >>
> >>> It seems like series does not apply on top of master, would that be
> >>> possible to rebase it?
> >>
> >> For some reason the RISC-V series are handled distinctly than the
> >> rest of QEMU, Alistair queues work on his repository and developers
> >> are custome to base their series on top of it (otherwise Alistair
> >> can not apply them on his tree and asks for reposts), see the
> >> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
> >
> > Unfortunately, it makes it hard to run any kind of automated testing,
> > especially for series like this that target specific configs.
>
> Don't we have ways of saying in the commit message "these patches applies
> on top of these other patches" and then the tooling would deal with it?
> I remember patchew doing stuff like that with that "Based-on: <message-id>"
> tag.

Yes, Based-on: is our convention for marking "this patchset needs some
other one to be applied first". But that should be the exception rather
than a common case -- if patchsets regularly need to be based on
something other than head-of-git, this is I think a sign that
maintainers are not sending out pull requests frequently enough.

I would prefer it if QEMU didn't develop kernel-style "subsystems
have their own particular workflows" fragmentation -- I don't
think we're big enough or that sub-parts of QEMU are sufficiently
well separated for it to work out well.

thanks
-- PMM

On 6/23/2026 6:58 AM, Peter Maydell wrote:
> On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza
> <daniel.barboza@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
>>> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
>>>> On 22/6/26 22:52, Pierrick Bouvier wrote:
>>>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>>>>>> Hello,
>>>>>>
>>>>>> This series looks scary but it's mostly trivial and mechanical work.
>>>>>>
>>>>>> It is yet another attempt at fixing --disable-tcg.  We have a recent
>>>>>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
>>>>>> Phil's work didn't get merged and it's now too hard to rebase and
>>>>>> revive, the most recent attempt got misled into the 'what is common code
>>>>>> between TCG and KVM' dungeon.
>>>>
>>>>
>>>>> It seems like series does not apply on top of master, would that be
>>>>> possible to rebase it?
>>>>
>>>> For some reason the RISC-V series are handled distinctly than the
>>>> rest of QEMU, Alistair queues work on his repository and developers
>>>> are custome to base their series on top of it (otherwise Alistair
>>>> can not apply them on his tree and asks for reposts), see the
>>>> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
>>>
>>> Unfortunately, it makes it hard to run any kind of automated testing,
>>> especially for series like this that target specific configs.
>>
>> Don't we have ways of saying in the commit message "these patches applies
>> on top of these other patches" and then the tooling would deal with it?
>> I remember patchew doing stuff like that with that "Based-on: <message-id>"
>> tag.
> 
> Yes, Based-on: is our convention for marking "this patchset needs some
> other one to be applied first". But that should be the exception rather
> than a common case -- if patchsets regularly need to be based on
> something other than head-of-git, this is I think a sign that
> maintainers are not sending out pull requests frequently enough.
> 
> I would prefer it if QEMU didn't develop kernel-style "subsystems
> have their own particular workflows" fragmentation -- I don't
> think we're big enough or that sub-parts of QEMU are sufficiently
> well separated for it to work out well.

I agree that rebasing things on master is better than rebasing it on the
maintainer's tree.  And we could make a better job at informing developers that
submitting a patch for qemu-riscv, vfio or any particular subtree, means that
the patch should be based on a maintainer tree X.

The thing is that sending patches on master only works if master is always up
to date, and that's not feasible with our current style of merging PRs.  This
series we're commenting on is an example: it doesn't apply to master because
there are pre-approved RISC-V patches in the maintainer's tree from 2 days ago
(also my patches, I might add) that caused conflicts that I wasn't aware that
would happen.  This conflict would have to be dealt with at some point by myself
or the maintainer, and it's not like 2 days is too much time without a PR.

We can argue "this is an exception that doesn't happen that often, we should
stick with using master as a base", and to a certain extend that's true.  But
then this sort of conflict happens again, then again, then again, it comes to
a point where it's easier to tell developers to use the maintainer's tree instead
of master.

Maybe I'm downplaying the problem because I've been sending stuff based on the
maintainer's tree since forever and got used to it.  IMO, unless we decide to be
like libvirt and create the "committer" role to allow trustworthy devs to push
stuff to master after acks, making it more feasible to expect master to be up to
date, I'm afraid we're closer to a kernel-style workflow.  For better or worse.


Thanks,
Daniel


> 
> thanks
> -- PMM

On Tue, Jun 23, 2026 at 9:39 PM Daniel Henrique Barboza
<daniel.barboza@oss.qualcomm.com> wrote:
>
>
>
> On 6/23/2026 6:58 AM, Peter Maydell wrote:
> > On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza
> > <daniel.barboza@oss.qualcomm.com> wrote:
> >>
> >>
> >>
> >> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
> >>> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
> >>>> On 22/6/26 22:52, Pierrick Bouvier wrote:
> >>>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> This series looks scary but it's mostly trivial and mechanical work.
> >>>>>>
> >>>>>> It is yet another attempt at fixing --disable-tcg.  We have a recent
> >>>>>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
> >>>>>> Phil's work didn't get merged and it's now too hard to rebase and
> >>>>>> revive, the most recent attempt got misled into the 'what is common code
> >>>>>> between TCG and KVM' dungeon.
> >>>>
> >>>>
> >>>>> It seems like series does not apply on top of master, would that be
> >>>>> possible to rebase it?
> >>>>
> >>>> For some reason the RISC-V series are handled distinctly than the
> >>>> rest of QEMU, Alistair queues work on his repository and developers
> >>>> are custome to base their series on top of it (otherwise Alistair
> >>>> can not apply them on his tree and asks for reposts), see the
> >>>> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
> >>>
> >>> Unfortunately, it makes it hard to run any kind of automated testing,
> >>> especially for series like this that target specific configs.
> >>
> >> Don't we have ways of saying in the commit message "these patches applies
> >> on top of these other patches" and then the tooling would deal with it?
> >> I remember patchew doing stuff like that with that "Based-on: <message-id>"
> >> tag.
> >
> > Yes, Based-on: is our convention for marking "this patchset needs some
> > other one to be applied first". But that should be the exception rather
> > than a common case -- if patchsets regularly need to be based on
> > something other than head-of-git, this is I think a sign that
> > maintainers are not sending out pull requests frequently enough.
> >
> > I would prefer it if QEMU didn't develop kernel-style "subsystems
> > have their own particular workflows" fragmentation -- I don't
> > think we're big enough or that sub-parts of QEMU are sufficiently
> > well separated for it to work out well.
>
> I agree that rebasing things on master is better than rebasing it on the
> maintainer's tree.  And we could make a better job at informing developers that
> submitting a patch for qemu-riscv, vfio or any particular subtree, means that
> the patch should be based on a maintainer tree X.

I would prefer patches on master, the issue is it just creates a lot
of conflicts. That takes time for me to fix and I'm always worried
that I'll mess something up and it will go upstream with a bug that
wasn't in the original patch because no one gets a chance to verify
that I rebased it correctly.

>
> The thing is that sending patches on master only works if master is always up
> to date, and that's not feasible with our current style of merging PRs.  This
> series we're commenting on is an example: it doesn't apply to master because
> there are pre-approved RISC-V patches in the maintainer's tree from 2 days ago
> (also my patches, I might add) that caused conflicts that I wasn't aware that
> would happen.  This conflict would have to be dealt with at some point by myself
> or the maintainer, and it's not like 2 days is too much time without a PR.

Yeah, I try to send them every few weeks, but when all the patches are
touching the same few files it's hard not to hit conflicts.

>
> We can argue "this is an exception that doesn't happen that often, we should
> stick with using master as a base", and to a certain extend that's true.  But
> then this sort of conflict happens again, then again, then again, it comes to
> a point where it's easier to tell developers to use the maintainer's tree instead
> of master.

Which is exactly what happened. I think I have just asked people to
rebase on the RISC-V tree enough times that they just start with that
from the beginning.

Alistair

>
> Maybe I'm downplaying the problem because I've been sending stuff based on the
> maintainer's tree since forever and got used to it.  IMO, unless we decide to be
> like libvirt and create the "committer" role to allow trustworthy devs to push
> stuff to master after acks, making it more feasible to expect master to be up to
> date, I'm afraid we're closer to a kernel-style workflow.  For better or worse.
>
>
> Thanks,
> Daniel
>
>
> >
> > thanks
> > -- PMM
>
>

On 6/25/2026 6:37 PM, Alistair Francis wrote:
> On Tue, Jun 23, 2026 at 9:39 PM Daniel Henrique Barboza
> <daniel.barboza@oss.qualcomm.com> wrote:
>>
>>
>>
>> On 6/23/2026 6:58 AM, Peter Maydell wrote:
>>> On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza
>>> <daniel.barboza@oss.qualcomm.com> wrote:
>>>>
>>>>
>>>>
>>>> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
>>>>> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
>>>>>> On 22/6/26 22:52, Pierrick Bouvier wrote:
>>>>>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> This series looks scary but it's mostly trivial and mechanical work.
>>>>>>>>
>>>>>>>> It is yet another attempt at fixing --disable-tcg.  We have a recent
>>>>>>>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
>>>>>>>> Phil's work didn't get merged and it's now too hard to rebase and
>>>>>>>> revive, the most recent attempt got misled into the 'what is common code
>>>>>>>> between TCG and KVM' dungeon.
>>>>>>
>>>>>>
>>>>>>> It seems like series does not apply on top of master, would that be
>>>>>>> possible to rebase it?
>>>>>>
>>>>>> For some reason the RISC-V series are handled distinctly than the
>>>>>> rest of QEMU, Alistair queues work on his repository and developers
>>>>>> are custome to base their series on top of it (otherwise Alistair
>>>>>> can not apply them on his tree and asks for reposts), see the
>>>>>> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
>>>>>
>>>>> Unfortunately, it makes it hard to run any kind of automated testing,
>>>>> especially for series like this that target specific configs.
>>>>
>>>> Don't we have ways of saying in the commit message "these patches applies
>>>> on top of these other patches" and then the tooling would deal with it?
>>>> I remember patchew doing stuff like that with that "Based-on: <message-id>"
>>>> tag.
>>>
>>> Yes, Based-on: is our convention for marking "this patchset needs some
>>> other one to be applied first". But that should be the exception rather
>>> than a common case -- if patchsets regularly need to be based on
>>> something other than head-of-git, this is I think a sign that
>>> maintainers are not sending out pull requests frequently enough.
>>>
>>> I would prefer it if QEMU didn't develop kernel-style "subsystems
>>> have their own particular workflows" fragmentation -- I don't
>>> think we're big enough or that sub-parts of QEMU are sufficiently
>>> well separated for it to work out well.
>>
>> I agree that rebasing things on master is better than rebasing it on the
>> maintainer's tree.  And we could make a better job at informing developers that
>> submitting a patch for qemu-riscv, vfio or any particular subtree, means that
>> the patch should be based on a maintainer tree X.
> 
> I would prefer patches on master, the issue is it just creates a lot
> of conflicts. That takes time for me to fix and I'm always worried
> that I'll mess something up and it will go upstream with a bug that
> wasn't in the original patch because no one gets a chance to verify
> that I rebased it correctly.
>

I agree it does not scale. It creates friction both for you and people
who submit in the subsystem.

>>
>> The thing is that sending patches on master only works if master is always up
>> to date, and that's not feasible with our current style of merging PRs.  This
>> series we're commenting on is an example: it doesn't apply to master because
>> there are pre-approved RISC-V patches in the maintainer's tree from 2 days ago
>> (also my patches, I might add) that caused conflicts that I wasn't aware that
>> would happen.  This conflict would have to be dealt with at some point by myself
>> or the maintainer, and it's not like 2 days is too much time without a PR.
> 
> Yeah, I try to send them every few weeks, but when all the patches are
> touching the same few files it's hard not to hit conflicts.
>

Then simply apply a FIFO strategy. Take series as they come, and leave
conflicting one out. IMHO, it should not be the responsibility of a
maintainer.

>>
>> We can argue "this is an exception that doesn't happen that often, we should
>> stick with using master as a base", and to a certain extend that's true.  But
>> then this sort of conflict happens again, then again, then again, it comes to
>> a point where it's easier to tell developers to use the maintainer's tree instead
>> of master.
> 
> Which is exactly what happened. I think I have just asked people to
> rebase on the RISC-V tree enough times that they just start with that
> from the beginning.
>

How about merging things to master fast enough so people can just rebase
on master? It seems like it would solve both people problems, and yours
also. No need to do any rebase, and no wait time for developers.

The only thing it requires is to increase PR frequency, and I would even
go as far as suggesting to send one PR per series if you want to provide
the best velocity possible for this subsystem. Just automate the push
and CI triggering, so it does not take more than 2 min of your time.

When a conflict happen or a test fail, simply ask "please rebase/fix",
and wait for the next version. Not your problem anymore.

What do you think?

> Alistair
> 
>>
>> Maybe I'm downplaying the problem because I've been sending stuff based on the
>> maintainer's tree since forever and got used to it.  IMO, unless we decide to be
>> like libvirt and create the "committer" role to allow trustworthy devs to push
>> stuff to master after acks, making it more feasible to expect master to be up to
>> date, I'm afraid we're closer to a kernel-style workflow.  For better or worse.
>>
>>
>> Thanks,
>> Daniel
>>
>>
>>>
>>> thanks
>>> -- PMM
>>
>>

Regards,
Pierrick

On 6/23/2026 4:38 AM, Daniel Henrique Barboza wrote:
> 
> 
> On 6/23/2026 6:58 AM, Peter Maydell wrote:
>> On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza
>> <daniel.barboza@oss.qualcomm.com> wrote:
>>>
>>>
>>>
>>> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
>>>> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
>>>>> On 22/6/26 22:52, Pierrick Bouvier wrote:
>>>>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> This series looks scary but it's mostly trivial and mechanical work.
>>>>>>>
>>>>>>> It is yet another attempt at fixing --disable-tcg.  We have a recent
>>>>>>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
>>>>>>> Phil's work didn't get merged and it's now too hard to rebase and
>>>>>>> revive, the most recent attempt got misled into the 'what is
>>>>>>> common code
>>>>>>> between TCG and KVM' dungeon.
>>>>>
>>>>>
>>>>>> It seems like series does not apply on top of master, would that be
>>>>>> possible to rebase it?
>>>>>
>>>>> For some reason the RISC-V series are handled distinctly than the
>>>>> rest of QEMU, Alistair queues work on his repository and developers
>>>>> are custome to base their series on top of it (otherwise Alistair
>>>>> can not apply them on his tree and asks for reposts), see the
>>>>> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
>>>>
>>>> Unfortunately, it makes it hard to run any kind of automated testing,
>>>> especially for series like this that target specific configs.
>>>
>>> Don't we have ways of saying in the commit message "these patches
>>> applies
>>> on top of these other patches" and then the tooling would deal with it?
>>> I remember patchew doing stuff like that with that "Based-on:
>>> <message-id>"
>>> tag.
>>
>> Yes, Based-on: is our convention for marking "this patchset needs some
>> other one to be applied first". But that should be the exception rather
>> than a common case -- if patchsets regularly need to be based on
>> something other than head-of-git, this is I think a sign that
>> maintainers are not sending out pull requests frequently enough.
>>
>> I would prefer it if QEMU didn't develop kernel-style "subsystems
>> have their own particular workflows" fragmentation -- I don't
>> think we're big enough or that sub-parts of QEMU are sufficiently
>> well separated for it to work out well.
> 
> I agree that rebasing things on master is better than rebasing it on the
> maintainer's tree.  And we could make a better job at informing
> developers that
> submitting a patch for qemu-riscv, vfio or any particular subtree, means
> that
> the patch should be based on a maintainer tree X.
> 
> The thing is that sending patches on master only works if master is
> always up
> to date, and that's not feasible with our current style of merging PRs. 
> This
> series we're commenting on is an example: it doesn't apply to master
> because
> there are pre-approved RISC-V patches in the maintainer's tree from 2
> days ago
> (also my patches, I might add) that caused conflicts that I wasn't aware
> that
> would happen.  This conflict would have to be dealt with at some point
> by myself
> or the maintainer, and it's not like 2 days is too much time without a PR.
> 
> We can argue "this is an exception that doesn't happen that often, we
> should
> stick with using master as a base", and to a certain extend that's
> true.  But
> then this sort of conflict happens again, then again, then again, it
> comes to
> a point where it's easier to tell developers to use the maintainer's
> tree instead
> of master.
> 
> Maybe I'm downplaying the problem because I've been sending stuff based
> on the
> maintainer's tree since forever and got used to it.  IMO, unless we
> decide to be
> like libvirt and create the "committer" role to allow trustworthy devs
> to push
> stuff to master after acks, making it more feasible to expect master to
> be up to
> date, I'm afraid we're closer to a kernel-style workflow.  For better or
> worse.
> 
> 
> Thanks,
> Daniel
> 
> 
>>
>> thanks
>> -- PMM
> 

In this very specific case, where base patches are needed, maybe it
would be better to make the required commits appear in this series, and
mention in cover letter that patches 1-N are just coming from another
series and are already reviewed/approved. IMHO it doesn't hurt, and
reviewers are free to skip commits already reviewed.

Or, a solution I'm not fond of but I ended up adopting most of the time,
just wait for required patches to be merged on master before posting the
series, and work on something else meanwhile.

Ideally, yes, it would be better if maintainers could send PR more
frequently to avoid creating those intermediate staging trees. The
faster we merge, the less conflicts we'll have.

Regards,
Pierrick

On 6/23/2026 1:10 PM, Pierrick Bouvier wrote:
> On 6/23/2026 4:38 AM, Daniel Henrique Barboza wrote:
>>
>>
>> On 6/23/2026 6:58 AM, Peter Maydell wrote:
>>> On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza
>>> <daniel.barboza@oss.qualcomm.com> wrote:
>>>>
>>>>
>>>>
>>>> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
>>>>> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
>>>>>> On 22/6/26 22:52, Pierrick Bouvier wrote:
>>>>>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> This series looks scary but it's mostly trivial and mechanical work.
>>>>>>>>
>>>>>>>> It is yet another attempt at fixing --disable-tcg.  We have a recent
>>>>>>>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
>>>>>>>> Phil's work didn't get merged and it's now too hard to rebase and
>>>>>>>> revive, the most recent attempt got misled into the 'what is
>>>>>>>> common code
>>>>>>>> between TCG and KVM' dungeon.
>>>>>>
>>>>>>
>>>>>>> It seems like series does not apply on top of master, would that be
>>>>>>> possible to rebase it?
>>>>>>
>>>>>> For some reason the RISC-V series are handled distinctly than the
>>>>>> rest of QEMU, Alistair queues work on his repository and developers
>>>>>> are custome to base their series on top of it (otherwise Alistair
>>>>>> can not apply them on his tree and asks for reposts), see the
>>>>>> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
>>>>>
>>>>> Unfortunately, it makes it hard to run any kind of automated testing,
>>>>> especially for series like this that target specific configs.
>>>>
>>>> Don't we have ways of saying in the commit message "these patches
>>>> applies
>>>> on top of these other patches" and then the tooling would deal with it?
>>>> I remember patchew doing stuff like that with that "Based-on:
>>>> <message-id>"
>>>> tag.
>>>
>>> Yes, Based-on: is our convention for marking "this patchset needs some
>>> other one to be applied first". But that should be the exception rather
>>> than a common case -- if patchsets regularly need to be based on
>>> something other than head-of-git, this is I think a sign that
>>> maintainers are not sending out pull requests frequently enough.
>>>
>>> I would prefer it if QEMU didn't develop kernel-style "subsystems
>>> have their own particular workflows" fragmentation -- I don't
>>> think we're big enough or that sub-parts of QEMU are sufficiently
>>> well separated for it to work out well.
>>
>> I agree that rebasing things on master is better than rebasing it on the
>> maintainer's tree.  And we could make a better job at informing
>> developers that
>> submitting a patch for qemu-riscv, vfio or any particular subtree, means
>> that
>> the patch should be based on a maintainer tree X.
>>
>> The thing is that sending patches on master only works if master is
>> always up
>> to date, and that's not feasible with our current style of merging PRs.
>> This
>> series we're commenting on is an example: it doesn't apply to master
>> because
>> there are pre-approved RISC-V patches in the maintainer's tree from 2
>> days ago
>> (also my patches, I might add) that caused conflicts that I wasn't aware
>> that
>> would happen.  This conflict would have to be dealt with at some point
>> by myself
>> or the maintainer, and it's not like 2 days is too much time without a PR.
>>
>> We can argue "this is an exception that doesn't happen that often, we
>> should
>> stick with using master as a base", and to a certain extend that's
>> true.  But
>> then this sort of conflict happens again, then again, then again, it
>> comes to
>> a point where it's easier to tell developers to use the maintainer's
>> tree instead
>> of master.
>>
>> Maybe I'm downplaying the problem because I've been sending stuff based
>> on the
>> maintainer's tree since forever and got used to it.  IMO, unless we
>> decide to be
>> like libvirt and create the "committer" role to allow trustworthy devs
>> to push
>> stuff to master after acks, making it more feasible to expect master to
>> be up to
>> date, I'm afraid we're closer to a kernel-style workflow.  For better or
>> worse.
>>
>>
>> Thanks,
>> Daniel
>>
>>
>>>
>>> thanks
>>> -- PMM
>>
> 
> In this very specific case, where base patches are needed, maybe it
> would be better to make the required commits appear in this series, and
> mention in cover letter that patches 1-N are just coming from another
> series and are already reviewed/approved. IMHO it doesn't hurt, and
> reviewers are free to skip commits already reviewed.

That's fair enough but I wonder if that won't scare people away with
even bigger series :D  in this case here I would need to either send all
the queued patches, making the series go to 40+, or I would need to triage
which patches from the queue creates a conflict with this work and send
only those.

Now, as for qemu-ci ...  How farfetched it is to make it read a specific tag
in the cover-letter, e.g. "branch-id", that can point to a gitlab/github
repo with the patches, and use that code base instead of applying the
patches to the master branch?  Then for the next version of this work
I could do

"branch-id: https://gitlab.com/danielhb/qemu/-/tree/riscv_disabletcg_v2"

and the tool would still work.  If there's no "branch-id" then it assumes
that the patches are to be applied on master.


And yeah, in an ideal world the problem goes away if we just do more PRs and
strive to keep 'master' updated.  I'm just thinking out loud about possible
alternatives until we reach that point.


Cheers,
Daniel

> 
> Or, a solution I'm not fond of but I ended up adopting most of the time,
> just wait for required patches to be merged on master before posting the
> series, and work on something else meanwhile.
> 
> Ideally, yes, it would be better if maintainers could send PR more
> frequently to avoid creating those intermediate staging trees. The
> faster we merge, the less conflicts we'll have.
> 
> Regards,
> Pierrick

On 6/23/2026 12:01 PM, Daniel Henrique Barboza wrote:
> 
> 
> On 6/23/2026 1:10 PM, Pierrick Bouvier wrote:
>> On 6/23/2026 4:38 AM, Daniel Henrique Barboza wrote:
>>>
>>>
>>> On 6/23/2026 6:58 AM, Peter Maydell wrote:
>>>> On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza
>>>> <daniel.barboza@oss.qualcomm.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
>>>>>> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
>>>>>>> On 22/6/26 22:52, Pierrick Bouvier wrote:
>>>>>>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> This series looks scary but it's mostly trivial and mechanical
>>>>>>>>> work.
>>>>>>>>>
>>>>>>>>> It is yet another attempt at fixing --disable-tcg.  We have a
>>>>>>>>> recent
>>>>>>>>> work sent to the ML [1] and we had Phil's attempt back in 2023
>>>>>>>>> [2].
>>>>>>>>> Phil's work didn't get merged and it's now too hard to rebase and
>>>>>>>>> revive, the most recent attempt got misled into the 'what is
>>>>>>>>> common code
>>>>>>>>> between TCG and KVM' dungeon.
>>>>>>>
>>>>>>>
>>>>>>>> It seems like series does not apply on top of master, would that be
>>>>>>>> possible to rebase it?
>>>>>>>
>>>>>>> For some reason the RISC-V series are handled distinctly than the
>>>>>>> rest of QEMU, Alistair queues work on his repository and developers
>>>>>>> are custome to base their series on top of it (otherwise Alistair
>>>>>>> can not apply them on his tree and asks for reposts), see the
>>>>>>> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
>>>>>>
>>>>>> Unfortunately, it makes it hard to run any kind of automated testing,
>>>>>> especially for series like this that target specific configs.
>>>>>
>>>>> Don't we have ways of saying in the commit message "these patches
>>>>> applies
>>>>> on top of these other patches" and then the tooling would deal with
>>>>> it?
>>>>> I remember patchew doing stuff like that with that "Based-on:
>>>>> <message-id>"
>>>>> tag.
>>>>
>>>> Yes, Based-on: is our convention for marking "this patchset needs some
>>>> other one to be applied first". But that should be the exception rather
>>>> than a common case -- if patchsets regularly need to be based on
>>>> something other than head-of-git, this is I think a sign that
>>>> maintainers are not sending out pull requests frequently enough.
>>>>
>>>> I would prefer it if QEMU didn't develop kernel-style "subsystems
>>>> have their own particular workflows" fragmentation -- I don't
>>>> think we're big enough or that sub-parts of QEMU are sufficiently
>>>> well separated for it to work out well.
>>>
>>> I agree that rebasing things on master is better than rebasing it on the
>>> maintainer's tree.  And we could make a better job at informing
>>> developers that
>>> submitting a patch for qemu-riscv, vfio or any particular subtree, means
>>> that
>>> the patch should be based on a maintainer tree X.
>>>
>>> The thing is that sending patches on master only works if master is
>>> always up
>>> to date, and that's not feasible with our current style of merging PRs.
>>> This
>>> series we're commenting on is an example: it doesn't apply to master
>>> because
>>> there are pre-approved RISC-V patches in the maintainer's tree from 2
>>> days ago
>>> (also my patches, I might add) that caused conflicts that I wasn't aware
>>> that
>>> would happen.  This conflict would have to be dealt with at some point
>>> by myself
>>> or the maintainer, and it's not like 2 days is too much time without
>>> a PR.
>>>
>>> We can argue "this is an exception that doesn't happen that often, we
>>> should
>>> stick with using master as a base", and to a certain extend that's
>>> true.  But
>>> then this sort of conflict happens again, then again, then again, it
>>> comes to
>>> a point where it's easier to tell developers to use the maintainer's
>>> tree instead
>>> of master.
>>>
>>> Maybe I'm downplaying the problem because I've been sending stuff based
>>> on the
>>> maintainer's tree since forever and got used to it.  IMO, unless we
>>> decide to be
>>> like libvirt and create the "committer" role to allow trustworthy devs
>>> to push
>>> stuff to master after acks, making it more feasible to expect master to
>>> be up to
>>> date, I'm afraid we're closer to a kernel-style workflow.  For better or
>>> worse.
>>>
>>>
>>> Thanks,
>>> Daniel
>>>
>>>
>>>>
>>>> thanks
>>>> -- PMM
>>>
>>
>> In this very specific case, where base patches are needed, maybe it
>> would be better to make the required commits appear in this series, and
>> mention in cover letter that patches 1-N are just coming from another
>> series and are already reviewed/approved. IMHO it doesn't hurt, and
>> reviewers are free to skip commits already reviewed.
> 
> That's fair enough but I wonder if that won't scare people away with
> even bigger series :D  in this case here I would need to either send all
> the queued patches, making the series go to 40+, or I would need to triage
> which patches from the queue creates a conflict with this work and send
> only those.
> 
> Now, as for qemu-ci ...  How farfetched it is to make it read a specific
> tag
> in the cover-letter, e.g. "branch-id", that can point to a gitlab/github
> repo with the patches, and use that code base instead of applying the
> patches to the master branch?  Then for the next version of this work
> I could do
> 
> "branch-id: https://gitlab.com/danielhb/qemu/-/tree/riscv_disabletcg_v2"
>

Based-on: is a QEMU specific tag, that is only understood by patchew,
and no other tool to my knowledge.
b4 has base_commit, which allows to give a specific base, but not a
specific repository. I'm not aware of any b4 tag that allows to mention
a base series. It makes sense, series are not branches, and stacking
them comes with a lot of problems.

So it seems like email workflow is quite limited in this regard, and the
only way to deal with it properly is to wait for base patches to be
merged, or include them in the series.

From another perspective, the same problem would exist if we would use a
forge like GitHub or GitLab. It's not possible to stack PR on top of
others, and only solution is to wait, or duplicate patches. IMHO, it's a
sane default, as it forces correct ordering instead of allowing chaotic
development.

> and the tool would still work.  If there's no "branch-id" then it assumes
> that the patches are to be applied on master.
> 
> 
> And yeah, in an ideal world the problem goes away if we just do more PRs
> and
> strive to keep 'master' updated.  I'm just thinking out loud about possible
> alternatives until we reach that point.
> 
> 
> Cheers,
> Daniel
> 
>>
>> Or, a solution I'm not fond of but I ended up adopting most of the time,
>> just wait for required patches to be merged on master before posting the
>> series, and work on something else meanwhile.
>>
>> Ideally, yes, it would be better if maintainers could send PR more
>> frequently to avoid creating those intermediate staging trees. The
>> faster we merge, the less conflicts we'll have.
>>
>> Regards,
>> Pierrick
> 

On Tue, Jun 23, 2026 at 12:16:56PM -0700, Pierrick Bouvier wrote:
> Based-on: is a QEMU specific tag, that is only understood by patchew,
> and no other tool to my knowledge.
> b4 has base_commit, which allows to give a specific base, but not a
> specific repository. I'm not aware of any b4 tag that allows to mention
> a base series. It makes sense, series are not branches, and stacking
> them comes with a lot of problems.
> 
> So it seems like email workflow is quite limited in this regard, and the
> only way to deal with it properly is to wait for base patches to be
> merged, or include them in the series.

You *can* specify dependencies with a b4-managed branch, via --edit-deps.
However, both the contributor and the maintainer have to use b4 to retrieve
and apply patches for it to really work.

If the maintainer retrieves the series using "b4 shazam <msgid>" then, if the
series specifies prerequisites, they will all be retrieved and applied.

See https://b4.docs.kernel.org/en/latest/contributor/prep.html#working-with-series-dependencies

It remains marked as "experimental" simply because not enough people use it
and therefore there are still many corner-case bugs that exist and just
haven't been properly discovered.

HTH!

-K

On 6/26/2026 8:31 PM, Konstantin Ryabitsev wrote:
> On Tue, Jun 23, 2026 at 12:16:56PM -0700, Pierrick Bouvier wrote:
>> Based-on: is a QEMU specific tag, that is only understood by patchew,
>> and no other tool to my knowledge.
>> b4 has base_commit, which allows to give a specific base, but not a
>> specific repository. I'm not aware of any b4 tag that allows to mention
>> a base series. It makes sense, series are not branches, and stacking
>> them comes with a lot of problems.
>>
>> So it seems like email workflow is quite limited in this regard, and the
>> only way to deal with it properly is to wait for base patches to be
>> merged, or include them in the series.
> 
> You *can* specify dependencies with a b4-managed branch, via --edit-deps.
> However, both the contributor and the maintainer have to use b4 to retrieve
> and apply patches for it to really work.
> 
> If the maintainer retrieves the series using "b4 shazam <msgid>" then, if the
> series specifies prerequisites, they will all be retrieved and applied.
> 
> See https://b4.docs.kernel.org/en/latest/contributor/prep.html#working-with-series-dependencies
> 
> It remains marked as "experimental" simply because not enough people use it
> and therefore there are still many corner-case bugs that exist and just
> haven't been properly discovered.
>

Maybe I missed something in the documentation (feel free to correct me),
but as mentioned above, it seems like b4 only has base-commit (+
change-id, message-id, patch-id). In the current discussion, the need
would be to specify a base commit/branch + a base repository, similar to
information included in a pull request, thus why I said it's limited. I
didn't see how to cover that with b4 or any other tool and email
workflow, and maybe it's not even a good idea to be honest.

> HTH!
> 
> -K

Thanks,
Pierrick

On Wed, Jun 24, 2026 at 5:18 AM Pierrick Bouvier
<pierrick.bouvier@oss.qualcomm.com> wrote:
>
> On 6/23/2026 12:01 PM, Daniel Henrique Barboza wrote:
> >
> >
> > On 6/23/2026 1:10 PM, Pierrick Bouvier wrote:
> >> On 6/23/2026 4:38 AM, Daniel Henrique Barboza wrote:
> >>>
> >>>
> >>> On 6/23/2026 6:58 AM, Peter Maydell wrote:
> >>>> On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza
> >>>> <daniel.barboza@oss.qualcomm.com> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
> >>>>>> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
> >>>>>>> On 22/6/26 22:52, Pierrick Bouvier wrote:
> >>>>>>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
> >>>>>>>>> Hello,
> >>>>>>>>>
> >>>>>>>>> This series looks scary but it's mostly trivial and mechanical
> >>>>>>>>> work.
> >>>>>>>>>
> >>>>>>>>> It is yet another attempt at fixing --disable-tcg.  We have a
> >>>>>>>>> recent
> >>>>>>>>> work sent to the ML [1] and we had Phil's attempt back in 2023
> >>>>>>>>> [2].
> >>>>>>>>> Phil's work didn't get merged and it's now too hard to rebase and
> >>>>>>>>> revive, the most recent attempt got misled into the 'what is
> >>>>>>>>> common code
> >>>>>>>>> between TCG and KVM' dungeon.
> >>>>>>>
> >>>>>>>
> >>>>>>>> It seems like series does not apply on top of master, would that be
> >>>>>>>> possible to rebase it?
> >>>>>>>
> >>>>>>> For some reason the RISC-V series are handled distinctly than the
> >>>>>>> rest of QEMU, Alistair queues work on his repository and developers
> >>>>>>> are custome to base their series on top of it (otherwise Alistair
> >>>>>>> can not apply them on his tree and asks for reposts), see the
> >>>>>>> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
> >>>>>>
> >>>>>> Unfortunately, it makes it hard to run any kind of automated testing,
> >>>>>> especially for series like this that target specific configs.
> >>>>>
> >>>>> Don't we have ways of saying in the commit message "these patches
> >>>>> applies
> >>>>> on top of these other patches" and then the tooling would deal with
> >>>>> it?
> >>>>> I remember patchew doing stuff like that with that "Based-on:
> >>>>> <message-id>"
> >>>>> tag.
> >>>>
> >>>> Yes, Based-on: is our convention for marking "this patchset needs some
> >>>> other one to be applied first". But that should be the exception rather
> >>>> than a common case -- if patchsets regularly need to be based on
> >>>> something other than head-of-git, this is I think a sign that
> >>>> maintainers are not sending out pull requests frequently enough.
> >>>>
> >>>> I would prefer it if QEMU didn't develop kernel-style "subsystems
> >>>> have their own particular workflows" fragmentation -- I don't
> >>>> think we're big enough or that sub-parts of QEMU are sufficiently
> >>>> well separated for it to work out well.
> >>>
> >>> I agree that rebasing things on master is better than rebasing it on the
> >>> maintainer's tree.  And we could make a better job at informing
> >>> developers that
> >>> submitting a patch for qemu-riscv, vfio or any particular subtree, means
> >>> that
> >>> the patch should be based on a maintainer tree X.
> >>>
> >>> The thing is that sending patches on master only works if master is
> >>> always up
> >>> to date, and that's not feasible with our current style of merging PRs.
> >>> This
> >>> series we're commenting on is an example: it doesn't apply to master
> >>> because
> >>> there are pre-approved RISC-V patches in the maintainer's tree from 2
> >>> days ago
> >>> (also my patches, I might add) that caused conflicts that I wasn't aware
> >>> that
> >>> would happen.  This conflict would have to be dealt with at some point
> >>> by myself
> >>> or the maintainer, and it's not like 2 days is too much time without
> >>> a PR.
> >>>
> >>> We can argue "this is an exception that doesn't happen that often, we
> >>> should
> >>> stick with using master as a base", and to a certain extend that's
> >>> true.  But
> >>> then this sort of conflict happens again, then again, then again, it
> >>> comes to
> >>> a point where it's easier to tell developers to use the maintainer's
> >>> tree instead
> >>> of master.
> >>>
> >>> Maybe I'm downplaying the problem because I've been sending stuff based
> >>> on the
> >>> maintainer's tree since forever and got used to it.  IMO, unless we
> >>> decide to be
> >>> like libvirt and create the "committer" role to allow trustworthy devs
> >>> to push
> >>> stuff to master after acks, making it more feasible to expect master to
> >>> be up to
> >>> date, I'm afraid we're closer to a kernel-style workflow.  For better or
> >>> worse.
> >>>
> >>>
> >>> Thanks,
> >>> Daniel
> >>>
> >>>
> >>>>
> >>>> thanks
> >>>> -- PMM
> >>>
> >>
> >> In this very specific case, where base patches are needed, maybe it
> >> would be better to make the required commits appear in this series, and
> >> mention in cover letter that patches 1-N are just coming from another
> >> series and are already reviewed/approved. IMHO it doesn't hurt, and
> >> reviewers are free to skip commits already reviewed.
> >
> > That's fair enough but I wonder if that won't scare people away with
> > even bigger series :D  in this case here I would need to either send all
> > the queued patches, making the series go to 40+, or I would need to triage
> > which patches from the queue creates a conflict with this work and send
> > only those.
> >
> > Now, as for qemu-ci ...  How farfetched it is to make it read a specific
> > tag
> > in the cover-letter, e.g. "branch-id", that can point to a gitlab/github
> > repo with the patches, and use that code base instead of applying the
> > patches to the master branch?  Then for the next version of this work
> > I could do
> >
> > "branch-id: https://gitlab.com/danielhb/qemu/-/tree/riscv_disabletcg_v2"
> >
>
> Based-on: is a QEMU specific tag, that is only understood by patchew,
> and no other tool to my knowledge.
> b4 has base_commit, which allows to give a specific base, but not a
> specific repository. I'm not aware of any b4 tag that allows to mention
> a base series. It makes sense, series are not branches, and stacking
> them comes with a lot of problems.
>
> So it seems like email workflow is quite limited in this regard, and the
> only way to deal with it properly is to wait for base patches to be
> merged, or include them in the series.
>
> From another perspective, the same problem would exist if we would use a
> forge like GitHub or GitLab. It's not possible to stack PR on top of
> others, and only solution is to wait, or duplicate patches. IMHO, it's a
> sane default, as it forces correct ordering instead of allowing chaotic
> development.
>
> > and the tool would still work.  If there's no "branch-id" then it assumes
> > that the patches are to be applied on master.
> >
> >
> > And yeah, in an ideal world the problem goes away if we just do more PRs
> > and
> > strive to keep 'master' updated.  I'm just thinking out loud about possible
> > alternatives until we reach that point.

When you sent v2 of this series it had been one week since the last
RISC-V PR. Are we really aiming for more than one PR a week?

> >
> >
> > Cheers,
> > Daniel
> >
> >>
> >> Or, a solution I'm not fond of but I ended up adopting most of the time,
> >> just wait for required patches to be merged on master before posting the
> >> series, and work on something else meanwhile.

I do feel that a few people do that, just not Daniel :)

Alistair

> >>
> >> Ideally, yes, it would be better if maintainers could send PR more
> >> frequently to avoid creating those intermediate staging trees. The
> >> faster we merge, the less conflicts we'll have.
> >>
> >> Regards,
> >> Pierrick
> >
>
>

On 6/25/2026 6:41 PM, Alistair Francis wrote:
> On Wed, Jun 24, 2026 at 5:18 AM Pierrick Bouvier
> <pierrick.bouvier@oss.qualcomm.com> wrote:
>>
>> On 6/23/2026 12:01 PM, Daniel Henrique Barboza wrote:
>>>
>>>
>>> On 6/23/2026 1:10 PM, Pierrick Bouvier wrote:
>>>> On 6/23/2026 4:38 AM, Daniel Henrique Barboza wrote:
>>>>>
>>>>>
>>>>> On 6/23/2026 6:58 AM, Peter Maydell wrote:
>>>>>> On Tue, 23 Jun 2026 at 10:49, Daniel Henrique Barboza
>>>>>> <daniel.barboza@oss.qualcomm.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 6/22/2026 6:34 PM, Pierrick Bouvier wrote:
>>>>>>>> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
>>>>>>>>> On 22/6/26 22:52, Pierrick Bouvier wrote:
>>>>>>>>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> This series looks scary but it's mostly trivial and mechanical
>>>>>>>>>>> work.
>>>>>>>>>>>
>>>>>>>>>>> It is yet another attempt at fixing --disable-tcg.  We have a
>>>>>>>>>>> recent
>>>>>>>>>>> work sent to the ML [1] and we had Phil's attempt back in 2023
>>>>>>>>>>> [2].
>>>>>>>>>>> Phil's work didn't get merged and it's now too hard to rebase and
>>>>>>>>>>> revive, the most recent attempt got misled into the 'what is
>>>>>>>>>>> common code
>>>>>>>>>>> between TCG and KVM' dungeon.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> It seems like series does not apply on top of master, would that be
>>>>>>>>>> possible to rebase it?
>>>>>>>>>
>>>>>>>>> For some reason the RISC-V series are handled distinctly than the
>>>>>>>>> rest of QEMU, Alistair queues work on his repository and developers
>>>>>>>>> are custome to base their series on top of it (otherwise Alistair
>>>>>>>>> can not apply them on his tree and asks for reposts), see the
>>>>>>>>> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
>>>>>>>>
>>>>>>>> Unfortunately, it makes it hard to run any kind of automated testing,
>>>>>>>> especially for series like this that target specific configs.
>>>>>>>
>>>>>>> Don't we have ways of saying in the commit message "these patches
>>>>>>> applies
>>>>>>> on top of these other patches" and then the tooling would deal with
>>>>>>> it?
>>>>>>> I remember patchew doing stuff like that with that "Based-on:
>>>>>>> <message-id>"
>>>>>>> tag.
>>>>>>
>>>>>> Yes, Based-on: is our convention for marking "this patchset needs some
>>>>>> other one to be applied first". But that should be the exception rather
>>>>>> than a common case -- if patchsets regularly need to be based on
>>>>>> something other than head-of-git, this is I think a sign that
>>>>>> maintainers are not sending out pull requests frequently enough.
>>>>>>
>>>>>> I would prefer it if QEMU didn't develop kernel-style "subsystems
>>>>>> have their own particular workflows" fragmentation -- I don't
>>>>>> think we're big enough or that sub-parts of QEMU are sufficiently
>>>>>> well separated for it to work out well.
>>>>>
>>>>> I agree that rebasing things on master is better than rebasing it on the
>>>>> maintainer's tree.  And we could make a better job at informing
>>>>> developers that
>>>>> submitting a patch for qemu-riscv, vfio or any particular subtree, means
>>>>> that
>>>>> the patch should be based on a maintainer tree X.
>>>>>
>>>>> The thing is that sending patches on master only works if master is
>>>>> always up
>>>>> to date, and that's not feasible with our current style of merging PRs.
>>>>> This
>>>>> series we're commenting on is an example: it doesn't apply to master
>>>>> because
>>>>> there are pre-approved RISC-V patches in the maintainer's tree from 2
>>>>> days ago
>>>>> (also my patches, I might add) that caused conflicts that I wasn't aware
>>>>> that
>>>>> would happen.  This conflict would have to be dealt with at some point
>>>>> by myself
>>>>> or the maintainer, and it's not like 2 days is too much time without
>>>>> a PR.
>>>>>
>>>>> We can argue "this is an exception that doesn't happen that often, we
>>>>> should
>>>>> stick with using master as a base", and to a certain extend that's
>>>>> true.  But
>>>>> then this sort of conflict happens again, then again, then again, it
>>>>> comes to
>>>>> a point where it's easier to tell developers to use the maintainer's
>>>>> tree instead
>>>>> of master.
>>>>>
>>>>> Maybe I'm downplaying the problem because I've been sending stuff based
>>>>> on the
>>>>> maintainer's tree since forever and got used to it.  IMO, unless we
>>>>> decide to be
>>>>> like libvirt and create the "committer" role to allow trustworthy devs
>>>>> to push
>>>>> stuff to master after acks, making it more feasible to expect master to
>>>>> be up to
>>>>> date, I'm afraid we're closer to a kernel-style workflow.  For better or
>>>>> worse.
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Daniel
>>>>>
>>>>>
>>>>>>
>>>>>> thanks
>>>>>> -- PMM
>>>>>
>>>>
>>>> In this very specific case, where base patches are needed, maybe it
>>>> would be better to make the required commits appear in this series, and
>>>> mention in cover letter that patches 1-N are just coming from another
>>>> series and are already reviewed/approved. IMHO it doesn't hurt, and
>>>> reviewers are free to skip commits already reviewed.
>>>
>>> That's fair enough but I wonder if that won't scare people away with
>>> even bigger series :D  in this case here I would need to either send all
>>> the queued patches, making the series go to 40+, or I would need to triage
>>> which patches from the queue creates a conflict with this work and send
>>> only those.
>>>
>>> Now, as for qemu-ci ...  How farfetched it is to make it read a specific
>>> tag
>>> in the cover-letter, e.g. "branch-id", that can point to a gitlab/github
>>> repo with the patches, and use that code base instead of applying the
>>> patches to the master branch?  Then for the next version of this work
>>> I could do
>>>
>>> "branch-id: https://gitlab.com/danielhb/qemu/-/tree/riscv_disabletcg_v2"
>>>
>>
>> Based-on: is a QEMU specific tag, that is only understood by patchew,
>> and no other tool to my knowledge.
>> b4 has base_commit, which allows to give a specific base, but not a
>> specific repository. I'm not aware of any b4 tag that allows to mention
>> a base series. It makes sense, series are not branches, and stacking
>> them comes with a lot of problems.
>>
>> So it seems like email workflow is quite limited in this regard, and the
>> only way to deal with it properly is to wait for base patches to be
>> merged, or include them in the series.
>>
>> From another perspective, the same problem would exist if we would use a
>> forge like GitHub or GitLab. It's not possible to stack PR on top of
>> others, and only solution is to wait, or duplicate patches. IMHO, it's a
>> sane default, as it forces correct ordering instead of allowing chaotic
>> development.
>>
>>> and the tool would still work.  If there's no "branch-id" then it assumes
>>> that the patches are to be applied on master.
>>>
>>>
>>> And yeah, in an ideal world the problem goes away if we just do more PRs
>>> and
>>> strive to keep 'master' updated.  I'm just thinking out loud about possible
>>> alternatives until we reach that point.
> 
> When you sent v2 of this series it had been one week since the last
> RISC-V PR. Are we really aiming for more than one PR a week?
> 
>>>
>>>
>>> Cheers,
>>> Daniel
>>>
>>>>
>>>> Or, a solution I'm not fond of but I ended up adopting most of the time,
>>>> just wait for required patches to be merged on master before posting the
>>>> series, and work on something else meanwhile.
> 
> I do feel that a few people do that, just not Daniel :)
>

Waiting works well if you know the wait period is deterministic. "Ok, I
missed this train, let me catch the one next week". Unfortunately, it
varies per maintainer, and some are even stochastic processes on their own.

I can't blame people who submit and are not maintainer to feel
frustration with this, it's a real issue.

> Alistair
> 
>>>>
>>>> Ideally, yes, it would be better if maintainers could send PR more
>>>> frequently to avoid creating those intermediate staging trees. The
>>>> faster we merge, the less conflicts we'll have.
>>>>
>>>> Regards,
>>>> Pierrick
>>>
>>
>>

On 22/6/26 23:34, Pierrick Bouvier wrote:
> On 6/22/2026 2:23 PM, Philippe Mathieu-Daudé wrote:
>> On 22/6/26 22:52, Pierrick Bouvier wrote:
>>> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>>>> Hello,
>>>>
>>>> This series looks scary but it's mostly trivial and mechanical work.
>>>>
>>>> It is yet another attempt at fixing --disable-tcg.  We have a recent
>>>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
>>>> Phil's work didn't get merged and it's now too hard to rebase and
>>>> revive, the most recent attempt got misled into the 'what is common code
>>>> between TCG and KVM' dungeon.
>>
>>
>>> It seems like series does not apply on top of master, would that be
>>> possible to rebase it?
>>
>> For some reason the RISC-V series are handled distinctly than the
>> rest of QEMU, Alistair queues work on his repository and developers
>> are custome to base their series on top of it (otherwise Alistair
>> can not apply them on his tree and asks for reposts), see the
>> riscv-to-apply.next branch on https://github.com/alistair23/qemu.
> 
> Unfortunately, it makes it hard to run any kind of automated testing,
> especially for series like this that target specific configs.

I agree, I was just explaining this special workflow. Peter also
told Cédric his preference for not using distinct workflow for VFIO:
https://lore.kernel.org/qemu-devel/CAFEAcA9HGWgJYvU_GVZCsxM7-WaR5QuwLES8aetPqD9jaLKr_A@mail.gmail.com/

On 6/22/2026 5:52 PM, Pierrick Bouvier wrote:
> On 6/22/2026 12:31 PM, Daniel Henrique Barboza wrote:
>> Hello,
>>
>> This series looks scary but it's mostly trivial and mechanical work.
>>
>> It is yet another attempt at fixing --disable-tcg.  We have a recent
>> work sent to the ML [1] and we had Phil's attempt back in 2023 [2].
>> Phil's work didn't get merged and it's now too hard to rebase and
>> revive, the most recent attempt got misled into the 'what is common code
>> between TCG and KVM' dungeon.
>>
>> After reviewing [1] I went ahead and look what other targets were doing
>> w.r.t their directory structure and comparing to RISC-V.  In our case we
>> have a log going on in target/riscv:
>>
>> $ ls target/riscv
>> Kconfig                 cpu_cfg.h             fpu_helper.c   machine.c         sbi_ecall_interface.h  vector_internals.c
>> XVentanaCondOps.decode  cpu_cfg_fields.h.inc  gdbstub.c      meson.build       tcg                    vector_internals.h
>> arch_dump.c             cpu_helper.c          helper.h       mips_csr.c        th_csr.c               xlrbr.decode
>> bitmanip_helper.c       cpu_user.h            insn16.decode  monitor.c         time_helper.c          xmips.decode
>> common-semi-target.c    cpu_vendorid.h        insn32.decode  op_helper.c       time_helper.h          xthead.decode
>> cpu-param.h             crypto_helper.c       insn_trans     pmp.c             trace-events           zce_helper.c
>> cpu-qom.h               csr.c                 instmap.h      pmp.h             trace.h
>> cpu.c                   csr.h                 internals.h    pmu.c             translate.c
>> cpu.h                   debug.c               kvm            pmu.h             vcrypto_helper.c
>> cpu_bits.h              debug.h               m128_helper.c  riscv-qmp-cmds.c  vector_helper.c
>>
>>
>> It is non-trivial to realize that most of this stuff is TCG specific.
>> Meanwhile our 'tcg' subdir is mostly empty:
>>
>> $ ls target/riscv/tcg
>> meson.build  tcg-cpu.c  tcg-cpu.h
>>
>> If we compare it with other targets, let's say loongarch:
>>
>> $ ls target/loongarch/
>> Kconfig      cpu-csr.h    cpu-qom.h  cpu_helper.c  disas.c    insns.decode  loongarch-qmp-cmds.c  tcg           translate.h
>> README       cpu-mmu.h    cpu.c      csr.c         gdbstub.c  internals.h   machine.c             trace-events  vec.h
>> arch_dump.c  cpu-param.h  cpu.h      csr.h         helper.h   kvm           meson.build           trace.h
>> $
>> $ ls target/loongarch/tcg
>> constant_timer.c  fpu_helper.c  insn_trans      meson.build  tcg_cpu.c        tlb_helper.c  vec_helper.c
>> csr_helper.c      helper.h      iocsr_helper.c  op_helper.c  tcg_loongarch.h  translate.c
>>
>> It is straightforward to see which files are TCG exclusive and which
>> files are common to all accels.
>>
>> And this is what we did here.  The patches goes mostly as follows:
>>
>> - move stuff to 'tcg' subdir.  Most stuff is straighforward and is
>>    manageable with a single patch.  Other things required some logic to
>>    go to either cpu.c or tcg-cpu;
>> - move TCG stuff to tcg-cpu.c;
>> - move common accel stuff to cpu.c.  Usually from cpu_helper.c;
>> - filter TCG specific code in cpu.c and other files;
>> - trivial/assorted fixes in misc files that were needed to make
>>    --disable-tcg work.
>>
>> Patch 24 is taken from Zephyr Li to enable the CI for --disable-tcg.
>> Hopefully we won't break it anytime soon.
>>
>> After this series we have --disable-tcg working and the following dir
>> structure:
>>
>> $ ls target/riscv
>> Kconfig                 cpu.c                 cpu_vendorid.h  internals.h       sbi_ecall_interface.h  xlrbr.decode
>> XVentanaCondOps.decode  cpu.h                 gdbstub.c       kvm               tcg                    xmips.decode
>> arch_dump.c             cpu_bits.h            helper.h        machine.c         time_helper.c          xthead.decode
>> common-semi-target.c    cpu_cfg.h             insn16.decode   meson.build       time_helper.h
>> cpu-param.h             cpu_cfg_fields.h.inc  insn32.decode   monitor.c         trace-events
>> cpu-qom.h               cpu_user.h            instmap.h       riscv-qmp-cmds.c  trace.h
>> $
>> $ ls target/riscv/tcg
>> bitmanip_helper.c  csr.h         insn_trans     op_helper.c  pmu.h      translate.c         vector_internals.h
>> cpu_helper.c       debug.c       m128_helper.c  pmp.c        tcg-cpu.c  vcrypto_helper.c    zce_helper.c
>> crypto_helper.c    debug.h       meson.build    pmp.h        tcg-cpu.h  vector_helper.c
>> csr.c              fpu_helper.c  mips_csr.c     pmu.c        th_csr.c   vector_internals.c
>>
>>
>> [1] https://lore.kernel.org/qemu-devel/20260602091753.3209261-1-fritchleybohrer@gmail.com/
>> [2] https://lore.kernel.org/qemu-devel/20230711121453.59138-1-philmd@linaro.org/
>>
>>
>> Daniel Henrique Barboza (22):
>>    target/riscv: move TCG only files to tcg subdir
>>    target/riscv/machine.c: do not migrate pmp state with kvm
>>    target/riscv: move pmp files to tcg subdir
>>    target/riscv: make some riscv_sysemu_ops TCG only
>>    target/riscv: move pmu.h to tcg subdir
>>    target/riscv: move debug.h to tcg subdir
>>    target/riscv: remove csr.h from kvm-cpu.c
>>    target/riscv: move csr.h to tcg subdir
>>    target/riscv: move custom_csrs logic to tcg-cpu.c
>>    target/riscv: move riscv_cpu_set_nmi() to tcg-cpu.c
>>    target/riscv: move valid_vm_* satp arrays to cpu.c
>>    target/riscv: move some irq helpers to cpu.c
>>    target/riscv: move riscv_cpu_claim_interrupts to cpu.c
>>    target/riscv/cpu.c: handle TCG bits of riscv_cpu_dump_state
>>    target/riscv: gate riscv_cpu_update_mip with tcg_enabled()
>>    target/riscv/cpu.c: filter TCG only bits in riscv_cpu_reset_hold()
>>    hw/riscv/riscv_hart.c isolate tcg only bits
>>    target/riscv/gdbstub.c: isolate TCG only checks
>>    target/riscv: move riscv_cpu_set_rdtime_fn to riscv_aclint
>>    target/riscv/tcg: remove unused riscv_cpu_get_geilen()
>>    target/riscv: move riscv_cpu_set_geilen() to riscv-imsic
>>    target/riscv: move riscv_cpu_set_aia_ireg_rmw_cb() to riscv_imsic
>>
>> Zephyr Li (2):
>>    target/riscv: Remove unused tcg/tcg.h include
>>    gitlab-ci.d/crossbuilds: add riscv64 KVM-only build job
>>
>>   .gitlab-ci.d/crossbuilds.yml                  |   8 +
>>   hw/intc/riscv_aclint.c                        |   8 +
>>   hw/intc/riscv_imsic.c                         |  24 ++
>>   hw/riscv/fdt-common.c                         |  52 +++
>>   hw/riscv/riscv_hart.c                         |   4 +-
>>   hw/riscv/virt.c                               |   1 -
>>   include/hw/riscv/fdt-common.h                 |   1 +
>>   target/riscv/cpu.c                            | 316 +++++++++++++++---
>>   target/riscv/cpu.h                            |  19 +-
>>   target/riscv/gdbstub.c                        |  10 +-
>>   target/riscv/kvm/kvm-cpu.c                    |   1 -
>>   target/riscv/machine.c                        |  15 +-
>>   target/riscv/meson.build                      |  17 -
>>   target/riscv/monitor.c                        |   4 +-
>>   target/riscv/riscv-qmp-cmds.c                 |   2 +-
>>   target/riscv/{ => tcg}/bitmanip_helper.c      |   0
>>   target/riscv/{ => tcg}/cpu_helper.c           | 239 +------------
>>   target/riscv/{ => tcg}/crypto_helper.c        |   0
>>   target/riscv/{ => tcg}/csr.c                  |  45 +--
>>   target/riscv/{ => tcg}/csr.h                  |   6 +-
>>   target/riscv/{ => tcg}/debug.c                |   2 +-
>>   target/riscv/{ => tcg}/debug.h                |   0
>>   target/riscv/{ => tcg}/fpu_helper.c           |   0
>>   .../insn_trans/trans_privileged.c.inc         |   0
>>   .../{ => tcg}/insn_trans/trans_rva.c.inc      |   0
>>   .../{ => tcg}/insn_trans/trans_rvb.c.inc      |   0
>>   .../{ => tcg}/insn_trans/trans_rvbf16.c.inc   |   0
>>   .../{ => tcg}/insn_trans/trans_rvd.c.inc      |   0
>>   .../{ => tcg}/insn_trans/trans_rvf.c.inc      |   0
>>   .../{ => tcg}/insn_trans/trans_rvh.c.inc      |   0
>>   .../{ => tcg}/insn_trans/trans_rvi.c.inc      |   0
>>   .../{ => tcg}/insn_trans/trans_rvk.c.inc      |   0
>>   .../{ => tcg}/insn_trans/trans_rvm.c.inc      |   0
>>   .../{ => tcg}/insn_trans/trans_rvv.c.inc      |   0
>>   .../{ => tcg}/insn_trans/trans_rvvk.c.inc     |   0
>>   .../{ => tcg}/insn_trans/trans_rvzabha.c.inc  |   0
>>   .../{ => tcg}/insn_trans/trans_rvzacas.c.inc  |   0
>>   .../{ => tcg}/insn_trans/trans_rvzalasr.c.inc |   0
>>   .../{ => tcg}/insn_trans/trans_rvzawrs.c.inc  |   0
>>   .../{ => tcg}/insn_trans/trans_rvzce.c.inc    |   0
>>   .../{ => tcg}/insn_trans/trans_rvzcmop.c.inc  |   0
>>   .../{ => tcg}/insn_trans/trans_rvzfa.c.inc    |   0
>>   .../{ => tcg}/insn_trans/trans_rvzfh.c.inc    |   0
>>   .../{ => tcg}/insn_trans/trans_rvzicbo.c.inc  |   0
>>   .../insn_trans/trans_rvzicfiss.c.inc          |   0
>>   .../{ => tcg}/insn_trans/trans_rvzicond.c.inc |   0
>>   .../{ => tcg}/insn_trans/trans_rvzimop.c.inc  |   0
>>   .../{ => tcg}/insn_trans/trans_svinval.c.inc  |   0
>>   .../{ => tcg}/insn_trans/trans_xlrbr.c.inc    |   0
>>   .../{ => tcg}/insn_trans/trans_xmips.c.inc    |   0
>>   .../{ => tcg}/insn_trans/trans_xthead.c.inc   |   0
>>   .../insn_trans/trans_xventanacondops.c.inc    |   0
>>   .../{ => tcg}/insn_trans/trans_zilsd.c.inc    |   0
>>   target/riscv/{ => tcg}/m128_helper.c          |   0
>>   target/riscv/tcg/meson.build                  |  31 +-
>>   target/riscv/{ => tcg}/mips_csr.c             |   2 +-
>>   target/riscv/{ => tcg}/op_helper.c            |   2 +-
>>   target/riscv/{ => tcg}/pmp.c                  |   2 +-
>>   target/riscv/{ => tcg}/pmp.h                  |   0
>>   target/riscv/{ => tcg}/pmu.c                  |  52 ---
>>   target/riscv/{ => tcg}/pmu.h                  |   1 -
>>   target/riscv/tcg/tcg-cpu.c                    |  30 +-
>>   target/riscv/{ => tcg}/th_csr.c               |   2 +-
>>   target/riscv/{ => tcg}/translate.c            |   0
>>   target/riscv/{ => tcg}/vcrypto_helper.c       |   0
>>   target/riscv/{ => tcg}/vector_helper.c        |   0
>>   target/riscv/{ => tcg}/vector_internals.c     |   0
>>   target/riscv/{ => tcg}/vector_internals.h     |   0
>>   target/riscv/{ => tcg}/zce_helper.c           |   0
>>   target/riscv/time_helper.c                    |  33 +-
>>   70 files changed, 495 insertions(+), 434 deletions(-)
>>   rename target/riscv/{ => tcg}/bitmanip_helper.c (100%)
>>   rename target/riscv/{ => tcg}/cpu_helper.c (92%)
>>   rename target/riscv/{ => tcg}/crypto_helper.c (100%)
>>   rename target/riscv/{ => tcg}/csr.c (99%)
>>   rename target/riscv/{ => tcg}/csr.h (96%)
>>   rename target/riscv/{ => tcg}/debug.c (99%)
>>   rename target/riscv/{ => tcg}/debug.h (100%)
>>   rename target/riscv/{ => tcg}/fpu_helper.c (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_privileged.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rva.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvb.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvbf16.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvd.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvf.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvh.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvi.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvk.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvm.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvv.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvvk.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzabha.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzacas.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzalasr.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzawrs.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzce.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzcmop.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzfa.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzfh.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzicbo.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzicfiss.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzicond.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_rvzimop.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_svinval.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_xlrbr.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_xmips.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_xthead.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_xventanacondops.c.inc (100%)
>>   rename target/riscv/{ => tcg}/insn_trans/trans_zilsd.c.inc (100%)
>>   rename target/riscv/{ => tcg}/m128_helper.c (100%)
>>   rename target/riscv/{ => tcg}/mips_csr.c (99%)
>>   rename target/riscv/{ => tcg}/op_helper.c (99%)
>>   rename target/riscv/{ => tcg}/pmp.c (99%)
>>   rename target/riscv/{ => tcg}/pmp.h (100%)
>>   rename target/riscv/{ => tcg}/pmu.c (86%)
>>   rename target/riscv/{ => tcg}/pmu.h (95%)
>>   rename target/riscv/{ => tcg}/th_csr.c (99%)
>>   rename target/riscv/{ => tcg}/translate.c (100%)
>>   rename target/riscv/{ => tcg}/vcrypto_helper.c (100%)
>>   rename target/riscv/{ => tcg}/vector_helper.c (100%)
>>   rename target/riscv/{ => tcg}/vector_internals.c (100%)
>>   rename target/riscv/{ => tcg}/vector_internals.h (100%)
>>   rename target/riscv/{ => tcg}/zce_helper.c (100%)
>>
> 
> It seems like series does not apply on top of master, would that be
> possible to rebase it?

Oh, sorry.  I forgot to mention that patches are based on alistair's
riscv-to-apply.next branch:

https://github.com/alistair23/qemu

Cheers,
Daniel

> 
> Regards,
> Pierrick