All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: "Radim Krčmář" <rkrcmar@redhat.com>
Cc: Shuai Ruan <shuai.ruan@linux.intel.com>,
	kvm@vger.kernel.org, allen.m.kay@intel.com
Subject: Re: [PATCH] KVM: x86: Add three MSRs to the list of ignored MSRs
Date: Fri, 15 Apr 2016 12:48:01 +0200	[thread overview]
Message-ID: <5710C6E1.2020802@redhat.com> (raw)
In-Reply-To: <20160414162907.GB3350@potion.brq.redhat.com>



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

  reply	other threads:[~2016-04-15 10:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-14  9:28 [PATCH] KVM: x86: Add three MSRs to the list of ignored MSRs Shuai Ruan
2016-04-14 13:33 ` Radim Krčmář
2016-04-14 14:42   ` Paolo Bonzini
2016-04-14 16:29     ` Radim Krčmář
2016-04-15 10:48       ` Paolo Bonzini [this message]
2016-04-15 14:12         ` Radim Krčmář
     [not found]           ` <20160419092025.GA2651@shuai.ruan@linux.intel.com>
2016-04-19 16:10             ` Kay, Allen M

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5710C6E1.2020802@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=allen.m.kay@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=rkrcmar@redhat.com \
    --cc=shuai.ruan@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.