Regarding the patch disabling AVX when eagerfpu is off: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3 94db20ca240741a08d472173db13d6f6a6e5a28
We have a suggestion that Intel documentation related to usage of CR0.TS bit may be not properly updated with additional support of AVX/AVX2/etc instructions. In fact, there is certain ambiguity about the causes of #NM exception in other sections of Intel documentation. Based on the chapter 2.4 INSTRUCTION EXCEPTION SPECIFICATION of Intel 64 and IA-32 Architectures Software Developer's Manual, all SSE/SSE2/SSE4/MMX/AVX/etc. instructions, which modify the FPU/MMX/AVX state are supposed to generate #NM exception when CR0.TS = 1. In addition, based on AMD documentation, the #NM exception is generated for both SSE and AVX instructions in protected mode - refer to AMD64 Architecture Programmer's Manual Volume 4: 128-Bit and 256-Bit Media Instructions and also "AMD64 Architecture Programmer's Manual Volume 2: System Programming" Chapter 3.1 (Task Switched (TS) Bit.3. When an attempt is made to execute an x87 or media instruction while TS=1, a device-not-available exception (#NM) occurs). Also, in our limited internal test on Intel I7 processor (repeated on two different machines), while executing the AVX VMOVAPS instruction with CR0.TS bit set, we've observed the #NM exception being always generated (although we didn't perform all-inclusive tests for entire set of AVX and similar new instructions). In view of above findings we would like to suggest to double check if disabling AVX together with "eagerfpu off" is actually required and is a real necessity. It would be helpful to consult with Intel engineers regarding related design details. Sincerely, Leonid Shatz, Seniour Software Enigneer, Hypervisor Team, Ravello Systems, Inc.