On 11/07/2011 07:08 PM, Andy Polyakov 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.
>
> Could you spell it for me? Which flags does guest observe exactly?
> XSAVE=0 and AVX=1? I.e. XEN cared to mask XSAVE flag, but not AVX? Is
> bit masking configurable? If not, how come it clears XSAVE, but not AVX
> (and FMA)? Wouldn't one consider it a bug? I'm not trying to push it
> away, just understand...
Because the hypervisor does nothing that forbids the use of AVX per se;
it's not working only because XSAVE doesn't. If Xen implemented XSAVE
were implemented, AVX would start working without any need to treat it
specially in the CPUID masking code.
>> The only assertion I found is that XSAVE=0 implies OSXSAVE=0 (and
>> OSXSAVE=1 implies XSAVE=1).
>
> But in order to be able to use AVX, you *have to* arrange OSXSAVE=1 (and
> of course corresponding bit in XCR0) and prerequisite for this is XSAVE
> being 1. I.e. there shouldn't be CPUs that have AVX, but not XSAVE.
But it's not in the spec, so it's wrong to assume it.
>> Also, I believe 13.7 implies that it's wrong to clear SSE feature bits
>> when XCR0.SSE=0:
>
> That's why it's '&jnc (&label("clear_avx"));' now, not "clear_xmm".
I don't think there is any reason to have clear_xmm, just like in
x86_64cpuid.pl.
> As for XEN, if it in fact masks XSAVE, but not AVX bits, than even
> check for XSAVE bit should '&jnc (&label("clear_avx"));' instead of
> "done". As well as that x86_64cpuid.pl should test for XSAVE...
That would also work, but it's useless because the spec OTOH says that
you *can* ignore XSAVE (and anyway XSAVE means nothing: it says the
feature is available, but only OSXSAVE says it is actually unusable).
Paolo
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
