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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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

Well, as said - interrupt injection has to happen after exception
injection, and only if there was no exception. Hence it doesn't really
matter how deep in the call tree the exception injection sits.

> Long story short, should we approach this or are there other plans for
> this to be fixed?

I for one have no plans (or time) for this. You may want to see
whether Andrew has intentions here, but I guess he'll be quite
busy with other stuff for the foreseeable future.

> If we should approach this, any pointers / suggestions
> with regard to the current Xen code and most desirable design approach?

Well, first of all get a clear understanding of what violations there
are in current code. Then it may become more clear whether some
simple re-ordering might already do the job, or whether more
intrusive changes are going to be needed.

Jan



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