From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: vm performance degradation after kvm live migration or save-restore
 with EPT enabled
Date: Thu, 08 Aug 2013 14:29:04 +0200
Message-ID: <52038F10.5070900@redhat.com>
References: <D3E216785288A145B7BC975F83A2ED103FEF984A@szxeml556-mbx.china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
	format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Xiao Guangrong <xiaoguangrong.eric@gmail.com>,
	Xiejunyong <xiejunyong@huawei.com>,
	"Huangweidong (C)" <weidong.huang@huawei.com>,
	KVM <kvm@vger.kernel.org>, Gleb Natapov <gleb@redhat.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	Luonengjun <luonengjun@huawei.com>, Xiahai <xiahai@huawei.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	"paolo.bonzini@gmail.com" <paolo.bonzini@gmail.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Bruce Rogers <brogers@suse.com>,
	Zanghongyong <zanghongyong@huawei.com>,
	Xin Rong Fu <XRFu@novell.com>, Yi Li <YiLi@novell.com>,
	"xiaoguangrong@linux.vnet.ibm.com" <xiaoguangrong@linux.vnet.ibm.com>,
	Hanweidong <hanweidong@huawei.com>,
	=?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= <afaerber@suse.de>
To: "Zhanghaoyu (A)" <haoyu.zhang@huawei.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-ee0-f46.google.com ([74.125.83.46]:43977 "EHLO
	mail-ee0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1757776Ab3HHM3M (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 8 Aug 2013 08:29:12 -0400
Received: by mail-ee0-f46.google.com with SMTP id c13so1459115eek.19
        for <kvm@vger.kernel.org>; Thu, 08 Aug 2013 05:29:11 -0700 (PDT)
In-Reply-To: <D3E216785288A145B7BC975F83A2ED103FEF984A@szxeml556-mbx.china.huawei.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On 08/08/2013 01:31 PM, Zhanghaoyu (A) wrote:
 > And, rebuild the kvm-kmod, then  re-insmod kvm-intel.ko with ept=3D0=
,
>
> 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=E2=80=
=99
> flooding is starting, take some examples to show as below,
>
> but,  after a period of time, only gfn =3D 240 printed constantly. An=
d
> 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=
=20
sure why a running OS would poke there.

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

Paolo