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

[Andrey Petushkov]

Hi Alex,

> On 07 Jun 2016, at 18:52, Alex Kashchenko <akashche at redhat.com> wrote:
> 
> Hi Andrey,
> 
> On 06/07/2016 03:44 PM, Andrey Petushkov wrote:
>> Hi Alex,
>> 
>> Thank you, yes, the approach is looking good to me. Although I’m slightly biased towards dynamic generation of the test code, much like is done e.g. on PPC platform: they generate code blob using hotspot assembler just as any other code and are using the hotspot's signal handler facilities to monitor the outcome.
>> I’m planning to fix ARM v6 support (currently does not work at least with C1) and can implement necessary changes in vm_version_aarch32, if you’d like
> 
> If you are going to implement capabilities probing in near future - of course please go on. I will follow vm_version_aarch32 changes closely and will try them on different platforms (including QEMU).
Yes, I’m taking this as my foreground task. Hopefully nothing distracts me
> 
> Side question about the ARMv6 support: are you planning to have a full implementation for CPUs that don't support ARMv6T2? I'll setup building/testing on RPi B+ (or on RPi Zero - have couple of them) in that case. Also, I think that is not the case, but just to be sure that decision on ARMv6 support is not motivated by QEMU problems (mentioned earlier in this thread) - as QEMU is not limited by ARMv6 (also supports ARMv7, AArch64 etc).
Yes, I thought about “pure” v6, but in fact I only have RPI B+ as a test machine which is ARMv6K which is easier compared to plain old ARMv6. If by the chance you have anything with real v6 that would be very much appreciated if you could help with checking!
And please don’t worry, you’re not the reason for me to switch into this :)

Regards,
Andrey
> 
>> 
>> Regards,
>> Andrey
>> 
>>> On 07 Jun 2016, at 01:38, Alex Kashchenko <akashche at redhat.com> wrote:
>>> 
>>> Hi,
>>> 
>>> On 06/02/2016 10:03 PM, Alex Kashchenko wrote:
>>>>> On 06/02/2016 07:57 PM, Edward Nevill wrote:
>>>>> [...]
>>>>> 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.
>>> 
>>> I prototyped a simplistic utility for CPU capabilities probing - http://cr.openjdk.java.net/~akasko/aarch32/jdk8u/8158502/detect.01/
>>> 
>>> It uses sigaction and siglongjmp for probing, probe-functions are precompiled. Currently it can only detect ARMv6T2 using movt, but adding more probes should be straightforward.
>>> 
>>> Looking for comments whether something like this can be used in vm_version_aarch32.
>>> 
>>> 
>>> References:
>>> - https://github.com/openssl/openssl/blob/4ac0329582829f5378d8078c8d314ad37db87736/crypto/armcap.c#L87
>>> - https://lkml.org/lkml/1996/4/27/27
>>> 
>>> --
>>> -Alex
>> 
>> 
> 
> 
> -- 
> -Alex