qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC] target/openrisc: Support non-busy idle stat


From: Richard Henderson
Subject: Re: [Qemu-devel] [PATCH RFC] target/openrisc: Support non-busy idle state using PMR SPR
Date: Tue, 25 Apr 2017 16:51:55 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

On 04/25/2017 04:18 PM, Stafford Horne wrote:
On Tue, Apr 25, 2017 at 12:11:00PM +0200, Richard Henderson wrote:
On 04/23/2017 11:54 PM, Stafford Horne wrote:
The OpenRISC architecture has the Power Management Register (PMR)
special purpose register to manage cpu power states.  The interesting
modes are:

   * Doze Mode (DME) - Stop cpu except timer & pic - wake on interrupt
   * Sleep Mode (SME) - Stop cpu and all units - wake on interrupt
   * Suspend Model (SUME) - Stop cpu and all units - wake on reset

The linux kernel will set DME when idle.

And SUME would be, essentially, poweroff?  Perhaps at least for the purposes
of QEMU; on real hardware one could press a button to assert reset and
reboot.

Yes, that is what I am thinking, but I could add this later, after some
reviews with other OpenRISC folks.

Also, I don't know if its due to this patch of an issue with the timer
interrupts.  After applying this patch the timer interrupts do not trigger
until a keypress is make.  i.e. something like this...

    $ sleep 5
    <hangs forever until a key is pressed>
...
+            cpu_restore_state(cs, GETPC() + 4);

This isn't correct.  You want

        cpu_restore_state(cs, GETPC());
        cs->env.pc += 4;

So what's happening is that you're re-executing the MTSPR and going back to
sleep again.  Which probably explains the hang.

I have changed to the above, but I think its essentially the same.  It
resumes after the MTSPR in both cases.

It's not essentially the same. GETPC is a host address. Doing guest arithmetic on that is just wrong.

I fixed this now though, you should see another patch.  The issue is the
timer events get ignored once the cpu is in halt state, I added a
qemu_cpu_kick() call in the timer hardware to wake up the cpu on timer
interrupts.  Not sure if thats the best way to do it, but it works 100%
now.

Ah, that could be.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]