[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <49BFC64F.4080300@zytor.com>
Date: Tue, 17 Mar 2009 08:48:31 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Andi Kleen <andi@...stfloor.org>
CC: Jan Beulich <jbeulich@...ell.com>,
Arjan van de Ven <arjan@...radead.org>,
Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
Jeremy Fitzhardinge <jeremy@...p.org>,
the arch/x86 maintainers <x86@...nel.org>,
Xen-devel <xen-devel@...ts.xensource.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 10/24] xen: mask XSAVE from cpuid
Andi Kleen wrote:
>> The point is YOU DON'T KNOW. In particular, there might be new traps,
>> there might be new state, there might be new MSRs, there might be new
>> control bits... anything. Therefore, you cannot blindly pass the bit
>> on, even though XSAVE solves one part of the problem.
>
> I think what will happen if you don't expose it is that there will
> be always hypervisors which are behind and applications/OS will end up
> doing probing for opcodes instead of trusting CPUID bits.
>
> Probably not what you intended.
>
Probing for opcodes is even more harmful, though. But yes, we don't
have a good answer to this, and I believe we *can't* have a good answer
to this either -- we could architect the CPUID instruction a bit
differently, but that doesn't account for the various needs of
differnent hypervisors.
Hypervisor vendors can of course make this easier by making their CPUID
code pluggable so the end user can "hotfix" upgrade it without upgrading
the hypervisor (which makes a lot of them nervous.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists