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

[Blue Swirl]

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.

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

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.