qemu discuss - Oct 2006 - 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
>
>  
>

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/

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)?

> 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

Like I was suggesting.


Since it was built on the Blastwave stack perhaps you could drop it into the
testing area also.

Also, can we get a CSWqemu update ?
> 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.
Dennis

Dennis Clarke wrote:
>Since it was built on the Blastwave stack perhaps you could drop it into the
>testing area also.
>  
>
Yes.
But I have to quit INSTANTLY.
Copying it over in apprx. 12 hours.
>Also, can we get a CSWqemu update ?
>  
>
Yes, of course.
That was my intention (just as announced last week).
It''s basically one effort.


Martin

>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/

> Dennis Clarke wrote:
>
>>Since it was built on the Blastwave stack perhaps you could drop it into
>> the
>>testing area also.
>>
>>
>
> Yes.
> But I have to quit INSTANTLY.
> Copying it over in apprx. 12 hours.
>
okay .. you were up all night again .. I can tell .. been there done that
with you a few times.

I will get this tested on a Solaris 8 sun4m machine also.  That is the
lowest common denominator I think.  I''m not expecting much on sun4m. 
At the
least I expect that it will work on Solaris 8 sun4u hardware.

I''ll stay in touch ...

Dennis

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