[Qemu-devel] ppc "stfiwx" floating point missing implementation
Hi
I'm using QEMU to emulate PowerPC 603e for testing my cross compiled root filesystem on i686.
When executing binary which is compiled (without -msoft-float) to use full floating point instruction set,
kernel returns "Illegal instruction" at runtime. After core dump debugging my
binary I found out,
that optional "stfiwx" instruction is not implemented. I'm trying to implement this instruction,
instead of returning RET_INVAL(ctx), I'm using code from "stfdx" function as an example which is similar to "stfiwx".
Now when "stfiwx" is executed it works but the code become unstable.
Because leak of knowledge about qemu pseudo instructions, I guess that the problem is how to properly load "integer word"
to the specified memory location. I think that op_ldst(stfs) is not proper
replacement or something else is still missing.
Could someone please to help implement the missing "stfiwx" instruction.
(hints are also appreciated) ;)
Tom
Here is my modified translate.c (still broken code)
--- target-ppc/translate.c.orig 2006-09-29 09:29:28.0 +0200
+++ target-ppc/translate.c 2006-09-29 09:39:17.0 +0200
@@ -1715,21 +1715,30 @@
GEN_STFS(fs, 0x14);
/* Optional: */
/* stfiwx */
GEN_HANDLER(stfiwx, 0x1F, 0x17, 0x1E, 0x0001, PPC_FLOAT)
{
if (!ctx->fpu_enabled) {
RET_EXCP(ctx, EXCP_NO_FP, 0);
return;
}
-RET_INVAL(ctx);
+
+if (rA(ctx->opcode) == 0) {
+gen_op_load_gpr_T0(rB(ctx->opcode));
+} else {
+gen_op_load_gpr_T0(rA(ctx->opcode));
+gen_op_load_gpr_T1(rB(ctx->opcode));
+gen_op_add();
+}
+gen_op_load_fpr_FT1(rS(ctx->opcode));
+op_ldst(stfs);
}
/***Branch ***/
static inline void gen_goto_tb(DisasContext *ctx, int n, target_ulong dest)
{
TranslationBlock *tb;
tb = ctx->tb;
if ((tb->pc & TARGET_PAGE_MASK) == (dest & TARGET_PAGE_MASK)) {
if (n == 0)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ppc "stfiwx" floating point missing implementation
Tom Marn wrote:
Here is my modified translate.c (still broken code)
Re-sending previous malformed patch (I hope this one will be formated ok).
--- target-ppc/translate.c.orig 2006-09-29 09:29:28.0 +0200
+++ target-ppc/translate.c 2006-09-29 09:39:17.0 +0200
@@ -1715,21 +1715,30 @@
GEN_STFS(fs, 0x14);
/* Optional: */
/* stfiwx */
GEN_HANDLER(stfiwx, 0x1F, 0x17, 0x1E, 0x0001, PPC_FLOAT)
{
if (!ctx->fpu_enabled) {
RET_EXCP(ctx, EXCP_NO_FP, 0);
return;
}
-RET_INVAL(ctx);
+
+if (rA(ctx->opcode) == 0) {
+gen_op_load_gpr_T0(rB(ctx->opcode));
+} else {
+gen_op_load_gpr_T0(rA(ctx->opcode));
+gen_op_load_gpr_T1(rB(ctx->opcode));
+gen_op_add();
+}
+gen_op_load_fpr_FT1(rS(ctx->opcode));
+op_ldst(stfs);
}
/***Branch ***/
static inline void gen_goto_tb(DisasContext *ctx, int n, target_ulong dest)
{
TranslationBlock *tb;
tb = ctx->tb;
if ((tb->pc & TARGET_PAGE_MASK) == (dest & TARGET_PAGE_MASK)) {
if (n == 0)
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] bug in ARM thumb usermode emulation
TLS and multithreaded applications are known to not work with usermode emulation. In the end, it was an uninitialized stack allocated variable in libc that was causing this problem (http://sources.redhat.com/ml/libc-alpha/2006-09/msg00063.html). Paul Thanks, Rafael ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] compiling qemu with arm compiler
Hello, Quite a dilema here, my objective is to execute a linux x86 binary on an linux arm host. I played with the qemu tarball relentlessly and I am not capable of getting qemu compiled with a arm target to support i386-user. Is it possible to get qemu to compile with an arm gcc compiler? If not is their any other recomendations to meet my objective? Thank you, Jonathan __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] PDF bug
Anyone else noticed qemu crash with Windows XP guest and pdf creation software? Prerequisites: Windows XP (any SP level) Adobe Acrobat Profesional 7.xx OR Nitro PDF Qemu 0.8.2 (without kqemu) Symptons: Launcing any of the apps crash the app (with Adobe Acrobat Pro it's in module Technical detail: Acrobat error: Faulting application acrobat.exe, version 7.0.5.172, faulting module libmysqld.dll, version 4.0.20.0, fault address 0x000bb2de Nitro error: The application, C:\Program Files\Nitro PDF\bin\ZDPlus.exe, generated an application error. ...The exception generated was c005 at address 100015C5 (ZeonData!CZeonString_CZeonString) Extra notes: If you run kqemu problem not present, using same VM running without kqemu, issue occur. Although suggesting to run qemu with kqemu seems like the obvious answer, I need to run it without kqemu as cannot install kqemu on all the machines I need to run it (admin rights). Regards ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: Regression: QEMU 0.8.2 (and CVS) fails to boot a debian arm
On Wed, Sep 06, 2006 at 12:14:44PM +0200, Aurelien Jarno wrote: I have setup a debian arm (unstable) under QEMU, until now using version 0.8.1 and a root on NFS. I wanted to use the new SCSI card emulation introduced in QEMU 0.8.2, but it fails to boot (still with root on NFS). It freeze, the last message being: INIT: version 2.86 booting I think I have found the problem. Actually the system is not frozen, but just very slow. I now get while booting the kernel: Calibrating delay loop... 12.16 BogoMIPS (lpj=60800) instead of Calibrating delay loop... 486.60 BogoMIPS (lpj=2433024) I suffered the same exact symptom, except that in my case it was caused by a kernel upgrade and fixed by using a kernel that was 2.6.16-rc3 or later while vanilla 2.6.16 gave this incredible slowdown. That may or may not be relevant... M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-arm user mode does not work with ARM EABI
Summary:
Ever since QEMU 0.8.1, qemu-arm-system mode works fine with ARM EABI
kernel and rootfs, but qemu-arm single-process mode is broken with
EABI, failing with "Unknown system call 0xf0005".
This is ARM private system call "set_tls", called from both the
linuxthreads and the NPTL pthread implementations in glibc-2.4, and
unimplemented in QEMU.
It is important that this mode work because scratchbox needs it to
be able to cross-compile Debian packages for the forthcoming
EABI-based Debian architecture.
Detail:
I have three kinds of ARM root filesystem:
- standard Debian ARM sarge using old-ABI: (glibc-2.3.6, linuxthreads)
- Voipio's "eabi-rootfs" which I gather uses EABI internally and glibc
shims to convert the system calls to old-ABI just before they hit the
kernel (glibc-2.3.4)
- Koen's EABI-toolchain-rootfs (from the Angstrom distro of
OpenEmbedded) which uses pure EABI (glibc-2.4,nptl)
# Here they are
martin:~/tftpboot$ ls
EABI-toolchain-rootfs/ debian-sarge-arm/ eabi-rootfs/
In qemu-system-arm (softmmu target) all three run fine (given
appropriate kernels) but qemu-arm fails on the second two.
# Even qemu-arm 0.8.1 works on old ABI
martin:~/tftpboot$ /usr/bin/qemu-arm -L `pwd`/deb* deb*/bin/echo hi
hi
martin:~/tftpboot$
# Both of the EABI scenarios fail the same way.
# With Debian QEMU (0.8.1):
martin:~/tftpboot$ /usr/bin/qemu-arm -L `pwd`/EABI* EABI*/bin/echo hi
Error: f0005
qemu: uncaught target signal 6 (Aborted) - exiting
martin:~/tftpboot$
# With qemu-arm 0.8.2 compiled from source (using gcc-3.4 of course):
martin:~/tftpboot$ /usr/local/bin/qemu-arm -L `pwd`/EABI* EABI*/bin/echo hi
qemu: Unsupported syscall: 983045
cannot set up thread-local storage: unknown error
martin:~/tftpboot$ echo 'obase=16; 983045' | bc
F0005
martin:~/tftpboot$
This is not a case of the new EABI picking up old ABI system calls,
which were encoded as SWI #(0x90 + n).
A couple of debugging printfs show that with the pure EABI rootfs, the
system call number is picked up by QEMU from r7 as it should, and when
executing a simple binary it correctly picks up about 20 system calls
starting with 'brk; uname; access; open; fstat64; mmap2' and ending
with 'close; mmap2; [F0005]; truncate; io_submit; [fail]'.
Using the intermediate glibc-shims version, the same bogus system call
number is received via the old-ABI system call mechanism.
The Linux kernel source, while decoding ARM system calls says
in arch/arm/kernel/traps.c
* 0x9f - 0x9f are some more esoteric system calls
and if we subtract the old syscall offset of 0x90 from this we get
our symptom of 0xf000* The extra __ARM_NR_* system call numbers run
from __NR_SYSCALL_BASE+__ARM_NR_BASE (0x90 + 0xf) and are
defined in include/asm-arm/unistd.h as:
1 __ARM_NR_breakpoint
2 __ARM_NR_cacheflush
3 __ARM_NR_usr26
4 __ARM_NR_usr32
5 __ARM_NR_set_tls <--- this one
This is glibc-2.4 using the internal ARM system call set_tls to
initialise(?) the thread local storage (something which the shims for
glibc-2.3.4 also evidently do). It is called from the macro:
glibc-2.4/ports/sysdeps/arm/{linuxthreads,nptl}/tls.h:
/* Code to initially initialize the thread pointer. This might need
special attention since 'errno' is not yet available and if the
operation can cause a failure 'errno' must not be touched. */
# define TLS_INIT_TP(TCBP, SECONDCALL) \
({ INTERNAL_SYSCALL_DECL (err); \
long result_var; \
result_var = INTERNAL_SYSCALL_ARM (set_tls, err, 1, (TCBP)); \
INTERNAL_SYSCALL_ERROR_P (result_var, err) \
? "unknown error" : NULL; })
And this is what the Linux kernel does with that:
linux-2.6.17/arch/arm/kernel/traps.c:
case NR(set_tls):
thread->tp_value = regs->ARM_r0;
#if defined(CONFIG_HAS_TLS_REG)
asm ("mcr p15, 0, %0, c13, c0, 3" : : "r" (regs->ARM_r0) );
#elif !defined(CONFIG_TLS_REG_EMUL)
/*
* User space must never try to access this directly.
* Expect your app to break eventually if you do so.
* The user helper at 0x0fe0 must be used instead.
* (see entry-armv.S for details)
*/
*((unsigned int *)0x0ff0) = regs->ARM_r0;
#endif
return 0;
Quite what that really means, and what QEMU should do about it, are
unclear to me. I've tried ignoring the f0005 system call, and the ARM
program segfaults straight away, so I guess *something* is necessary.
The 32-bit parameter ARM_r0 is always in the 0x7e* and 0x7f* range and
is different at each execution. Does this call set the area used for
thread-local storage?
Any ideas?
M
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] A question about QEMU performance
> If I run qemu for i386 without kqemu it uses soft-mmu, so it operates as > another architetture as ppc or mips right? > So... are the performace of qemu the same if I use i386 or mips or something > change deeply? > Example: if I run the same program on i386 emulation without kqemu or on > mips are the performance circa the same? Would you expect qemu to perform the same on an AMD 4600X2 as a 400 Mhz MIPS? There are some statistics at freaknet.org/martin/QEMU for various types of x86 processor, but giving only BogoMIPS, which are way overrated. I presume this is cos QEMU translates the kernel speed test loop once then runs it as x86 code, while "real" tasks need to be translated all the time. The only concrete figures I have are from when I timed the running of bash's configure script, which causes a lot of program execution as well as compiling and running lots of short test programs. The results are in cluster.aleph1.co.uk/~martin/qemu.html (please ignore the other garbage on that page!) M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] A question about QEMU performance
There are some statistics at freaknet.org/martin/QEMU for various are in cluster.aleph1.co.uk/~martin/qemu.html (please ignore the other Sorry, that first page is bogus. I meant the second. M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: qemu-arm user mode does not work with ARM EABI
2006/9/26, Martin Guy <[EMAIL PROTECTED]>: Ever since QEMU 0.8.1, qemu-arm-system mode works fine with ARM EABI kernel and rootfs, but qemu-arm single-process mode is broken with EABI, failing with "Unknown system call 0xf0005". Fixed for simple cases by pbrook's preliminary patches mentioned at http://lists.gnu.org/archive/html/qemu-devel/2006-09/msg00194.html These patches do not apply cleanly using "patch" (it can't find most of the files to patch), so I've repackaged them and put the trouble-free version (cd qemu-0.8.2; patch -p1 < ../patch*mg1) under http://freaknet.org/martin/QEMU Bless M ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] future OS X support
Am 29.08.2006 um 00:29 schrieb Fabrice Bellard: Hi, Mike Kronenberg wrote: @Fabrice How are your plans about supporting OS X in the future? We, for our part, are eager to push dev on OS X: - with the patches of Gwenole and pbrook, qemu 0.8.2 builds great on OS X ppc and intel (gcc4). All tests are OK. Maybe I can merge part of it if the changes are not too intrusive ? We are currently in the progress of investigating and merging, because most patches do not apply gracefully to current CVS and some should be obsolete. As soon as we are done with this process we will send over the patches. - I'm willing to rewrite my OS X block.c patches for hardware CD- ROM support. OK. - I've just written a complete new cocoa frontend based on Anthony shmem patches (quartz and openGL). (only problem is the 4mb limit on OS X atm) Good. Why is cocoa.m not sufficient ? Because it is not flexible enough. We wrote nearly 10,000 lines of code for the qemu enhancing part and Q frontend itself and the Interface Builder files (nib) save us approximately another 10,000 lines, I think. The shmem code allows us drop most of qemu enhancing part fortunately. - There are some other small patches like basic bootorder support that are ready, too. This one will be merged ASAP. As qemu was one of the first usable emulators on OS X, it is still widely used and known. Things even look like we get included on the C'T disk next month IMHO, you should concentrate on porting kqemu on Mac OS X. I don't think it should be more more complicated than the other ports. I can provide support for that if someone if motivated. With kqemu you would be able to compete with the other (and more expensive !) virtualizers... Thanks for offering support for this. We are of course interested in having kqemu on Mac OS X. I already spoke to Mike and we are willing to try the port. Can you specify what needs to be done first to do the port? Mike already mentioned that kqemu is mostly os-independent and the dependent parts are in qemu. Regards, cordney* Regards, Fabrice. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-arm user mode does not work with ARM EABI
- Voipio's "eabi-rootfs" which I gather uses EABI internally and glibc shims to convert the system calls to old-ABI just before they hit the kernel (glibc-2.3.4) I have a similar setup with a maemo 2.0 rootstrap (glibc 2.3.5). I am currently able to compile a functional python package. I am not sure if there is any particular patch applied to glibc, but you can find the patches at http://repository.maemo.org/pool/maemo2.0/free/source/ Best Regards, Rafael ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-arm user mode does not work with ARM EABI
On Tuesday 26 September 2006 19:27, Martin Guy wrote: > Summary: > Ever since QEMU 0.8.1, qemu-arm-system mode works fine with ARM EABI > kernel and rootfs, but qemu-arm single-process mode is broken with > EABI, failing with "Unknown system call 0xf0005". > This is ARM private system call "set_tls", called from both the > linuxthreads and the NPTL pthread implementations in glibc-2.4, and > unimplemented in QEMU. > It is important that this mode work because scratchbox needs it to > be able to cross-compile Debian packages for the forthcoming > EABI-based Debian architecture. I've already answered this question three times in the last month... > Fixed for simple cases by pbrook's preliminary patches mentioned at > http://lists.gnu.org/archive/html/qemu-devel/2006-09/msg00194.html ... the answer is in that email. > These patches do not apply cleanly using "patch" (it can't find most > of the files to patch) The original patch applies fine with patch -p0. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] qemu-0.8.2 question..
I saw the file src/hw/lance.c. Is it the driver for amdlance NIC (as the one emulated in vmware)? I don't know what vmware emulates, but the Lance NIC for Sparc32 is based on Am7990. In the CVS version it was merged with PCNet driver, because Am79C970A is fully downwards compatible towards Am7990. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu-arm is a shared library?
When I build qemu-0.8.2, qemu-arm is a shared library rather than being an executable. This seems highly suspicious and makes it particularly difficult to debug. What's the rationale behind this? --rich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu-arm is a shared library?
On Friday 29 September 2006 18:52, K. Richard Pixley wrote: > When I build qemu-0.8.2, qemu-arm is a shared library rather than being > an executable. This seems highly suspicious and makes it particularly > difficult to debug. What's the rationale behind this? http://www.qemu.org/qemu-tech.html#SEC23 You can disable it by configuring with --static. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-i386 helper.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Fabrice Bellard06/09/29 20:01:17 Modified files: target-i386: helper.c Log message: 32 bit RSP update fix (aka Open Solaris x86_64 bug) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.72&r2=1.73 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] qemu/target-i386 helper.c
Woohoo! Thanks to everybody on the quick turnaround on this, it's very exciting to see it booting now. :) - Eric --- Fabrice Bellard <[EMAIL PROTECTED]> wrote: > CVSROOT: /sources/qemu > Module name: qemu > Changes by: Fabrice Bellard06/09/29 > 20:01:17 > > Modified files: > target-i386: helper.c > > Log message: > 32 bit RSP update fix (aka Open Solaris x86_64 bug) > > CVSWeb URLs: > http://cvs.savannah.gnu.org/viewcvs/qemu/target-i386/helper.c?cvsroot=qemu&r1=1.72&r2=1.73 > > > ___ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
