RFR: JDK-8158502: aarch32: detect QEMU user-mode emulation

Andrey Petushkov andrey.petushkov at gmail.com
Thu Jun 2 16:51:06 UTC 2016


Hi Alex,

Sorry but I’m a bit hesitant to follow the approach you presented. I’m not sure that the solution is stable enough, specifically around removing of assertions in the relocation support. As the result you actually get into the situation when the code cannot be patched correctly and will end up executing the wrong version (in best case) or executing mere garbage. So I’d rather understand why at all such situation can happen. Given the explanation you’re provided I can assume that the real reason for the problem is absence of indication of the cpu version in the /proc/cpuinfo, since java sees the host’s version, which has nothing to do with instruction set being emulated. As such we fall into lowest armv6 mode, which is actually not supported by the code (currently the lowest supported cpu is armv6t2). The support of the armv6 (non t2) in aarch32 port has problem of emitting code which cannot be patched later (it’s just not implemented). Although it might happen that actual relocation of the code is not needed for interpreter only build, it becomes extremely important when C1 implementation is integrated

So in order to have this problem addressed I’d rather go in a different way. Assuming that your emulator can do armv6t2 or v7 I’d better add an command line option (much like those UseAES etc) to override the information obtained from /proc/cpuinfo (and avoid calling getauxv, since it likely to return host’s capabilities). This way java should function fully in accordance to the capabilities of the emulator (assuming the passed values are correct, of course). The same time the problem of yours should go away.

Well, another way can be is to hardcode the value of the ProcessorFeatures, once emulation is detected. However such solution is too much inflexible so I’d better abstain from it

In the meanwhile I’ve tried to reproduce the situation but failed to install necessary environment (I’m using Ubuntu and there’s no armhf libc.so available in the stock repos, I’ve tried to install from debian manually, but failed on missing the package multiarch-support-armhf-cross. Both google and myself have no idea where to get it :( ). So I can only hope that emu-user-static is capable of emulating at least armv6t2, otherwise the problem is much bigger than just the asserts..

Regards,
Andrey

> On 02 Jun 2016, at 14:21, Alex Kashchenko <akashche at redhat.com> wrote:
> 
> Hi,
> 
> This patch detects that jvm runs on x86_64 hardware using QEMU user-mode emulation and prevents (ignores) assertions that currently happen in that environment:
> 
> - issue: https://bugs.openjdk.java.net/browse/JDK-8158502
> - webrev: http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8158502/webrev.00/
> 
> QEMU allows to run arm32 programs on x86_64 hardware with user-mode emulation tools (qemu-arm-static). Along with binfmt_misc setup it allows to run aarch32 jvm on x86_64 hardware transparently like a native binary (albeit at the much slower speed). That may be useful during the cross-compilation for smoke testing aarch32 changes.
> 
> Currently jvm asserts on startup in that environment. Proposed change is to detect QEMU user-mode emulation and prevent (ignore) assertions in that case.
> 
> Detection is done looking into "lm" (64-bit) or "tm" (32-bit) entry in "flags" field in /proc/cpuinfo. It is assumed that if we can see x86(_64) CPU from aarch32 JVM - we are running in user-mode emulation as QEMU+kernel emulation reports its own /proc/cpuinfo. Detection result is saved as FT_UMEmu (User Mode Emulation) flag in VMVersion.
> 
> Actual changes are in relocInfo_aarch32.cpp , they are deliberately non-intrusive to mainline execution code - effectively just assertions are ignored. It may (or may not) be better to implement proper support for user-mode emulation in that code in future.
> 
> Checks before printing warnings have been required, because these warnings (all 4 of them) being printed in release builds - that breaks jdk version detection.
> 
> Running in user-mode emulation aarch32 vm is stable - during testing I bootstrapped slowdebug aarch32-jdk8u using fastdebug aarch32-jdk8u as a boot jdk on x86_64 hardware.
> 
> Webrev is done against the current state of jdk8u forest. Changes to vm_version part may conflict with other patches. After the review I'll rebase this patch onto the new state and will create committed webrevs for jdk8u and jdk9.
> 
> -- 
> -Alex



More information about the aarch32-port-dev mailing list