Re: [PATCH v3 2/4] target/riscv: Add server platform reference cpu

[Chao Liu <chao.liu.riscv@isrc.iscas.ac.cn>]

On 10/30/2025 11:14 PM, Daniel Henrique Barboza wrote:
> 
> 
> On 10/30/25 12:01 PM, Chao Liu wrote:
>> On Wed, May 28, 2025 at 05:01:29PM -0300, Daniel Henrique Barboza wrote:
>>> rom: Fei Wu <wu.fei9@sanechips.com.cn>
>>>
>>> he harts requirements of RISC-V server platform [1] require RVA23 ISA
>>> rofile support, plus Sv48, Svadu, H, Sscofmpf etc. This patch provides
>>> virt CPU type (rvsp-ref) as compliant as possible.
>>>
>>> 1] https://github.com/riscv-non-isa/riscv-server-platform/blob/main/server_platform_requirements.adoc
>>>
>>> igned-off-by: Fei Wu <fei2.wu@intel.com>
>>> igned-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
>>> -- 
>>> target/riscv/cpu-qom.h |  1 +
>>> target/riscv/cpu.c     | 11 +++++++++++
>>> 2 files changed, 12 insertions(+)
>>>
>>> iff --git a/target/riscv/cpu-qom.h b/target/riscv/cpu-qom.h
>>> ndex 1ee05eb393..70978fd53c 100644
>>> -- a/target/riscv/cpu-qom.h
>>> ++ b/target/riscv/cpu-qom.h
>>> @ -55,6 +55,7 @@
>>> #define TYPE_RISCV_CPU_VEYRON_V1        RISCV_CPU_TYPE_NAME("veyron-v1")
>>> #define TYPE_RISCV_CPU_TT_ASCALON       RISCV_CPU_TYPE_NAME("tt-ascalon")
>>> #define TYPE_RISCV_CPU_XIANGSHAN_NANHU  RISCV_CPU_TYPE_NAME("xiangshan-nanhu")
>>> #define TYPE_RISCV_CPU_RVSP_REF         RISCV_CPU_TYPE_NAME("rvsp-ref")
>>> #define TYPE_RISCV_CPU_HOST             RISCV_CPU_TYPE_NAME("host")
>>>
>>> OBJECT_DECLARE_CPU_TYPE(RISCVCPU, RISCVCPUClass, RISCV_CPU)
>>> iff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
>>> ndex 4a30cf8444..ec2fbc0e78 100644
>>> -- a/target/riscv/cpu.c
>>> ++ b/target/riscv/cpu.c
>>> @ -3166,6 +3166,17 @@ static const TypeInfo riscv_cpu_type_infos[] = {
>>>        .cfg.max_satp_mode = VM_1_10_SV39,
>>>    ),
>>>
>>>    DEFINE_RISCV_CPU(TYPE_RISCV_CPU_RVSP_REF, TYPE_RISCV_VENDOR_CPU,
>>
>> I'm not sure the parent type TYPE_RISCV_VENDOR_CPU is right here.
>>
>> To be on the safe side, I tested this CPU type using an openEuler image that
>> can boot on a virtual machine. This image supports rva23s64, and my command is
>> as follows:
>>
>> cmd="$QEMU_SYSTEM_RISCV64 \
>>    -nographic -machine virt,pflash0=pflash0,pflash1=pflash1,acpi=off \
>>    -cpu rvsp-ref \
>>    -smp "$vcpu" -m "$memory"G \
>>    -blockdev node-name=pflash0,driver=file,read-only=on,filename="$fw1" \
>>    -blockdev node-name=pflash1,driver=file,filename="$fw2" \
>>    -drive file="$drive",format=qcow2,id=hd0,if=none \
>>    -object rng-random,filename=/dev/urandom,id=rng0 \
>>    -device virtio-vga \
>>    -device virtio-rng-device,rng=rng0 \
>>    -device virtio-blk-device,drive=hd0 \
>>    -device virtio-net-device,netdev=usernet \
>>    -netdev user,id=usernet,hostfwd=tcp::"$ssh_port"-:22 \
>>    -device qemu-xhci -usb -device usb-kbd -device usb-tablet"
>>
>> This process gets stuck at the initialization stage:
>>
>> ```
>>      Loading Linux 6.6.0-102.0.0.5.oe2509.riscv64 ...
>>      Loading initial ramdisk ...
>> ```
>>
>> If I use the parameter `-cpu rva23s64`, the system can boot normally.
>>
>> I tried changing TYPE_RISCV_VENDOR_CPU to TYPE_RISCV_BARE_CPU and found that
>> the system then boots normally.
> 
> There is a chance that we're mishandling the .profile property with VENDOR
> type CPUs. Maybe worth taking a look.
> 
> There's nothing stopping us from declaring the CPU as BARE though. It's
> probably a good idea - it gives us a clean CPU without any enabled default
> extensions to work on. I believe we can change that for v4.
> 

I have done more tests. TYPE_RISCV_BARE_CPU works well in the virt machine,
but it can’t start EDKII normally in the rvsp-ref machine.

I think it’s really worth finding out the exact reason first before
we decide whether to make the change.

If I get any progress on my part, I will reply to this email quickly :).

Thanks,
Chao