王昊然 <msl0000023...@gmail.com> writes:
>> int main() {
>> unsigned long int hwcap = getauxval(AT_HWCAP);
>> printf("hwcap = 0x%lx\n", hwcap);
>> return 0;
>> }
>> whr@debian:~/src$ gcc -Wall cpu-feature-test.c
>> whr@debian:~/src$ ./a.out
>> hwcap = 0xdc0065c2
And the flags checked by nettle are (from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/include/uapi/asm/cputable.h?h=v6.1-rc1)
#define PPC_FEATURE_HAS_ALTIVEC 0x10000000
#define PPC_FEATURE_HAS_VSX 0x00000080
so both set in your case.
>>
>>> Is the program that crashes running under a vm, or is the kernel running
>>> on the bare metal? Each layer of vm tends to be ian opportunity to
>>> introduce
>>> errors in the list of available processor features.
>>
>> Operating systems on this machine are always running on the Power
>> Hypervisor,
>> which is a part of the server firmware.
>>
>
> I just checked the nettle source code, it is indeed correctly checked both
> PPC_FEATURE_HAS_ALTIVEC and PPC_FEATURE_HAS_VSX; and with my HWCAP has
> PPC_FEATURE_HAS_VSX set, I think it hits a limitation of this processor
> feature checking logic: hardware supporting it, but the kernel didn't.
>
> I will try to build a new kernel with CONFIG_VSX enabled by tomorrow.
My understanding is that AT_HWCAP should describe what instructions are
available to userspace processes. If an instruction set extension isn't
fully supported and enabled by all of hw/kernel/hypervisor, it should
not be listed in hwcap. So the alternative might be to leave VSX
disabled, but ensure it isn't advertised in hwcaps.
Regards,
/Niels
--
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.
