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

["Bochnig, Martin" <mb1x@gmx.com>]

(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