qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] QEMU on SPARC host - Summary and suggested vl.c PATCH


From: Bochnig, Martin
Subject: [Qemu-devel] QEMU on SPARC host - Summary and suggested vl.c PATCH
Date: Wed, 01 Sep 2004 04:57:51 +0200
User-agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.5a) Gecko/20030905

(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 <sys/time.h>
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]