Re: [PATCH v4 09/13] hw/riscv: Add Tenstorrent Atlantis machine

[Nicholas Piggin <npiggin@gmail.com>]

On Thu, Apr 30, 2026 at 09:57:34AM +1000, Alistair Francis wrote:
> On Sat, Apr 25, 2026 at 11:20 PM Joel Stanley <joel@jms.id.au> wrote:
> >
> > The Tenstorrent Atlantis platform is a collaboration between Tenstorrent
> > and CoreLab Technology. It is based on the Atlantis SoC, which includes
> > the Ascalon-X CPU and other IP from Tenstorrent and CoreLab Technology.
> 
> Can you provide a link to documentation

Also not presently.

[...]

> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index e1942a86eba5..635a380945fd 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -1760,6 +1760,17 @@ F: hw/*/*sifive*.c
> >  F: include/hw/*/*sifive*.h
> >  F: tests/functional/test_riscv64_sifive_u.py
> >
> > +Tenstorrent Machines
> > +M: Joel Stanley <joel@jms.id.au>
> > +R: Nicholas Piggin <npiggin@gmail.com>
> > +R: Michael Ellerman <mpe@kernel.org>
> > +L: qemu-riscv@nongnu.org
> > +S: Supported
> > +F: docs/system/riscv/tt_*.rst
> > +F: hw/riscv/tt_*.c
> > +F: hw/riscv/aia.[ch]
> 
> AIA?

Not sure why that is there, there's no Tenstorrent implementation detail
in there AFAIKS. Let's remove that line.

> 
> > +F: include/hw/riscv/tt_*.h
> > +
> >  AMD Microblaze-V Generic Board
> >  M: Sai Pavan Boddu <sai.pavan.boddu@amd.com>
> >  S: Maintained
> > diff --git a/docs/system/riscv/tt_atlantis.rst b/docs/system/riscv/tt_atlantis.rst
> > new file mode 100644
> > index 000000000000..640cabf7b046
> > --- /dev/null
> > +++ b/docs/system/riscv/tt_atlantis.rst
> > @@ -0,0 +1,38 @@
> > +Tenstorrent Atlantis (``tt-atlantis``)
> > +======================================
> > +
> > +The Tenstorrent Atlantis platform is a collaboration between Tenstorrent
> > +and CoreLab Technology. It is based on the Atlantis SoC, which includes
> > +the Ascalon-X CPU and other IP from Tenstorrent and CoreLab Technology.
> > +
> > +The Tenstorrent Ascalon-X is a high performance 64-bit RVA23 compliant
> > +RISC-V CPU.
> > +
> > +Features
> > +--------
> > +
> > +* 8-core Ascalon-X CPU Cluster
> > +* Dual x32 LPDDR5 @ 6400 MT/s
> > +* RISC-V compliant Advanced Interrupt Architecture
> > +* PCIe Gen4
> > +* RISC-V compliant IOMMU
> 
> IOMMU isn't supported (at least not in this patch), maybe this should
> list things that are supported in QEMU (and can then be expanded).
> Leave the features list to your official documentation (which is
> missing a link here)

Sounds reasonable.

[...]

> > +
> > +static void create_fdt_cpus(TTAtlantisState *s, uint32_t *intc_phandles)
> 
> So generally we only create a device tree for virtual boards, that is
> boards that don't really exist and are just QEMU constructs.
> 
> You said that this is based on the "Atlantis SoC" so I assume it's
> real hardware. In the real hardware do you expect the device tree to
> be provided by the ROM? Usually for boards users supply the device
> tree as part of the boot flow (via u-boot or something similar). In
> which case should QEMU actually generate this or can users just supply
> their own?
> 
> Basically the question is, if you are trying to model the hardware, is
> generating the device tree here correct?
> 
> Obviously the advantage of doing it here is then the device tree
> describes what QEMU supports, which is great. But that can be harder
> to manage when the hardware doesn't do that, as then you have
> divergence.

We went around this same discussion internally and yeah it's a valid
question, we could have explained this a bit better.

In the real (unreleased) hardware and the DT will be loaded from ROM.
I think we should do that when the model and firmware and dt is more
complete. At the moment it has been easier for development to use QEMU
generated fdt.

Is that acceptable to do that now and switch to a fdt ROM later...

[...]

> > +static void finalize_fdt(TTAtlantisState *s)
> > +{
> > +    uint32_t aplic_s_phandle = next_phandle();
> > +    uint32_t imsic_s_phandle = next_phandle();
> > +    void *fdt = MACHINE(s)->fdt;
> > +
> > +    create_fdt_cpu(s, s->memmap, aplic_s_phandle, imsic_s_phandle);
> > +
> > +    /*
> > +     * We want to do this, but the Linux aplic driver was broken before v6.16
> > +     *
> > +     * qemu_fdt_setprop_cell(MACHINE(s)->fdt, "/soc", "interrupt-parent",
> > +     *                       aplic_s_phandle);
> > +     */
> 
> And now we are stuck with hacks like this, which we really don't want
> to be dealing with. Maybe it's best to leave the device tree to the
> kernel.

... Despite issues like this?

[...]

> > diff --git a/hw/riscv/Kconfig b/hw/riscv/Kconfig
> > index 0222c93f878b..0601ae1a7494 100644
> > --- a/hw/riscv/Kconfig
> > +++ b/hw/riscv/Kconfig
> > @@ -120,6 +120,21 @@ config SPIKE
> >      select RISCV_ACLINT
> >      select SIFIVE_PLIC
> >
> > +config TENSTORRENT
> > +    bool
> > +    default y
> > +    depends on RISCV64
> > +    imply PCI_DEVICES
> > +    imply TEST_DEVICES
> > +    select DEVICE_TREE
> > +    select RISCV_NUMA
> 
> Do you actually need NUMA? You have a numa include as well which I
> don't think is required.

Hardware is not NUMA. It was probably just copied from the VIRT config.

Thanks,
Nick