On Fri, 2011-11-18 at 12:16 +0100, Andy Polyakov via RT wrote:
> > 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?
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 [email protected]
Automated List Manager [email protected]
