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

Re: [Xen-devel] fma4/avx under xen

On Wed, 2012-05-02 at 19:54 +0100, Jim Westfall wrote:
> Hi
> I wanted to bring this to your attention
> https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/956051
> The summary is that when gcc compiles something with -mfma4 it also 
> enables the use of the avx instruction set.  Since by default xen 
> disables avx it leads to invalid opcodes.
> This ends up being kinda nasty with the multiarch glibc since its doing 
> stuff like
> (HAS_FMA4 ? run_fma4_func() : (HAS_AVX ? run_avx_func() : run_func()))
> run_fma4_func() can end up bombing out from the invalid opcode when run 
> under xen.
> Its not clear to me if xen should be filtering fma4 as part of its avx 
> filter or if gcc should not assume avx support when compiling with 
> -mfma4.

is pretty clear about the need for code to verify that the OS supports
these instructions before using them (see under "Detecting Availability
and Support"). The bit people seem to forget is the requirement to check
CPUID.1:ECX.OSXSAVE = 1 to ensure the OS supports the use of these
instructions (since they are not transparent to the OS) as well as
checking the processor features themselves.

If gcc/eglibc is not doing this before using those instructions then
that seems like it is a bug in either gcc or eglibc.

If the user is using some gcc option which forces the use of those
instructions when the (virtualised, or otherwise) processor does not
support them that seems like user error to me, it's no different to
using -mcpu=686 and then trying to run on a 486 class processor.

Sounds a lot like the same issue as


> thoughts?
> thanks
> jim
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.