RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]

[Robbin Ehn]

On Wed, 9 Apr 2025 07:29:01 GMT, Fei Yang <fyang at openjdk.org> wrote:

> > > > It's not some intermittently failure. The majority of them can't work as they use pstack, open core files, use PerfData, etc.. and expected it to be rv64. But core files, pstack are in host arch as we are running qemu-user. I can remove tests which timeouts and only keep test which simply can't work in qemu-user environment in this PR. Seems good?
> > > 
> > > 
> > > Hi, That make sense to me. And it doesn't seem to me to be riscv-specific issue, but rather one with qemu-user. Maybe we should update the title and changes to reflect that? I sometimes see people testing with qemu for other CPU platforms as well like ppc, s390, etc. Guess they might be helped with this too.
> > 
> > 
> > Hey, thanks for considering. The default qemu /proc/cpu do not contain any information about this being qemu. And there is no standard way to find this out AFIAK. Some platforms have target specific /proc/cpu and put qemu in there, but it have no standard format. The whole proc -> uarch string -> jvm cpu string -> jtreg require is qemu/linux-user/riscv specific.
> 
> Ah, I see. But I guess it won't bite us if we can't parse `qemu` in /proc/cpuinfo? I am not familiar with how qemu-user works. Can I expect this to work at least for some other CPUs supported by the JVM?

qemu-user, "uarch: qemu" in cpuinfo:
`[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond`
Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).

`/proc/cpuinfo` do not contain uarch:
[0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond
We have no clue if this is emulated or on real hardware, tests will be executed.

Tests are only excluded if we know it's qemu-user.

Did that anwser your Q ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2788717608