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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan



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