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

[Alex Kashchenko]

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).

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).

>
> 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