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

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

[Mateusz Loskot]

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


Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
Member of ACCU, http://accu.org

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

[Blue Swirl]

On Sat, Jan 15, 2011 at 1:44 AM, Mateusz Loskot <mateusz@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.

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.

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 <mateusz@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

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

[Blue Swirl]

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

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.