On Thu, Apr 08, 2010 at 02:27:53PM +0900, Yoshiaki Tamura wrote: > >Currently we complete instructions for output operations and leave them > >incomplete for input operations. Deferring completion for output > >operations should work, except it may break the vmware backdoor port > >(see hw/vmport.c), which changes register state following an output > >instruction, and KVM_EXIT_TPR_ACCESS, where userspace reads the state > >following a write instruction. > > > >Do you really need to transfer the vcpu state before the instruction, or > >do you just need a consistent state? If the latter, then you can get > >away by posting a signal and re-entering the guest. kvm will complete > >the instruction and exit immediately, and you will have fully consistent > >state. > > The requirement is that the guest must always be able to replay at > least the instruction which triggered the synchronization on the > primary. From that point of view, I think I need to transfer the > vcpu state before the instruction. If I post a signal and let the > guest or emulator proceed, I'm not sure whether the guest on the > secondary can be replay as expected. Please point out if I were > misunderstanding. All you need is some consistent sate to restart VM from, no? So if you transfer VM state after instruction that caused IO is completed you can restart VM on secondary from that state in case primary fails. I guess my question is: Can you make synchronization point to be immediately after IO instruction instead of before? -- 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
