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