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 17:30:08 +0900 Message-ID: <4BBD9410.1090208@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> <4BBD8628.3060904@lab.ntt.co.jp> <4BBD87A2.5000909@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Gleb Natapov , kvm@vger.kernel.org, Marcelo Tosatti To: Avi Kivity Return-path: Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]:33041 "EHLO tama50.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751342Ab0DHIaY (ORCPT ); Thu, 8 Apr 2010 04:30:24 -0400 In-Reply-To: <4BBD87A2.5000909@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > On 04/08/2010 10:30 AM, Yoshiaki Tamura wrote: >> >> To answer your question, it should be possible to implement. >> The down side is that after going into KVM to make the guest state t= o >> consistent, we need to go back to qemu to actually transfer the gues= t, >> and this bounce would introduce another overhead if I'm understandin= g >> correctly. > > Yes. It should be around a microsecond or so, given you will issue I/= O > after this I don't think this will affect performance. That is a good news. >> And yes, all I need is some consistent state to resume VM from, whic= h >> 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 V= M >> state after completing output is acceptable. >> > > I suggest you start with this. If it turns out performance is severel= y > impacted, we can revisit instruction completion. If performance is > satisfactory, then we'll be able to run Kemari with older kernels. I was almost to say yes here, but let me ask one more question. BTW, thank you two for taking time for this discussion which isn't a to= pic on=20 KVM itself. If I transferred a VM after I/O operations, let's say the VM sent an TC= P ACK to=20 the client, and if a hardware failure occurred to the primary during th= e VM=20 transferring *but the client received the TCP ACK*, the secondary will = resume=20 from the previous state, and it may need to receive some data from the = client.=20 However, because the client has already receiver TCP=E3=80=80ACK, it wo= n't resend the=20 data to the secondary. It looks this data is going to be dropped. Am = I missing=20 some point here?