public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Shuai Ruan <shuai.ruan@linux.intel.com>
Cc: pbonzini@redhat.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: Thu, 14 Apr 2016 15:33:33 +0200	[thread overview]
Message-ID: <20160414133332.GA3350@potion.brq.redhat.com> (raw)
In-Reply-To: <1460626109-24343-1-git-send-email-shuai.ruan@linux.intel.com>

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? :)

  reply	other threads:[~2016-04-14 13:33 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ář [this message]
2016-04-14 14:42   ` Paolo Bonzini
2016-04-14 16:29     ` Radim Krčmář
2016-04-15 10:48       ` Paolo Bonzini
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=20160414133332.GA3350@potion.brq.redhat.com \
    --to=rkrcmar@redhat.com \
    --cc=allen.m.kay@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox