|
From: | Dirk Behme |
Subject: | Re: [Qemu-devel] Wrong reset of MIPS hflags EXL after interrupt? |
Date: | Wed, 16 Aug 2006 22:18:22 +0200 |
User-agent: | Mozilla Thunderbird 1.0.7 (X11/20050923) |
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
[Prev in Thread] | Current Thread | [Next in Thread] |