On 15/01/11 07:39, Blue Swirl wrote: > On Sat, Jan 15, 2011 at 1:44 AM, Mateusz Loskot <mate...@loskot.net> > 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