From: Thiemo Seufer <ths@networkno.de>
To: Alexander Voropay <a.voropay@equant.ru>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] CP0 after reset bug (Was: Add MIPS ELF loader)
Date: Fri, 21 Apr 2006 13:51:55 +0100 [thread overview]
Message-ID: <20060421125154.GK10665@networkno.de> (raw)
In-Reply-To: <3bc401c66540$2738bd20$e90d11ac@spb.in.rosprint.ru>
Alexander Voropay wrote:
[snip]
> Unfortunately, this code clears CU0 bits in the CP0(SR).
> It makes CP0 unusable for program and causes an exception 11 :
> Coprocessor Unusable on the next CP0 access.
>
> The Qemu has a bug there. The "See MIPS Run" p.51 states:
>
> CU0 - Coprocessor 0 usable; Set 1 to be able to use some nominally
> priveleged instructions in the user mode. You don't want to do this.
> The CPU control instructions encoded as coprocessor 0 type are
> always usable in kernel mode, regardless of the setting of this bit.
>
> Qemu does simply check:
> ./target-mips/translate.c:1181
> ===================
> if (!(ctx->CP0_Status & (1 << CP0St_CU0)) &&
> !(ctx->hflags & MIPS_HFLAG_UM) &&
> !(ctx->hflags & MIPS_HFLAG_ERL) &&
> !(ctx->hflags & MIPS_HFLAG_EXL)) {
> if (loglevel & CPU_LOG_TB_IN_ASM) {
> fprintf(logfile, "CP0 is not usable\n");
> }
> generate_exception_err (ctx, EXCP_CpU, 0);
> return;
> ===================
>
> This check is not enought to emulate a Coprocessor Unusable
> situation on Reset (when CPU is in the kernel mode).
A patch which doesn't negate the HFLAGS_UM check fixes this and was
posted here a while ago.
Thiemo
next prev parent reply other threads:[~2006-04-21 12:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <154e01c66453$111e4f20$e90d11ac@spb.in.rosprint.ru>
2006-04-20 10:16 ` [Qemu-devel] [PATCH] Add MIPS ELF loader Marius Groeger
2006-04-20 10:28 ` Thiemo Seufer
2006-04-20 11:02 ` Alexander Voropay
2006-04-20 12:19 ` Alexander Voropay
2006-04-21 12:35 ` [Qemu-devel] CP0 after reset bug (Was: Add MIPS ELF loader) Alexander Voropay
2006-04-21 12:51 ` Thiemo Seufer [this message]
2006-04-21 14:29 ` Alexander Voropay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060421125154.GK10665@networkno.de \
--to=ths@networkno.de \
--cc=a.voropay@equant.ru \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.