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 guest. > > > > The detection of AVX feature includes OSXSAVE bit testing. When > > OSXSAVE bit > > not set, even if AVX is supported, the AVX instruction would result > > in UD > > as > > well. So we're safe to expose AVX bits to guest directly. > > > > Signed-off-by: Sheng Yang <sh...@linux.intel.com> > > Signed-off-by: Avi Kivity <a...@redhat.com> > > This kind of sounds that it *was* masked and they decided to change > this. Question is why? BTW, why isn't FMA flag discussed at the same time? > > > Latest KVM still exposes AVX, and sets OSXSAVE to 0. This gives the > > guest > > kernel the option, which is based on XSAVE. > > This kind sounds that KVM maintains per-guest XCR0 in which case it's > indeed more than appropriate to stop masking AVX flag. I.e. is it > possible to conclude that what it was masked earlier and they stopped > masking it after making KVM XCR0-aware? If so, why do you find it > appropriate to not mask it without making Xen XCR0-aware? But the > question is more of rhetorical character... because we kind of agree > that latest version is acceptable, right?
I forwarded your other questions to our virtualization developers. However for the last question the answer is yes, the latest version is acceptable. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org