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?
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.
--
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
