From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=58766 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PNljH-0006At-W9 for qemu-devel@nongnu.org; Wed, 01 Dec 2010 07:24:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PNljG-0003tP-FP for qemu-devel@nongnu.org; Wed, 01 Dec 2010 07:24:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:17760) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PNljG-0003tI-1z for qemu-devel@nongnu.org; Wed, 01 Dec 2010 07:24:10 -0500 Message-ID: <4CF63E60.4050309@redhat.com> Date: Wed, 01 Dec 2010 14:24:00 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1291202264-3128-1-git-send-email-andre.przywara@amd.com> In-Reply-To: <1291202264-3128-1-git-send-email-andre.przywara@amd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] kvm/x86: enlarge number of possible CPUID leaves List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andre Przywara Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org On 12/01/2010 01:17 PM, Andre Przywara wrote: > Currently the number of CPUID leaves KVM handles is limited to 40. > My desktop machine (AthlonII) already has 35 and future CPUs will > expand this well beyond the limit. Extend the limit to 80 to make > room for future processors. > > Signed-off-by: Andre Przywara > --- > arch/x86/include/asm/kvm_host.h | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > Hi, > I found that either KVM or QEMU (possibly both) are broken in respect > to handling more CPUID entries than the limit dictates. KVM will > return -E2BIG, which is the same error as if the user hasn't provided > enough space to hold all entries. Now QEMU will continue to enlarge > the allocated memory until it gets into an out-of-memory condition. > I have tried to fix this with teaching KVM how to deal with a capped > number of entries (there are some bugs in the current code), but this > will limit the number of CPUID entries KVM handles, which will surely > cut of the lastly appended PV leaves. > A proper fix would be to make this allocation dynamic. Is this a > feasible way or will this lead to issues or side-effects? > Well, there has to be some limit, or userspace can allocate unbounded kernel memory. -- error compiling committee.c: too many arguments to function