Thiemo Seufer wrote:
Dirk Behme wrote:
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.
This was the reason why I first tried it with a small test
program before using Linux ;)
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.
Anybody with a short explanation of the basics of this? I
think this would really help debugging this issue.
Many thanks
Dirk
_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
