Re: [Qemu-devel] qemu-system-sparc uses all host cpu (continued)

[Mateusz Loskot]

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