From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtMoz-0002gf-Gd for qemu-devel@nongnu.org; Mon, 13 Apr 2009 10:07:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtMot-0002cn-U2 for qemu-devel@nongnu.org; Mon, 13 Apr 2009 10:07:36 -0400 Received: from [199.232.76.173] (port=33470 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtMot-0002cZ-KL for qemu-devel@nongnu.org; Mon, 13 Apr 2009 10:07:31 -0400 Received: from verein.lst.de ([213.95.11.210]:33550) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1LtMot-0001sC-1i for qemu-devel@nongnu.org; Mon, 13 Apr 2009 10:07:31 -0400 Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id n3DE7RIF013256 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 13 Apr 2009 16:07:27 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id n3DE7RKc013254 for qemu-devel@nongnu.org; Mon, 13 Apr 2009 16:07:27 +0200 Date: Mon, 13 Apr 2009 16:07:27 +0200 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH][STABLE] kvm: Fix cpuid initialization Message-ID: <20090413140727.GA13193@lst.de> References: <49E2FD72.6000101@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E2FD72.6000101@web.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Mon, Apr 13, 2009 at 10:53:06AM +0200, Jan Kiszka wrote: > [ Looks like we need more kvm users via upstream qemu... ] > > Fix (more or less) spurious guest boot failures due to corrupted cpuid > states. The reason was insufficient initialization of cpuid entries > before passing them to the kernel. > > At this chance also fix improper entry pointer progression and simplify > the code a bit. Is that guest kernel stuck on the "testing hlt" message in the Linux kernel with that one? I've seen that hang for a while now, but haven't been able to bisect it yet.