From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42321)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZxFu7-0004KJ-UO
	for qemu-devel@nongnu.org; Fri, 13 Nov 2015 10:04:44 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZxFu3-0007hK-UJ
	for qemu-devel@nongnu.org; Fri, 13 Nov 2015 10:04:43 -0500
Received: from mx1.redhat.com ([209.132.183.28]:56516)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZxFu3-0007h9-Pg
	for qemu-devel@nongnu.org; Fri, 13 Nov 2015 10:04:39 -0500
References: <5645F9FD.2050807@proxmox.com> <5645FB32.1080108@redhat.com>
	<5645FBD7.5020101@proxmox.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <5645FC03.7070606@redhat.com>
Date: Fri, 13 Nov 2015 16:04:35 +0100
MIME-Version: 1.0
In-Reply-To: <5645FBD7.5020101@proxmox.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] Problems with VM after kernel commit
 b18d5431acc7a2fd22767925f3a6f597aa4bd29e
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: Wolfgang Link <w.link@proxmox.com>, guangrong.xiao@linux.intel.com
Cc: qemu-devel@nongnu.org



On 13/11/2015 16:03, Wolfgang Link wrote:
> Thanks you for the quick reply and the good news.

BTW, for kernel issues please use kvm@vger.kernel.org :)

Paolo

> Wolfgang
> On 11/13/2015 04:01 PM, Paolo Bonzini wrote:
>>
>> On 13/11/2015 15:55, Wolfgang Link wrote:
>>> Hi,
>>>
>>> We have problems with a HP ProLiant DL380 Gen9 and Vm's with large
>>> amount of memory, grater then 30GB.
>>>
>>> The problem is that the vm need about 10 sec to start to boot.
>>> and when it comes to syncing the cpu clock, it takes a long time to
>>> finish this task.
>>> What also occurs is the vcpus need at startup 100% cpu usage and take
>>> over 1 min.
>> This has been fixed already, and the fix is slowly propagating to the
>> stable kernels.
>>
>> The fixes are:
>>
>> - KVM: vmx: obey KVM_QUIRK_CD_NW_CLEARED (fixed already in 4.2)
>>
>> - KVM: x86: obey KVM_X86_QUIRK_CD_NW_CLEARED in kvm_set_cr0() (in 4.4,
>> will be backported)
>>
>> Paolo
>>
> 
>