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

Andrey Petushkov andrey.petushkov at gmail.com
Tue Jun 7 14:44:46 UTC 2016


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

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



More information about the aarch32-port-dev mailing list