Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)
Thomas Orgis wrote: Am Fri, 23 Mar 2007 15:45:49 + schrieb Paul Brook [EMAIL PROTECTED]: I do not understand enough of QEMU yet, but I have checked out CVS and am reading through its source. When I understand more I hope we can fix this long-standing annoyance. This is GCC PR16185 http://gcc.gnu.org/PR16185. Hm, I think I stumbled over this before... so it is still valid. There's no fundamental reason why some options trigger it, and others don't. It trigerrs fairly randomly depending on the code generation choices gcc happens to make. So it is indeed the case that nothing particular in qemu triggers it, just the general grab on the registers. And it is something that won't be fixed anytime soon (in gcc), apart from ia32 going out of use... Personally, I started using qemu with my Pentium-M 1.4GHz laptop... so 32bit is the way there for a few years. So I'll check for every new qemu release and gcc version if it perhaps builds with normal optimization settings... or one identifies a spot to release a register for x86 where it doesn't hurt qemu (since it's always softmmu_template.h with helper.c). Anyway, this sounds more and more like a FAQ entry. Perhaps it should be mentioned in qemu docs. The problem is that x86 is chronically short of registers. qemu makes this significantly worse by telling gcc it can't use most of them. gcc simply isn't designed to work in these extreme situations. Yep, x86 is chronically short of many things and loaded with others. At work I secured two good old XP1000 alphas for myself... they're not really as fast as my laptop, but register starvation is nothing I expect to happen there. They got .. hm, what's the correct term... a shitload of registers! ;-) x86 really was the worst arch to become market leader for home computing. On the other hand that leadership was what made the arch mutate in the ways it did. Thomas. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel As far as X86 is concerned i386/i486/i586 are very different from later generation processors. I am wondering whether another host and target architecture could be created called i686 that makes use of something like MMX or other registers in Intel Pentium II/III/4 and AMD Athlon to negate the lack of general purpose registers. In a certain sense i486 compatibility holds back the options you have for optimisation. The fact that QEMU works and can be optimised on x86_64 is the only saving grace for the architecture, that is still suffering from a lack of registers compared to any other architecture. Anyhow, I expect 32-bit hardware to gradually die because of wear and tear in the next few years and the replacement will be 64-bit hardware so the problem will solve itself that way. Sunil. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] 0.9.0 and svn don't build with -march=pentium2 etc.; was: Latest SVN fails to build on Fedora Core 6 (same with 0.9.0)
As far as X86 is concerned i386/i486/i586 are very different from later generation processors. I am wondering whether another host and target architecture could be created called i686 that makes use of something like MMX or other registers in Intel Pentium II/III/4 and AMD Athlon to negate the lack of general purpose registers. I don't see how. MMX/SSE is suitable for SIMD processing of media data and to some extent for floating point, but is largely unusable for ad-hoc integer computation, especially anything that involves address calculations. The fact that QEMU works and can be optimised on x86_64 is the only saving grace for the architecture, that is still suffering from a lack of registers compared to any other architecture. The lack of registers isn't ideal, but it's not a big deal, and in the grand scheme of things x86_64 has a lot going for it. The most important of which are that (from the software side) all the hard-won knowledge of how to compile good code for x86 carries across more or less directly to x86_64, and (from the hardware side) hardware people already know how to make fast, cheap x86s, so it's easy to move to making fast, cheap x86_64s. The problems of the gcc backend to qemu have already been discussed extensively on this list. Stealing 3+ registers from gcc on x86 really is asking for trouble, and I believe it is generally understood that the best long term solution is to move to a self-contained back end that does not use gcc for dynamic code generation. J ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Sparc user broken
Hi, Programs in the Sparc test suite do not work currently, some even crash. Running cvs-bisect revealed that the following change has broken Sparc32 user emulation. Index: Makefile.target === RCS file: /cvsroot/qemu/qemu/Makefile.target,v retrieving revision 1.150 retrieving revision 1.151 diff -u -r1.150 -r1.151 --- Makefile.target 18 Mar 2007 23:23:31 - 1.150 +++ Makefile.target 19 Mar 2007 13:32:45 - 1.151 @@ -208,6 +208,7 @@ ifdef CONFIG_LINUX_USER OBJS= main.o syscall.o mmap.o signal.o path.o osdep.o thunk.o \ elfload.o linuxload.o +LIBS+= $(AIOLIBS) ifdef TARGET_HAS_BFLT OBJS+= flatload.o endif Linking without -lrt gives a working emulator, but i386 needs -lrt for clock_gettime. Any suggestions? _ 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] Problem with x86_64 bit linux guest (2.6.18), opensuse
All, some time ago I reported problems with Qemu and the installation of openSUSE 10.1 or 10.2 64bit systems. Today I did a CVS download and compiled Qemu again, using a gcc 3.3.6 compiler. To simplify it I configured it as follows: ./configure --prefix=/usr/local --cc=/opt/gcc33/bin/gcc-3.3 \ --enable-adlib --target-list=i386-softmmu x86_64-softmmu For Kqemu I use that latest tar.gz version (1.3.0pre11), compiled with the standard compiler (gcc 4.1.2) on my openSUSE 10.2 system (Host). Hardware is AMD Athlon 64bit. My W2K works with qemu, with -kernel-kqemu -no-acpi. But trying to install a standard openSUSE 10.2 from DVD image fails. When using -kernel-kqemu it loops (seems forever), starting without it crashes shortly after the installation process started while scaning some devices. Checking documentation says: x86_64 full virtualization support for kqemu. Is this a know problem? shall I use a different gcc to build qemu? some switches to set? config options? Regards, Werner ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] please review smc91c111 network bug fix
address mapping error and cause arm versatile unstable.
Index: hw/smc91c111.c
===
RCS file: /sources/qemu/qemu/hw/smc91c111.c,v
retrieving revision 1.5
diff -u -r1.5 smc91c111.c
--- hw/smc91c111.c 21 Dec 2006 17:23:49 - 1.5
+++ hw/smc91c111.c 24 Mar 2007 18:15:21 -
@@ -446,7 +446,9 @@
case 7:
/* Not implemented. */
return 0;
-case 8: /* Free memory available. */
+case 8: /* Memory size. */
+return NUM_PACKETS;
+case 9: /* Free memory available. */
{
int i;
int n;
@@ -457,8 +459,6 @@
}
return n;
}
-case 9: /* Memory size. */
-return NUM_PACKETS;
case 10: case 11: /* RPCR */
/* Not implemented. */
return 0;
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64 -no-kqemu) compiles with gcc4 and works
Axel Zeuner wrote: Hi, Hi Axel, By adding some GCC4 fixes on top of your patch, I was able to get qemu for i386 (on i386) to compile and run. So far, I've only tested a win2k guest. The big problem (which pbrook helped me with) was GCC4 freaking out over some stq's. Splitting up the 64bit ops into 32bit ops seemed to address most of the problems. The tricky thing I still can't figure out is how to get ASM_SOFTMMU working. The problem is GLUE(st, SUFFIX) function. First GCC cannot deal with the register pressure. The problem I can't seem to fix though is that GCC sticks %1 in %esi because we're only using an r constraint, not a q constraint. This results in the generation of %sib which is an invalid register. However, refactoring the code to not require a q constraint doesn't seem to help either. The attached patch is what I have so far. Some help with people more familiar with gcc asm foo would be appreciated! Regards, Anthony Liguori there were a lot of discussions about compiling qemu with gcc4 or higher. The summary of the discussions were, as I understood, that compiling qemu with gcc4 requires changing the code generation engine of the most of the supported targets. These changes require a lot of work and time. How about splitting the current static code generation process further? Today gcc produces object code and dyngen adapts it for the purposes of qemu, i.e produces the generation function, patches in parameters ..: gcc -c op.o op.c ;dyngen -o op.h ... op.o . The op_XXX functions generated by gcc may not contain more than one exit and this exit must be at the end, no not intended jumps to external functions may occur. It is possible to split the transformation into the following steps: Generate assembly output from the C-Sources: gcc -S -o op-0.s op.c. Convert the assembly output: cvtasm op.s op-0.s. Assemble the converted assembler sources: as -o op.o op.s. Use dyngen as before: dyngen -o op.h ... op.o. Nothing will change if cvtasm copies only the input to the output, i.e. this additional pass will not break existing code. A full featured converter (cvtasm) has a lot of dependencies: it has to support all hosts (M) (with all assembler dialects M') and all targets N, i.e. in the worst case one would end with M'x N variants of it, or M x N if one supports only one assembler dialect per host. It is clear, that the number of variants is one of the biggest disadvantages of such an approach. Now I will focus on x86_64 host and x86_64-softmmu target. cvtasm has to do the following tasks in this case: 0) convert repXXX; ret to ret only. (Not done yet, x86_64 only, but does not harm). 1) append to all functions, where the last instruction is not a return a ret instruction. 2) add a label to all functions with more than one return before the last return. 3) replace all returns not at the end of a function with an unconditional jump to the generated end label. Avoid touching op_exit_tb here. 4) check all jump instructions if they contain jumps to external labels, replace jumps to external labels with calls to the labels. The task 0-2 are easy, task 3 may, task 4 is definitely target/host dependent, because there exist intentionally some jumps to external labels, i.e. outside of the function, for instance op_goto_tb. Please correct me, if I am wrong or something is not mentioned above. The attached cvtasm.c allows compiling op.c/op.s/op.o without any disabled optimisations in Makefile.target (patches for Makefile and Makefile.target are attached). The program itself definitely needs a rewrite, is not failsafe and produces to much output on stdout. The macro OP_GOTO_TB from exec-all.h in the general case contains two nice variables and label definitions to force a reference from a variable into the op_goto_tbXXX functions. Unfortunately gcc4 detects that these variables and lables are unused and suppresses their generation, as result dyngen does not generate two lines in op.h: case INDEX_op_goto_tb0: ... label_offsets[0] = 8 + (gen_code_ptr - gen_code_buf); // -- ... case INDEX_op_goto_tb1: ... label_offsets[1] = 8 + (gen_code_ptr - gen_code_buf); // -- ... and qemu produces a SIGSEGV on the first jump from one buffer to the next. I was not able to force gcc4 to generate the two variables, therefore I had to replace the general macro with a host dependent one for x86_64 similar to x86 but using the indirect branch method. After the replacement qemu worked when compiled with gcc4. I made my checks with the following compilers using Debian testing amd64: gcc version 3.4.6 (Debian 3.4.6-5) and gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21). Please note: These patches work only for x86_64 hosts and x86_64 targets. They will break all other architectures. I did not check i386-softmmu. It works for me. I apologise for the size of the attachments. Kind regards Axel
[Qemu-devel] sparc-softmmu debian netinst fails
Hi. A few months ago I was able to successfully install from a debian sparc netinst iso. This doesn't seem to be possible now as the install hangs right after the Detecting Hardware dialogue (after asking for hostname and domain). The screen will change from the usual blue background/light grey foreground to completely black display. The iso is linked below. I used `qemu-system-sparc -hda deb-sparc.img -cdrom debian-31r5-sparc-netinst.iso -localtime -nographic -boot d` to try the install again on the same linux x86 host. http://cdimage.debian.org/debian-cd/3.1_r5/sparc/iso-cd/debian-31r5-sparc-netinst.iso ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] sparc-softmmu debian netinst fails
On Sat, Mar 24, 2007 at 03:37:32PM -0500, Lonnie Mendez wrote: Hi. A few months ago I was able to successfully install from a debian sparc netinst iso. This doesn't seem to be possible now as the install hangs right after the Detecting Hardware dialogue (after asking for hostname and domain). The screen will change from the usual blue background/light grey foreground to completely black display. The iso is linked below. Which version of qemu do you use? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] sparc-softmmu debian netinst fails
Going back and testing previous netinst isos: debian-31r1a-sparc-netinst - OK debian-31r2-sparc-netinst - OK debian-31r3-sparc-netinst - OK (sunlance load failed - forced to choose no network card to continue) debian-31r4-sparc-netinst - X (sunlance load failed) debian-31r5-sparc-netinst - X (sunlance load failed) It is possible I used one of the first the installers and this is a problem with the recent debian installers. In which case sorry for the noise. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Problem with x86_64 bit linux guest (2.6.18), opensuse
An additionl to my previous post: I tried to install openSUSE X86_64 with -no-kqemu. This time it went ok until the step that installs grub to prpare the disk for first boot. AFAIK this problem was also reported some time ago. Is there any way I can help here, for example creating dumps, traces that give additional information on top what was alraedy posted some time ago. Regards, Werner Werner Dittmann wrote: All, some time ago I reported problems with Qemu and the installation of openSUSE 10.1 or 10.2 64bit systems. Today I did a CVS download and compiled Qemu again, using a gcc 3.3.6 compiler. To simplify it I configured it as follows: ./configure --prefix=/usr/local --cc=/opt/gcc33/bin/gcc-3.3 \ --enable-adlib --target-list=i386-softmmu x86_64-softmmu For Kqemu I use that latest tar.gz version (1.3.0pre11), compiled with the standard compiler (gcc 4.1.2) on my openSUSE 10.2 system (Host). Hardware is AMD Athlon 64bit. My W2K works with qemu, with -kernel-kqemu -no-acpi. But trying to install a standard openSUSE 10.2 from DVD image fails. When using -kernel-kqemu it loops (seems forever), starting without it crashes shortly after the installation process started while scaning some devices. Checking documentation says: x86_64 full virtualization support for kqemu. Is this a know problem? shall I use a different gcc to build qemu? some switches to set? config options? Regards, Werner ___ 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] sparc-softmmu debian netinst fails
Lonnie Mendez a écrit : Going back and testing previous netinst isos: debian-31r1a-sparc-netinst - OK debian-31r2-sparc-netinst - OK debian-31r3-sparc-netinst - OK (sunlance load failed - forced to choose no network card to continue) debian-31r4-sparc-netinst - X (sunlance load failed) debian-31r5-sparc-netinst - X (sunlance load failed) It is possible I used one of the first the installers and this is a problem with the recent debian installers. In which case sorry for the noise. Starting with Debian 3.1r3, the kernel has been updated. The problem may comes from here. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] qemu/target-mips translate_init.c
CVSROOT:/sources/qemu Module name:qemu Changes by: Thiemo Seufer ths 07/03/24 23:36:18 Modified files: target-mips: translate_init.c Log message: One more bit of mips CPU configuration, and support for early 4KEc which implemented only MIPS32R1. Thanks to Stefan Weil to insist he's right on that. :-) CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/qemu/target-mips/translate_init.c?cvsroot=qemur1=1.2r2=1.3 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
Stefan Weil wrote: Hi, here is the patch which adds a 4KEcR1 CPU (a 4KEc, processor revision 2.2, with MIPS32 Release 1 (!) instruction set is the heart of the AR7 SoC). See also include/asm-mips/cpu.h in the Linux kernel sources: ./include/asm-mips/cpu.h:#define PRID_IMP_4KEC 0x8400 ./include/asm-mips/cpu.h:#define PRID_IMP_4KECR20x9000 This was the bit which prompted to to ask The People Who Know[TM]. Indeed the early 4KEc were MIPS32R1 only. About the branch-in-delay-slot I got the following information: Very simple pipelines with branch delay slots tend to behave like this (when both branches are taken): - Execute the first branch, that is, calculate the target of the branch. This has no effect until it ran far enough through the pipeline. Increment PC. - Execute the second branch. This changes the branch target value again. Increment PC. - Execute the second branch's delay slot instruction. Increment PC. - Now the PC is overridden by the first branch's target. A single instruction from that place is executed. - The PC is overridden again by the second branch's target. Normal execution resumes from there. Apparently the SPARC architecture _requires_ this behaviour for all CPUs. Can you check if this is the behaviour you see on an AR7? Thiemo ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
Thiemo Seufer a écrit : Stefan Weil wrote: Hi, here is the patch which adds a 4KEcR1 CPU (a 4KEc, processor revision 2.2, with MIPS32 Release 1 (!) instruction set is the heart of the AR7 SoC). See also include/asm-mips/cpu.h in the Linux kernel sources: ./include/asm-mips/cpu.h:#define PRID_IMP_4KEC 0x8400 ./include/asm-mips/cpu.h:#define PRID_IMP_4KECR20x9000 This was the bit which prompted to to ask The People Who Know[TM]. Indeed the early 4KEc were MIPS32R1 only. About the branch-in-delay-slot I got the following information: Very simple pipelines with branch delay slots tend to behave like this (when both branches are taken): - Execute the first branch, that is, calculate the target of the branch. This has no effect until it ran far enough through the pipeline. Increment PC. - Execute the second branch. This changes the branch target value again. Increment PC. - Execute the second branch's delay slot instruction. Increment PC. - Now the PC is overridden by the first branch's target. A single instruction from that place is executed. - The PC is overridden again by the second branch's target. Normal execution resumes from there. Apparently the SPARC architecture _requires_ this behaviour for all CPUs. Yep I confirm that, it is clearly explained starting at the page 54 of the SPARC v8 manual. To avoid this behaviour it is possible to cancel the delay slot instruction by having a=1. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
