On 14/04/2016 18:29, Radim Krčmář wrote: > I don't see that as a compromise. igd would fail even if we fixed the > host side, so we'll have problems regardless of what we do. Would it? I suppose that Shuai tested his patch. > We have a bug, because certain v/f/m/s implies some features (MSRs, > constant_tsc, ...) and those aren't emulated. > > I do agree that we don't want to fix the bug, either by whitelisting and > emulating features that makes little sense in virt or by forcing guests > to adopt new v/f/m/s (the latter option is more reasonable), Well, the Pentium was the last processor without MSRs. :) More code would break if you set f=5 than if you return a bogus value for MSR_PLATFORM_INFO. This is the compromise I was referring to. The only solution is to bug Intel to add CPUID bits even for non-architectural features. Then _if_ the CPUID bit is there you use f/m/s to find the details of the feature. Intel likes to get feedback from us and we did provide such feedback. The problem is that the 2-3 years that pass between giving feedback and getting our hands on the silicon. Paolo > because > rare occurences of the bug take *much* less work to fix on the guest > side. (The only part I'm concerned about is that we don't have a good > excuse for some guest errors ...) -- 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
