From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1C2LRY-0002Nk-KH for qemu-devel@nongnu.org; Tue, 31 Aug 2004 23:05:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1C2LRY-0002NY-3k for qemu-devel@nongnu.org; Tue, 31 Aug 2004 23:05:52 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1C2LRY-0002NV-0X for qemu-devel@nongnu.org; Tue, 31 Aug 2004 23:05:52 -0400 Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1C2LM5-0005Lm-Aq for qemu-devel@nongnu.org; Tue, 31 Aug 2004 23:00:13 -0400 Message-ID: <41353AAF.3050201@gmx.com> Date: Wed, 01 Sep 2004 04:57:51 +0200 From: "Bochnig, Martin" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] QEMU on SPARC host - Summary and suggested vl.c PATCH Reply-To: bochnig@pool.math.tu-berlin.de, qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org (now in its own thread) Hi, Unfortunately I'm not a hacker. However - what about the SPARC host side? As I reported recently, I got qemu0.6.0 compiled both under Linux (Suse7.3, Debian3.0 r2) and Solaris10 both running on HyperSPARC and UltraSPARC_IIi. Unfortunately the emulation engine libqemu.a doesn't appear to work. The sdl window pops up, the monitor-cli works but eventually the whole process either hangs or segfaults (A few times it managed to load the linux-test kernel, but the guest kernel then crashed due to division by zero.) After most compile sessions not even that one comes up. I tried binutils 2.12/2.13/2.14, gcc 2.95/2.96/3.0/3.2/3.32/3.41, gmake 3.79/3.80. The scenario described (with a launched but crashing linux guest kernel in '-nographics' console io mode) was the very best I ever could get. I did some research And I began to realise, how the host cpu code in vl.c would have to be implemented for SPARC (I cannot speak for Fujitsu's implementation of sparcv9 or earlier.): *v7 (gcc's default), v8 do not seem to have any equivalent for x86's rdtsc instruction. *v9 (as well as v8plus) seem to offer %tick as alternative. Now we SPARC-host users are on the horns of a dilemma: QEMU's existing SPARC support is optimized for SPARCv7 only. While we are required to build for v9 / SPARC64, the build process gives tons of errors caused by invalid type definitions/invalid size castings and doesn't complete. The whole sources may need to be adjusted (by a real hacker, not me). I edited Makefile.target, Makefile and configure and tested several '-mcpu=' and '-m32' vs. '-m64' settings - including '-mcpu=ultrasparc -m32' which is to produce so called sparcv8plus ELF 32 binaries. I tried to build statically. I enabled bigendian and gprof in 'configure'. The build did NEVER complete with '-mcpu=ultrasparc' - no matter how all the other variations looked like. So I could never test or even tune my theoretical %tick code (BTW: The vl.o object builds fine). op.o seemed to be broken and dyngen complained and was unable to generate op.h. :-(( ../dyngen -o op.h op.o dyngen: ret; restore; not found at end of op_setbe_T0_subl gmake[1]: *** [op.h] Error 1 gmake[1]: Leaving directory `/export/home/bochnig/QEMU_SOLARIS_SPARC_HOST/0.6.0/qemu-0.6.0/i386-softmmu' gmake: *** [all] Error 1 Compiling w/o SDL support increased the chance to make QEMU the guest-linux kernel loading ('-nographics'). But only on a linux host - on Solaris10 it didn't help and I never managed to get it doing anything but freezing or segfaulting. No idea. Here my patch suggestions to add SPARC host support to vl.c : #elif defined(__sparc__) /* Derived from: "m68k updates #2" by Richard Zidlicky "crude hack to get some sort of rdtsc support" */ #include static int64_t cputicks=0; static struct timeval lastcptcall={0,0}; // assume 5 MHz Pentium, min 80 ticks between rdtsc calls int64_t cpu_get_real_ticks(void) { struct timeval tp; gettimeofday(&tp,(void*)0); if (tp.tv_sec == lastcptcall.tv_sec && tp.tv_usec == lastcptcall.tv_usec ){ cputicks += 1; } else { cputicks=0; lastcptcall=tp; } return ((int64_t)tp.tv_sec*1000000+tp.tv_usec)*5+cputicks; } #elif defined(__sparc64__) /* I'm not sure it was worth it, personally. * *UltraSparc: * * unsigned long x; * asm volatile ("rd %tick, %0" : "=r"(x)); * * Earlier Sparcs do not have this feature. * * */ int64_t cpu_get_real_ticks(void) { int64_t val; asm volatile ("rd %%tick, %0" : "=r"(val)); return val; } #else #error unsupported CPU #endif Any ideas would be appreciated. Martin