Re: [Xen-devel] another state machine issue? (was: [PATCH] x86emul: adjust handling of AVX2 gathers)

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> Sent: 20 April 2018 13:34
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-devel <xen-
> devel@xxxxxxxxxxxxxxxxxxxx>
> Subject: another state machine issue? (was: [PATCH] x86emul: adjust
> handling of AVX2 gathers)
> 
> >>> On 20.04.18 at 11:25, <JBeulich@xxxxxxxx> wrote:
> > @@ -7692,12 +7693,23 @@ x86_emulate(
> >                                 ea.mem.off + (idx << state->sib_scale),
> >                                 (void *)mmvalp + i * op_bytes, op_bytes, 
> > ctxt);
> >                  if ( rc != X86EMUL_OKAY )
> > +                {
> > +                    /*
> > +                     * If we've made any progress and the access did not 
> > fault,
> > +                     * force a retry instead. This is for example 
> > necessary to
> > +                     * cope with the limited capacity of HVM's MMIO cache.
> > +                     */
> > +                    if ( rc != X86EMUL_EXCEPTION && done )
> > +                        rc = X86EMUL_RETRY;
> >                      break;
> > +                }
> >
> >  #ifdef __XEN__
> >                  if ( i + 1 < n && local_events_need_delivery() )
> >                      rc = X86EMUL_RETRY;
> >  #endif
> 
> I've just noticed that these two as well as any other current or future
> X86EMUL_RETRY returns (at least ones directly from the emulator) are
> in conflict with _hvm_emulate_one() having
> 
>     case X86EMUL_RETRY:
>         BUILD_BUG_ON(sizeof(vio->mmio_insn) < sizeof(hvmemul_ctxt-
> >insn_buf));
>         vio->mmio_insn_bytes = hvmemul_ctxt->insn_buf_bytes;
>         memcpy(vio->mmio_insn, hvmemul_ctxt->insn_buf, vio-
> >mmio_insn_bytes);
>         break;
> 
> when processing the result of x86_emulate(). I think we need to distinguish
> here whether we are going to return to guest context (in which case we
> need to discard all cached data, as done a few lines above) or whether
> we're going to sleep. When exiting to guest, the guest may take an interrupt
> before resuming the instruction we've been emulating, and if the interrupt
> handler incurs emulation, we'd wrongly use the cached insn. If I'm not
> mistaken, simply keying this off of hvm_vcpu_io_need_completion()'s result
> should do.
> 

Well, as we know, things may go badly wrong if hvm_vcpu_io_need_completion() is 
true and we don't re-emulate same instruction so this sounds plausible.

  Paul

> Jan
> 


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