From: Joerg Roedel <joro@8bytes.org>
To: Bandan Das <bsd@redhat.com>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
kvm@vger.kernel.org, "Dirk Müller" <dmueller@suse.com>
Subject: Re: [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS
Date: Mon, 5 Oct 2015 11:50:22 +0200 [thread overview]
Message-ID: <20151005095022.GX3036@8bytes.org> (raw)
In-Reply-To: <jpgbncixlts.fsf@linux.bootlegged.copy>
On Thu, Oct 01, 2015 at 06:31:27PM -0400, Bandan Das wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
>
> > On 01/10/2015 13:43, Dirk Müller wrote:
> >> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> >> index 94b7d15..0a42859 100644
> >> --- a/arch/x86/kvm/svm.c
> >> +++ b/arch/x86/kvm/svm.c
> >> @@ -514,7 +514,7 @@ static void skip_emulated_instruction(struct kvm_vcpu *vcpu)
> >> struct vcpu_svm *svm = to_svm(vcpu);
> >>
> >> if (svm->vmcb->control.next_rip != 0) {
> >> - WARN_ON(!static_cpu_has(X86_FEATURE_NRIPS));
> >> + WARN_ON_ONCE(!static_cpu_has(X86_FEATURE_NRIPS));
> >> svm->next_rip = svm->vmcb->control.next_rip;
> >> }
> >>
> >
> > Bandan, what was the reason for warning here?
>
> I added the warning so that we catch if the next_rip field is being written
> to (even if the feature isn't supported) by a buggy L1 hypervisor.
Even if the L1 hypervisor writes to the next_rip field in the VMCB, we
would never see it in this code path, as we access the shadow VMCB in
this statement.
We don't even care if the L1 hypervisor writes to its next_rip field
because we only write to this field on an emulatated VMEXIT and never
read it back.
So what's the point in adding a guest-triggerable warning at all?
Joerg
next prev parent reply other threads:[~2015-10-05 9:50 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-01 11:43 [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS Dirk Müller
2015-10-01 12:25 ` Paolo Bonzini
2015-10-01 12:45 ` Dirk Müller
2015-10-01 12:31 ` Paolo Bonzini
2015-10-01 22:31 ` Bandan Das
2015-10-02 6:43 ` Dirk Müller
2015-10-05 1:15 ` Bandan Das
2015-10-05 9:50 ` Joerg Roedel [this message]
2015-10-05 16:54 ` Bandan Das
2015-10-05 17:15 ` Joerg Roedel
2015-10-05 17:42 ` Bandan Das
2015-10-06 10:23 ` Joerg Roedel
2015-10-06 18:02 ` Bandan Das
2015-10-05 20:12 ` Dirk Müller
2015-10-05 22:00 ` Bandan Das
2015-10-06 10:28 ` Joerg Roedel
2015-10-06 17:59 ` Bandan Das
2015-10-07 11:03 ` Joerg Roedel
2015-10-07 12:47 ` [PATCH] kvm: svm: Only propagate next_rip when guest supports it Joerg Roedel
2015-10-07 12:57 ` kbuild test robot
2015-10-07 15:48 ` Bandan Das
2015-10-07 16:14 ` Joerg Roedel
2015-10-07 17:03 ` Dirk Müller
2015-10-07 14:58 ` [PATCH] Use WARN_ON_ONCE for missing X86_FEATURE_NRIPS Bandan Das
2015-10-07 15:24 ` Joerg Roedel
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=20151005095022.GX3036@8bytes.org \
--to=joro@8bytes.org \
--cc=bsd@redhat.com \
--cc=dmueller@suse.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).