Re: [Xen-devel] Interrupt issues with hvm_emulate_one_vm_event()

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 26/05/17 15:29, Jan Beulich wrote:
>>>> On 25.05.17 at 11:40, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> I've noticed that, with pages marked NX and vm_event emulation, we can
>> end up emulating an ud2, for which hvm_emulate_one() returns
>> X86EMUL_EXCEPTION in hvm_emulate_one_vm_event().
> Could you explain what would lead to emulation of UD2?
>
>> This, in turn, causes a hvm_inject_event() call in the context of
>> hvm_do_resume(), which can, if there's already a pending event there,
>> cause a 101 BSOD (timer-related, if I understand correctly) or loss of
>> input (mouse frozen, keyboard unresponsive).
>>
>> After much trial and error, I've been able to confirm this by leaving a
>> guest on for almost a full day with this change:
>>
>>      case X86EMUL_EXCEPTION:
>> -        hvm_inject_event(&ctx.ctxt.event);
>> +        if ( !hvm_event_pending(current) )
>> +            hvm_inject_event(&ctx.ctxt.event);
>>
>> and checking that there's been no BSOD or loss of input.
>>
>> However, just losing the event here, while fine to prove that this is
>> indeed the problem, is not OK. But I'm not sure what an elegant / robust
>> way of fixing this is.
> Much depends on what the other event is: If it's an interrupt, I'd
> assume there to be an ordering problem (interrupts shouldn't be
> injected when there is a pending exception, their delivery instead
> should be attempted on the first instruction of the exception
> handler [if interrupts remain on] or whenever interrupts get
> re-enabled).

I suspect it is an ordering issue, and something has processed and
interrupt before the emulation occurs as part of the vm_event reply happens.

The interrupt ordering spec indicates that external interrupts take
precedent over faults raised from executing an instruction, on the basis
that once the interrupt handler returns, the instruction will generate
the same fault again.  However, its not obvious how this is intended to
interact with interrupt windows and vmexits.  I expect we can get away
with ensuring that external interrupts are the final thing considered
for injection on the return-to-guest path.

It might be an idea to leave an assert in vmx_inject_event() that an
event is not already pending, but in the short term, this probably also
wants debugging by trying to identify what sequence of actions is
leading us to inject two events in this case (if indeed this is what is
happening).

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel