> commit 6c3f6041172b78d5532c6bf3680d304e92ec2e66 > Author: Sheng Yang <[email protected]> > 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 <[email protected]> > Signed-off-by: Avi Kivity <[email protected]>
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? ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
