[Qemu-devel] wfi in qemu-system-arm (v6) on a Mac host locks up qemu

[Qemu-devel] wfi in qemu-system-arm (v6) on a Mac host locks up qemu

[Steve Lemke]

Is anyone running an ARM v6 kernel in qemu-system-arm on a Mac built  
from recent qemu trunk?

When the target issues a "wfi" (wait for interrupt) instruction, the  
select timeout gets set to 5000 which appears to cause the entire app  
to block in select for 5 seconds at a time and Mac OS doesn't seem to  
be too thrilled about that.

It looks like changing HELPER(wfi) in op_helper.c to simply call  
cpu_loop_exit() without setting env->exception_index or env_halted  
appears to fix it, (essentially attempting to handle it more like a  
NOP, I suppose) though I'm not sure that's the best "fix".

(I suppose using a v4 or v5 kernel would probably work as well if that  
happens to be an available option...)

Paul pointed me to the recent (related) "Fix nographic mode and VNC"  
thread, but that thread didn't seem to actually end in a solution.

Has anyone thought about this any more?

--Steve

Re: [Qemu-devel] wfi in qemu-system-arm (v6) on a Mac host locks up qemu

[Paul Brook]

On Thursday 05 February 2009, Steve Lemke wrote:
> Is anyone running an ARM v6 kernel in qemu-system-arm on a Mac built
> from recent qemu trunk?
>
> When the target issues a "wfi" (wait for interrupt) instruction, the
> select timeout gets set to 5000 which appears to cause the entire app
> to block in select for 5 seconds at a time and Mac OS doesn't seem to
> be too thrilled about that.

What exactly is OSX expecting qemu to do in that time?

GUI updates (which generally involves polling the OS for GUI events) should be 
driven off the gui timer. If the GUI isn't active then why shouldn't we sleep 
for a long period of time?

Paul