From: Jes Sorensen
Injecting an NMI while GUEST_INTR_STATE_STI is set may fail,
which can cause an EXIT with invalid state, resulting in the
guest dieing.
Credit to Gleb for figuring out why it was failing and how to
fix it.
Signed-off-by: Jes Sorensen
Signed-off-by: Gleb Natapov
---
arch/x8
Am 26.08.2010 22:06, jes.soren...@redhat.com wrote:
> From: Jes Sorensen
>
> Injecting an NMI while GUEST_INTR_STATE_STI is set may fail,
> which can cause an EXIT with invalid state, resulting in the
> guest dieing.
Very interesting. Reality obviously doesn't bother about the statement
of the v
On 08/27/10 10:27, Jan Kiszka wrote:
> Am 26.08.2010 22:06, jes.soren...@redhat.com wrote:
>> From: Jes Sorensen
>>
>> Injecting an NMI while GUEST_INTR_STATE_STI is set may fail,
>> which can cause an EXIT with invalid state, resulting in the
>> guest dieing.
>
> Very interesting. Reality obviou
Jes Sorensen wrote:
> On 08/27/10 10:27, Jan Kiszka wrote:
>> Am 26.08.2010 22:06, jes.soren...@redhat.com wrote:
>>> From: Jes Sorensen
>>>
>>> Injecting an NMI while GUEST_INTR_STATE_STI is set may fail,
>>> which can cause an EXIT with invalid state, resulting in the
>>> guest dieing.
>> Very i
On 08/26/2010 11:06 PM, jes.soren...@redhat.com wrote:
From: Jes Sorensen
Injecting an NMI while GUEST_INTR_STATE_STI is set may fail,
which can cause an EXIT with invalid state, resulting in the
guest dieing.
Credit to Gleb for figuring out why it was failing and how to
fix it.
Signed-off-by
On 08/27/10 11:21, Avi Kivity wrote:
>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
>> index cf56462..8e95371 100644
>> --- a/arch/x86/kvm/vmx.c
>> +++ b/arch/x86/kvm/vmx.c
>> @@ -2888,6 +2888,8 @@ static void vmx_inject_nmi(struct kvm_vcpu *vcpu)
>> kvm_rip_write(vcpu, vmx->rmod
On 08/27/2010 11:27 AM, Jan Kiszka wrote:
Am 26.08.2010 22:06, jes.soren...@redhat.com wrote:
From: Jes Sorensen
Injecting an NMI while GUEST_INTR_STATE_STI is set may fail,
which can cause an EXIT with invalid state, resulting in the
guest dieing.
Very interesting. Reality obviously doesn't
On 08/27/2010 11:39 AM, Jan Kiszka wrote:
AMD does not differentiate between MOV-SS and STI interrupt shadows.
But AMD has its own NMI problems as it does not allow to trap after
IRET-from-NMI and requires magic dances which are partly broken in KVM.
I'm leaning towards NMI window emulation vi
On 08/27/2010 12:41 PM, Jes Sorensen wrote:
On 08/27/10 11:21, Avi Kivity wrote:
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index cf56462..8e95371 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2888,6 +2888,8 @@ static void vmx_inject_nmi(struct kvm_vcpu *vcpu)
On 08/27/10 11:47, Avi Kivity wrote:
> On 08/27/2010 12:41 PM, Jes Sorensen wrote:
>> Ok, try v2 that I just posted - and forgot to add v2 in the Subject line
>> to - sorry.
>>
>
> Well, in light of Jan's comment re sti; hlt being clobbered by this, we
> should think about requesting an interrupt
On 08/27/2010 12:56 PM, Jes Sorensen wrote:
Well, in light of Jan's comment re sti; hlt being clobbered by this, we
should think about requesting an interrupt window instead...
Ok, I heading onto thin ice here :)
How does one do that, just a call to
kvm_x86_ops->enable_nmi_window(vcpu)
On 08/27/10 11:59, Avi Kivity wrote:
> On 08/27/2010 12:56 PM, Jes Sorensen wrote:
>>
>>> Well, in light of Jan's comment re sti; hlt being clobbered by this, we
>>> should think about requesting an interrupt window instead...
>>>
>> Ok, I heading onto thin ice here :)
>>
>> How does one do that,
On Fri, Aug 27, 2010 at 10:27:37AM +0200, Jan Kiszka wrote:
> Am 26.08.2010 22:06, jes.soren...@redhat.com wrote:
> > From: Jes Sorensen
> >
> > Injecting an NMI while GUEST_INTR_STATE_STI is set may fail,
> > which can cause an EXIT with invalid state, resulting in the
> > guest dieing.
>
> Ver
Avi Kivity wrote:
> On 08/27/2010 11:27 AM, Jan Kiszka wrote:
>> Am 26.08.2010 22:06, jes.soren...@redhat.com wrote:
>>> From: Jes Sorensen
>>>
>>> Injecting an NMI while GUEST_INTR_STATE_STI is set may fail,
>>> which can cause an EXIT with invalid state, resulting in the
>>> guest dieing.
>> Ve
Avi Kivity wrote:
> On 08/27/2010 11:39 AM, Jan Kiszka wrote:
>> AMD does not differentiate between MOV-SS and STI interrupt shadows.
>>
>> But AMD has its own NMI problems as it does not allow to trap after
>> IRET-from-NMI and requires magic dances which are partly broken in KVM.
>> I'm leaning
Gleb Natapov wrote:
> On Fri, Aug 27, 2010 at 10:27:37AM +0200, Jan Kiszka wrote:
>> Am 26.08.2010 22:06, jes.soren...@redhat.com wrote:
>>> From: Jes Sorensen
>>>
>>> Injecting an NMI while GUEST_INTR_STATE_STI is set may fail,
>>> which can cause an EXIT with invalid state, resulting in the
>>>
On Fri, Aug 27, 2010 at 12:44:41PM +0300, Avi Kivity wrote:
> >Thinking about the implications: Independent of virtualization, this
> >means that no code code can in any way rely on the STI shadow if there
> >are NMIs present that could "consume" it. Because after return from
> >those NMIs, interru
Gleb Natapov wrote:
> On Fri, Aug 27, 2010 at 12:44:41PM +0300, Avi Kivity wrote:
>>> Thinking about the implications: Independent of virtualization, this
>>> means that no code code can in any way rely on the STI shadow if there
>>> are NMIs present that could "consume" it. Because after return fr
On Fri, Aug 27, 2010 at 01:23:06PM +0200, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Fri, Aug 27, 2010 at 12:44:41PM +0300, Avi Kivity wrote:
> >>> Thinking about the implications: Independent of virtualization, this
> >>> means that no code code can in any way rely on the STI shadow if there
>
On 08/27/2010 02:06 PM, Jan Kiszka wrote:
Wow. Maybe we should request an interrupt window instead when
blocked-by-STI is active instead of clearing it.
Then we are (almost) back in pre-NMI-window times when the guest happens
to spin with IRQs disabled.
No. We only request an interrupt w
On 08/27/2010 02:06 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 08/27/2010 11:39 AM, Jan Kiszka wrote:
AMD does not differentiate between MOV-SS and STI interrupt shadows.
But AMD has its own NMI problems as it does not allow to trap after
IRET-from-NMI and requires magic dances which are p
Avi Kivity wrote:
> On 08/27/2010 02:06 PM, Jan Kiszka wrote:
>>> Wow. Maybe we should request an interrupt window instead when
>>> blocked-by-STI is active instead of clearing it.
>>>
>> Then we are (almost) back in pre-NMI-window times when the guest happens
>> to spin with IRQs disabled.
>
>
Avi Kivity wrote:
> On 08/27/2010 02:06 PM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>>On 08/27/2010 11:39 AM, Jan Kiszka wrote:
AMD does not differentiate between MOV-SS and STI interrupt shadows.
But AMD has its own NMI problems as it does not allow to trap after
IRET-fro
On 08/27/2010 05:13 PM, Jan Kiszka wrote:
I forgot them already. What was that, exception during IRET?
Exception during IRET or any instruction under the interrupt shadow will
push the TF we set to step over this issue on the guest stack. We do not
intercept all the possible exceptions, so w
Avi Kivity wrote:
> On 08/27/2010 05:13 PM, Jan Kiszka wrote:
>>> I forgot them already. What was that, exception during IRET?
>> Exception during IRET or any instruction under the interrupt shadow will
>> push the TF we set to step over this issue on the guest stack. We do not
>> intercept all
On 08/27/2010 07:43 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 08/27/2010 05:13 PM, Jan Kiszka wrote:
I forgot them already. What was that, exception during IRET?
Exception during IRET or any instruction under the interrupt shadow will
push the TF we set to step over this issue on the gue
26 matches
Mail list logo
