Re: [Xen-devel] another state machine issue?

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 20/04/18 13:33, Jan Beulich wrote:
>>>> 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.

Yes - we must not cache anything across a return-to-guest.  The guests
interrupt/exception handler is at liberty to rewrite the instruction stream.

~Andrew

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