Gleb Natapov <gleb@xxxxxxxxxx> writes: > On Tue, Jun 18, 2013 at 11:29:27AM -0400, Bandan Das wrote: >> Gleb Natapov <gleb@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
