Doing something like AES-GCM with the AES in the engine and GCM Hash in
OpenSSL though I'd expect to see an impact, you are basically doingthe AES
a blcok at a time in that sceenario.
Just for reference. This is kind of bad example, because OpenSSL GCM
implementation allows to deploy stream
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
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?
On Tue, 2011-11-08 at 20:32 +0100, Andy Polyakov via RT wrote:
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
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
