From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Xu <peterx@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: Fri, 26 Jun 2020 08:56:57 -0700 [thread overview]
Message-ID: <20200626155657.GC6583@linux.intel.com> (raw)
In-Reply-To: <df859fb0-a665-a82a-0cf1-8db95179cb74@redhat.com>
On Thu, Jun 25, 2020 at 08:44:16PM +0200, Paolo Bonzini wrote:
> On 25/06/20 18:25, Sean Christopherson wrote:
> > I get the "what" of the change, and even the "why" to some extent, but I
> > dislike the idea of supporting/encouraging blind reads/writes to MSRs.
> > Blind writes are just asking for problems, and suppressing warnings on reads
> > is almost guaranteed to be suppressing a KVM bug.
>
> Right, that's why this patch does not just suppress warnings: it adds a
> different return value to detect the case.
>
> > TSC_CTRL aside, if we insist on pointing a gun at our foot at some point,
> > this should be a dedicated flavor of MSR access, e.g. msr_data.kvm_initiated,
> > so that it at least requires intentionally loading the gun.
>
> With this patch, __kvm_get_msr does not know about ignore_msrs at all,
> that seems to be strictly an improvement; do you agree with that?
Not really? It's solving a problem that doesn't exist in the current code
base (assuming TSC_CTRL is fixed), and IMO solving it in an ugly fashion.
I would much prefer that, _if_ we want to support blind KVM-internal MSR
accesses, we end up with code like:
if (msr_info->kvm_internal) {
return 1;
} else if (!ignore_msrs) {
vcpu_debug_ratelimited(vcpu, "unhandled wrmsr: 0x%x data 0x%llx\n",
msr, data);
return 1;
} else {
if (report_ignored_msrs)
vcpu_unimpl(vcpu,
"ignored wrmsr: 0x%x data 0x%llx\n",
msr, data);
break;
}
But I'm still not convinced that there is a legimiate scenario for setting
kvm_internal=true.
> What would you think about adding warn_unused_result to __kvm_get_msr?
I guess I wouldn't object to it, but that seems like an orthogonal issue.
next prev parent reply other threads:[~2020-06-26 15:57 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 [this message]
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
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=20200626155657.GC6583@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.