discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Volk library invalid opcode exception


From: Joanna Rutkowska
Subject: Re: [Discuss-gnuradio] Volk library invalid opcode exception
Date: Sun, 15 Apr 2012 23:26:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 04/15/12 17:45, Tom Rondeau wrote:
> Yes, so the vmovss is an AVX instruction (the AVX version of movss),
> but your processor doesn't have AVX according to your flags above.
> Except that it does. According to Intel, the i5-2540M processor
> supports AVX, but your OS isn't recognizing the avx flag in
> /proc/cpuinfo. The Volk build process asks the processor directly for
> the flags that it can use.
> 
> I really think this is a problem with Xen (or at least something in the 
> setup).

Assuming that the VM kernel is messing up the info that is exposed to
apps via /proc/cpuinfo (this might be likely, sure), and that volk uses
cpuid instruction to actually figure out whether AVX is supported, it
should still work fine -- volk would just use AVX instruction and it
SHOULD work, because this is a ring3 instruction and Xen has no way to
intercept it or prevent its execution (this is true for both PV and HVM
guests -- in case of HVMs there is no VMX intercept that would trigger
on AVX execution, at least I couldn't find one in the SDM)...

So, why it doesn't work? Is there any way one can configure a processor
(via MSR perhaps?) to disable AVX? Xen could be doing that, and
forgetting to remove the AVX flag from the cpuid info exposed to guests...

Another potential explanations of why this doesn't work I could come up
with:

1) Perhaps volk somehow erroneously interprets cpuid info and assumes
that AVX is present, while it is no...? Tom, can you point out the
specific code in volk that is responsible for deciding whether to use
AVX or not?

2) There is a compiler error with generating this opcode correctly
(which would be, however, very strange, as the gdb displays this
instruction fine...),

3) My processor is buggy :o

Any other idea?

This is getting interesting :)

Thanks,
joanna.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]