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

[Blue Swirl]

On Sat, Jan 15, 2011 at 4:01 PM, Mateusz Loskot <address@hidden> wrote:
> 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.

QEMU can be debugged like any normal application, in fact stepping
around with GDB may be the fastest way to learn how the code is
structured. Debugging generated code is a bit hard with GDB, it may be
easier to just look at the log generated by -d in_asm,op,out_asm. Code
which interfaces directly with generated code, like cpu-exec.c and
target-*/op_helper.c, use a global register variable for the CPUState
pointer and this may also confuse GDB.

For tracing, please read docs/tracing.txt.