>>> On 23.03.18 at 14:41, <paul.durr...@citrix.com> wrote: > Ah that's true. We will do the check based on the response state even if the > next IO is going to be dealt with internally. So, yes, the real question is > why the previous I/O was completed without apparently waiting for QEMU to > finish. > We should have sent the VGA PIO out to QEMU, resulting in > hvm_vcpu_io_need_completion() returning true in handle_pio() meaning that > vio->io_completion gets set to HVMIO_pio_completion. We should then return > true from handle_pio() resulting in RIP being advanced when we return to > guest, but we should not get back into the guest because hvm_do_resume() > should see the pending IO flag on one of the ioreq server vcpus and block on > the relevant event channel. > So somehow it appears the vcpu got back into guest and executed the next > instruction whilst there was pending I/O.
I've extended my debugging patch to check vio->io_req.state for being other STATE_IOREQ_NONE first thing in the VMEXIT handler as well as first and last thing in vmx_vmenter_helper(). If you have any other ideas where to place sanity checks, I'm all ears. If that doesn't help, I guess I'll have to pull out a bigger hammer and log recent ioreq-s handled (and perhaps individual steps thereof) to see if their sequence rings any bell. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel