From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jim Mattson <jmattson@google.com>,
Xiaoyao Li <xiaoyao.li@intel.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
kvm list <kvm@vger.kernel.org>,
Eric Hankland <ehankland@google.com>,
Peter Shier <pshier@google.com>,
Krish Sadhukhan <krish.sadhukhan@oracle.com>
Subject: Re: [PATCH] kvm: x86: Add Intel PMU MSRs to msrs_to_save[]
Date: Fri, 27 Sep 2019 10:23:32 -0700 [thread overview]
Message-ID: <20190927172332.GF25513@linux.intel.com> (raw)
In-Reply-To: <7a12a208-4969-e3fe-4a42-b432b91599d8@redhat.com>
On Fri, Sep 27, 2019 at 07:19:14PM +0200, Paolo Bonzini wrote:
> On 27/09/19 19:14, Sean Christopherson wrote:
> >>
> >> Perhaps we can make all MSRs supported unconditionally if
> >> host_initiated. For unsupported performance counters it's easy to make
> >> them return 0, and allow setting them to 0, if host_initiated
> > I don't think we need to go that far. Allowing any ol' MSR access seems
> > like it would cause more problems than it would solve, e.g. userspace
> > could completely botch something and never know.
>
> Well, I didn't mean really _all_ MSRs, only those returned by
> KVM_GET_MSR_INDEX_LIST.
Ah, that makes way more sense :-)
> > For the perf MSRs, could we enumerate all arch perf MSRs that are supported
> > by hardware? That would also be the list of MSRs that host_initiated MSR
> > accesses can touch regardless of guest support.
>
> Yes, that is easy indeed. Any ideas about VMX?
Can you elaborate on the problem with VMX MSRs?
next prev parent reply other threads:[~2019-09-27 17:23 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 18:20 [PATCH] kvm: x86: Add Intel PMU MSRs to msrs_to_save[] Jim Mattson
2019-09-06 16:48 ` Jim Mattson
[not found] ` <8907173e-9f27-6769-09fc-0b82c22d6352@oracle.com>
2019-09-06 20:30 ` Jim Mattson
2019-09-06 20:43 ` Krish Sadhukhan
2019-09-06 21:08 ` Jim Mattson
2019-09-16 20:43 ` Jim Mattson
2019-09-17 12:39 ` Paolo Bonzini
2019-09-27 13:53 ` Vitaly Kuznetsov
2019-09-27 14:00 ` Paolo Bonzini
2019-09-27 14:40 ` Vitaly Kuznetsov
2019-09-27 15:19 ` Paolo Bonzini
2019-09-27 15:26 ` Sean Christopherson
2019-09-27 15:46 ` Vitaly Kuznetsov
2019-09-27 15:55 ` Jim Mattson
2019-09-27 15:59 ` Jim Mattson
2019-09-27 16:01 ` Paolo Bonzini
2019-09-27 15:58 ` Xiaoyao Li
2019-09-27 16:06 ` Paolo Bonzini
2019-09-27 16:10 ` Jim Mattson
2019-09-27 16:32 ` Paolo Bonzini
2019-09-27 17:14 ` Sean Christopherson
2019-09-27 17:19 ` Paolo Bonzini
2019-09-27 17:23 ` Sean Christopherson [this message]
2019-09-27 17:30 ` Jim Mattson
2019-09-27 17:35 ` Sean Christopherson
2019-09-27 19:03 ` Jim Mattson
2019-09-27 17:22 ` Jim Mattson
2019-09-27 17:34 ` Sean Christopherson
2019-09-27 17:26 ` Jim Mattson
2019-09-27 16:06 ` Jim Mattson
2019-09-27 17:36 ` Jim Mattson
2019-09-27 17:45 ` Sean Christopherson
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=20190927172332.GF25513@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=ehankland@google.com \
--cc=jmattson@google.com \
--cc=krish.sadhukhan@oracle.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=pshier@google.com \
--cc=vkuznets@redhat.com \
--cc=xiaoyao.li@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.