Re: Question on skip_emulated_instructions()

[Yoshiaki Tamura <tamura.yoshiaki@lab.ntt.co.jp>]

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.