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.

Patches based on alistair/riscv-to-apply.next.


Changes from v2:
- patch 1 (new):
  - allow CPUs other than 'bare' to assign profiles
- patch 2 (former 1):
  - added RVA23 profile support in the rvsp-ref CPU
- patch 3 (former 2):
  - hw/riscv/Kconfig changes:
    * added 'default y' in hw/riscv/Kconfig to build the board by default
    * added 'depends on RISCV64' to prevent the board to be built for qemu-system-riscv32

  - HMP qtest fixes:
    * added rvsp_aclint_allowed(). Use it instead of (!tcg_enabled()) when checking aclint support

  - changes in rvsp_ref_machine_done():
    * added 'RISCVBootInfo boot_info' struct
    * changed riscv_find_and_load_firmware(), riscv_calc_kernel_start_addr(),
      riscv_load_kernel() and riscv_compute_fdt_addr() to use boot_info

  - added "hw/char/serial-mm.h" include
  - changed 'addr' mem variables to 'hwaddr'
  - use HWADDR_PRIx format with 'addr' variables
  - changed GPEX_NUM_IRQS to PCI_NUM_PINS

- patch 4 (new):
  - add riscv-iommu-sys platform device
- v2 link: https://lore.kernel.org/qemu-riscv/20240312135222.3187945-1-fei2.wu@intel.com/


[1] https://lore.kernel.org/qemu-riscv/20240312135222.3187945-1-fei2.wu@intel.com/
[2] https://lore.kernel.org/qemu-riscv/CAHBxVyG186Zo7nAm7o8=vhBtzU+x8ry4_mWwHxuaZ8BasnDyPg@mail.gmail.com/

Daniel Henrique Barboza (2):
  target/riscv/cpu.c: remove 'bare' condition for .profile
  hw/riscv/server_platform_ref.c: add riscv-iommu-sys

Fei Wu (2):
  target/riscv: Add server platform reference cpu
  hw/riscv: Add server platform reference machine

 configs/devices/riscv64-softmmu/default.mak |    1 +
 hw/riscv/Kconfig                            |   15 +
 hw/riscv/meson.build                        |    1 +
 hw/riscv/server_platform_ref.c              | 1346 +++++++++++++++++++
 target/riscv/cpu-qom.h                      |    1 +
 target/riscv/cpu.c                          |   12 +-
 6 files changed, 1375 insertions(+), 1 deletion(-)
 create mode 100644 hw/riscv/server_platform_ref.c

-- 
2.49.0

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?

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.

Thanks,
Chao

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?


> 
> 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 get emails from time to time from people asking about the status of this work
so I'm considering pushing the patches as is, without sdext, and add documentation
saying that this isn't a 100% rsvp-ref compliant board. The absence of sdext
seems tolerable for the current uses ppl have for the board ATM, so upstreaming
it as is can be beneficial for everyone. We can add sdext support later and
then update the docs claiming 100% compliance.

At very least I'll have to send a v4 now that you pointed out a wrong memory
address in the memmap, so I'll start with that.


Thanks,

Daniel


> 
> Thanks,
> Chao

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?
> 
> 
>>
>> 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.

Thank,
Chao

> I get emails from time to time from people asking about the status of this work
> so I'm considering pushing the patches as is, without sdext, and add documentation
> saying that this isn't a 100% rsvp-ref compliant board. The absence of sdext
> seems tolerable for the current uses ppl have for the board ATM, so upstreaming
> it as is can be beneficial for everyone. We can add sdext support later and
> then update the docs claiming 100% compliance.
> 
> At very least I'll have to send a v4 now that you pointed out a wrong memory
> address in the memmap, so I'll start with that.
> 
> 
> Thanks,
> 
> Daniel
> 
> 
>>
>> Thanks,
>> Chao

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?
>>
>>
>>>
>>> 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.


Thanks,

Daniel

> 
> Thank,
> Chao
> 
>> I get emails from time to time from people asking about the status of this work
>> so I'm considering pushing the patches as is, without sdext, and add documentation
>> saying that this isn't a 100% rsvp-ref compliant board. The absence of sdext
>> seems tolerable for the current uses ppl have for the board ATM, so upstreaming
>> it as is can be beneficial for everyone. We can add sdext support later and
>> then update the docs claiming 100% compliance.
>>
>> At very least I'll have to send a v4 now that you pointed out a wrong memory
>> address in the memmap, so I'll start with that.
>>
>>
>> Thanks,
>>
>> Daniel
>>
>>
>>>
>>> Thanks,
>>> Chao
> 

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