[Qemu-devel] ppc emulation and interrupts

[Qemu-devel] ppc emulation and interrupts

[Stefano Stabellini]

Hi all,
one of the recent problems, noticed after the displaystate change,
affects ppc emulation only and is due to the fact that none on ppc
emulation is issuing any interrupt request of the CPU_INTERRUPT_EXIT
kind if the gui timer is disabled.
Hence qemu never leaves the loop in cpu-exec.c:cpu_exec.
If the gui timer is enabled qemu is able to leave the loop because the
condition (interrupt_request & CPU_INTERRUPT_EXIT) is true when the
timer is triggered.
I think this is a problem with the ppc emulation but if you ppc guys
need the gui timer to be always on, I can arrange for it to be.
Regards,

Stefano Stabellini

Re: [Qemu-devel] ppc emulation and interrupts

[Lennart Sorensen]

On Wed, Jan 21, 2009 at 11:49:10AM +0000, Stefano Stabellini wrote:
> Hi all,
> one of the recent problems, noticed after the displaystate change,
> affects ppc emulation only and is due to the fact that none on ppc
> emulation is issuing any interrupt request of the CPU_INTERRUPT_EXIT
> kind if the gui timer is disabled.
> Hence qemu never leaves the loop in cpu-exec.c:cpu_exec.
> If the gui timer is enabled qemu is able to leave the loop because the
> condition (interrupt_request & CPU_INTERRUPT_EXIT) is true when the
> timer is triggered.
> I think this is a problem with the ppc emulation but if you ppc guys
> need the gui timer to be always on, I can arrange for it to be.
> Regards,

So does this explain why vnc runs fast and sdl runs slow?

Even with the latest patches, sdl is still slow for ppc emulation.  Not
using much cpu either of course.

-- 
Len Sorensen

Re: [Qemu-devel] ppc emulation and interrupts

[Blue Swirl]

On 1/21/09, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> Hi all,
>  one of the recent problems, noticed after the displaystate change,
>  affects ppc emulation only and is due to the fact that none on ppc
>  emulation is issuing any interrupt request of the CPU_INTERRUPT_EXIT
>  kind if the gui timer is disabled.
>  Hence qemu never leaves the loop in cpu-exec.c:cpu_exec.
>  If the gui timer is enabled qemu is able to leave the loop because the
>  condition (interrupt_request & CPU_INTERRUPT_EXIT) is true when the
>  timer is triggered.
>  I think this is a problem with the ppc emulation but if you ppc guys
>  need the gui timer to be always on, I can arrange for it to be.
>  Regards,

It's not only PPC problem, Sparc64 with -nographic never exits cpu
loop because no timers are running. Serial input does not work,
because IO does not cause exit from cpu loop.

We could add a dummy timer just to exit the cpu loop, but that's a bit ugly.

I think SIGIO was discussed at some point, but rejected.

Would it be very hard to move to the IO thread model?

Re: [Qemu-devel] ppc emulation and interrupts

[Stefano Stabellini]

Lennart Sorensen wrote:

> On Wed, Jan 21, 2009 at 11:49:10AM +0000, Stefano Stabellini wrote:
>> Hi all,
>> one of the recent problems, noticed after the displaystate change,
>> affects ppc emulation only and is due to the fact that none on ppc
>> emulation is issuing any interrupt request of the CPU_INTERRUPT_EXIT
>> kind if the gui timer is disabled.
>> Hence qemu never leaves the loop in cpu-exec.c:cpu_exec.
>> If the gui timer is enabled qemu is able to leave the loop because the
>> condition (interrupt_request & CPU_INTERRUPT_EXIT) is true when the
>> timer is triggered.
>> I think this is a problem with the ppc emulation but if you ppc guys
>> need the gui timer to be always on, I can arrange for it to be.
>> Regards,
> 
> So does this explain why vnc runs fast and sdl runs slow?


No, this bug prevents qemu from working when only vnc is enabled.

 
> Even with the latest patches, sdl is still slow for ppc emulation.  Not
> using much cpu either of course.
> 


I'll investigate more on this.
As I said before, sdl shouldn't be noticeable slower now, unless you are
using remote X.
I have just tried debian ppc and I get similar performances using vnc
(localhost) or sdl (local X server).

Re: [Qemu-devel] ppc emulation and interrupts

[Blue Swirl]

On 1/21/09, Stefano Stabellini <stefano.stabellini@eu.citrix.com> wrote:
> Lennart Sorensen wrote:
>
>  > On Wed, Jan 21, 2009 at 11:49:10AM +0000, Stefano Stabellini wrote:
>  >> Hi all,
>  >> one of the recent problems, noticed after the displaystate change,
>  >> affects ppc emulation only and is due to the fact that none on ppc
>  >> emulation is issuing any interrupt request of the CPU_INTERRUPT_EXIT
>  >> kind if the gui timer is disabled.
>  >> Hence qemu never leaves the loop in cpu-exec.c:cpu_exec.
>  >> If the gui timer is enabled qemu is able to leave the loop because the
>  >> condition (interrupt_request & CPU_INTERRUPT_EXIT) is true when the
>  >> timer is triggered.
>  >> I think this is a problem with the ppc emulation but if you ppc guys
>  >> need the gui timer to be always on, I can arrange for it to be.
>  >> Regards,
>  >
>  > So does this explain why vnc runs fast and sdl runs slow?
>
>
>
> No, this bug prevents qemu from working when only vnc is enabled.
>
>
>
>  > Even with the latest patches, sdl is still slow for ppc emulation.  Not
>  > using much cpu either of course.
>  >
>
>
>
> I'll investigate more on this.
>  As I said before, sdl shouldn't be noticeable slower now, unless you are
>  using remote X.
>  I have just tried debian ppc and I get similar performances using vnc
>  (localhost) or sdl (local X server).

I just committed a fix, now both -nographic and VNC work for Sparc64
and VNC on PPC.

Re: [Qemu-devel] ppc emulation and interrupts

[Lennart Sorensen]

On Wed, Jan 21, 2009 at 07:24:40PM +0000, Stefano Stabellini wrote:
> No, this bug prevents qemu from working when only vnc is enabled.

Oh that one.  Right.

> I'll investigate more on this.
> As I said before, sdl shouldn't be noticeable slower now, unless you are
> using remote X.
> I have just tried debian ppc and I get similar performances using vnc
> (localhost) or sdl (local X server).

I sent a patch to my original thread that makes remote sdl fast for me
again.

-- 
Len Sorensen