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: Tom Rondeau
Subject: Re: [Discuss-gnuradio] Volk library invalid opcode exception
Date: Thu, 19 Apr 2012 10:08:24 -0400

On Mon, Apr 16, 2012 at 11:25 AM, Nick Foster <address@hidden> wrote:
> On Mon, Apr 16, 2012 at 5:50 AM, Joanna Rutkowska
> <address@hidden> wrote:
>>
>> On 04/16/12 14:20, Joanna Rutkowska wrote:
>> /.../
>> >
>> > So, it seems like it is not a Xen issue, but instead that the kernel
>> > I'm using in the VM (essentially a vanilla 3.0.4) is not enabling AVX
>> > in XCR0. It would be interesting if anybody could try this on a
>> > non-Xen system with a similarly old kernel as I have (and on the
>> > AVX-capable processor, of course).
>> >
>>
>> Interestingly, I tried another kernel in the VM (essentially a vanilla
>> 3.2.7), and again the AVX seemed to be disabled in the VM (volk used
>> sse4 again).
>>
>> So, I quickly looked through the kernel sources and I think that the
>> kernel enables AVX in this code:
>>
>> static void __init xstate_enable_boot_cpu(void)
>> {
>> /.../
>>    cpuid_count(XSTATE_CPUID, 0, &eax, &ebx, &ecx, &edx);
>>    pcntxt_mask = eax + ((u64)edx << 32);
>>
>>    if ((pcntxt_mask & XSTATE_FPSSE) != XSTATE_FPSSE) {
>>        printk(KERN_ERR "FP/SSE not shown under xsave features 0x%llx\n",
>>               pcntxt_mask);
>>        BUG();
>>    }
>>
>>    /*
>>     * Support only the state known to OS.
>>     */
>>    pcntxt_mask = pcntxt_mask & XCNTXT_MASK;
>>
>>    xstate_enable();
>>
>>
>> The XSTATE_FPSSE and XCNTXT_MASK are defined as follows:
>>
>> #define XSTATE_FP   0x1
>> #define XSTATE_SSE  0x2
>> #define XSTATE_YMM  0x4
>>
>> #define XSTATE_FPSSE    (XSTATE_FP | XSTATE_SSE)
>> #define XCNTXT_MASK (XSTATE_FP | XSTATE_SSE | XSTATE_YMM)
>>
>> The YMM corresponds to the AVX enable flag (not sure why they call it
>> differently?).
>>
>> Anyway, this shows that, assuming CPUID returns correct values (that
>> indicate AVX to be enabled), then the (guest) kernel should enable AVX
>> (and Xen should emulate this and allow for this, as indicated in the
>> previous message). And if CPUID was not returning correct values (i.e.
>> omitting the AVX flag), then we would not have this whole discussion.
>>
>> So, what am I missing?
>>
>> Can you point out which kernels do you use that you have AVX working fine?
>
>
> Linux smidgen 3.0.0-17-generic #30-Ubuntu SMP Thu Mar 8 20:45:39 UTC 2012
> x86_64 x86_64 x86_64 GNU/Linux
>
> I really do think it's a Xen issue; do you have a kernel you can try to run
> outside the hypervisor?
>
> In any case, it's mostly a moot point, as there are very few Volk kernels
> which make use of AVX, and those which do don't appear to be significantly
> faster than their SSE3 counterparts. I think that's due to either memory
> bandwidth or instruction promotion of SSE3 intrinsics, but that's a
> different story.
>
> --n

That's true for right now, but we will hopefully be using more AVX
instructions to help those processors that can make use of them. Since
there's all sorts of version issues out there with kernels,
hypervisors, GCC, etc., we're going to be going through a few of these
growing pains to get the best and most stable use out of our systems.

In the meantime, great job coming up with a patch for it so quickly,
and hopefully the new build system for Volk that you, Josh, et al. are
working on will help this even more.

Tom



reply via email to

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