On Tue, May 5, 2026 at 4:56 AM Daniel Henrique Barboza <[email protected]> wrote: > > > > On 5/1/2026 12:27 AM, Alistair Francis wrote: > > On Sat, Apr 25, 2026 at 5:13 AM Daniel Henrique Barboza > > <[email protected]> wrote: > >> > >> From: Fei Wu <[email protected]> > >> > >> The RISC-V Server Platform specification [1] defines a standardized set > >> of hardware and software capabilities, that portable system software, > >> such as OS and hypervisors can rely on being present in a RISC-V server > >> platform. > >> > >> The main features included in this emulation are: > >> > >> - Based on riscv virt machine type; > >> - A new memory map as close as virt machine as possible; > >> - An always present IOMMU platform device (riscv-iommu-sys) that uses > >> IRQs 36 to 39, one IRQ for queue, similar to the 'virt' board; > >> - AIA; > >> - PCIe AHCI; > >> - PCIe NIC; > >> - No virtio device; > >> - No fw_cfg device; > >> - No ACPI table provided; > >> - Only minimal device tree nodes. > > > > Can you describe why we actually need/want this? The virt machine > > already covers a lot of this and OSes and Hypervisors can pretty > > easily target that. I'm not clear what this buys us in QEMU. Maintaing > > a machine isn't that hard, but it would be nice to have a good reason > > to support it. > > I'm late to the discussions but following up what Leif and Peter already > commented: this is a similar use case as ARM's sbsa-ref machine. It is a > development focused board that adheres to a reference spec, it is not a > board to be used for overall consumption - for that we have 'virt'.
That is all good information to add to the documentation :) > > If the reference spec changes the emulation will follow suit, and existing > software that was working previously can stop working. The assumption made > here is that, when a spec change happens, developers must strive to make > the SW work on the updated spec/reference machine. I'm not sure people will like that though. If you are mid-way through making hardware to target v1.0 and v2.0 comes out you don't expect QEMU to update and break your entire setup. But no one is going to expect to migrate, so we could just add a new machine when v2.0 comes out. So hopefully it isn't too much of a hassle > > Last but not the least, this design decision also spare us from dealing with > machine versioning. Yep, seems fair Alistair
