From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Question on skip_emulated_instructions() Date: Thu, 08 Apr 2010 11:38:27 +0300 Message-ID: <4BBD9603.10105@redhat.com> 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> <4BBD9410.1090208@lab.ntt.co.jp> 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: Yoshiaki Tamura Return-path: Received: from mx1.redhat.com ([209.132.183.28]:39060 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751410Ab0DHIia (ORCPT ); Thu, 8 Apr 2010 04:38:30 -0400 In-Reply-To: <4BBD9410.1090208@lab.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 04/08/2010 11:30 AM, Yoshiaki Tamura wrote: > > If I transferred a VM after I/O operations, let's say the VM sent an=20 > TCP ACK to the client, and if a hardware failure occurred to the=20 > primary during the VM transferring *but the client received the TCP=20 > ACK*, the secondary will resume from the previous state, and it may=20 > need to receive some data from the client. However, because the clien= t=20 > has already receiver TCP=E3=80=80ACK, it won't resend the data to the= =20 > secondary. It looks this data is going to be dropped. Am I missing=20 > some point here? > I think you should block I/O not at the cpu/device boundary (that's=20 inefficient as many cpu I/O instructions don't necessarily cause=20 externally visible I/O) but at the device level. Whenever the network=20 device wants to send out a packet, halt the guest (letting any I/O=20 instructions complete), synchronize the secondary, and then release the= =20 pending I/O. This ensures that the secondary has all of the data prior= =20 to the ack being sent out. --=20 error compiling committee.c: too many arguments to function