From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSyRw-00044r-Ed for qemu-devel@nongnu.org; Tue, 12 Aug 2008 14:18:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KSyRu-00041e-Li for qemu-devel@nongnu.org; Tue, 12 Aug 2008 14:18:27 -0400 Received: from [199.232.76.173] (port=57979 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSyRu-00041K-Ch for qemu-devel@nongnu.org; Tue, 12 Aug 2008 14:18:26 -0400 Received: from wr-out-0506.google.com ([64.233.184.232]:15561) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KSyRu-0006Nl-53 for qemu-devel@nongnu.org; Tue, 12 Aug 2008 14:18:26 -0400 Received: by wr-out-0506.google.com with SMTP id c46so2314854wra.18 for ; Tue, 12 Aug 2008 11:18:25 -0700 (PDT) Message-ID: <48A1D3CA.9010308@codemonkey.ws> Date: Tue, 12 Aug 2008 13:17:46 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] AMD 100% CPU bug; patch available? References: <48A1BBF8.30407@quinthar.com> In-Reply-To: <48A1BBF8.30407@quinthar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 David Barrett wrote: > Can anybody confirm that qemu works on an AMD processor with a Linux > host and Linux guest (ideally Ubuntu 8.04 in both cases) without using > 100% CPU? (qemu process on the host uses 100% CPU despite all > processes on the guest being idle.) > > Or is there a known bug that qemu with a Ubuntu guest always uses 100% > CPU on AMD Ubuntu hosts? If so, is there a patch or workaround for it? > > I don't know this for certain, but it's the only pattern I can see: > I've run qemu on a bunch of laptops and servers over the past 12 > months -- often with the exact same image and exact same commands -- > and some hosts see the guest VM use limited CPU, and others a solid > 100%. This seems to be the case whether or not -kernel-kqemu is used. Do you still see this if you use -no-kqemu? Regards, Anthony Liguori