Hi Andy,
On 11/07/2011 08:23 AM, Tomas Mraz via RT wrote:
>> No, the test is bypassed if XSAVE is 0, not 1. XSAVE being 0 also
>> implies that AVX flag [as well as FMA and XOP] is 0, which is why is
>> jumps to 'done' and not 'clear_avx'.
>
> This assertion is unfortunately not true on RHEL-6 guests on AVX capable
> CPUs in XEN VM.
In fact, I can't find in any spec the assertion that XSAVE=0 implies
AVX=FMA=XOP=0 (I checked "Intel 64 and IA-32 Architectures
Software Developer's Manual" volumes 1/2/3 and Intel appnote 485, "Intel
Processor Identification and the CPUID Instruction".
The only assertion I found is that XSAVE=0 implies OSXSAVE=0 (and
OSXSAVE=1 implies XSAVE=1). It's in 13.8.1 of the SDM volume 3A, and
the text there roughly matches my patch and x86_64cpuid.pl:
Applications do not need to check the value of CPUID.01H:ECX.XSAVE
because "CPUID.01H:ECX.OSXSAVE = 1" implies OS has successfully
verified CPUID.01H:ECX.XSAVE = 1. CPUID.01H:ECX.OSXSAVE reflects the
value of CR4.OSXSAVE, and this bit cannot be set to 1 unless
CPUID.01H:ECX.XSAVE = 1.
Also, I believe 13.7 implies that it's wrong to clear SSE feature bits
when XCR0.SSE=0:
It is also possible for system software to adopt an alternate
approach of using FXSAVE/FXRSTOR for x87 and SSE state management,
and implementing forward processor extended state management using
XSAVE/XRSTOR. In this case, system software must specify the bit
vector mask in EDX:EAX appropriately when executing XSAVE/XRSTOR
instructions.
(Regarding my statement that "the whole test is bypassed if XSAVE=1",
that was indeed my mistake).
Paolo
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
