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 _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
