Prev: Another BUG_ON() in blkio controller
Next: KVM: SVM: Sync cr0 and cr3 to kvm state before nested handling
From: Alexander Graf on 23 Apr 2010 10:50

On 23.04.2010, at 16:31, Joerg Roedel wrote:

> On Fri, Apr 23, 2010 at 04:24:54PM +0200, Alexander Graf wrote:
>>
>> On 23.04.2010, at 16:22, Joerg Roedel wrote:
>
>>> No, nested_svm_nmi runs in atomic context where we can't emulate a
>>> vmexit. We set exit_required and emulate the vmexit later.
>>
>> So we modify the L2 rflags and then trigger a #vmexit, leaving the l2
>> state broken?
>
> No, the rflags are changed in enable_nmi_window which isn't called when
> we run nested and the nested hypervisor intercepts nmi. So it only runs
> in the !nested case where it can't corrupt L2 state.

Last time I checked the code enable_nmi_window was the function triggering the #vmexit, so it should run in that exact scenario. If what you say is true, where do we #vmexit instead then?


Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Joerg Roedel on 23 Apr 2010 11:00
On Fri, Apr 23, 2010 at 04:42:52PM +0200, Alexander Graf wrote:
>
> On 23.04.2010, at 16:31, Joerg Roedel wrote:
>
> > On Fri, Apr 23, 2010 at 04:24:54PM +0200, Alexander Graf wrote:
> >>
> >> On 23.04.2010, at 16:22, Joerg Roedel wrote:
> >
> >>> No, nested_svm_nmi runs in atomic context where we can't emulate a
> >>> vmexit. We set exit_required and emulate the vmexit later.
> >>
> >> So we modify the L2 rflags and then trigger a #vmexit, leaving the l2
> >> state broken?
> >
> > No, the rflags are changed in enable_nmi_window which isn't called when
> > we run nested and the nested hypervisor intercepts nmi. So it only runs
> > in the !nested case where it can't corrupt L2 state.
>
> Last time I checked the code enable_nmi_window was the function
> triggering the #vmexit,

Yes, thats the bug which this patch fixes :-)

>so it should run in that exact scenario. If what you say is true, where
>do we #vmexit instead then?

After setting exit_required we run into svm.c:svm_vcpu_run. There the
exit_required flag is checked and if set, the function immediatly
returns without doing a vmrun. A few cycles later we run into
svm.c:handle_exit() where at the beginning exit_required is checked, and
if set the vmexit is emulated.

Joerg


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Alexander Graf on 23 Apr 2010 15:20

On 23.04.2010, at 16:51, Joerg Roedel wrote:

> On Fri, Apr 23, 2010 at 04:42:52PM +0200, Alexander Graf wrote:
>>
>> On 23.04.2010, at 16:31, Joerg Roedel wrote:
>>
>>> On Fri, Apr 23, 2010 at 04:24:54PM +0200, Alexander Graf wrote:
>>>>
>>>> On 23.04.2010, at 16:22, Joerg Roedel wrote:
>>>
>>>>> No, nested_svm_nmi runs in atomic context where we can't emulate a
>>>>> vmexit. We set exit_required and emulate the vmexit later.
>>>>
>>>> So we modify the L2 rflags and then trigger a #vmexit, leaving the l2
>>>> state broken?
>>>
>>> No, the rflags are changed in enable_nmi_window which isn't called when
>>> we run nested and the nested hypervisor intercepts nmi. So it only runs
>>> in the !nested case where it can't corrupt L2 state.
>>
>> Last time I checked the code enable_nmi_window was the function
>> triggering the #vmexit,
>
> Yes, thats the bug which this patch fixes :-)
>
>> so it should run in that exact scenario. If what you say is true, where
>> do we #vmexit instead then?
>
> After setting exit_required we run into svm.c:svm_vcpu_run. There the
> exit_required flag is checked and if set, the function immediatly
> returns without doing a vmrun. A few cycles later we run into
> svm.c:handle_exit() where at the beginning exit_required is checked, and
> if set the vmexit is emulated.

Oh well, I guess I have to trust you on this one :)


Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  | 
Pages: 1 2
Prev: Another BUG_ON() in blkio controller
Next: KVM: SVM: Sync cr0 and cr3 to kvm state before nested handling