From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Peter Xu <peterx@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
Vitaly Kuznetsov <vkuznets@redhat.com>
Subject: Re: [PATCH 1/2] KVM: X86: Move ignore_msrs handling upper the stack
Date: Thu, 9 Jul 2020 12:24:40 -0700 [thread overview]
Message-ID: <20200709192440.GD24919@linux.intel.com> (raw)
In-Reply-To: <20200709182220.GG199122@xz-x1>
On Thu, Jul 09, 2020 at 02:22:20PM -0400, Peter Xu wrote:
> On Tue, Jun 30, 2020 at 08:47:26AM -0700, Sean Christopherson wrote:
> > On Sat, Jun 27, 2020 at 04:24:34PM +0200, Paolo Bonzini wrote:
> > > On 26/06/20 20:18, Sean Christopherson wrote:
> > > >> Btw, would it be more staightforward to check "vcpu->arch.arch_capabilities &
> > > >> ARCH_CAP_TSX_CTRL_MSR" rather than "*ebx | (F(RTM) | F(HLE))" even if we want
> > > >> to have such a fix?
> > > > Not really, That ends up duplicating the check in vmx_get_msr(). From an
> > > > emulation perspective, this really is a "guest" access to the MSR, in the
> > > > sense that it the virtual CPU is in the guest domain, i.e. not a god-like
> > > > entity that gets to break the rules of emulation.
> > >
> > > But if you wrote a guest that wants to read MSR_IA32_TSX_CTRL, there are
> > > two choices:
> > >
> > > 1) check ARCH_CAPABILITIES first
> > >
> > > 2) blindly access it and default to 0.
> > >
> > > Both are fine, because we know MSR_IA32_TSX_CTRL has no
> > > reserved/must-be-one bits. Calling __kvm_get_msr and checking for an
> > > invalid MSR through the return value is not breaking the rules of
> > > emulation, it is "faking" a #GP handler.
> >
> > "guest" was the wrong choice of word. My point was that, IMO, emulation
> > should never set host_initiated=true.
> >
> > To me, accessing MSRs with host_initiated is the equivalent of loading a
> > ucode patch, i.e. it's super duper special stuff that deliberately turns
> > off all safeguards and can change the fundamental behavior of the (virtual)
> > CPU.
>
> This seems to be an orthogonal change against what this series tried to do. We
> use host_initiated=true in current code, and this series won't change that fact
> either. As I mentioned in the other thread, at least the rdmsr warning is
> ambiguous when it's not initiated from the guest if without this patchset, and
> this series could address that.
My argument is that using host_initiated=true is wrong.
> > > So I think Peter's patch is fine, but (possibly on top as a third patch)
> > > __must_check should be added to MSR getters and setters. Also one
> > > possibility is to return -EINVAL for invalid MSRs.
>
> Yeah I can add another patch for that. Also if to repost, I tend to also
> introduce KVM_MSR_RET_[OK|ERROR] too, which seems to be cleaner when we had
> KVM_MSR_RET_INVALID.
>
> Any objections before I repost?
Heh, or perhaps "Any objections that haven't been overruled before I repost?" :-D
next prev parent reply other threads:[~2020-07-09 19:24 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-22 22:04 [PATCH 0/2] KVM: X86: A few fixes around ignore_msrs Peter Xu
2020-06-22 22:04 ` [PATCH 1/2] KVM: X86: Move ignore_msrs handling upper the stack Peter Xu
2020-06-25 6:15 ` Sean Christopherson
2020-06-25 8:09 ` Paolo Bonzini
2020-06-25 16:25 ` Sean Christopherson
2020-06-25 17:45 ` Sean Christopherson
2020-06-25 18:44 ` Paolo Bonzini
2020-06-26 15:56 ` Sean Christopherson
2020-06-26 17:37 ` Peter Xu
2020-06-26 17:46 ` Sean Christopherson
2020-06-26 18:07 ` Peter Xu
2020-06-26 18:18 ` Sean Christopherson
2020-06-26 19:11 ` Peter Xu
2020-06-27 14:24 ` Paolo Bonzini
2020-06-30 15:47 ` Sean Christopherson
2020-07-09 18:22 ` Peter Xu
2020-07-09 18:24 ` Paolo Bonzini
2020-07-09 18:34 ` Peter Xu
2020-07-09 19:24 ` Sean Christopherson [this message]
2020-07-09 21:09 ` Peter Xu
2020-07-09 21:26 ` Sean Christopherson
2020-07-09 21:50 ` Peter Xu
2020-07-09 22:11 ` Paolo Bonzini
2020-07-10 4:58 ` Sean Christopherson
2020-06-22 22:04 ` [PATCH 2/2] KVM: X86: Do the same ignore_msrs check for feature msrs Peter Xu
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=20200709192440.GD24919@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=vkuznets@redhat.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.