On Wed, 9 Apr 2025 07:29:01 GMT, Fei Yang <fy...@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

Reply via email to