Re: [Qemu-devel] [PATCH] TCG S/390 backend

[malc <av1474@comtv.ru>]

On Tue, 12 May 2009, Ulrich Hecht wrote:

> On Tuesday 05 May 2009, malc wrote:
> > On Tue, 5 May 2009, Ulrich Hecht wrote:
> > > Now i386, AMD64, ARM, SH4, and m68k system emulators work. MIPS
> > > works at least as well as on an AMD64 host, i.e. the test image from
> > > qemu.org just
> >
> > Should work with '-M mips'.
> 
> It complains about a missing "mips_bios.bin" then, which isn't in 
> pc-bios.

Harmless. To verify I just built fresh QEMU checkout and run things like
this:

/path/to/freshly/built/qemu/mips-softmmu/qemu-system-mips \
-kernel vmlinux-2.6.18-3-qemu \
-initrd initrd.gz \
-append console=ttyS0 \
-monitor stdio \
-m 128 \
-M mips

Got:
qemu: Warning, could not load MIPS bios '/usr/local/share/qemu/mips_bios.bin'

Then pressing ctrl-alt-2 brought me straight to ttyS0 where Linux was
printing it's boot messages.

> 
> > > sits there without doing anything. The SPARC test image fails with a
> > > memory access exception in the target system, but works on an AMD64
> > > host, so there probably still is a bug somewhere in the backend.
> >
> > Tried to compare `-d in_asm' outputs of S390/AMD64 when using
> > deterministic execution (`-icount N')?
> 
> I found the problem: TCG does not zero- or sign-extend arguments to 
> function calls. Unlike, for instance, AMD64, 32-bit arithmetic ops on 
> S/390 leave the upper 32 bits of the destination register untouched, so 
> there could be any kind of garbage there. If a helper taking a 64-bit 
> argument is called with the result of such an operation, stuff breaks. 
> IMO, TCG should do the extension in tcg_reg_alloc_call(), but that seems 
> to be impossible because it has no information on the types of the input 
> arguments the callee expects. Working around this in the backend is 
> hardly possible as it does not have the information either.

If the target performs 32bit arithmetics on 64bit arguments then all bets
are off - the target that does that is broken. FWIW on PPC64 logical and
simple arithmetic ops do not have 32-bit forms so that higher order bits
(lower order according to IBM for which many people are eternally grateful) 
contain "garbage". Shifts/muls/divs have separate 32/64bit forms though
and, at least, for shifts those lower/higher order bits will be masked.

> 
> I have the suspicion that even on other 64-bit hosts, this only works by 
> accident (if it does at all): Even if the 32-bit arithmetic op does sign 
> extension, what if the function argument is a pointer? Depending on the 
> address, the function may get a value with a lot of F's in front...

If 32-bit arithmetic op is performed on a 64-bit pointer target
translation is broken.

> 
> Any ideas?

As an experiment you can try to manually zero/sign extend results of all
_i32 ops, but methinks the real problem should be identified. 

-- 
mailto:av1474@comtv.ru