On Tue, Mar 8, 2022 at 2:53 PM Atish Patra <ati...@atishpatra.org> wrote: > > On Sat, Mar 5, 2022 at 10:43 PM Frank Chang <frank.ch...@sifive.com> wrote: > > > > On Sun, Mar 6, 2022 at 2:12 PM Atish Kumar Patra <ati...@rivosinc.com> > > wrote: > >> > >> > >> > >> 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. > > > > > > Thanks, that would be great. > > > > BTW, I think current QEMU RISC-V isa string includes both "s" and "u": > > https://github.com/qemu/qemu/blob/master/target/riscv/cpu.c#L37 > > But in fact, they should not be presented in the DTS isa string. > > Do you think we should exclude them as well? > > > > There is a patch in the mailing list fixing that issue > > https://lists.nongnu.org/archive/html/qemu-riscv/2022-02/msg00099.html >
I just realized that it was only sent to qemu-ri...@nongnu.org not qemu-devel. @Tsukasa OI : Can you please send it again to both qemu-riscv & qemu-devel so that it is accessible to the broader qemu community. > > Regards, > > Frank Chang > > > >> > >>> > >>> 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 > >>>>> > >> > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> > > > -- > Regards, > Atish -- Regards, Atish
