Ah, I admit that I haven't tested the availability of the H extension, I could update the new patch to only add the V extension.
Regarding the motivation for this modification, the ncnn project uses the risc-v vector extension to optimize the efficiency of nn inference. I am very happy to find that qemu already supports rvv. I want to use qemu's userspace mode to do unit testing faster and more conveniently on the ci server. In the past, I used the rvv branch of sifive/qemu. On that branch, the V bit exists in hwcap and works well [1]. I can distinguish at runtime whether the current system supports rvv by checking this bit. As an early adopter of rvv, I think exposing V bit will help rvv to be more tested and widely used. After all, rvv is not enabled by default. This V bit will only exist in the -cpu rv64,v=true parameter, which is for some advanced developers. We know that qemu currently implements rvv-1.0 and removes rvv-0.7.1. [1] https://github.com/sifive/qemu/commit/7a3e8e23b4cf1422ec48e9d4b4009337a05a635d best wishes nihui At 2022-05-05 00:05:31, "Palmer Dabbelt" <pal...@dabbelt.com> wrote: >On Wed, 04 May 2022 08:10:03 PDT (-0700), alistai...@gmail.com wrote: >> On Wed, May 4, 2022 at 2:32 PM nihui <shuizhuyuan...@126.com> wrote: >>> >>> This patch brings the optional risc-v vector and hypervisor bits >>> in hwcap so that application could detect these isa support from >>> /proc/self/auxv correctly in qemu userspace mode. >>> >>> Signed-off-by: Ni Hui <shuizhuyuan...@126.com> >>> --- >>> linux-user/elfload.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >>> >>> diff --git a/linux-user/elfload.c b/linux-user/elfload.c >>> index 61063fd974..3f0ef2b8f6 100644 >>> --- a/linux-user/elfload.c >>> +++ b/linux-user/elfload.c >>> @@ -1484,7 +1484,8 @@ static uint32_t get_elf_hwcap(void) >>> #define MISA_BIT(EXT) (1 << (EXT - 'A')) >>> RISCVCPU *cpu = RISCV_CPU(thread_cpu); >>> uint32_t mask = MISA_BIT('I') | MISA_BIT('M') | MISA_BIT('A') >>> - | MISA_BIT('F') | MISA_BIT('D') | MISA_BIT('C'); >>> + | MISA_BIT('F') | MISA_BIT('D') | MISA_BIT('C') >>> + | MISA_BIT('V') | MISA_BIT('H'); >> >> The kernel doesn't support H or V. I understand V should be supported >> in the future, but what is the use case for H? > >IMO even V is a bit in question: sure that bit's likely to be set at >some point, but there's many flavors of V now and we'll have to give >userspace a way to differentiate between them. There's been some >proposals (see Kito's talk from Plumbers last year, for example) about >how to deal with this, but nothing really concrete has shown up yet. > >If we flip on the V bit in user mode emulation then we run the risk of >having a wacky ABI here, where QEMU is setting the V bit but then not >setting whatever extra info is expected to come along with it. That'd >mean userspace has to deal with that case -- maybe that's not the worst >problem, and I guess it's better than just assuming V is always on, >which is all userspace can do now, but any ABI divergence is going to >lead to headaches at some point. > >IMO the right way forward here is to just sort out what the actual >interface is, last time I talked to Kito about it we had a rough idea of >where to go and plans to do it. Not sure what's up these days, so I've >added him to the thread. If it's a long way off then we can always toss >some intermediate thing together like this, but if it's close then it's >probably best to just get the interface ironed out and then have it >match. > >> >> Alistair >> >>> >>> return cpu->env.misa_ext & mask; >>> #undef MISA_BIT >>> -- >>> 2.25.1 >>> >>>
