On Sat, Mar 5, 2022 at 9:36 PM Frank Chang <frank.ch...@sifive.com> wrote:
> On Sun, Mar 6, 2022 at 7:42 AM Atish Kumar Patra <ati...@rivosinc.com> > wrote: > >> >> >> On Sat, Mar 5, 2022 at 10:05 AM Heiko Stuebner <he...@sntech.de> wrote: >> >>> Hi, >>> >>> Am Donnerstag, 3. März 2022, 19:58:38 CET schrieb Atish Patra: >>> > On Fri, Feb 25, 2022 at 11:46 PM Frank Chang <frank.ch...@sifive.com> >>> wrote: >>> > > Atish Patra <ati...@rivosinc.com> 於 2022年2月23日 週三 上午6:39寫道： >>> > >> >>> > >> The Linux kernel parses the ISA extensions from "riscv,isa" DT >>> > >> property. It used to parse only the single letter base extensions >>> > >> until now. A generic ISA extension parsing framework was proposed[1] >>> > >> recently that can parse multi-letter ISA extensions as well. >>> > >> >>> > >> Generate the extended ISA string by appending the available ISA >>> extensions >>> > >> to the "riscv,isa" string if it is enabled so that kernel can >>> process it. >>> > >> >>> > >> [1] https://lkml.org/lkml/2022/2/15/263 >>> > >> >>> > >> Suggested-by: Heiko Stubner <he...@sntech.de> >>> > >> Signed-off-by: Atish Patra <ati...@rivosinc.com> >>> > >> --- >>> > >> Changes from v2->v3: >>> > >> 1. Used g_strconcat to replace snprintf & a max isa string length as >>> > >> suggested by Anup. >>> > >> 2. I have not included the Tested-by Tag from Heiko because the >>> > >> implementation changed from v2 to v3. >>> > >> >>> > >> Changes from v1->v2: >>> > >> 1. Improved the code redability by using arrays instead of >>> individual check >>> > >> --- >>> > >> target/riscv/cpu.c | 29 +++++++++++++++++++++++++++++ >>> > >> 1 file changed, 29 insertions(+) >>> > >> >>> > >> diff --git a/target/riscv/cpu.c b/target/riscv/cpu.c >>> > >> index b0a40b83e7a8..2c7ff6ef555a 100644 >>> > >> --- a/target/riscv/cpu.c >>> > >> +++ b/target/riscv/cpu.c >>> > >> @@ -34,6 +34,12 @@ >>> > >> >>> > >> /* RISC-V CPU definitions */ >>> > >> >>> > >> +/* This includes the null terminated character '\0' */ >>> > >> +struct isa_ext_data { >>> > >> + const char *name; >>> > >> + bool enabled; >>> > >> +}; >>> > >> + >>> > >> static const char riscv_exts[26] = "IEMAFDQCLBJTPVNSUHKORWXYZG"; >>> > >> >>> > >> const char * const riscv_int_regnames[] = { >>> > >> @@ -881,6 +887,28 @@ static void riscv_cpu_class_init(ObjectClass >>> *c, void *data) >>> > >> device_class_set_props(dc, riscv_cpu_properties); >>> > >> } >>> > >> >>> > >> +static void riscv_isa_string_ext(RISCVCPU *cpu, char **isa_str, >>> int max_str_len) >>> > >> +{ >>> > >> + char *old = *isa_str; >>> > >> + char *new = *isa_str; >>> > >> + int i; >>> > >> + struct isa_ext_data isa_edata_arr[] = { >>> > >> + { "svpbmt", cpu->cfg.ext_svpbmt }, >>> > >> + { "svinval", cpu->cfg.ext_svinval }, >>> > >> + { "svnapot", cpu->cfg.ext_svnapot }, >>> > > >>> > > >>> > > We still have other sub-extensions, e.g. Zfh, Zba, Zbb, Zbc, Zbs... >>> etc. >>> > > Do you mind adding them as well? >>> > > >>> > >>> > Do we really need it ? Does any OS actually parse it from the device >>> tree ? >>> > AFAIK, Linux kernel doesn't use them. As the device tree is intended >>> > to keep the information useful >>> > for supervisor software, >>> >>> That actually isn't true ;-) . >>> >>> The devicetree is intended to _describe_ the hardware present in full >>> and has really nothing to do with what the userspace needs. >>> So the argument "Linux doesn't need this" is never true when talking >>> about devicetrees ;-) . >>> >> >> Yes. I didn’t mean that way. I was simply asking if these extensions >> currently in use. I just mentioned Linux as an example. >> >> The larger point I was trying to make if we should add all the supported >> extensions when they are added to Qemu or on a need basis. >> >> I don’t feel strongly either way. So I am okay with the former approach >> if that’s what everyone prefers! >> > > Linux Kernel itself might not, > but userspace applications may query /proc/cpuinfo to get core's > capabilities, e.g. for those vector applications. > It really depends on how the application is written. > > I still think adding all the enabled extensions into the isa string would > be a proper solution, no matter they are used or not. > However, we can leave that beyond this patch. > Fair enough. I will update the patch to include all the extension available. > Regards, > Frank Chang > > >> >>> On the other hand the devicetree user doesn't need to parse everything >>> from DT. So adding code to parse things only really is needed if you >>> need that information. >>> >> >> Agreed. >> >> >>> So if some part of the kernel needs to know about those additional >>> extensions, the array entries for them can also be added in a later >>> patch. >>> >> >> Yes. That was the idea in isa extension framework series where the >> extension specific array entries will only be added when support for that >> extension is enabled. >> >>> >>> >>> Heiko >>> >>> > > Also, I think the order of ISA strings should be alphabetical as >>> described: >>> > > >>> https://github.com/riscv/riscv-isa-manual/blob/master/src/naming.tex#L96 >>> > > >>> > >>> > Ahh yes. I will order them in alphabetical order and leave a big >>> > comment for future reference as well. >>> > >>> > > Regards, >>> > > Frank Chang >>> > > >>> > >> >>> > >> + }; >>> > >> + >>> > >> + for (i = 0; i < ARRAY_SIZE(isa_edata_arr); i++) { >>> > >> + if (isa_edata_arr[i].enabled) { >>> > >> + new = g_strconcat(old, "_", isa_edata_arr[i].name, >>> NULL); >>> > >> + g_free(old); >>> > >> + old = new; >>> > >> + } >>> > >> + } >>> > >> + >>> > >> + *isa_str = new; >>> > >> +} >>> > >> + >>> > >> char *riscv_isa_string(RISCVCPU *cpu) >>> > >> { >>> > >> int i; >>> > >> @@ -893,6 +921,7 @@ char *riscv_isa_string(RISCVCPU *cpu) >>> > >> } >>> > >> } >>> > >> *p = '\0'; >>> > >> + riscv_isa_string_ext(cpu, &isa_str, maxlen); >>> > >> return isa_str; >>> > >> } >>> > >> >>> > >> -- >>> > >> 2.30.2 >>> > >> >>> > >>> > >>> > >>> >>> >>> >>> >>>
