[Xen-devel] Emulation and active (valid) interrupts

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 8/13/18 3:22 PM, Jan Beulich wrote:
>>>> On 13.08.18 at 13:55, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 8/9/18 11:35 AM, Jan Beulich wrote:
>>>>>> On 09.08.18 at 10:20, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>> On 8/9/18 10:54 AM, Jan Beulich wrote:
>>>>>>>> On 08.08.18 at 16:26, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>>>>>> 1. Is it possible to already have a valid interrupt written in
>>>>>> VM_ENTRY_INTR_INFO at EXIT_REASON_EPT_VIOLATION-time in
>>>>>> vmx_vmexit_handler()?
>>>>>
>>>>> You mean right after the exit? Where would that come from? I'm
>>>>> afraid I don't see the connection to your issue (or the call traces
>>>>> you've provided).
>>>>
>>>> I mean right before the exit
>>>
>>> Before? Iirc the CPU doesn't itself write VM_ENTRY_* fields,
>>> other than to clear them (presumably during VM exit processing).
>>
>> I've dumped the backtraces of all places that
>> __vmwrite(VM_ENTRY_INTR_INFO, ...), and it appears that the last place
>> that does that before a domain crash caused by invalid guest state is
>> vmx_idtv_reinject(), which in my Xen 4.7.5 sources is called in
>> vmx_vmexit_handler(), and regardless of exit_reason.
> 
> That's indeed right after the exit, but aiui no other interrupt / exception
> can legitimately be raised in that situation. In fact another exception
> ought to combine to #DF, unless it's a benign one that can be squashed.
> But just like for instructions and their boundaries, no unrelated interrupt
> can be recognized while delivering an exception/interrupt. The next
> possible checking point is the first insn of the respective handler.

It also seems to be closely related to a CLI in the area:

(XEN) [  217.984301] Xen call trace:
(XEN) [  217.984302]    [<ffff82d0802027fc>] vmx_vmexit_handler+0x68a/0x1bf7
(XEN) [  217.984304]    [<ffff82d080208aaa>]
vmx_asm_vmexit_handler+0xfa/0x260
(XEN) [  217.984305]
(XEN) [  217.984754] d2v0 32bit @ 0008:826c0e1b -> fa f6 83 54 1a 00 00
3f 74 13 b1 02 ff 15 a0 a0
(XEN) [  217.984757] Failed vm entry (exit reason 0x80000021) caused by
invalid guest state (0).
(XEN) [  217.984758] ************* VMCS Area **************

I believe the following patch prints out the instruction that has been
emulated (I hope it's not the one immediately after it):

diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 194d48e..f017120 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -1966,6 +1966,7 @@ int hvm_mem_access_emulate_one(enum emul_kind
kind, unsigned int trapnr,
         /* Intentional fall-through. */
     default:
         rc = hvm_emulate_one(&ctx);
+        hvm_dump_emulation_state(XENLOG_G_DEBUG, &ctx);
     }

     switch ( rc )

So first we've got that vmx_idtv_reinject() call writing to the VMCS,
then we emulate a CLI, then the failed vmentry. I can't tell if the CLI
ran first and then an interrupt popped up, or if an interrupt had
already been __vmwrit()ten and then CLI caused the invalid guest state.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel