On Thu, Apr 08, 2010 at 02:27:53PM +0900, Yoshiaki Tamura wrote: > Avi Kivity wrote: > >On 04/07/2010 08:21 PM, Yoshiaki Tamura wrote: > >> > >>The problem here is that, I needed to transfer the VM state which is > >>just *before* the output to the devices. Otherwise, the VM state has > >>already been proceeded, and after failover, some I/O didn't work as I > >>expected. > >>I tracked down this issue, and figured out rip was already proceeded > >>in KVM, > >>and transferring this VCPU state was meaningless. > >> > >>I'm planning to post the patch set of Kemari soon, but I would like to > >>solve > >>this rip issue before that. If there is no drawback, I'm happy to work > >>and post a patch. > > > >vcpu state is undefined when an mmio operation is pending, > >Documentation/kvm/api.txt says the following: > > > >>NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI, the corresponding > >>operations are complete (and guest state is consistent) only after > >>userspace > >>has re-entered the kernel with KVM_RUN. The kernel side will first finish > >>incomplete operations and then check for pending signals. Userspace > >>can re-enter the guest with an unmasked signal pending to complete > >>pending operations. > > Thanks for the information. > > So the point is the vcpu state that can been observed from qemu upon > KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI should not be used > because it's not complete/consistent? > Definitely. VCPU is in the middle of an instruction execution, so the state is undefined. One instruction may generate more then one IO exit during its execution BTW. -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
