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

[Alex Kashchenko]

Hi Edward,

On 06/02/2016 07:57 PM, Edward Nevill wrote:
> Hi,
>
> On Thu, 2016-06-02 at 18:48 +0100, Alex Kashchenko wrote:
>
>>> 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.
>>
>> So we basically need to make platform detection (from /proc/cpuinfo)
>> clever enough not only to detect the user-mode emulation but also to
>> detect correct supported instruction set (and other emulated cpu
>> features). And support more command line args for enabling/disabling
>> detected features directly.
>
> The reading of /proc/cpuinfo is a horrible wart which we should try to
> expunge. getauxv() is only marginally better. Both are non portable and
> break under virtualisation.
>
> The only reliable way to determine what features the CPU has is to test
> the CPU itself. Unfortunately ARM have a habit of making the ID
> registers only accessible in privileged modes, presumably to allow for
> virtualisation, but then the kernels don't pass the information through.
>
> I would almost prefer a scheme where we test an instruction from the
> feature set we wish to use and if we catch a SIGILL we mark the feature
> as not available.

Thanks for the explanation. I know that OpenSSL library uses this 
approach [1]. I also checked Android cpufeatures library [2] (that is 
likely fine-tuned for arm32), but unfortunately it doesn't use this 
approach [3], probably because it runs in more controlled environment.

>>> 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 :( ).
>>
>> I wrote down details of cross-compilation env setup some time ago here -
>> https://github.com/akashche/wiki/wiki/AArch32CrossCompile . It is a bit
>> over the top as the initial version has been written for IcedTea7-arm32
>> that runs freshly built vm during the build. It is for Ubuntu 15.10, but
>> also works for 16.04 (changing only version numbers and "wily" ->
>> "xenial" for repos). Also VM can be used instead of Docker.
>>
>
> If you are building in a chroot your should just be able to ln a
> 'correct' /proc/cpuinfo. This is what I do and it seems to work. But
> then I am only 'cross' compiling from aarch64 to aarch32.

Yes, I can make it run in local env with some tuning, I currently just 
patching these asserts (doing this for some time, and initial patch was 
an attempt to upstream it with minimal changes), but disguising 
/proc/cpuinfo will likely work too. Though I think it would be great to 
have cpu detection sorted out properly so aarch32 will "just work" with 
QEMU.

aarch64 with hardware emulation of aarch32 is much more convenient of 
course, but it has it's own shortcomings as you likely need a quite 
bulky aarch64 machine to compete in compilation speed with x86_64 laptop.

>
> All the best,
> Ed.
>
>

[1] https://www.openssl.org/docs/faq.html#PROG17
[2] https://developer.android.com/ndk/guides/cpu-features.html
[3] 
https://chromium.googlesource.com/android_tools/+/704c8ddee726aabe0e78bb88545972d2cf298190/ndk/sources/android/cpufeatures/cpu-features.c#496

-- 
-Alex