Re: [PATCH] linux-user: Expose risc-v V and H isa bit in get_elf_hwcap()

[nihui]

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" <palmer@dabbelt.com> wrote:
>On Wed, 04 May 2022 08:10:03 PDT (-0700), alistair23@gmail.com wrote:
>> On Wed, May 4, 2022 at 2:32 PM nihui <shuizhuyuanluo@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 <shuizhuyuanluo@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
>>>
>>>