| commit | f86368493ec038218e8663cc1b6e5393cd8e008a | |
| author | Avi Kivity <avi@redhat.com> | |
| Thu, 3 Feb 2011 13:07:07 +0000 (3 15:07 +0200) | ||
| committer | Marcelo Tosatti <mtosatti@redhat.com> | |
| Thu, 17 Mar 2011 16:08:30 +0000 (17 13:08 -0300) | ||
| tree | d4108bd01616b4cd511a314ea3b5dfc8ba50bd23 | treesnapshot (tar.gz zip) |
| parent | 217ece6129f2d3b4fdd18d9e79be9e43d8d14a42 | commitdiff |
KVM: Fix race between nmi injection and enabling nmi window
The interrupt injection logic looks something like
if an nmi is pending, and nmi injection allowed
inject nmi
if an nmi is pending
request exit on nmi window
the problem is that "nmi is pending" can be set asynchronously by
the PIT; if it happens to fire between the two if statements, we
will request an nmi window even though nmi injection is allowed. On
SVM, this has disasterous results, since it causes eflags.TF to be
set in random guest code.
The fix is simple; make nmi_pending synchronous using the standard
vcpu->requests mechanism; this ensures the code above is completely
synchronous wrt nmi_pending.
Signed-off-by: Avi Kivity <avi@redhat.com>
The interrupt injection logic looks something like
if an nmi is pending, and nmi injection allowed
inject nmi
if an nmi is pending
request exit on nmi window
the problem is that "nmi is pending" can be set asynchronously by
the PIT; if it happens to fire between the two if statements, we
will request an nmi window even though nmi injection is allowed. On
SVM, this has disasterous results, since it causes eflags.TF to be
set in random guest code.
The fix is simple; make nmi_pending synchronous using the standard
vcpu->requests mechanism; this ensures the code above is completely
synchronous wrt nmi_pending.
Signed-off-by: Avi Kivity <avi@redhat.com>
| arch/x86/kvm/x86.c | diffblobblamehistory | |
| include/linux/kvm_host.h | diffblobblamehistory |