On Thu, Oct 30, 2025 at 12:37:00PM -0300, Daniel Henrique Barboza wrote: > > > On 10/30/25 12:23 PM, Chao Liu wrote: > > On 10/30/2025 9:33 PM, Daniel Henrique Barboza wrote: > > > > > > > > > On 10/30/25 8:48 AM, Chao Liu wrote: > > > > On Wed, May 28, 2025 at 05:01:29PM -0300, Daniel Henrique Barboza wrote: > > > > > Hi, > > > > > > > > > > This is my attempt to ressurect the Server SoC Platform reference work > > > > > that has been buried for an year. The last posting was made an year > > > > > ago > > > > > [1]. > > > > > Most of the changes were made due to upstream differences from one > > > > > year > > > > > ago. Patch 1 is an example of that. > > > > > > > > > > In patch 2 (former 1), the main difference is the new CPU is rva23s64 > > > > > compliant. This wasn't possible in May 2024 because we didn't have > > > > > this > > > > > support back then. > > > > > > > > > > Patch 3 consists mostly of code base changes rather than functional > > > > > changes. There was a discussion about whether we should supply fdts in > > > > > this machine back in the v2 review [2]. The answer is yes: machine > > > > > mode > > > > > requires fdt to work, and we want to be flexible enough to generate > > > > > our > > > > > own fdt instead of relying on EDK2 to supply them. Note that we can > > > > > also > > > > > supply an EDK2-generated fdt via command line, bypassing the fdt > > > > > created > > > > > by QEMU, if desired. > > > > > > > > > > Patch 4 adds a riscv-iommu-sys device to the board. This wasn't > > > > > possible > > > > > back then because we didn't have the required upstream support for it. > > > > > > > > > > > > > Hi, Daniel. > > > > > > > > Do we have any plans to support virt-io on the rvsp-ref machine in the > > > > future? > > > > > > Hmmm good question. In theory we're interested only in implementing the > > > rvsp-ref > > > spec but adding virt-io support doesn't hurt the spec implementation in > > > any > > > way ... I think. Drew, any comments?
Allowing virtio devices should be fine. I think other reference models have shied away from supporting virtio devices since they want to strictly represent real hardware. Of course there can be real hardware which implements the virtio spec, though, so I don't see a problem of allowing them even when being strict. > > > > > > > > > > > > > > Recently, I have been using the RISC-V reference platform built on this > > > > set of > > > > patches to support running the OpenEuler RISC-V operating system. > > > > > > > > I will actively feed back any test results to the upstream. > > > > > > > > > This series has been stale because, as you might've read in the thread, > > > it turns > > > out we're missing a mandatory extension (sdext). > > > > > > > I have a basic version of the sdext extension ready. I’ll improve it later > > and > > share it with the upstream community to discuss. > > > That's awesome! Guess we'll be able to upstream a 100% compliant server > platform > emulation sooner than I've expected. And I would prefer we wait until the reference model is complete before merging it, unless it gets merged with a temporary "experimental" type name. Thanks, drew
