This series adds QEMU machine support for VEGA, a RISC-V SoC family
developed by C-DAC (Centre for Development of Advanced Computing,
India) as part of the DIR-V processor program.

VEGA series of microprocessors are developed as part of the
Microprocessor Development Programme, initiated and funded by MeitY
(Ministry of Electronics and Information Technology, Government of
India), with the mission objective to design and develop
indigenously a family of microprocessors, related IPs, and the
complete ecosystem to enable fully indigenous product development
catering to various requirements in the strategic, industrial, and
commercial sectors. VEGA is developed at C-DAC, Thiruvananthapuram.

Background
----------
VEGA is a series of 32-bit and 64-bit single/multi-core RISC-V
processors (Thejas32 and Thejas64) developed under the DIR-V program,
integrated with multi-level caches, an MMU, and a coherent
interconnect on real silicon. This series adds a QEMU 'vega' machine
model supporting both the Thejas32 (RV32) and Thejas64 (RV64)
variants, modelled on real silicon behaviour rather than a
synthetic/virtual platform.

More details on the VEGA processor series:
  https://vegaprocessors.in/
VEGA documentation:
  https://cdac-vega.gitlab.io/

The model has been validated against Aries boards (Thejas32) and
Thejas64 SoCs, booting:
  - bare-metal ELF payloads via -bios (no DTB, fixed UART framing),
    for both RV32 and RV64, using the VEGA SDK's example UART
    "hello world" application
  - Linux via BBL with a user-supplied -dtb describing the SoC (RV64)

What's included
----------------
 - hw/riscv/vega.c            - machine model, device creation, boot flow.
                                 Note: VEGA does not generate its device
                                 tree internally; -dtb is required for any
                                 -kernel boot (see note below)
 - hw/intc/vega_plic.c        - CDAC PLIC variant (register layout
                                 differs from the generic riscv,plic0;
                                 see patch N/N for details)
 - hw/intc/vega_aclint.c      - ACLINT MSWI/SSWI/MTIMER, with the
                                 STIMECMP handling VEGA's boot ROM /
                                 BBL relies on
 - target/riscv/cpu.c         - adds TYPE_RISCV_CPU_VEGA32 and
                                 TYPE_RISCV_CPU_VEGA64, CPU subtypes
                                 baking in VEGA's fixed baseline (IMA +
                                 S/U + Zicsr/Zifencei + SV32/SV39), so
                                 -M vega boots on either architecture
                                 without a manual -cpu string; see note
                                 below on why both are parented on
                                 sifive-u rather than the generic base
                                 CPU type
 - docs/system/riscv/vega.rst - user-facing documentation
 - tests/functional/riscv32/test_vega.py,
   tests/functional/riscv64/test_vega.py
                               - functional tests booting -M vega on
                                 both architectures (bare-metal on
                                 both; bare-metal + Linux/BBL on
                                 riscv64), fetching small test binaries
                                 from a stable, checksummed external
                                 asset repository
 - MAINTAINERS entry

Notable hardware characteristics reviewers should know up front
-----------------------------------------------------------------
 - The PLIC and CLINT/ACLINT are co-located at the same base address
   on real VEGA silicon (0x20010000). This is not a QEMU modelling
   error; it reflects the actual SoC memory map.
 - The PLIC aperture is 0x400 bytes, sized for the current maximum
   hart count on this SoC family; it is not the generic upstream PLIC
   aperture size.
 - UART register framing differs between boot modes: bare-metal always
   uses shift=2/io-width=4 (fixed 32-bit stride), while Linux boot
   reads reg-shift from the DTB serial node, since the two boot paths
   exercise the hardware through different firmware layers.
 - TYPE_RISCV_CPU_VEGA32/VEGA64 are parented on TYPE_RISCV_CPU_SIFIVE_U
   rather than TYPE_RISCV_CPU_BASE or TYPE_RISCV_BARE_CPU.
   TYPE_RISCV_CPU_BASE's default misa_ext includes RVH, and the
   class-level misa_ext merge is OR-only (a subtype cannot clear a bit
   its parent already set), so RVH could not be disabled from a
   TYPE_RISCV_CPU_BASE-derived subtype. TYPE_RISCV_BARE_CPU avoids
   that, but unconditionally forces max_satp_mode to 'bare' for any
   CPU in its lineage regardless of what the subtype configures, which
   breaks paging. TYPE_RISCV_CPU_SIFIVE_U has neither issue, but
   silently sets priv_spec to PRIV_VERSION_1_10_0 (an older RISC-V
   privileged spec version) rather than the current one. This surfaced
   as a real boot hang against production BBL/DTB pairs (BBL's
   delegate_traps() mideleg assertion failed) that was not visible in
   simpler test boots, since the hang depends on firmware built
   against a newer priv spec than 1.10.0. Both VEGA CPU subtypes
   explicitly override priv_spec back to PRIV_VERSION_LATEST to fix
   this; anyone deriving a new CPU subtype from a SiFive-family parent
   should be aware this default does not propagate the way ISA
   extension bits might be assumed to.
 - VEGA does not generate a device tree internally. -dtb is required
   for any -kernel (Linux/BBL) boot; the machine errors out clearly if
   a kernel is given without -dtb and without -bios firmware. A bare
   "-M vega" with no boot arguments at all (e.g. qtest's generic
   smoke tests) is a valid, inert state and does not error. This keeps
   the initial series scoped to what has been directly tested;
   internal FDT generation may follow as a later series.
 - PLIC and CLINT compatible strings are "cdac,plic-1.0.0" and
   "riscv,clint0" respectively. CDAC's own Buildroot-based BBL/Linux
   builds use a CDAC-specific PLIC driver matched against the former,
   and use the generic CLINT compatible string directly (no
   CDAC-specific CLINT driver exists in any current VEGA firmware
   variant). A DTB intended to boot stock, unmodified riscv-pk/BBL
   (which only recognises "riscv,plic0" verbatim) will need to
   additionally advertise that generic string for the PLIC node.

What is NOT included / deliberately left out
---------------------------------------------
 - No AIA/APLIC/IMSIC support: current VEGA silicon does not implement
   AIA, so that code path (present in earlier internal revisions) has
   been removed rather than left as dead code.
 - No internal device-tree generation: see note above; -dtb is
   required for -kernel boots in this series.
 - No SDHCI, SPI, I2C functional models yet: exposed as
   unimplemented-device stubs matching the real address ranges, so
   guest software can probe them safely; functional models may follow
   in later series.
 - No RV32 Linux boot test yet: the functional test suite covers
   bare-metal on both architectures and a full Linux/BBL boot on
   riscv64 only, since an RV32 (Thejas32) Linux/BBL boot has not yet
   been verified; this may follow in a later series once available.

Testing
-------
 - riscv32-softmmu and riscv64-softmmu builds, `make check` clean on
   both
 - checkpatch.pl clean across the series
 - Functional tests added under tests/functional/riscv32/test_vega.py
   and tests/functional/riscv64/test_vega.py, passing via both direct
   invocation and `meson test` on both architectures:
     - bare-metal "hello world" boot (RV32 and RV64)
     - full Linux boot via BBL to a login prompt (RV64)
 - Manual testing additionally covered: virtio-net networking, and an
   extended stress-ng run (CPU, matrix, VM, filesystem, device-access
   stressors) under Linux on -M vega

We previously posted an early version of VEGA machine support
(Message-ID: <385625713.441366.1761727810206@webmail2.cdac.in>)
without a proper cover letter, MAINTAINERS entry, documentation, or
tests, and sent via a webmail client rather than git send-email,
which likely affected formatting. This series is a corrected
resubmission addressing all of that: it is sent via git send-email,
and adds the documentation, MAINTAINERS entry, and functional tests
that were missing before. We've since read and followed
docs/devel/submitting-a-patch.rst in full. Feedback on process as
well as code is very welcome.

Karthika B (7):
  hw/intc: Add CDAC VEGA PLIC device model
  hw/intc: Add CDAC VEGA ACLINT device model
  target/riscv: Add VEGA32 and VEGA64 CPU types
  hw/riscv: Add CDAC VEGA machine model
  docs/system/riscv: Add VEGA machine documentation
  tests/functional: Add VEGA machine functional tests
  MAINTAINERS: Add entry for VEGA machine

 MAINTAINERS                                 |  14 +
 configs/devices/riscv64-softmmu/default.mak |   1 +
 docs/system/riscv/vega.rst                  | 219 +++++++
 docs/system/target-riscv.rst                |   1 +
 hw/intc/Kconfig                             |   7 +
 hw/intc/meson.build                         |   2 +
 hw/intc/vega_aclint.c                       | 668 ++++++++++++++++++++
 hw/intc/vega_plic.c                         | 517 +++++++++++++++
 hw/riscv/Kconfig                            |  11 +
 hw/riscv/meson.build                        |   1 +
 hw/riscv/vega.c                             | 502 +++++++++++++++
 include/hw/intc/vega_aclint.h               |  84 +++
 include/hw/intc/vega_plic.h                 |  87 +++
 include/hw/riscv/vega.h                     | 136 ++++
 target/riscv/cpu-qom.h                      |   2 +
 target/riscv/cpu.c                          |  25 +
 tests/functional/riscv32/meson.build        |   1 +
 tests/functional/riscv32/test_vega.py       |  32 +
 tests/functional/riscv64/meson.build        |   1 +
 tests/functional/riscv64/test_vega.py       |  63 ++
 20 files changed, 2374 insertions(+)
 create mode 100644 docs/system/riscv/vega.rst
 create mode 100644 hw/intc/vega_aclint.c
 create mode 100644 hw/intc/vega_plic.c
 create mode 100644 hw/riscv/vega.c
 create mode 100644 include/hw/intc/vega_aclint.h
 create mode 100644 include/hw/intc/vega_plic.h
 create mode 100644 include/hw/riscv/vega.h
 create mode 100644 tests/functional/riscv32/test_vega.py
 create mode 100644 tests/functional/riscv64/test_vega.py

-- 
2.43.0

------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
------------------------------------------------------------------------------------------------------------

On Fri, 2026-10-16 at 13:37 +0530, Karthika B wrote:
> This series adds QEMU machine support for VEGA, a RISC-V SoC family
> developed by C-DAC (Centre for Development of Advanced Computing,
> India) as part of the DIR-V processor program.
> VEGA series of microprocessors are developed as part of the
> Microprocessor Development Programme, initiated and funded by MeitY
> (Ministry of Electronics and Information Technology, Government of
> India), with the mission objective to design and develop
> indigenously a family of microprocessors, related IPs, and the
> complete ecosystem to enable fully indigenous product development
> catering to various requirements in the strategic, industrial, and
> commercial sectors. VEGA is developed at C-DAC, Thiruvananthapuram.
> 
> Background
> ----------
> VEGA is a series of 32-bit and 64-bit single/multi-core RISC-V
> processors (Thejas32 and Thejas64) developed under the DIR-V program,
> integrated with multi-level caches, an MMU, and a coherent
> interconnect on real silicon. This series adds a QEMU 'vega' machine
> model supporting both the Thejas32 (RV32) and Thejas64 (RV64)
> variants, modelled on real silicon behaviour rather than a
> synthetic/virtual platform.

Thanks for the series. It's cool to see some more RISC-V designs.

Thank you for submitting the patches.

For some context, we already have support for a Shakti machine, and
that is being deprecated and removed as it hasn't been maintained by
the original submitter.

I also noticed that you listed yourself as "Odd Fixes" in the
maintainers file, so this won't be accepted.

We don't have the resource to maintain your custom board and reviewers
are stretched very thin to look at your patches. If you don't want to
maintain it, we aren't going to be able to either.

> 
> More details on the VEGA processor series:
>   https://vegaprocessors.in/
> VEGA documentation:
>   https://cdac-vega.gitlab.io/
> 
> The model has been validated against Aries boards (Thejas32) and
> Thejas64 SoCs, booting:
>   - bare-metal ELF payloads via -bios (no DTB, fixed UART framing),
>     for both RV32 and RV64, using the VEGA SDK's example UART
>     "hello world" application
>   - Linux via BBL with a user-supplied -dtb describing the SoC (RV64)

No BBL, please use OpenSBI or an equivalent

> 
> What's included
> ----------------
>  - hw/riscv/vega.c            - machine model, device creation, boot
> flow.
>                                  Note: VEGA does not generate its
> device
>                                  tree internally; -dtb is required
> for any
>                                  -kernel boot (see note below)
>  - hw/intc/vega_plic.c        - CDAC PLIC variant (register layout
>                                  differs from the generic
> riscv,plic0;

Why?

>                                  see patch N/N for details)
>  - hw/intc/vega_aclint.c      - ACLINT MSWI/SSWI/MTIMER, with the
>                                  STIMECMP handling VEGA's boot ROM /
>                                  BBL relies on
>  - target/riscv/cpu.c         - adds TYPE_RISCV_CPU_VEGA32 and
>                                  TYPE_RISCV_CPU_VEGA64, CPU subtypes
>                                  baking in VEGA's fixed baseline (IMA
> +
>                                  S/U + Zicsr/Zifencei + SV32/SV39),
> so
>                                  -M vega boots on either architecture
>                                  without a manual -cpu string; see
> note
>                                  below on why both are parented on
>                                  sifive-u rather than the generic
> base
>                                  CPU type
>  - docs/system/riscv/vega.rst - user-facing documentation
>  - tests/functional/riscv32/test_vega.py,
>    tests/functional/riscv64/test_vega.py
>                                - functional tests booting -M vega on
>                                  both architectures (bare-metal on
>                                  both; bare-metal + Linux/BBL on
>                                  riscv64), fetching small test
> binaries
>                                  from a stable, checksummed external
>                                  asset repository
>  - MAINTAINERS entry
> 
> Notable hardware characteristics reviewers should know up front

Have you read QEMU's AI policy?

https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-generated-content

> -----------------------------------------------------------------
>  - The PLIC and CLINT/ACLINT are co-located at the same base address
>    on real VEGA silicon (0x20010000). This is not a QEMU modelling
>    error; it reflects the actual SoC memory map.

What? Why?

>  - The PLIC aperture is 0x400 bytes, sized for the current maximum
>    hart count on this SoC family; it is not the generic upstream PLIC
>    aperture size.
>  - UART register framing differs between boot modes: bare-metal
> always
>    uses shift=2/io-width=4 (fixed 32-bit stride), while Linux boot
>    reads reg-shift from the DTB serial node, since the two boot paths
>    exercise the hardware through different firmware layers.
>  - TYPE_RISCV_CPU_VEGA32/VEGA64 are parented on
> TYPE_RISCV_CPU_SIFIVE_U
>    rather than TYPE_RISCV_CPU_BASE or TYPE_RISCV_BARE_CPU.
>    TYPE_RISCV_CPU_BASE's default misa_ext includes RVH, and the
>    class-level misa_ext merge is OR-only (a subtype cannot clear a
> bit
>    its parent already set), so RVH could not be disabled from a
>    TYPE_RISCV_CPU_BASE-derived subtype. TYPE_RISCV_BARE_CPU avoids
>    that, but unconditionally forces max_satp_mode to 'bare' for any
>    CPU in its lineage regardless of what the subtype configures,
> which
>    breaks paging. TYPE_RISCV_CPU_SIFIVE_U has neither issue, but
>    silently sets priv_spec to PRIV_VERSION_1_10_0 (an older RISC-V
>    privileged spec version) rather than the current one. This
> surfaced
>    as a real boot hang against production BBL/DTB pairs (BBL's
>    delegate_traps() mideleg assertion failed) that was not visible in
>    simpler test boots, since the hang depends on firmware built
>    against a newer priv spec than 1.10.0. Both VEGA CPU subtypes
>    explicitly override priv_spec back to PRIV_VERSION_LATEST to fix
>    this; anyone deriving a new CPU subtype from a SiFive-family
> parent
>    should be aware this default does not propagate the way ISA
>    extension bits might be assumed to.
>  - VEGA does not generate a device tree internally. -dtb is required
>    for any -kernel (Linux/BBL) boot; the machine errors out clearly
> if
>    a kernel is given without -dtb and without -bios firmware. A bare
>    "-M vega" with no boot arguments at all (e.g. qtest's generic
>    smoke tests) is a valid, inert state and does not error. This
> keeps
>    the initial series scoped to what has been directly tested;
>    internal FDT generation may follow as a later series.
>  - PLIC and CLINT compatible strings are "cdac,plic-1.0.0" and
>    "riscv,clint0" respectively. CDAC's own Buildroot-based BBL/Linux
>    builds use a CDAC-specific PLIC driver matched against the former,
>    and use the generic CLINT compatible string directly (no
>    CDAC-specific CLINT driver exists in any current VEGA firmware
>    variant). A DTB intended to boot stock, unmodified riscv-pk/BBL
>    (which only recognises "riscv,plic0" verbatim) will need to
>    additionally advertise that generic string for the PLIC node.
> 
> What is NOT included / deliberately left out
> ---------------------------------------------
>  - No AIA/APLIC/IMSIC support: current VEGA silicon does not
> implement
>    AIA, so that code path (present in earlier internal revisions) has
>    been removed rather than left as dead code.

Again, please read the AI code policy

https://www.qemu.org/docs/master/devel/code-provenance.html#use-of-ai-generated-content

Alistair

>  - No internal device-tree generation: see note above; -dtb is
>    required for -kernel boots in this series.
>  - No SDHCI, SPI, I2C functional models yet: exposed as
>    unimplemented-device stubs matching the real address ranges, so
>    guest software can probe them safely; functional models may follow
>    in later series.
>  - No RV32 Linux boot test yet: the functional test suite covers
>    bare-metal on both architectures and a full Linux/BBL boot on
>    riscv64 only, since an RV32 (Thejas32) Linux/BBL boot has not yet
>    been verified; this may follow in a later series once available.
> 
> Testing
> -------
>  - riscv32-softmmu and riscv64-softmmu builds, `make check` clean on
>    both
>  - checkpatch.pl clean across the series
>  - Functional tests added under tests/functional/riscv32/test_vega.py
>    and tests/functional/riscv64/test_vega.py, passing via both direct
>    invocation and `meson test` on both architectures:
>      - bare-metal "hello world" boot (RV32 and RV64)
>      - full Linux boot via BBL to a login prompt (RV64)
>  - Manual testing additionally covered: virtio-net networking, and an
>    extended stress-ng run (CPU, matrix, VM, filesystem, device-access
>    stressors) under Linux on -M vega
> 
> We previously posted an early version of VEGA machine support
> (Message-ID: <385625713.441366.1761727810206@webmail2.cdac.in>)
> without a proper cover letter, MAINTAINERS entry, documentation, or
> tests, and sent via a webmail client rather than git send-email,
> which likely affected formatting. This series is a corrected
> resubmission addressing all of that: it is sent via git send-email,
> and adds the documentation, MAINTAINERS entry, and functional tests
> that were missing before. We've since read and followed
> docs/devel/submitting-a-patch.rst in full. Feedback on process as
> well as code is very welcome.
> 
> Karthika B (7):
>   hw/intc: Add CDAC VEGA PLIC device model
>   hw/intc: Add CDAC VEGA ACLINT device model
>   target/riscv: Add VEGA32 and VEGA64 CPU types
>   hw/riscv: Add CDAC VEGA machine model
>   docs/system/riscv: Add VEGA machine documentation
>   tests/functional: Add VEGA machine functional tests
>   MAINTAINERS: Add entry for VEGA machine
> 
>  MAINTAINERS                                 |  14 +
>  configs/devices/riscv64-softmmu/default.mak |   1 +
>  docs/system/riscv/vega.rst                  | 219 +++++++
>  docs/system/target-riscv.rst                |   1 +
>  hw/intc/Kconfig                             |   7 +
>  hw/intc/meson.build                         |   2 +
>  hw/intc/vega_aclint.c                       | 668
> ++++++++++++++++++++
>  hw/intc/vega_plic.c                         | 517 +++++++++++++++
>  hw/riscv/Kconfig                            |  11 +
>  hw/riscv/meson.build                        |   1 +
>  hw/riscv/vega.c                             | 502 +++++++++++++++
>  include/hw/intc/vega_aclint.h               |  84 +++
>  include/hw/intc/vega_plic.h                 |  87 +++
>  include/hw/riscv/vega.h                     | 136 ++++
>  target/riscv/cpu-qom.h                      |   2 +
>  target/riscv/cpu.c                          |  25 +
>  tests/functional/riscv32/meson.build        |   1 +
>  tests/functional/riscv32/test_vega.py       |  32 +
>  tests/functional/riscv64/meson.build        |   1 +
>  tests/functional/riscv64/test_vega.py       |  63 ++
>  20 files changed, 2374 insertions(+)
>  create mode 100644 docs/system/riscv/vega.rst
>  create mode 100644 hw/intc/vega_aclint.c
>  create mode 100644 hw/intc/vega_plic.c
>  create mode 100644 hw/riscv/vega.c
>  create mode 100644 include/hw/intc/vega_aclint.h
>  create mode 100644 include/hw/intc/vega_plic.h
>  create mode 100644 include/hw/riscv/vega.h
>  create mode 100644 tests/functional/riscv32/test_vega.py
>  create mode 100644 tests/functional/riscv64/test_vega.py