All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bandan Das <bsd@redhat.com>
To: Peter Hornyack <peterhornyack@google.com>
Cc: kvm list <kvm@vger.kernel.org>, Gleb Natapov <gleb@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Joerg Roedel <joro@8bytes.org>
Subject: Re: [RFC PATCH 0/5] KVM: x86: exit to user space on unhandled MSR accesses
Date: Wed, 19 Aug 2015 14:43:09 -0700	[thread overview]
Message-ID: <jpg7foreyz6.fsf@linux.bootlegged.copy> (raw)
In-Reply-To: <1439923615-10600-1-git-send-email-peterhornyack@google.com> (Peter Hornyack's message of "Tue, 18 Aug 2015 11:46:50 -0700")

Peter Hornyack <peterhornyack@google.com> writes:

> There are numerous MSRs that kvm does not currently handle. On Intel
> platforms we have observed guest VMs accessing some of these MSRs (for
> example, MSR_PLATFORM_INFO) and behaving poorly (to the point of guest OS
> crashes) when they receive a GP fault because the MSR is not emulated. This
> patchset adds a new kvm exit path for unhandled MSR accesses that allows
> user space to emulate additional MSRs without having to implement them in
> kvm.

^^ So, I am trying to understand this motivation. A while back when 
a patch was posted to emulate MSR_PLATFORM_INFO, it was rejected.
Why ? Because it seemed impossible to emulate it correctly (most concerns were
related to migration iirc). Although I haven't reviewed all patches in this series
yet, what I understand from the above message is-"It's ok to emulate
MSR_PLATFORM_INFO *incorrectly* as long as we are doing it in the user space."

I understand the part where it makes sense to move stuff to userspace.
But if kvm isn't emulating certain msrs yet, either we should add support,
or they haven't been added because it's not possible to emulate them
correctly. The logic that it's probably ok to let userspace do the (incorrect)
emulation is something I don't understand. It seems like the next in line
is to let userspace emulate thier own version of unimplemented x86 instructions.


> The core of the patchset modifies the vmx handle_rdmsr and handle_wrmsr
> functions to exit to user space on MSR reads/writes that kvm can't handle
> itself. Then, on the return path into kvm we check for outstanding user
> space MSR completions and either complete the MSR access successfully or
> inject a GP fault as kvm would do by default. This new exit path must be
> enabled for the vm via the KVM_CAP_UNHANDLED_MSR_EXITS capability.
>
> In the future we plan to extend this functionality to allow user space to
> register the MSRs that it would like to handle itself, even if kvm already
> provides an implementation. In the long-term we will move the

I seriously hope we don't do this!

Bandan
> implementation of all non-performance-sensitive MSRs to user space,
> reducing the potential attack surface of kvm and allowing us to respond to
> bugs more quickly.
>
> This patchset has been tested with our non-qemu user space hypervisor on
> vmx platforms; svm support is not implemented.
>
> Peter Hornyack (5):
>   KVM: x86: refactor vmx rdmsr/wrmsr completion into new functions
>   KVM: add KVM_EXIT_MSR exit reason and capability.
>   KVM: x86: add msr_exits_supported to kvm_x86_ops
>   KVM: x86: enable unhandled MSR exits for vmx
>   KVM: x86: add trace events for unhandled MSR exits
>
>  Documentation/virtual/kvm/api.txt |  48 +++++++++++++++
>  arch/x86/include/asm/kvm_host.h   |   2 +
>  arch/x86/kvm/svm.c                |   6 ++
>  arch/x86/kvm/trace.h              |  28 +++++++++
>  arch/x86/kvm/vmx.c                | 126 ++++++++++++++++++++++++++++++++++----
>  arch/x86/kvm/x86.c                |  13 ++++
>  include/trace/events/kvm.h        |   2 +-
>  include/uapi/linux/kvm.h          |  14 +++++
>  8 files changed, 227 insertions(+), 12 deletions(-)

  parent reply	other threads:[~2015-08-19 21:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-18 18:46 [RFC PATCH 0/5] KVM: x86: exit to user space on unhandled MSR accesses Peter Hornyack
2015-08-18 18:46 ` [RFC PATCH 1/5] KVM: x86: refactor vmx rdmsr/wrmsr completion into new functions Peter Hornyack
2015-08-18 18:46 ` [RFC PATCH 2/5] KVM: add KVM_EXIT_MSR exit reason and capability Peter Hornyack
2015-12-18 21:25   ` Paolo Bonzini
2015-12-18 23:56     ` Peter Hornyack
2015-12-21 18:58     ` Peter Hornyack
2015-12-22  7:24       ` Pavel Fedin
2015-12-22 12:01         ` 'Roman Kagan'
2015-12-22 12:51           ` Pavel Fedin
2015-12-22 14:09             ` 'Roman Kagan'
2015-12-23  7:47               ` Pavel Fedin
2016-01-12  3:21         ` Peter Hornyack
2015-08-18 18:46 ` [RFC PATCH 3/5] KVM: x86: add msr_exits_supported to kvm_x86_ops Peter Hornyack
2015-08-24 23:15   ` Bandan Das
2015-08-18 18:46 ` [RFC PATCH 4/5] KVM: x86: enable unhandled MSR exits for vmx Peter Hornyack
2015-08-24 23:14   ` Bandan Das
2015-08-18 18:46 ` [RFC PATCH 5/5] KVM: x86: add trace events for unhandled MSR exits Peter Hornyack
2015-08-19 21:43 ` Bandan Das [this message]
2015-08-20 19:40   ` [RFC PATCH 0/5] KVM: x86: exit to user space on unhandled MSR accesses Peter Hornyack
2015-08-24 23:21     ` Bandan Das

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=jpg7foreyz6.fsf@linux.bootlegged.copy \
    --to=bsd@redhat.com \
    --cc=gleb@kernel.org \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterhornyack@google.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.