From: Marcelo Tosatti <mtosatti@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, Jan Kiszka <jan.kiszka@siemens.com>,
Joerg Roedel <joerg.roedel@amd.com>
Subject: Re: [PATCH 2/2] KVM: SVM: check for progress after IRET interception
Date: Tue, 8 Feb 2011 11:49:23 -0200 [thread overview]
Message-ID: <20110208134923.GA4412@amt.cnet> (raw)
In-Reply-To: <4D4AC4B5.7060009@redhat.com>
On Thu, Feb 03, 2011 at 05:07:33PM +0200, Avi Kivity wrote:
> On 02/03/2011 05:02 PM, Avi Kivity wrote:
> >When we enable an NMI window, we ask for an IRET intercept, since
> >the IRET re-enables NMIs. However, the IRET intercept happens before
> >the instruction executes, while the NMI window architecturally opens
> >afterwards.
> >
> >To compensate for this mismatch, we only open the NMI window in the
> >following exit, assuming that the IRET has by then executed; however,
> >this assumption is not always correct; we may exit due to a host interrupt
> >or page fault, without having executed the instruction.
> >
> >Fix by checking for forward progress by recording and comparing the IRET's
> >rip. This is somewhat of a hack, since an unchaging rip does not mean that
> >no forward progress has been made, but is the simplest fix for now.
> >
Looks good.
> So what would be a better fix? We could unconditionally single step
> on iret_interception() which would fix the problem at the cost of
> making NMIs less efficient (three exits instead of two). We could
> emulate the IRET (doubling kvm's code and likely slower, and
> certainly buggier, than the first option). Alternatively, can
> anyone think of a reliable way to make sure forward progress has
> been made?
Is there other negative impact of the RIP hack than NMI being delayed?
next prev parent reply other threads:[~2011-02-08 14:01 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-03 15:02 [PATCH 0/2] SVM NMI fixes Avi Kivity
2011-02-03 15:02 ` [PATCH 1/2] KVM: Fix race between nmi injection and enabling nmi window Avi Kivity
2011-02-03 15:11 ` Jan Kiszka
2011-02-03 15:15 ` Avi Kivity
2011-02-03 15:02 ` [PATCH 2/2] KVM: SVM: check for progress after IRET interception Avi Kivity
2011-02-03 15:07 ` Avi Kivity
2011-02-03 15:21 ` Jan Kiszka
2011-02-03 15:30 ` Avi Kivity
2011-02-03 15:55 ` Jan Kiszka
2011-02-03 15:58 ` Avi Kivity
2011-02-03 16:14 ` Jan Kiszka
2011-02-03 16:20 ` Avi Kivity
2011-02-03 16:30 ` Jan Kiszka
2011-02-08 13:49 ` Marcelo Tosatti [this message]
2011-02-08 14:05 ` Avi Kivity
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=20110208134923.GA4412@amt.cnet \
--to=mtosatti@redhat.com \
--cc=avi@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
/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.