Re: [RISC-V][tech-server-platform] [RISC-V][tech-server-soc] [RFC 2/2] target/riscv: Add server platform reference cpu

[Daniel Henrique Barboza <dbarboza@ventanamicro.com>]

On 3/7/24 09:17, Heinrich Schuchardt wrote:
> On 07.03.24 08:36, Wu, Fei2 wrote:
>> On 3/6/2024 9:26 PM, Wu, Fei wrote:
>>> On 3/5/2024 1:58 PM, Wu, Fei wrote:
>>>> On 3/5/2024 3:43 AM, Daniel Henrique Barboza wrote:
>>>>>
>>>>>
>>>>> On 3/4/24 07:25, Fei Wu wrote:
>>>>>> The harts requirements of RISC-V server platform [1] require RVA23 ISA
>>>>>> profile support, plus Sv48, Svadu, H, Sscofmpf etc. This patch provides
>>>>>> a 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
>>>>>>
>>>>>> Signed-off-by: Fei Wu <fei2.wu@intel.com>
>>>>>> --->   hw/riscv/server_platform_ref.c |  6 +++-
>>>>>>    target/riscv/cpu-qom.h         |  1 +
>>>>>>    target/riscv/cpu.c             | 62 ++++++++++++++++++++++++++++++++++
>>>>>>    3 files changed, 68 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/hw/riscv/server_platform_ref.c
>>>>>> b/hw/riscv/server_platform_ref.c
>>>>>> index ae90c4b27a..52ec607cee 100644
>>>>>> --- a/hw/riscv/server_platform_ref.c
>>>>>> +++ b/hw/riscv/server_platform_ref.c
>>>>>> @@ -1205,11 +1205,15 @@ static void
>>>>>> rvsp_ref_machine_class_init(ObjectClass *oc, void *data)
>>>>>>    {
>>>>>>        char str[128];
>>>>>>        MachineClass *mc = MACHINE_CLASS(oc);
>>>>>> +    static const char * const valid_cpu_types[] = {
>>>>>> +        TYPE_RISCV_CPU_RVSP_REF,
>>>>>> +    };
>>>>>>          mc->desc = "RISC-V Server SoC Reference board";
>>>>>>        mc->init = rvsp_ref_machine_init;
>>>>>>        mc->max_cpus = RVSP_CPUS_MAX;
>>>>>> -    mc->default_cpu_type = TYPE_RISCV_CPU_BASE;
>>>>>> +    mc->default_cpu_type = TYPE_RISCV_CPU_RVSP_REF;
>>>>>> +    mc->valid_cpu_types = valid_cpu_types;
>>>>>
>>>>> I suggest introducing this patch first, then the new machine type that
>>>>> will use it as a default
>>>>> CPU. The reason is to facilitate future bisects. If we introduce the
>>>>> board first, a future bisect
>>>>> might hit the previous patch, the board will be run using RV64 instead
>>>>> of the correct CPU, and
>>>>> we'll have different results because of it.
>>>>>
>>>> Good suggestion.
>>>>
>>>>>>        mc->pci_allow_0_address = true;
>>>>>>        mc->default_nic = "e1000e";
>>>>>>        mc->possible_cpu_arch_ids = riscv_numa_possible_cpu_arch_ids;
>>>>>> diff --git a/target/riscv/cpu-qom.h b/target/riscv/cpu-qom.h
>>>>>> index 3670cfe6d9..adb934d19e 100644
>>>>>> --- a/target/riscv/cpu-qom.h
>>>>>> +++ b/target/riscv/cpu-qom.h
>>>>>> @@ -49,6 +49,7 @@
>>>>>>    #define TYPE_RISCV_CPU_SIFIVE_U54
>>>>>> RISCV_CPU_TYPE_NAME("sifive-u54")
>>>>>>    #define TYPE_RISCV_CPU_THEAD_C906
>>>>>> RISCV_CPU_TYPE_NAME("thead-c906")
>>>>>>    #define TYPE_RISCV_CPU_VEYRON_V1
>>>>>> RISCV_CPU_TYPE_NAME("veyron-v1")
>>>>>> +#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)
>>>>>> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c
>>>>>> index 5ff0192c52..bc91be702b 100644
>>>>>> --- a/target/riscv/cpu.c
>>>>>> +++ b/target/riscv/cpu.c
>>>>>> @@ -2282,6 +2282,67 @@ static void rva22s64_profile_cpu_init(Object *obj)
>>>>>>          RVA22S64.enabled = true;
>>>>>>    }
>>>>>> +
>>>>>> +static void rv64_rvsp_ref_cpu_init(Object *obj)
>>>>>> +{
>>>>>> +    CPURISCVState *env = &RISCV_CPU(obj)->env;
>>>>>> +    RISCVCPU *cpu = RISCV_CPU(obj);
>>>>>> +
>>>>>> +    riscv_cpu_set_misa_ext(env, RVG | RVC | RVS | RVU | RVH | RVV);
>>>>>> +
>>>>>> +    /* FIXME: change to 1.13 */
>>>>>> +    env->priv_ver = PRIV_VERSION_1_12_0;
>>>>>> +
>>>>>> +    /* RVA22U64 */
>>>>>> +    cpu->cfg.mmu = true;
>>>>>> +    cpu->cfg.ext_zifencei = true;
>>>>>> +    cpu->cfg.ext_zicsr = true;
>>>>>> +    cpu->cfg.ext_zicntr = true;
>>>>>> +    cpu->cfg.ext_zihpm = true;
>>>>>> +    cpu->cfg.ext_zihintpause = true;
>>>>>> +    cpu->cfg.ext_zba = true;
>>>>>> +    cpu->cfg.ext_zbb = true;
>>>>>> +    cpu->cfg.ext_zbs = true;
>>>>>> +    cpu->cfg.zic64b = true;
>>>>>> +    cpu->cfg.ext_zicbom = true;
>>>>>> +    cpu->cfg.ext_zicbop = true;
>>>>>> +    cpu->cfg.ext_zicboz = true;
>>>>>> +    cpu->cfg.cbom_blocksize = 64;
>>>>>> +    cpu->cfg.cbop_blocksize = 64;
>>>>>> +    cpu->cfg.cboz_blocksize = 64;
>>>>>> +    cpu->cfg.ext_zfhmin = true;
>>>>>> +    cpu->cfg.ext_zkt = true;
>>>>>
>>>>> You can change this whole block with:
>>>>>
>>>>> RVA22U64.enabled = true;
>>>>>
>>>>>
>>>>> riscv_cpu_add_profiles() will check if we have a profile enabled and, if
>>>>> that's the
>>>>> case, we'll enable all its extensions in the CPU.
>>>>>
>>>>> In the near future, when we implement a proper RVA23 support, we'll be
>>>>> able to just do
>>>>> a single RVA23S64.enabled = true in this cpu_init(). But for now we can
>>>>> at least declare
>>>>> RVA22U64 (perhaps RVA22S64) support for this CPU.
>>>>>
>>>
>>> Hi Daniel,
>>>
>>> I'm not sure if it's a regression or the usage has been changed. I'm not
>>> able to use '-cpu rva22s64' on latest qemu (db596ae190).
>>>
>> I did a quick git bisect and found that commit d06f28db6 "target/riscv:
>> move 'mmu' to riscv_cpu_properties[]" disabled mmu by default, so that
>> an explicit mmu option should be added to qemu command line like '-cpu
>> rva22s64,mmu=true', I think rva22s64 should enable it by default.
>>
>> Thanks,
>> Fei.
> 
> It is nice that the MMU can be disabled. But is there any reason why the MMU should be disabled by default on the virt machine (which typically is used to run an operating system)?

'mmu' is currently being handled as a CPU property, not a board property. So using
the 'virt' board without a MMU is valid (albeit not that useful/common).

> 
> Can we add mmu=true as default to the rv64 CPU?

Excluding vendor CPUs (where every vendor can do whatever they want), all CPUs that
aren't bare (rv32i, rv64i, rv32e, rv64e) are running with mmu=true. The behavior
described by Fei with profile CPUs is fixed in riscv-to-apply and queued to be
merged.


Thanks,

Daniel


> 
> Best regards
> 
> Heinrich