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

Re: [Xen-devel] [RFC Patch v4 6/9] don't zero out ioreq page and handle the pended I/O after resuming



>>> On 22.09.14 at 07:59, <wency@xxxxxxxxxxxxxx> wrote:
> I check ioreq->state after suspending the guest, and it can be
> STATE_IOREQ_NONE, STATE_IOREQ_READY or STATE_IORESP_READY.
> 1. If it is STATE_IOREQ_NONE, nothing need to be done.
> 2. If it is STATE_IOREQ_RESP_READY, we will get the response
>    in hvm_wait_for_io() before resuming.
> 3. If it is STATE_IOREQ_READY, we need to kick the event channel,
>    and qemu can handle the request.

This is contrary to what you wrote earlier in a reply to David Vrabel
asking "Under what conditions can there be pending I/O?  A domain
suspend should not complete until any I/O accesses are complete":

"IIRC, I print ioreq.state after suspending vm, and ioreq.state can be
STATE_IOREQ_NONE, STATE_IOREQ_READY or STATE_IORESP_READY. If the
state is STATE_IOREQ_READY, we should kick vcpu event channel on resume
after migration.

But I test it again today, the state is always STATE_IOREQ_NONE...

If the state is always STATE_IOREQ_NONE, no need to touch hypervisor/Qemu
to handle pending I/O req(state is STATE_IOREQ_READY)."

and will hence at least need clarification.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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