qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt?


From: Thiemo Seufer
Subject: Re: [Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt?
Date: Wed, 16 Aug 2006 19:29:09 +0100
User-agent: Mutt/1.5.12-2006-07-14

Dirk Behme wrote:
> Hi,
> 
> I'm not sure, but while playing with MIPS interrupts, it 
> seems to me that something with reset of interrupt flag 
> MIPS_HFLAG_EXL (0x04) at exception exit (eret) is wrong. It 
> seems to me that only one interrupt is executed because 
> after eret, MIPS_HFLAG_EXL stays set in env->hflags. Then, 
> at next interrupt, system correctly checks for 
> MIPS_HFLAG_EXL, but this is still set and no further 
> interrupt happens.

This explains some weirdness I saw on my hacked up qemu
when running a mips32r2-compiled Linux kernel.

> Debugging shows that op_eret() in MIPS op.c correctly reset 
> this bit: env->hflags &= ~MIPS_HFLAG_EXL; But debug output 
> at end of e.g. save_cpu_state() (debug output of ctx->hflags 
> and ctx->saved_hflags ) or in function which tries to issue 
> (next) timer interrupt (debug output of env->hflags) 
> MIPS_HFLAG_EXL is still (again?) set everywhere. Looks like 
> the correct env->hflags from op_eret() is overwritten 
> somewhere later with wrong value.
> 
> These three ctx->hflags, ctx->saved_hflags and env->hflags 
> are confusing me ;) Where are they synchronized after eret? 
> Or who overwrites the env->hflags correctly set by eret 
> again? Any ideas, why eret sets env->hflags correctly and 
> later global env->hflags has still/again wrong value? Any 
> other hints?

AFAIU qemu maintains an environment stack, I guess popping the
environment restores the old flag contents.


Thiemo




reply via email to

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