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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

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 - so a scenario where VM_ENTRY_INTR_INFO
has been written into and then ept_handle_violation() gets called - in
which case it's too late to block interrupts in vmx_intr_assist() since
one is already pending (somehow) when we get to hvm_do_resume().

The call traces I've provided do not indeed illustrate this case.
They've been posted as proof of what can (and did happen) with emulation
and interrupts (I did not have such specific information last time we've
discussed this).

> I also can't help but thinking that we've had a similar discussion
> before, with the (iirc) clear outcome that injection of the various
> kinds of events needs to be re-arranged to strictly follow
> architectural definitions. That is, for example, no interrupt may
> be injected before _all_ exception injection sources for the
> current insn have been dealt with. That's because real hardware
> also only ever checks for interrupts at instruction boundaries,
> not in the middle of processing an instruction.

We did discuss that, and that's what I've also understood the conclusion
to be. However there's no clear action plan for achieving that at this
time (that I am aware of), and since that's sensitive and somewhat
complex code I thought it would be nice to at least discuss general
guidelines of how to go about this.

It hasn't been a priority so far because in the past we've only seen
this when our agent injected an UD (which gets emulated with upstream
Xen, but is re-executed with the help of the Monitor Trap Flag in
XenServer). We could do this because that can only happen for execute
faults (on pages marked rw-), and for those faults we don't emulate but
run the instruction on hardware.

Also, in the UD case, we had more control, as we were explicitly calling
hvm_inject_event(&ctx.ctxt.event); in hvm_emulate_one_vm_event(). With
this backtrace, however, hvm_inject_page_fault() gets called further
down the line by hvm_emulate_one() and we can't control when or if that
happens.

Long story short, should we approach this or are there other plans for
this to be fixed? If we should approach this, any pointers / suggestions
with regard to the current Xen code and most desirable design approach?


Thanks,
Razvan

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