[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-devel] QEMU on SPARC host - Summary and suggested vl.c PATCH,
Bochnig, Martin <=