Gleb Natapov wrote:
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?
To answer your question, it should be possible to implement.
The down side is that after going into KVM to make the guest state to
consistent, we need to go back to qemu to actually transfer the guest, and this
bounce would introduce another overhead if I'm understanding correctly.
And yes, all I need is some consistent state to resume VM from, which must be
able to continue I/O operations, like writing to disks and sending ack over the
network. If I can guarantee this, sending the VM state after completing output
is acceptable.
--
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
