Re: [PATCH] KVM: x86: Add three MSRs to the list of ignored MSRs

["Radim Krčmář" <rkrcmar@redhat.com>]

2016-04-15 12:48+0200, Paolo Bonzini:
> 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.

I meant a fix that would make KVM behave according to the spec, which
would not help igd on kvm64 CPU model, because igd accesses MSRs that
don't exist, so #GP is the only response.

The patch does completely work around current igd issue, but we trade an
obvious #GP for an unknown error when the guest acts as if
MSR_PLATFORM_INFO was 0.

>> 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.

True.  The loss becomes less clear with f=15 (kvm64 and Pentium 4) that
"solves" the igd bug by not providing MSR_PLATFORM_INFO ...
Btw. do we emulate any feature of newer GenuineIntel/f/m/s?

>                     This is the compromise I was referring to.

Ah, thanks.  I only saw a complete disadvantage for KVM. :)

> 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.

That is great!  (CPUID-only feature detection would suit us more, but
f/m/s will at least have a chance to regain trust under KVM.)