Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-18 Thread Andy Polyakov via RT
Specification says that AVX instruction will generate #UD exception if XCR0 is not set up appropriately. Which is indeed what happens, and that's the bug in OpenSSL we were trying to fix. OpenSSL assumed (against the spec) that XSAVE=0 implies AVX=0, and didn't check whether AVX needed

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-18 Thread Andy Polyakov via RT
commit 6c3f6041172b78d5532c6bf3680d304e92ec2e66 Author: Sheng Yang sh...@linux.intel.com Date: Tue Jun 22 13:49:21 2010 +0800 KVM: x86: Enable AVX for guest Enable Intel(R) Advanced Vector Extension(AVX) for guest. The detection of AVX feature includes OSXSAVE bit

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-18 Thread Tomas Mraz via RT
On Fri, 2011-11-18 at 12:16 +0100, Andy Polyakov via RT wrote: commit 6c3f6041172b78d5532c6bf3680d304e92ec2e66 Author: Sheng Yang sh...@linux.intel.com Date: Tue Jun 22 13:49:21 2010 +0800 KVM: x86: Enable AVX for guest Enable Intel(R) Advanced Vector Extension(AVX) for

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-09 Thread Tomas Mraz via RT
On Tue, 2011-11-08 at 22:29 +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

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-09 Thread Paolo Bonzini via RT
On 11/08/2011 08:32 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

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-08 Thread Paolo Bonzini via RT
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

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-08 Thread Andy Polyakov via RT
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?

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-08 Thread Tomas Mraz
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

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-08 Thread Andy Polyakov via RT
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

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-07 Thread Paolo Bonzini via RT
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

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-07 Thread Paolo Bonzini
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

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-07 Thread Andy Polyakov via RT
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?

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-06 Thread Tomas Mraz via RT
On Sat, 2011-11-05 at 11:53 +0100, Andy Polyakov via RT wrote: x86cpuid.pl instead is completely broken: - the whole test is bypassed if XSAVE=1, which makes absolutely no sense. x86_64cpuid.pl is right in testing OSXSAVE No, the test is bypassed if XSAVE is 0, not 1. XSAVE being 0

Re: [openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-11-05 Thread Andy Polyakov via RT
Here is analysis by Paolo Bonzini: I compared crypto/x86_64cpuid.pl and crypto/x86cpuid.pl, and the code in the latter is wrong. From x86_64cpuid.pl: mov %edx,%r10d # %r9d:%r10d is copy of %ecx:%edx bt \$27,%r9d # check OSXSAVE bit

[openssl.org #2633] x86cpuid.pl incorrectly handles AVX when OSXSAVE not set

2011-10-31 Thread Tomas Mraz via RT
Here is analysis by Paolo Bonzini: I compared crypto/x86_64cpuid.pl and crypto/x86cpuid.pl, and the code in the latter is wrong. From x86_64cpuid.pl: mov %edx,%r10d # %r9d:%r10d is copy of %ecx:%edx bt \$27,%r9d # check OSXSAVE bit jnc