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

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

[nihui]

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');
 
     return cpu->env.misa_ext & mask;
 #undef MISA_BIT
-- 
2.25.1

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

[Alistair Francis]

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?

Alistair

>
>      return cpu->env.misa_ext & mask;
>  #undef MISA_BIT
> --
> 2.25.1
>
>

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

[Palmer Dabbelt]

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
>>
>>

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
>>>
>>>

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

[Alistair Francis]

On Thu, May 5, 2022 at 12:30 PM nihui <shuizhuyuanluo@126.com> wrote:
>
> 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'm glad to hear that QEMU is helping you test Vector extensions!

> I want to use qemu's userspace mode to do unit testing faster and more conveniently on the ci server.

Does your Linux system expose V via hwcap? As Palmer says I think you
are currently stuck with just enabling it at build time as Linux
doesn't expose this information to userspace

>
> 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.

I agree, but Linux and other software doesn't support Vector yet (at
least not that I know of) so it's difficult to enable 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.

Thank you for the patch, we really appreciate it and I hope to see
more patches from you in the future!

I think in this case though we shouldn't take this patch in QEMU at
the moment. It's important that QEMU follows Linux here, as we don't
want to diverge.

Alistair