From mboxrd@z Thu Jan 1 00:00:00 1970 From: Radim =?utf-8?B?S3LEjW3DocWZ?= Subject: Re: [PATCH] KVM: x86: Add three MSRs to the list of ignored MSRs Date: Fri, 15 Apr 2016 16:12:39 +0200 Message-ID: <20160415141238.GB18429@potion.brq.redhat.com> References: <1460626109-24343-1-git-send-email-shuai.ruan@linux.intel.com> <20160414133332.GA3350@potion.brq.redhat.com> <570FAC6F.10704@redhat.com> <20160414162907.GB3350@potion.brq.redhat.com> <5710C6E1.2020802@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Shuai Ruan , kvm@vger.kernel.org, allen.m.kay@intel.com To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:42417 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750914AbcDOOMn (ORCPT ); Fri, 15 Apr 2016 10:12:43 -0400 Content-Disposition: inline In-Reply-To: <5710C6E1.2020802@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 2016-04-15 12:48+0200, Paolo Bonzini: > On 14/04/2016 18:29, Radim Kr=C4=8Dm=C3=A1=C5=99 wrote: >> I don't see that as a compromise. igd would fail even if we fixed t= he >> host side, so we'll have problems regardless of what we do. >=20 > 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 a= n 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. >>=20 >> 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 gue= sts >> to adopt new v/f/m/s (the latter option is more reasonable), >=20 > Well, the Pentium was the last processor without MSRs. :) More code > would break if you set f=3D5 than if you return a bogus value for > MSR_PLATFORM_INFO. True. The loss becomes less clear with f=3D15 (kvm64 and Pentium 4) th= at "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 feedbac= k > 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.)