From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bandan Das Subject: Re: [PATCH v2 0/2] kvm: x86: Emulate MSR_PLATFORM_INFO Date: Wed, 19 Jun 2013 13:50:45 -0400 Message-ID: References: <1370361738-4277-1-git-send-email-bsd@redhat.com> <20130605084213.GQ4725@redhat.com> <51C06914.1090904@redhat.com> <20130618151652.GA21032@redhat.com> <20130618154045.GD21032@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Cc: Paolo Bonzini , kvm@vger.kernel.org, Marcelo Tosatti , "Nakajima\, Jun" To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53352 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757212Ab3FSRu5 (ORCPT ); Wed, 19 Jun 2013 13:50:57 -0400 In-Reply-To: <20130618154045.GD21032@redhat.com> (Gleb Natapov's message of "Tue, 18 Jun 2013 18:40:45 +0300") Sender: kvm-owner@vger.kernel.org List-ID: Gleb Natapov writes: > On Tue, Jun 18, 2013 at 11:29:27AM -0400, Bandan Das wrote: >> Gleb Natapov writes: >> >> > 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. >> >> If support is the issue, can't we have a flag that disables this by >> default and users who want to take the plunge (and be responsible >> for the consequences) can enable it to read platform_info ? >> > We have it already :) ignore_msrs. If it is set unimplemented MSRs will > not inject #GP, but return zero value instead. Zero it as incorrect as > anything else in the case of migration. But does the intended purpose of ignore_msrs fit here ? Even if we return 0 after a migration, there's no guarantee that the application will give correct results based on the old value of the MSR it read. I agree with you on the potential problems but I think we are completely ignoring the "non-migration" use case. These users will probably benefit from a correct value of (virtual) msr_platform_info. And it appears, the easiest way to give both options to the user is using a new module_param, say ignore_platform_info. Scenarios : 1. ignore_platform_info = 0 (Default). Inject #GP if application tries to read this MSR. 2. ignore_platform_info = 1. User wants to read the calculated value, her environment doesn't require migration. 3. ignore_msrs = 1. If this is set, we always return 0 and application will hopefully resort to a workaround. Bandan > -- > Gleb. > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html