Re: Question on skip_emulated_instructions()

[Avi Kivity <avi@redhat.com>]

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.

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.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.