From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yoshiaki Tamura Subject: Re: Question on skip_emulated_instructions() Date: Thu, 08 Apr 2010 16:30:48 +0900 Message-ID: <4BBD8628.3060904@lab.ntt.co.jp> References: <4BBAB46B.9010405@lab.ntt.co.jp> <20100406100522.GW5235@redhat.com> <20100407154324.GF303@redhat.com> <4BBCC2C9.1040301@redhat.com> <4BBD6959.6080003@lab.ntt.co.jp> <20100408065620.GH303@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , kvm@vger.kernel.org, Marcelo Tosatti To: Gleb Natapov Return-path: Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]:64958 "EHLO tama50.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758402Ab0DHHbH (ORCPT ); Thu, 8 Apr 2010 03:31:07 -0400 In-Reply-To: <20100408065620.GH303@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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.