Re: [PATCH] target/riscv: Report QEMU CPU archid as 42

[Charlie Jenkins <thecharlesjenkins@gmail.com>]

On Thu, Jun 25, 2026 at 01:29:37PM -0300, Daniel Henrique Barboza wrote:
> 
> 
> On 6/25/2026 12:10 PM, Philippe Mathieu-Daudé wrote:
> > Hi,
> > 
> > On 25/6/26 14:13, Daniel Henrique Barboza wrote:
> > > Hi,
> > > 
> > > On 6/25/2026 3:26 AM, Charlie Jenkins wrote:
> > > > When a non-vendor CPU is used, report the archid as 42 which has been
> > > > allocated for QEMU in the riscv isa manual [1]. This can help software
> > > > check if it is running in QEMU.
> > > > 
> > > > [1] https://github.com/riscv/riscv-isa-manual/blob/main/marchid.md
> > > > 
> > > > Signed-off-by: Charlie Jenkins <thecharlesjenkins@gmail.com>
> > > > ---
> > > > This series was original proposed by Palmer Dabbelt [1] with a follow up
> > > > by Daniel Henrique Barboza. This patch implement's Daniel's suggestion.
> > > > 
> > > > When booting with a non-vendor CPU such as with the qemu arg "-cpu rv64"
> > > > marchid will now be reported as 42.
> > > > 
> > > > > qemu-system-riscv64 ... -cpu rv64
> > > > 
> > > > processor       : 0
> > > > hart            : 0
> > > > isa             : rv64imafdch_zicbom_zicbop_zicboz_ziccrse_zicntr_zicsr_zifencei_zihintntl_zihintpause_zihpm_zaamo_zalrsc_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu_svvptc
> > > > mmu             : sv57
> > > > mvendorid       : 0x0
> > > > marchid         : 0x2a
> > > > mimpid          : 0x0
> > > > hart isa        : rv64imafdch_zicbom_zicbop_zicboz_ziccrse_zicntr_zicsr_zifencei_zihintntl_zihintpause_zihpm_zaamo_zalrsc_zawrs_zfa_zca_zcd_zba_zbb_zbc_zbs_sstc_svadu_svvptc
> > > > 
> > > > When booting with a vendor CPU like veyron-v1, the proper marchid will
> > > > still appear.
> > > > 
> > > > > qemu-system-riscv64 ... -cpu veyron-v1
> > > > 
> > > > processor       : 0
> > > > hart            : 0
> > > > isa             : rv64imafdch_zicbom_zicboz_ziccrse_zicntr_zicsr_zifencei_zihpm_zaamo_zalrsc_zca_zcd_zba_zbb_zbc_zbs_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt
> > > > mmu             : sv48
> > > > mvendorid       : 0x61f
> > > > marchid         : 0x8000000000010000
> > > > mimpid          : 0x111
> > > > hart isa        : rv64imafdch_zicbom_zicboz_ziccrse_zicntr_zicsr_zifencei_zihpm_zaamo_zalrsc_zca_zcd_zba_zbb_zbc_zbs_smaia_smstateen_ssaia_sscofpmf_sstc_svinval_svnapot_svpbmt
> > > > 
> > > > [1] https://lore.kernel.org/all/20240131182430.20174-1- palmer@rivosinc.com/
> > > 
> > > Thanks for linking the discussion.  I have but a vague memory of it and the link
> > > helped.
> > > 
> > > 
> > > > ---
> > > >   target/riscv/cpu.c | 9 +++++++++
> > > >   1 file changed, 9 insertions(+)
> > > > 
> > > > diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
> > > > index fa497e5e8a..59d63f82c2 100644
> > > > --- a/target/riscv/cpu.c
> > > > +++ b/target/riscv/cpu.c
> > > > @@ -44,6 +44,9 @@
> > > >   #endif
> > > >   /* RISC-V CPU definitions */
> > > > +#define RISCV_CPU_MVENDORID 0
> > > > +#define RISCV_CPU_MARCHID 42
> > 
> > Worth adding a comment (possibly linking to the previous URL)
> > making explicit this is an assigned number and not the answer
> > for the ultimate question of life, the universe, and everything.
> 
> Don't forget to thank for all the fish!

Haha yeah. I'll link the riscv-isa-manual entry for it.

> 
> > 
> > > > +#define RISCV_CPU_MIMPID 0
> > > >   static const char riscv_single_letter_exts[] = "IEMAFDQCBPVH";
> > > >   const uint32_t misa_bits[] = {RVI, RVE, RVM, RVA, RVF, RVD, RVV,
> > > >                                 RVC, RVS, RVU, RVH, RVG, RVB, 0};
> > > > @@ -1198,6 +1201,12 @@ static void riscv_cpu_init(Object *obj)
> > > >       }
> > > >   #endif
> > > > +    if (!riscv_cpu_is_vendor(obj)) {
> > > > +        RISCV_CPU(obj)->cfg.mvendorid = RISCV_CPU_MVENDORID;
> > > > +        RISCV_CPU(obj)->cfg.marchid = RISCV_CPU_MARCHID;
> > > > +        RISCV_CPU(obj)->cfg.mimpid = RISCV_CPU_MIMPID;
> > > > +    }
> > > > +
> > > 
> > > Two things:
> > > 
> > > - we have a 'cpu' pointer at the start so you can use cpu->cfg... instead;
> > 
> > Yep, cleaner.
> > 
> > > 
> > > - the "cpu_is_vendor" check shouldn't be needed.  Whatever is set as default during
> > > cpu_init() must be overwritten by CPUDef settings done in each DEFINE_RISCV_CPU()
> > > macro.
> > > 
> > > This happens at this point:
> > > 
> > > 
> > >      env->misa_ext_mask = env->misa_ext = mcc->def->misa_ext;
> > >      riscv_cpu_cfg_merge(&cpu->cfg, &mcc->def->cfg);  <================
> > > 
> > > Therefore we can remove the "cpu_is_vendor" check and just assign the default QEMU IDs
> > > as long as we do it before cpu_cfg_merge(e.g. right after "cpu-  >cfg.max_satp_mode = -1;").
> > > If we do that we'll ensure that all CPUs will carry the RVI archid 42 unless told otherwise
> > > by the CPU definition.

Oh, much better :)

> > > 
> > > Yes, this will end up changing the IDs for vendor CPUs that don't set their own IDs.  This is
> > > fine - if the CPU doesn't bother setting its own ID this means that the CPU is perfectly
> > > fine with whatever default ID QEMU will provide.> > 
> > Should we check for unset marchid and warn or even not accept config
> > with this field unset?
> 
> Hmmm maybe we can adopt a new policy where new CPUs must have an explicit
> ID set, even if zero, to be clear that the CPU doesn't care about the
> field.  But I wouldn't bother about existing vendor CPUs that doesn't set
> mvendorid TBH ... people will most likely complain about existing CPUs
> throwing warnings that they weren't throwing before.
>

I agree, it probably won't be an issue for any existing vendor CPUs to
fall back to the new value, but it would make sense to expect new ones
to set the values explicitly.

- Charlie

> 
> Cheers,
> Daniel
> 
> > 
> > > 
> > > 
> > > Thanks,
> > > Daniel
> > > 
> > > 
> > > >       accel_cpu_instance_init(CPU(obj));
> > > >   }
> > > > 
> > > > ---
> > > > base-commit: b83371668192a705b878e909c5ae9c1233cbd5fb
> > > > change-id: 20260624-marchid-80d176b873d8
> > > > 
> > > > Best regards,
> > > > -- 
> > > > - Charlie
> > > > 
> > > 
> > > 
> > 
>