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

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

[Bochnig, Martin]

(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

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

[Gwenole Beauchesne]

Hi,

> 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.

Not sure if that helps but something worth knowing about is you need a 
kernel recent enough or specific Dave S. Miller patch to get accurate 
address in si_addr member of siginfo_t.  Otherwise, the reported 
address is truncated to page boundaries IIRC. Or, you would need to 
decode the instruction and possibly traverse the register windows.

Bye,
Gwenolé.

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

[Bochnig, Martin]

Gwenole Beauchesne wrote:
> Hi,
> 
>> 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.
> 
> 
> Not sure if that helps but something worth knowing about is you need a 
> kernel recent enough or specific Dave S. Miller patch to get accurate 
> address in si_addr member of siginfo_t.  Otherwise, the reported address 
> is truncated to page boundaries IIRC. Or, you would need to decode the 
> instruction and possibly traverse the register windows.

Hi,

I'm afraid you're right.
Sounds plausible.
I surfed dyngen.c and tried to figure out, how/when the error messsages
are to be produced.
I may need help in order to get it running (especially for Solaris 10).
I may have to learn SPARC assembly?

Many thanks,
Martin


> 
> Bye,
> Gwenolé.
> 
> 
> 

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

[Richard Zidlicky]

On Wed, Sep 01, 2004 at 04:57:51AM +0200, Bochnig, Martin wrote:
> (now in its own thread)
> 
> Hi,

> 
> 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

so look at the code generated for op_setbe_T0_subl in op.o,
eg objdump -S op.o. 
Chances are that you have forgotten some no-reorder-block or 
noomit-fp compiler flags. Or the instructions have been
reordered in some new way by the compiler or some V9 specific
opcode. Just figure out what the compiler does instead of
"ret; restore" and strip off these instructions.

Richard

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

[Bochnig, Martin]

Hi,

thank you for your valuable hints, thoughts, comments.

I hope I will manage to get things running - earlier or later.
Most of my systems are SPARC based (all except 1 PC).
Furthermore I would love to see people using QEMU on top of SPARC hw 
(both on Solaris and LinUX as well as *BSD).

I'll keep in touch with you / the ml.


Thanx,

Martin




Richard Zidlicky wrote:
> On Wed, Sep 01, 2004 at 04:57:51AM +0200, Bochnig, Martin wrote:
> 
>>(now in its own thread)
>>
>>Hi,
> 
> 
>>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
> 
> 
> so look at the code generated for op_setbe_T0_subl in op.o,
> eg objdump -S op.o. 
> Chances are that you have forgotten some no-reorder-block or 
> noomit-fp compiler flags. Or the instructions have been
> reordered in some new way by the compiler or some V9 specific
> opcode. Just figure out what the compiler does instead of
> "ret; restore" and strip off these instructions.
> 
> Richard
> 
>