[Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
Following the patches done for elfload32, it appeared to me that there
were still problems that would prevent 32 bits executables to run on 64
bits target in linux user mode emulation.
First of all, the personality was never set to PER_LINUX32
The second problem was that pointers used to set the values on the stack
were still of target_ulong size, which lead 32 bits executable crash
dereferencing NULL pointers as soon as they wanted to parse their
arguments.
The attached patch makes 32 bits PowerPC executables run in
ppc64_linux_user target. More fixes may be needed in the start_thread
function and elf_check_arch to make other targets run as well.
Please comment.
--
J. Mayer [EMAIL PROTECTED]
Never organized
Index: configure
===
RCS file: /sources/qemu/qemu/configure,v
retrieving revision 1.161
diff -u -d -d -p -r1.161 configure
--- configure 9 Oct 2007 16:34:28 - 1.161
+++ configure 10 Oct 2007 07:38:59 -
@@ -1029,11 +1030,12 @@ elif test $target_cpu = ppc ; then
echo TARGET_ARCH=ppc $config_mak
echo #define TARGET_ARCH \ppc\ $config_h
echo #define TARGET_PPC 1 $config_h
elif test $target_cpu = ppc64 ; then
echo TARGET_ARCH=ppc64 $config_mak
echo #define TARGET_ARCH \ppc64\ $config_h
echo #define TARGET_PPC 1 $config_h
echo #define TARGET_PPC64 1 $config_h
+ elfload32=yes
elif test $target_cpu = ppcemb ; then
echo TARGET_ARCH=ppcemb $config_mak
echo #define TARGET_ARCH \ppcemb\ $config_h
Index: linux-user/elfload.c
===
RCS file: /sources/qemu/qemu/linux-user/elfload.c,v
retrieving revision 1.51
diff -u -d -d -p -r1.51 elfload.c
--- linux-user/elfload.c 9 Oct 2007 16:34:29 - 1.51
+++ linux-user/elfload.c 10 Oct 2007 07:38:59 -
@@ -12,65 +12,10 @@
#include qemu.h
#include disas.h
-/* from personality.h */
-
-/*
- * Flags for bug emulation.
- *
- * These occupy the top three bytes.
- */
-enum {
- ADDR_NO_RANDOMIZE = 0x004, /* disable randomization of VA space */
- FDPIC_FUNCPTRS = 0x008, /* userspace function ptrs point to descriptors
- * (signal handling)
- */
- MMAP_PAGE_ZERO = 0x010,
- ADDR_COMPAT_LAYOUT = 0x020,
- READ_IMPLIES_EXEC = 0x040,
- ADDR_LIMIT_32BIT = 0x080,
- SHORT_INODE = 0x100,
- WHOLE_SECONDS = 0x200,
- STICKY_TIMEOUTS = 0x400,
- ADDR_LIMIT_3GB = 0x800,
-};
-
-/*
- * Personality types.
- *
- * These go in the low byte. Avoid using the top bit, it will
- * conflict with error returns.
- */
-enum {
- PER_LINUX = 0x,
- PER_LINUX_32BIT = 0x | ADDR_LIMIT_32BIT,
- PER_LINUX_FDPIC = 0x | FDPIC_FUNCPTRS,
- PER_SVR4 = 0x0001 | STICKY_TIMEOUTS | MMAP_PAGE_ZERO,
- PER_SVR3 = 0x0002 | STICKY_TIMEOUTS | SHORT_INODE,
- PER_SCOSVR3 = 0x0003 | STICKY_TIMEOUTS |
- WHOLE_SECONDS | SHORT_INODE,
- PER_OSR5 = 0x0003 | STICKY_TIMEOUTS | WHOLE_SECONDS,
- PER_WYSEV386 = 0x0004 | STICKY_TIMEOUTS | SHORT_INODE,
- PER_ISCR4 = 0x0005 | STICKY_TIMEOUTS,
- PER_BSD = 0x0006,
- PER_SUNOS = 0x0006 | STICKY_TIMEOUTS,
- PER_XENIX = 0x0007 | STICKY_TIMEOUTS | SHORT_INODE,
- PER_LINUX32 = 0x0008,
- PER_LINUX32_3GB = 0x0008 | ADDR_LIMIT_3GB,
- PER_IRIX32 = 0x0009 | STICKY_TIMEOUTS,/* IRIX5 32-bit */
- PER_IRIXN32 = 0x000a | STICKY_TIMEOUTS,/* IRIX6 new 32-bit */
- PER_IRIX64 = 0x000b | STICKY_TIMEOUTS,/* IRIX6 64-bit */
- PER_RISCOS = 0x000c,
- PER_SOLARIS = 0x000d | STICKY_TIMEOUTS,
- PER_UW7 = 0x000e | STICKY_TIMEOUTS | MMAP_PAGE_ZERO,
- PER_OSF4 = 0x000f, /* OSF/1 v4 */
- PER_HPUX = 0x0010,
- PER_MASK = 0x00ff,
-};
-
/*
* Return the base personality without flags.
*/
-#define personality(pers) (pers PER_MASK)
+#define personality(pers) ((pers) PER_MASK)
/* this flag is uneffective under linux too, should be deleted */
#ifndef MAP_DENYWRITE
@@ -215,6 +160,7 @@ enum
#define ELF_START_MMAP 0x8000
#define elf_check_arch(x) ( (x) == EM_SPARCV9 || (x) == EM_SPARC32PLUS )
+#define elf_check_arch32(x) ( (x) == EM_SPARC32PLUS )
#define ELF_CLASS ELFCLASS64
#define ELF_DATAELFDATA2MSB
@@ -261,7 +207,8 @@ static inline void init_thread(struct ta
#ifdef TARGET_PPC64
-#define elf_check_arch(x) ( (x) == EM_PPC64 )
+#define elf_check_arch(x) ( (x) == EM_PPC64 || (x) == EM_PPC )
+#define elf_check_arch32(x) ( (x) == EM_PPC )
#define ELF_CLASS ELFCLASS64
@@ -311,32 +258,51 @@ do {
NEW_AUX_ENT(AT_IGNOREPPC, AT_IGNOREPPC); \
} while (0)
-static inline void init_thread(struct target_pt_regs *_regs, struct image_info *infop)
+static inline void init_thread(struct target_pt_regs *_regs,
+ struct image_info *infop)
{
target_ulong pos = infop-start_stack;
-target_ulong tmp;
+target_ulong tmp, elen;
#ifdef TARGET_PPC64
target_ulong entry, toc;
#endif
-_regs-msr = 1 MSR_PR; /* Set user mode */
+_regs-msr = 1ULL MSR_PR; /*
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). Fabrice.
[Qemu-devel] Hacking QEMU to use a real video card
I was curious if anyone thinks that it may be possible to get a KVM-patched QEMU to use a real video card? For example, let's say I had a second video card. Is QEMU a codebase which would support hacking in the ability to utilize this second video card? And in the situation of a laptop, would it be possible to boot the host Linux in a way that it would not utilize the video card, but get a qemu guest to use it? Theoretically, there's no reason this isn't possible, right? Thanks, - Tony
[Qemu-devel] FP emulation bugs for x86_64-softmmu
Some x86_64 SSE2 instructions that convert floats to ints appear to ignore the rounding mode (in mxcsr), and so produce wrong results if mxcsr is set to anything other than default rounding. For example cvtsd2si et al. I'm looking at softfloat-native.c and softfloat.c and wondering how to fix it. A couple of questions: * is softfloat-native.c intended to handle such corner cases as accurately as softfloat.c ? * is it possible to build x86_64-softmmu to use softfloat.c rather than softfloat-native.c? I hacked ./configure to use CONFIG_SOFTFLOAT for x86_64 (added x86_64 as a softfloat cpu in test at line 1095), but the build then dies like this: target-i386/exec.h:296: warning: conflicting types for built-in function 'sinl' target-i386/exec.h:297: warning: conflicting types for built-in function 'cosl' target-i386/exec.h:298: warning: conflicting types for built-in function 'sqrtl' target-i386/exec.h:299: warning: conflicting types for built-in function 'powl' target-i386/exec.h:300: warning: conflicting types for built-in function 'logl' target-i386/exec.h:301: warning: conflicting types for built-in function 'tanl' target-i386/exec.h:302: warning: conflicting types for built-in function 'atan2l' target-i386/exec.h:303: warning: conflicting types for built-in function 'floorl' target-i386/exec.h:304: warning: conflicting types for built-in function 'ceill' target-i386/exec.h: In function `helper_fldt': target-i386/exec.h:440: error: incompatible types in return target-i386/exec.h: In function `helper_fstt': target-i386/exec.h:447: error: incompatible types in assignment (many more errors like this follow) Is this some minor compile bug, or is it the case that x86_64-softmmu (and i386-softmmu) is not intended to use softfloat.c? J
[Qemu-devel] Re: [kvm-devel] FreeBSD image hangs during boot
Avi Kivity a écrit : Aurelien Jarno wrote: Avi Kivity a écrit : Aurelien Jarno wrote: I also confirm that using -no-acpi fixes the problem. However, I have seen strange data corruption, even on Intel. Basically, booting a recently installed FreeBSD leads to the following message from the bootloader: No kernel found. And the next time, I get from the *BIOS*: Boot from Hard Disk failed: not a bootable disk. Looking at the disk image, the partition table (and maybe more?) has disappeared. This is with a raw image disk. [snip] After a few more tests, I have been able to reproduce it with the current CVS version of QEMU. I conclude this is a QEMU or a BIOS problem, and not a KVM one. Sorry for the noise. Well, it still needs to be fixed. I think there's a git import of qemu available somewhere, that can be used for bisecting. Well the IDE code hasn't changed a lot recently, so I checked the CVS history and easily (first test) found the commit that causes the problem: Last AIO patch, by Vladimir N. Oleynik. http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemur1=1.64r2=1.65 -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net
[Qemu-devel] i386 page fault recovery / user-code continuation
hi everyone! I have a question concerning how i386 execution is continued after a page fault has occured... What I have understood so far: In the executing TB the TLB is checked and if the address is not found __ld (e.g. __ldl_user) is called. this calls lb_fill (if it really has to) which in turns asks cpu_x86_handle_mmu_fault if it is really a page fault or just a TLB miss... if it is a fault however, tb_find_pc finds the TB and its last assembler instruction and uses raise_exception_err to jump to the main-loop and handle the fault there --- I hope this is correct so far :-) My question now: where does the execution continue after the fault has been handled? the saved assembler-instruction is the instruction AFTER call __ldl_user , what does not really make sense to jump back to... Does cpu_restore_state find out what the last executing, translated op-code was, restores that and continues at the BEGINNING of that op-code TB?? If someone could help me out on this, it'd be really appreciated ;-) Thanks!!!
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
On 10/10/07, J. Mayer [EMAIL PROTECTED] wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. First of all, the personality was never set to PER_LINUX32 It's set in elfload32.c, but I think your approach is better. The check for elf_ex-e_ident[EI_CLASS] == ELFCLASS64 could be moved from elfload32.c. The second problem was that pointers used to set the values on the stack were still of target_ulong size, which lead 32 bits executable crash dereferencing NULL pointers as soon as they wanted to parse their arguments. Nice, I was wondering why my test program crashed.
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
On 10/10/07, Fabrice Bellard [EMAIL PROTECTED] wrote: J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). True. But I hope some day we have Solaris binary execution support, and we need this 32+64 mode for that. I think Linux can emulate Solaris system calls.
[Qemu-devel] Sparc taddctv/tsubcctv patch
This patch fixes a couple of bugs in taddcctv and tsubcctv on the Sparc. It saves the state so that if the instructions trap the correct address is delivered to the kernel and it fixes the detection of overflow in taddcctv. This was patched against CVS version of 20070816 but the fixes don't seem to be in the current CVS. To provide a bit of context: I'm maintaining Poly/ML (www.polyml.org) on various platforms including the Sparc. The Sparc code-generator is now nearly 20 years old and uses the taddcctv and tsubcctv instructions for arbitrary precision arithmetic. I'm using an ageing Sparcstation 5 with 16M and it is painfully slow so I tried out qemu. I couldn't get Solaris to boot but the Debian installation runs fine. I was using the Debian package of qemu which seems to have been prepared on 16th August. I did try the latest CVS but that gave an exception on booting Sparc Debian. Perhaps I need a newer version of openbios as well. Thanks for all your work on qemu. David. Index: target-sparc/op.c === RCS file: /sources/qemu/qemu/target-sparc/op.c,v retrieving revision 1.35 diff -u -r1.35 op.c --- target-sparc/op.c 11 Jul 2007 16:43:30 - 1.35 +++ target-sparc/op.c 10 Oct 2007 16:26:34 - @@ -531,7 +531,7 @@ ((src1 0x) ^ (T0 0x))) (1 31)) raise_exception(TT_TOVF); #else -if ((src1 0x03) || (T1 0x03)) +if (((src1 ^ T1 ^ -1) (src1 ^ T0)) (1 31)) raise_exception(TT_TOVF); #endif Index: target-sparc/translate.c === RCS file: /sources/qemu/qemu/target-sparc/translate.c,v retrieving revision 1.65 diff -u -r1.65 translate.c --- target-sparc/translate.c11 Jul 2007 16:43:30 - 1.65 +++ target-sparc/translate.c10 Oct 2007 16:26:36 - @@ -1928,10 +1928,12 @@ gen_movl_T0_reg(rd); break; case 0x22: /* taddcctv */ +save_state(dc); gen_op_tadd_T1_T0_ccTV(); gen_movl_T0_reg(rd); break; case 0x23: /* tsubcctv */ +save_state(dc); gen_op_tsub_T1_T0_ccTV(); gen_movl_T0_reg(rd); break;
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
Fabrice Bellard wrote: J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). I would think this feature will be limited to platforms which can handle 32bit and 64bit binaries with a single personality. Thiemo
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
On Wed, 2007-10-10 at 19:01 +0300, Blue Swirl wrote: On 10/10/07, J. Mayer [EMAIL PROTECTED] wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. First of all, the personality was never set to PER_LINUX32 It's set in elfload32.c, but I think your approach is better. The check for elf_ex-e_ident[EI_CLASS] == ELFCLASS64 could be moved from elfload32.c. Well, it is overriden just before the create_elf_table call... And it's especially needed there and in the start_thread code, at least for PowerPC. As the kernel set it up at this point, it seems to be a good idea to do the same ! The second problem was that pointers used to set the values on the stack were still of target_ulong size, which lead 32 bits executable crash dereferencing NULL pointers as soon as they wanted to parse their arguments. Nice, I was wondering why my test program crashed. I realized there are tons of unneeded checks/code in my patch, as this code is compiled twice. I will repost a cleaned one soon... -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
Thiemo Seufer wrote: Fabrice Bellard wrote: J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). I would think this feature will be limited to platforms which can handle 32bit and 64bit binaries with a single personality. I am not sure it is a common case ! However, I suggest to emulate a 32 bit user linux system with a 64 bit guest CPU running in 32 bit compatibily mode. It would be useful to test 64 bit CPUs in 32 bit compatibility mode. The only required modification in linux user is to rename target_ulong so that it can have a different size of the CPU word default size. Regards, Fabrice.
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
On 10/10/07, Fabrice Bellard [EMAIL PROTECTED] wrote: Thiemo Seufer wrote: Fabrice Bellard wrote: J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). I would think this feature will be limited to platforms which can handle 32bit and 64bit binaries with a single personality. I am not sure it is a common case ! However, I suggest to emulate a 32 bit user linux system with a 64 bit guest CPU running in 32 bit compatibily mode. It would be useful to test 64 bit CPUs in 32 bit compatibility mode. The only required modification in linux user is to rename target_ulong so that it can have a different size of the CPU word default size. I think this would be sufficient for the Sparc and this way there would be no need to convert the structures. Brilliant! Should we revert the elfload32 patch? What about PPC?
[Qemu-devel] qemu/target-sparc op.c translate.c
CVSROOT:/cvsroot/qemu Module name:qemu Changes by: Blue Swirl blueswir1 07/10/10 19:11:54 Modified files: target-sparc : op.c translate.c Log message: Fix taddcctv and tsubcctv (David Matthews) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/op.c?cvsroot=qemur1=1.41r2=1.42 http://cvs.savannah.gnu.org/viewcvs/qemu/target-sparc/translate.c?cvsroot=qemur1=1.73r2=1.74
Re: [Qemu-devel] RFC: fix run of 32 bits Linux executables on 64 bits targets
On Wed, 2007-10-10 at 22:02 +0300, Blue Swirl wrote: On 10/10/07, Fabrice Bellard [EMAIL PROTECTED] wrote: Thiemo Seufer wrote: Fabrice Bellard wrote: J. Mayer wrote: Following the patches done for elfload32, it appeared to me that there were still problems that would prevent 32 bits executables to run on 64 bits target in linux user mode emulation. [...] Are you sure it is a good idea to try to add 32 bit executable support to a 64 bit target ? In the end you will need to write a 64 bit to 32 bit linux syscall converter which would mean duplicating all the linux-user code of the corresponding 32 bit target (think of ioctls with strutures, signals frames, etc...). I would think this feature will be limited to platforms which can handle 32bit and 64bit binaries with a single personality. I am not sure it is a common case ! However, I suggest to emulate a 32 bit user linux system with a 64 bit guest CPU running in 32 bit compatibily mode. It would be useful to test 64 bit CPUs in 32 bit compatibility mode. The only required modification in linux user is to rename target_ulong so that it can have a different size of the CPU word default size. I think this would be sufficient for the Sparc and this way there would be no need to convert the structures. Brilliant! Should we revert the elfload32 patch? What about PPC? We can keep the elfload32 for now, it does not hurt. This approach is OK for PPC too. And as I got some 32 bits programs running in the 64 bits linux-user emulator, the same programs behavior can be compared to find eventual issues... -- J. Mayer [EMAIL PROTECTED] Never organized
Re: [Qemu-devel] qemu-system-m68k and booting m68k images
On Saturday 06 October 2007 8:59:02 pm Ian Graeme Hilt wrote: Two questions: 1. Why does qemu-system-m68k require a kernel image? I'd actually be pretty happy if I could figure out which kernel image I could build that the sucker would boot. qemu-system-m68k -M ? lists two boards: the mcf5208evb and arnewsh 5206 are both coldfire board. I got gcc to build an m68k toolchain and want to run an actual m68k kernel, but the only Kconfig entries mentioning those are in the m68knommu architecture... 2. Is support planned for booting m68k bootable images, e.g. floppy images, harddrive images? First, is support planned for booting an m68k system at all, rather than a coldfire one? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson.
Re: [Qemu-devel] qemu-system-m68k and booting m68k images
On Wed, Oct 10, 2007 at 06:20:57PM -0500, Rob Landley wrote: On Saturday 06 October 2007 8:59:02 pm Ian Graeme Hilt wrote: Two questions: 1. Why does qemu-system-m68k require a kernel image? I'd actually be pretty happy if I could figure out which kernel image I could build that the sucker would boot. Have you tried http://fabrice.bellard.free.fr/qemu/coldfire-test-0.1.tar.bz2 qemu-system-m68k -M ? lists two boards: the mcf5208evb and arnewsh 5206 are both coldfire board. I got gcc to build an m68k toolchain and want to run an actual m68k kernel, but the only Kconfig entries mentioning those are in the m68knommu architecture... 2. Is support planned for booting m68k bootable images, e.g. floppy images, harddrive images? First, is support planned for booting an m68k system at all, rather than a coldfire one? Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. -- Ian Graeme Hilt
