[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] possible I/O emulation state machine issue



>>> On 23.03.18 at 14:41, <Paul.Durrant@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.