Re: [PATCH v2 0/2] kvm: x86: Emulate MSR_PLATFORM_INFO

[Gleb Natapov <gleb@redhat.com>]

On Tue, Jun 18, 2013 at 10:59:37AM -0700, Nakajima, Jun wrote:
> On Tue, Jun 18, 2013 at 8:16 AM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Tue, Jun 18, 2013 at 04:05:08PM +0200, Paolo Bonzini wrote:
> >> Il 05/06/2013 10:42, Gleb Natapov ha scritto:
> >> >> > These patches add an emulated MSR_PLATFORM_INFO that kvm guests
> >> >> > can read as described in section 14.3.2.4 of the Intel SDM.
> >> >> > The relevant changes and details are in [2/2]; [1/2] makes vendor_intel
> >> >> > generic. There are atleat two known applications that fail to run because
> >> >> > of this MSR missing - Sandra and vTune.
> >> > So I really want Intel opinion on this. Right now it is impossible to
> >> > implement the MSR correctly in the face of migration (may be with tsc
> >> > scaling it will be possible) and while it is unimplemented if application
> >> > tries to use it it fails, but if we will implement it application will
> >> > just produce incorrect result without any means for user to detect it.
> >>
> >> Jun, ping?  (Perhaps Gleb you want to ask a more specific question though).
> >>
> >> I don't think this is much different from any other RDTSC usage in
> >> applications (they will typically do their calibration manually, and do
> >> it just once).  I'm applying it to queue.
> >>
> > And we do not support application that uses RDTSC directly! If we could
> > catch those it would be good from support point of view, so the way
> > MSR_PLATFORM_INFO behaves now it better then proposed alternative.
> 
> Is it reasonable or possible to expose MSR_PLATFORM_INFO more and then
> disable migration? Some use cases (like VTune) don't need live
> migration.
> 
VTune is just an application and IT wants to run developers machine on a
"cloud" and developers want to use the tool. Also, since MSR_PLATFORM_INFO
is non architectural MSR there is no way to know when it is exposed;
there is no cpuid bit that management sets to "expose" it to a guest. Of
course we can create some other mechanism for that, but it looks like
a lot of ad-hoc work for a little gain.

The simplest thing to do is to return zero for the MSR and do not
#GP. What VTune will do in this case? The value is obviously incorrect,
so my hope is that it will disable the feature that depends on it instead
of blindly use it and crash with divide by zero later on.
 
--
			Gleb.