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 useless because the spec OTOH says that
> >>> you *can* ignore XSAVE (and anyway XSAVE means nothing: it says the
> >>> feature is available, but only OSXSAVE says it is actually unusable).
> >> I still fail to see how exactly did it fail for you. Once again, which
> >> flags does guest OS observe exactly? Is guest OS YMM-capable? Does
> >> latest x86cpuid.pl work for you or is it still problem?
> > No, it does not work as the cpuid on the guest OS observes cleared XSAVE
> > and set AVX bit.
>
> How does XSAVE end up being 0? Hypervisor masks it, right? By what
> means? Through a config file or is it explicitly programmed? What was
> the reasoning for masking it? In config file or code? Why same reasoning
> didn't apply to AVX [as FMA] bit? As implied, I'd argue that it's
> inappropriate to mask XSAVE but not AVX [and FMA].
>
> Either way, can you at least tell if it's controlled through config? Or
> in other words, it it possible to work around the problem by configuring
> your Xen? Context of the question is frozen FIPS code.
>
> > Which means that the AVX instructions will be used in
> > the SHA1 code which then fail with SIGILL.
> >
> > The OSXSAVE is also cleared so that means if the XSAVE test was just
> > dropped it would work.
>
> So would jumping to "clear_avx" if XSAVE is 0, right? Anyway, see
> http://cvs.openssl.org/chngview?cn=21675.
>
Forwarding reply from our virtualization developers:
RHEL5 Xen's cpuid masking is hardcoded in the HV (so no nice config to
quick
modify). We've recently changed it to be a whitelist, where the
structure is
heavily influenced by KVM. Looking at KVM's whitelist patch history I
found
this commit, which I believe describes this issue best.
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]>
Latest KVM still exposes AVX, and sets OSXSAVE to 0. This gives the
guest
kernel the option, which is based on XSAVE. Now, RHEL Xen masks XSAVE,
so the
option isn't really there for its guest kernels, but I don't believe
that means
we can't rely on the same protocol.
--
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]
