2016-04-14 17:28+0800, Shuai Ruan: > When passthrough the Intel GPU Device (igd) to windows guest, > the idg driver of the guest will read three MSRs: > > MSR_NHM_TURBO_RATIO_LIMIT > MSR_PLATFORM_INFO > MSR_PKG_POWER_LIMIT > > Windows guest os will crash as kvm will inject a #GP into the guest > if that tries to access unhandled MSRs, so add this three MSRS to > the list of ignored MSRs. It's not a list of ignored MSRs, it's a list of MSRs that are emulated by returning 0. I don't think that these MSRs return 0, so we should try harder: MSR_NHM_TURBO_RATIO_LIMIT: We probaly have to return the Maximum Ratio Limit (without turbo) and the MSR value also depends on the amount of cores the guest has per package. Writes are problematic, but maybe we can #GP if the value doesn't equal what we begin with. MSR_PKG_POWER_LIMIT: returning "1 << 63" (just the lock bit) might be acceptable. Writes could then be emulated by doing nothing. MSR_PLATFORM_INFO: Intel changes it from family to family and there is no obvious overlap or default. If we picked 0 (any other fixed value), then the guest would have to know that 0 doesn't mean that MSR_PLATFORM_INFO returned 0, but that KVM doesn't emulate this MSR and the value cannot be used. This is very similar to handling a #GP in the guest, but also has a disadvantage, because KVM cannot say that MSR_PLATFORM_INFO is 0. Simple emulation is not possible. The main bug in KVM is that it allows the guest to think that it runs on CPU that isn't emulated: any CPU that has MSR_PLATFORM_INFO shouldn't be exposed in KVM. Incorrect use of CPU also is a userspace problem, so KVM could just pass this MSR for emulation to userspace. (Passing to userspace won't directly fix your problem, though) The main bug in igd is that it always accesses these MSRs, even if the CPU doesn't have them, like when running on kvm64 CPU. igd needs to avoid accesses on kvm64 even if KVM changes, so what about catching the #GP in igd to fix this bug? :) -- 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
