From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:34333)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1V7PLF-0004Ie-JJ
	for qemu-devel@nongnu.org; Thu, 08 Aug 2013 08:29:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1V7PL6-0001Yv-Av
	for qemu-devel@nongnu.org; Thu, 08 Aug 2013 08:29:21 -0400
Received: from mail-ea0-x22e.google.com ([2a00:1450:4013:c01::22e]:56671)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paolo.bonzini@gmail.com>) id 1V7PL6-0001Xc-4v
	for qemu-devel@nongnu.org; Thu, 08 Aug 2013 08:29:12 -0400
Received: by mail-ea0-f174.google.com with SMTP id z15so1383117ead.19
	for <qemu-devel@nongnu.org>; Thu, 08 Aug 2013 05:29:11 -0700 (PDT)
Sender: Paolo Bonzini <paolo.bonzini@gmail.com>
Message-ID: <52038F10.5070900@redhat.com>
Date: Thu, 08 Aug 2013 14:29:04 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <D3E216785288A145B7BC975F83A2ED103FEF984A@szxeml556-mbx.china.huawei.com>
In-Reply-To: <D3E216785288A145B7BC975F83A2ED103FEF984A@szxeml556-mbx.china.huawei.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] vm performance degradation after kvm live
 migration or save-restore with EPT enabled
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: "Zhanghaoyu (A)" <haoyu.zhang@huawei.com>
Cc: "xiaoguangrong@linux.vnet.ibm.com" <xiaoguangrong@linux.vnet.ibm.com>, Marcelo Tosatti <mtosatti@redhat.com>, "Huangweidong (C)" <weidong.huang@huawei.com>, Xiao Guangrong <xiaoguangrong.eric@gmail.com>, Gleb Natapov <gleb@redhat.com>, "Michael S. Tsirkin" <mst@redhat.com>, "paolo.bonzini@gmail.com" <paolo.bonzini@gmail.com>, Xiejunyong <xiejunyong@huawei.com>, Luonengjun <luonengjun@huawei.com>, qemu-devel <qemu-devel@nongnu.org>, Xiahai <xiahai@huawei.com>, Zanghongyong <zanghongyong@huawei.com>, Xin Rong Fu <XRFu@novell.com>, Yi Li <YiLi@novell.com>, KVM <kvm@vger.kernel.org>, Bruce Rogers <brogers@suse.com>, Hanweidong <hanweidong@huawei.com>, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>

On 08/08/2013 01:31 PM, Zhanghaoyu (A) wrote:
 > And, rebuild the kvm-kmod, then  re-insmod kvm-intel.ko with ept=0,
>
> I virsh-save the VM, and then virsh-restore the VM,  the performance
> degradation disappeared, and no GFN printed.
>
> But, I also made a test on the first bad
> commit(612819c3c6e67bac8fceaa7cc402f13b1b63f7e4), and applied above
> patch too,
>
> With EPT disabled,  as soon as the restoring completed, the GFNs’
> flooding is starting, take some examples to show as below,
>
> but,  after a period of time, only gfn = 240 printed constantly. And
> some processes restore failed, so the performance cannot be measured.

This is 0xF0000 which is the BIOS.  It makes some sense, though I'm not 
sure why a running OS would poke there.

It can be a useful hint, but please do as Gleb said.  Try your kernel 
(+kvm-kmod) with current QEMU, current kernel with your QEMU, current 
kernel with current QEMU.  Make a table of which kernel/QEMU combos work 
and which do not.  Then we can try to understand if the bug still exists 
and perhaps get hints about how your vendor could backport the fix.

Paolo