[Qemu-devel] SUNWqemu-0.8.2, REV=2006.10.14-sol8-sparc-opt.pkg released
Martin Bochnig wrote: >Hello, > >uploading gdiff and sparc-pkg to www.martux.org/qemu/RELEASES/sparc and >to the opensolaris site. >In a few minutes. > > Ouch, file too big: File 1 (SUNWqemu-0.8.2,REV=2006.10.14-sol8-sparc-opt.pkg.gz) was ignored. The file size is 28080k, which exceeds the maximum size of 15360k. Cannot be uploaded to http://opensolaris.org/os/project/qemu/downloads Please download the file(s) from http://www.martux.org/qemu/RELEASES/sparc/ http://www.martux.org/qemu/RELEASES/sparc/SUNWqemu-0.8.2,REV=2006.10.14-sol8-sparc-opt.pkg.gz http://www.martux.org/qemu/RELEASES/sparc/qemu-0.8.2-solaris__20061002mon__EricL__versus__qemu-0.8.2-solaris__20061013fri__MB.gdiff http://www.martux.org/qemu/RELEASES/sparc/qemu-0.8.2__default_FabriceB__versus__qemu-0.8.2-solaris__20061013fri__MB.gdiff for now. See the diffs for added features. Attention: IDE-Patch is derived from old IDE patch written by grand-master Juergen Keil, who once achieved the major part of porting QEMU to Solaris (!) back in 2004 . He submitted that ide.c patch over a year ago, but it never made it into CVS for some odd reason. Regards -- Martin Bochnig http://www.martux.org/RELEASES/x86_and_x64/DVD/ (amd64) http://www.genunix.org/distributions/martux/marTux_0.2/(sparcv9) >Generating x86 pkg till Sunday. >(port down to Sol8-i386 has to be polished up) > > >Regards, >Martin > > > ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
RE: [Qemu-devel] SUNWqemu-0.8.2, REV=2006.10.14-sol8-sparc-opt.pkg released
A few comments on the patches: Is there some problem that can't be fixed with the sparc64.ld instead of disabling it for Solaris? The ARM/MIPS bits could be rewritten more generally with #ifdef AREG0 instead of _sparc_. Maybe these would be better handled once in dyngen-exec.h so that that the targets don't assume they get any asm registers. Why do you reorder the registers in Sparc? The int64_t issue could be checked with configure, resulting in HAS_INT64 #defined as needed. _ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] SUNWqemu-0.8.2,REV=2006.10.14-sol8-sparc-opt.pkg released
Blue Swirl wrote: > Is there some problem that can't be fixed with the sparc64.ld instead > of disabling it for Solaris? Yes and no. The problem is gnu-ld vs. sun-ld, rather than Linux vs. Solaris. I cannot find an equivalent option for sun-ld. 32bit sparc.ld is also disabled under Solaris for that reason, and has always been. OpenSolaris is still based on its own SUNW-toolchain, not on binutils. (though I'm not sure about Nextenda/GNU-Solaris) Even though OpenSolaris can optionally be compiled with SUNW's gcc 3.4.x now (/usr/sfw/bin/gcc), it still uses its own /usr/ccs/bin/as and ld. All gcc-packages offered on Solaris freeware sites are also built not to use gas or gnu-ld. If you simply make a dirty symlink to /usr/ccs/bin/[as|ld] small things may build and link just good enough. But qemu doesn't, because certain dependencies (like -lm) are skipped / not considered valid, for some reason. It all _might_ potentially work when one would build a complete toolchain only for the purpose of getting qemu built with sparc32: LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc.ld and sparc64: LDFLAGS+=-Wl,-T,$(SRC_PATH)/sparc64.ld But the resulting performance benefit may be zero, if not negative: SUNW's assembler and linker are not bad, especially on sparc. > > The ARM/MIPS bits could be rewritten more generally with #ifdef AREG0 > instead of _sparc_. Maybe these would be better handled once in > dyngen-exec.h so that that the targets don't assume they get any asm > registers. Yes, of course. But I plan to use a faster method and to actually use as much as possible physical host registers (see sparc-target directly below). > Why do you reorder the registers in Sparc? Dumb trying-out is sometimes the only wayout: I *tried* all possible combinations of registers in a systematic testing-approach (I only did this on the sparc-target so far, need to do the same for mips and arm). The assignments in the patch are the best I could get (as many as possible fast host registers, rather than slow main memory locations). Any other order of assignments resulted in segfaults. That's why everything appears to be out of order in target-sparc/exec.h. And if I would bring target-sparc/exec.h in order again, by changing the AREG assignments in dyngen-exec.h, I would mess up all the other targets like i386-softmmu and x86_64-softmmu. One odd observation: If I try to make use of AREG1 in target-sparc/exec.h, it would _always_ result in a segfault in gen_code_buffer(), no matter at all, which physical sparc host-register I would have assigned to AREG1 in dyngen-exec.h. There is something that makes AREG1 itself unusable on sparc hosts for all other emulation targets, except i386-softmmu, x86_64-softmmu (and maybe ppc-softmmu). > > The int64_t issue could be checked with configure, resulting in > HAS_INT64 #defined as needed. Yep. Thanks for your feedback. And for your good work on the sparc target(s). The Solaris_sparc guest 32bit kernel still died a month ago, did you make progress? Are there ways to lern from the now open source sun4v's OBP to see, what SUNW's proprietary OBP handles differently, when compared to the public ieee1275-1994 standard or other implementations like SmartFirmware? (wasn't there a "SUNW-compatibility" #ifdef in SmartFirmware [I don't have that code] ? ) May it be possible, to employ SUNW's sun4v OBP in a potential future sun4v emulation target (i.e. as -M option of sparc64-softmmu)? ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] SUNWqemu-0.8.2, REV=2006.10.14-sol8-sparc-opt.pkg released
The problem is gnu-ld vs. sun-ld, rather than Linux vs. Solaris. I cannot find an equivalent option for sun-ld. 32bit sparc.ld is also disabled under Solaris for that reason, and has always been. Thanks for the long explanation, I asked because the script was a quick hack. One odd observation: If I try to make use of AREG1 in target-sparc/exec.h, it would _always_ result in a segfault in gen_code_buffer(), no matter at all, which physical sparc host-register I would have assigned to AREG1 in dyngen-exec.h. There is something that makes AREG1 itself unusable on sparc hosts for all other emulation targets, except i386-softmmu, x86_64-softmmu (and maybe ppc-softmmu). Linux libc uses %g1 without saving in setjmp, maybe Solaris has the same problem. I haven't found any free three global registers which would work. Using local registers would solve this problem, but then no functions outside the TB couldn't access T0-2. Maybe we could use global registers for T0 and T1 and env->T2 for T2? The Solaris_sparc guest 32bit kernel still died a month ago, did you make progress? Is there an installation disk somewhere for sparc32? I thought the last Solaris supporting V8 CPUs was Solaris 8, which was very much not free. Are there ways to lern from the now open source sun4v's OBP to see, what SUNW's proprietary OBP handles differently, when compared to the public ieee1275-1994 standard or other implementations like SmartFirmware? (wasn't there a "SUNW-compatibility" #ifdef in SmartFirmware [I don't have that code] ? ) Someone with advanced Forth skills could try to find the differences. The sun4v model is a bit different from sun4u and sun4m, OBP just talks to the hypervisor. May it be possible, to employ SUNW's sun4v OBP in a potential future sun4v emulation target (i.e. as -M option of sparc64-softmmu)? Sure. The existing unfinished sun4u code could be enhanced with the needed sun4v features. But there is still much to do with the common stuff, like adding VIS instructions, interrupt handling and PCI. Maybe you could try to add sparc_v8plus support for the Linux user emulator to polish the CPU? Or add emulation for Linux userland on Solaris? _ 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
Re: [Qemu-devel] SUNWqemu-0.8.2,REV=2006.10.14-sol8-sparc-opt.pkg released
I'm back. Blue Swirl wrote: > Linux libc uses %g1 without saving in setjmp, maybe Solaris has the > same problem. I haven't found any free three global registers which > would work. Using local registers would solve this problem, but then > no functions outside the TB couldn't access T0-2. > > Maybe we could use global registers for T0 and T1 and env->T2 for T2? Yes. Something like that will work. I just booted Win95 on Aurora 1.0 sparc32 . > >> The Solaris_sparc guest 32bit kernel still died a month ago, did you >> make progress? > > > Is there an installation disk somewhere for sparc32? I thought the > last Solaris supporting V8 CPUs was Solaris 8, which was very much not > free. The use is free (RTU license). Solaris 9 was the last public version with a 32bit sparc kernel. It can be downloaded for free after a quick registration from sun.com. > >> Are there ways to lern from the now open source sun4v's OBP to see, what >> SUNW's proprietary OBP handles differently, when compared to the public >> ieee1275-1994 standard or other implementations like SmartFirmware? >> (wasn't there a "SUNW-compatibility" #ifdef in SmartFirmware [I don't >> have that code] ? ) > > > Someone with advanced Forth skills could try to find the differences. > The sun4v model is a bit different from sun4u and sun4m, OBP just > talks to the hypervisor. I'm lerning Forth, but I don't have advanced skills. > >> May it be possible, to employ SUNW's sun4v OBP in a potential future >> sun4v emulation target (i.e. as -M option of sparc64-softmmu)? > > > Sure. The existing unfinished sun4u code could be enhanced with the > needed sun4v features. But there is still much to do with the common > stuff, like adding VIS instructions, interrupt handling and PCI. Maybe > you could try to add sparc_v8plus support for the Linux user emulator > to polish the CPU? Or add emulation for Linux userland on Solaris? Maybe next year in summer. Sorry, the new semester just started yesterday. I _have_ to do more for university. I already had to drop other intended projects because of that. I can look into it, when I next find some time, if any. ### I will remove the demo images from the actual SUNWqemu package (maybe offering separate guest image packages). Then the new pkg will meet the space requirements necessary for uploading it to OpenSolaris.org. SUNWqemu: Building new Solaris10_U1 based packages for sparcv9 and x64. (only offering sparcv8plus on sparc as Solaris 10 already requires UltraSPARC) CSWqemu: Solaris 8 users will have legacy support in the upcoming CSW package. Questions criticism, feedback? Regards, --Martin ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
