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: Mon, 16 Apr 2012 14:20:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 04/16/12 13:47, Tom Rondeau wrote:
> On Sun, Apr 15, 2012 at 8:24 PM, Nick Foster <address@hidden> wrote:
>> > Attached is a patch with one further check -- to make sure the check that
>> > AVX is enabled by the OS, is enabled by the OS.
>> >
>> > No kidding.
>> >
>> > --n
> Wonderful, Nick, thanks.
> 
> Joanna, let us know how this works for you. I'm going to be on the
> road for the next few days, so I'll be sparsely available.

Yes, it works! I can now use the gr_add block to add to sin signals, how
cool! ;)

BTW, as Nick's patch didn't apply cleanly on v3.5.3, I pulled from the
git and applied it on top of the HEAD -- please let me know if you think
it can get me into troubles to work on GR/GRC build from the HEAD
instead of from some v3.5.x tag.

Anyway, I looked into Xen sources and it seems like Xen *does allow* the
guest PV kernel to set bits 1 and 2 in the XCR0 register -- here's the
relevant code (I think):

   case 0xd1: /* XSETBV */
        {
            u64 new_xfeature = (u32)regs->eax | ((u64)regs->edx << 32);

            if ( lock || rep_prefix || opsize_prefix
                 || !(v->arch.guest_context.ctrlreg[4] & X86_CR4_OSXSAVE) )
            {
                do_guest_trap(TRAP_invalid_op, regs, 0);
                goto skip;
            }

            if ( !guest_kernel_mode(v, regs) )
                goto fail;

            switch ( (u32)regs->ecx )
            {
                case XCR_XFEATURE_ENABLED_MASK:
                    /* bit 0 of XCR0 must be set and reserved bit must
not be set */
                    if ( !(new_xfeature & XSTATE_FP) || (new_xfeature &
~xfeature_mask) )
                        goto fail;

                    v->arch.xcr0 = new_xfeature;
                    v->arch.xcr0_accum |= new_xfeature;
                    set_xcr0(new_xfeature);
                    break;
                default:
                    goto fail;
            }
            break;

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

Thanks,
joanna.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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