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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

Jan



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