On Thu, May 5, 2022 at 12:30 PM nihui <shuizhuyuan...@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" <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. 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
