From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39529 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pe8Zp-0007GZ-Hz for qemu-devel@nongnu.org; Sat, 15 Jan 2011 11:02:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pe8Zo-0005S8-8d for qemu-devel@nongnu.org; Sat, 15 Jan 2011 11:02:05 -0500 Received: from srv1.whshost.com ([174.121.90.50]:52911) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pe8Zo-0005Ro-3f for qemu-devel@nongnu.org; Sat, 15 Jan 2011 11:02:04 -0500 Message-ID: <4D31C4F6.6050908@loskot.net> Date: Sat, 15 Jan 2011 16:01:58 +0000 From: Mateusz Loskot MIME-Version: 1.0 Subject: Re: [Qemu-devel] qemu-system-sparc uses all host cpu (continued) References: <4D30FBFE.1030407@loskot.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org On 15/01/11 07:39, Blue Swirl wrote: > On Sat, Jan 15, 2011 at 1:44 AM, Mateusz Loskot > wrote: >> Hi, >> >> I'm running QEMU built from Git current repo to emulate SPARC with >> NetBSD 5.0 installed. My host runs x86_64 GNU/Linux with kernel >> 2.6.35 on Intel P8600 CPU. >> >> I've noticed qemu-system-sparc constantly uses 100% of CPU I found >> similar report in the ml archives [1] and tried to apply the >> patches mentioned there, but it looks they have been partially >> added to Git repo. Only the part in slavio_misc.c seems missing. >> >> Is this known issue? >> >> [1] >> http://lists.nongnu.org/archive/html/qemu-devel/2006-09/msg00210.html > >> > Unfortunately Sparc32 does not have any halt instruction to shut > down the CPU, waking up later when an interrupt is received. On some > machines (like SS-5, but not SS-20) there is chip (APC) that does > something similar. In order to activate power management, guest OS > has to use the chip each time the kernel goes idle. Linux can use use > it, and host CPU load goes very low when the guest is doing nothing. > NetBSD and OpenBSD can't, so the alternative is just to run an > infinite loop. Thanks very much for detailed explanation. I'm not OS programmer, so it's all new but interesting matter to me. > I think this line at NetBSD startup tells that the device was found > in the OpenFirmware device tree, but no driver claimed it: > power-management at sbus0 slot 4 offset 0xa000000 not configured > > Similar line with OpenBSD: "power-management" at sbus0 slot 4 offset > 0xa000000 not configured > > But Linux says: apc: power management initialized Great, now I know what kernel messages to look for when I will be playing with Linux on SPARC. > Adding the driver for *BSD should be easy, basically when the > machine is idle, one bit has to be written to APC device. > > It might also be possible for QEMU to detect a busy loop, and ugly > hacks can be made using OS program counter values known in advance. > A generic busy loop detector design would help other cases, like x86 > with DOS or when Windows sometimes has problems with ACPI (IIRC). > > For example, QEMU could be started in special analyzer mode (or > enabled at run time with tracepoint like system), in which detailed > information about basic blocks executed would be logged. The logs > could then be analyzed offline. The results would then be used to > optimize QEMU behavior (including busy loops) for the production > runs. At the other extreme end, based on the logs, pre-compiled > replacements could be set up for most of the guest code. I believe I understand, but I'm afraid I can't help in contributing here. Though, is there any document about debugging or tracing QEMU? I should have no problems with some testing if needed, but I have never debugged emulators. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org