[Top][All Lists]
[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