From: Rob Landley <rob@landley.net>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] arm1136 CPU emulation won't run current kernels?
Date: Tue, 07 Jun 2011 19:32:07 -0500 [thread overview]
Message-ID: <4DEEC307.40103@landley.net> (raw)
QEMU's -cpu arm1136 emulation stopped working in the 2.6.35 and later
kernels, now QEMU dies early in the kernel boot with:
qemu: fatal: Unimplemented cp15 register write (c13, c0, {0, 3})
This is due to this change to the Linux kernel:
commit f159f4ed55bb0fa5470800641e03a13a7e0eae6e
Author: Tony Lindgren <tony@atomide.com>
Date: Mon Jul 5 14:53:10 2010 +0100
ARM: 6207/1: Replace CONFIG_HAS_TLS_REG with HWCAP_TLS and check for
it on V6
The TLS register is only available on ARM1136 r1p0 and later.
Set HWCAP_TLS flags if hardware TLS is available and test for
it if CONFIG_CPU_32v6K is not set for V6.
Which does is remove the CONFIG_HAS_TLS_REG kernel config symbol, and
replaces it with a probe. I.E. this code:
+++ b/arch/arm/kernel/entry-armv.S
-#if defined(CONFIG_HAS_TLS_REG)
- mcr p15, 0, r3, c13, c0, 3 @ set TLS register
-#elif !defined(CONFIG_TLS_REG_EMUL)
- mov r4, #0xffff0fff
- str r3, [r4, #-15] @ TLS val at 0xffff0ff0
-#endif
Becomes this code:
+++ b/arch/arm/include/asm/hwcap.h
+#define HWCAP_TLS 32768
+ .macro set_tls_v6, tp, tmp1, tmp2
+ ldr \tmp1, =elf_hwcap
+ ldr \tmp1, [\tmp1, #0]
+ mov \tmp2, #0xffff0fff
+ tst \tmp1, #HWCAP_TLS @ hardware TLS available?
+ mcrne p15, 0, \tp, c13, c0, 3 @ yes, set TLS register
+ streq \tp, [\tmp2, #-15] @ set TLS value at
0xffff0ff0
+ .endm
The elf_hwcap variable with the HWCAP_TLS bit is initialized (in
mm/proc-v6.S) with HWCAP_TLS always set, and then this switches it off:
+static void __init feat_v6_fixup(void)
+{
+ int id = read_cpuid_id();
+
+ if ((id & 0xff0f0000) != 0x41070000)
+ return;
+
+ /*
+ * HWCAP_TLS is available only on 1136 r1p0 and later,
+ * see also kuser_get_tls_init.
+ */
+ if ((((id >> 4) & 0xfff) == 0xb36) && (((id >> 20) & 3) == 0))
+ elf_hwcap &= ~HWCAP_TLS;
+}
+
The CPUID for arm1136 QEMU emulates a process that should have hardware
TLS (target-arm/cpu.h):
#define ARM_CPUID_ARM1136 0x4117b363
Meaning the above "switch it off" test doesn't trigger, the kernel tries
to access a hardware feature QEMU doesn't emulate, and QEMU aborts.
Note: I can work around this with -cpu arm1136-r2 (0x4107b363), but it
seems like the correct fix would be to add "hardware" TLS support to arm
kernels. Is this currently on anybody's todo list? (Is there a data
sheet somewhere...?)
Rob
next reply other threads:[~2011-06-08 0:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 0:32 Rob Landley [this message]
2011-06-08 13:03 ` [Qemu-devel] arm1136 CPU emulation won't run current kernels? Peter Maydell
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=4DEEC307.40103@landley.net \
--to=rob@landley.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).