Re: [Xen-devel] xc_hvm_inject_trap() races

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.11.16 at 10:37, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> The problem there is that vmx_idtv_reinject() is a corner case: it
> writes VM_ENTRY_INTR_INFO directly, and this can happen _before_ the
> guest exits with, let's say, an EPT vm_event.
> 
> In that case, the guest has exited, there's already an interrupt
> pending, and while the VCPU is paused waiting for the vm_event reply we
> request an injection that effectively obliterates the pending interrupt.
> 
> Going the singlestep way is satisfactory for us for most cases, but it
> still leaves the described corner case. The only fix proposal we could
> think of is to, instead of vmx_idtv_reinject() doing the work, simply
> set some flags, and have a later function do the actual work, in
> vmx_intr_assist() style.
> 
> I hope I've been able to make this clearer (and I haven't misunderstood
> something in the process :) ).

You did, thanks. Yet I continue to remain on my earlier position: It's
the non-architectural (injected) event which should get deferred,
not architectural ones (either the variant you describe above, or
any which hypervisor processing found necessary to deliver). The
single step case can be viewed as an exception here, albeit ideally
it also wouldn't need to be special cased.

Jan


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