[Qemu-devel] [PATCH] OSX x86_32 host support

[Qemu-devel] [PATCH] OSX x86_32 host support

[Mike Kronenberg]

[-- Attachment #1: Type: text/plain, Size: 452 bytes --]

Looks like I'm a little late for the party, as always :) .

I really encourage everyone to work towards a gcc4.x solution for OS X.

I just read and tried Alexanders x86_64 patch, as I finished our x86_32.
If we could reach an out of the box solution for OS X, that would be  
great!

You'll find the patches at [1]
It's basically an adaption of Pauls, Gwenoles and the Qs gcc4 OS X x86  
patches.

Best regards
Mike

[1] http://www.kronenberg.org/qemu

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2111 bytes --]

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Alexander Graf]

On Jan 14, 2008, at 12:43 AM, Mike Kronenberg wrote:

> Looks like I'm a little late for the party, as always :) .
>
> I really encourage everyone to work towards a gcc4.x solution for OS  
> X.
>
> I just read and tried Alexanders x86_64 patch, as I finished our  
> x86_32.
> If we could reach an out of the box solution for OS X, that would be  
> great!
>

That would really be great. I'd really love to see OSX as a supported  
host OS.

> You'll find the patches at [1]
> It's basically an adaption of Pauls, Gwenoles and the Qs gcc4 OS X  
> x86 patches.

I'd rather go with Michael Matz's gcc4 patches. They look more sane  
and clean to me than Gwenoles do and I believe the 5% performance hit  
that goes with them is no real problem, as most people should be using  
x86_64 nowadays anyway. On OSX this is even less of a problem, as only  
few Intel Macs are not capable of running x86_64 code (namely the Core  
Solo and Core Duo generation) and there is no need to run an x86_64  
kernel to use x86_64 userspace code.

If by any chance you find the time to do this, please try to get  
Michael Matz's patches conditional for gcc4 (no performance hit on  
gcc3) and do the mach-o i386 support separate from that. I believe  
this way everyone benefits from it and we could finally remove the  
gcc3 dependency.

Cheers,

Alex

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Mike Kronenberg]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

  Alex,

>> You'll find the patches at [1]
>> It's basically an adaption of Pauls, Gwenoles and the Qs gcc4 OS X  
>> x86 patches.
>
> I'd rather go with Michael Matz's gcc4 patches. They look more sane  
> and clean to me than Gwenoles do and I believe the 5% performance  
> hit that goes with them is no real problem, as most people should be  
> using x86_64 nowadays anyway. On OSX this is even less of a problem,  
> as only few Intel Macs are not capable of running x86_64 code  
> (namely the Core Solo and Core Duo generation) and there is no need  
> to run an x86_64 kernel to use x86_64 userspace code.
And I'm one of them, stuck with a Core Duo Macbook pro, which will  
stay for some more time :)
But I do have a Core 2 Duo to test x86-64.

> If by any chance you find the time to do this, please try to get  
> Michael Matz's patches conditional for gcc4 (no performance hit on  
> gcc3) and do the mach-o i386 support separate from that. I believe  
> this way everyone benefits from it and we could finally remove the  
> gcc3 dependency.
>
> Cheers,
>
> Alex

Yes, I'll do probably a clean patch on top of yours, so that all hosts  
can be satisfied.

Best Mike

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2111 bytes --]

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Jamie Lokier]

Alexander Graf wrote:
> I believe the 5% performance hit  
> that goes with them is no real problem, as most people should be using  
> x86_64 nowadays anyway.

*Boggle*!  x86_64 is only a few years old, and cheap low-power x86_64
laptops are relatively recent.

-- Jamie

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Alexander Graf]

Jamie Lokier wrote:
> Alexander Graf wrote:
>   
>> I believe the 5% performance hit  
>> that goes with them is no real problem, as most people should be using  
>> x86_64 nowadays anyway.
>>     
>
> *Boggle*!  x86_64 is only a few years old, and cheap low-power x86_64
> laptops are relatively recent.
>
> -- Jamie
>
>   
So you really want to do dynamic retranslation on ancient hardware? To
me emulated systems already feel slow on really recent machines, I
don't  want to go back to something even slower.
If you use kqemu there even is near no performance hit at all, which I
believe is the main use of qemu on i386 anyway. Furthermore x86_64 is
_way_ faster, as it provides a lot more registers.

I think the benefit you get from cutting the gcc3 dependency is way more
important than a major performance hit that people will usually only see
on the next release of qemu, by which time things have shifted towards
x86_64 even more.

Regards,

Alex

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Jamie Lokier]

Alexander Graf wrote:
> Jamie Lokier wrote:
> > Alexander Graf wrote:
> >> I believe the 5% performance hit  
> >> that goes with them is no real problem, as most people should be using  
> >> x86_64 nowadays anyway.
> >
> > *Boggle*!  x86_64 is only a few years old, and cheap low-power x86_64
> > laptops are relatively recent.
> >   
> So you really want to do dynamic retranslation on ancient hardware?

I think you are using 'ancient' to mean what I call 'relatively
recent'.

I bought my current main machine just 1.5 years ago, and there were
_no_ fast 64-bit low power laptop CPUs available at the time.  I
hardly call 1.5 years ancient.  Now there are chips available, but the
overall improvement isn't enough to justify paying to replace a good
1.5 year old machine yet.

> To me emulated systems already feel slow on really recent machines,
> I don't want to go back to something even slower.

No problem with your experience, and you're right about the speed of
course.  I only object to generalising that, to say that nearly
everyone _should_ be using x86_64 now, and (by implication) that
x86_32 is no longer relevant and should get second class support.  It
seems to imply that only people who buy a new computer every 2 years
(at most) use Qemu.  But Qemu is used for lots of different things,
and on lots of machines.  It'll be a few more years before 32-bit Qemu
users are a rarity, imho.

> If you use kqemu there even is near no performance hit at all, which I
> believe is the main use of qemu on i386 anyway.

It's also the main use of Qemu on x86_64, so irrelevant point :-)

> Furthermore x86_64 is _way_ faster, as it provides a lot more
> registers.

For some loads, x86_64 is slower because it uses more memory for
pointers.  But really, the actual relative speed of 32/64 x86 is quite
offtopic.  It's the idea that people "should" use x86_64 with Qemu and
therefore 32-bit x86 should be a second class platform that I object
to.  I don't think it's time for that yet.

> I think the benefit you get from cutting the gcc3 dependency is way more
> important than a major performance hit that people will usually only see
> on the next release of qemu, by which time things have shifted towards
> x86_64 even more.

This I agree with.  Cutting the gcc3 dependency is good, even if it
costs a little in performance.  Clearly, the best performance would
come from a different kind of code generation backend which understood
the host CPU directly, not depending on GCC code fragments at all.

-- Jamie

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Johannes Schindelin]

Hi,

On Tue, 15 Jan 2008, Alexander Graf wrote:

> Jamie Lokier wrote:
> > Alexander Graf wrote:
> >   
> >> I believe the 5% performance hit that goes with them is no real 
> >> problem, as most people should be using x86_64 nowadays anyway.
> >
> > *Boggle*!  x86_64 is only a few years old, and cheap low-power x86_64 
> > laptops are relatively recent.
>
> So you really want to do dynamic retranslation on ancient hardware?

Isn't it a little bit selfish to leave all those poor people behind who 
just plainly cannot _afford_ better hardware?

> To me emulated systems already feel slow on really recent machines, I 
> don't want to go back to something even slower.

Yes, keep on rubbing it in.

> If you use kqemu there even is near no performance hit at all, which I 
> believe is the main use of qemu on i386 anyway.

Another use is to make sure your software works on different hardware than 
you actually have.

> Furthermore x86_64 is _way_ faster, as it provides a lot more registers.

Again, just rub it in.

> I think the benefit you get from cutting the gcc3 dependency is way more 
> important than a major performance hit that people will usually only see 
> on the next release of qemu, by which time things have shifted towards 
> x86_64 even more.

AFAICT the gcc4 problem is not even half-way solved, yet you talk about 
cutting the gcc3 dependency.

Tell you what: solve the gcc4 problem first, not only on x86_64, but also 
on i386 (since it is still the most widespread platform), and ARM, and 
PPC, and all the other supported platforms, and _then_ we can talk about 
cutting the gcc3 dependency.

Hth,
Dscho

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Andreas Färber]

Am 15.01.2008 um 17:32 schrieb Alexander Graf:

> Jamie Lokier wrote:
>> Alexander Graf wrote:
>>
>>> I believe the 5% performance hit
>>> that goes with them is no real problem, as most people should be  
>>> using
>>> x86_64 nowadays anyway.
>>>
>>
>> *Boggle*!  x86_64 is only a few years old, and cheap low-power x86_64
>> laptops are relatively recent.
>>
>> -- Jamie
>>
>>
> So you really want to do dynamic retranslation on ancient hardware? To
> me emulated systems already feel slow on really recent machines, I
> don't  want to go back to something even slower.
> If you use kqemu there even is near no performance hit at all, which I
> believe is the main use of qemu on i386 anyway. Furthermore x86_64 is
> _way_ faster, as it provides a lot more registers.
>
> I think the benefit you get from cutting the gcc3 dependency is way  
> more
> important than a major performance hit that people will usually only  
> see
> on the next release of qemu, by which time things have shifted towards
> x86_64 even more.

One thing you don't seem to understand is that QEMU releases don't  
upgrade our hardware, especially not from Apple. An x86_64 Mac Pro is  
more than double the price for my PowerMac G5 back then. Don't think  
about what people "should" be using in your opinion, look at what they  
are actually using.
People want to run software, including Q or QEMU, on their hard- and  
software, which may include ppc hardware as well as Panther/Tiger  
operating systems ... both much more "ancient" than Intel Core 2 Duo  
based Macs. And yes, it's "slow". Does that stop me? No. And you  
likely don't have a kqemu on your Mac either. Occasionally trying an  
image does not justify buying VMware Fusion, and such commercial  
products only do virtualization anyway and are incapable of emulating  
different hardware. Just in case you forgot, Open Source software in  
general usually has the benefit of not being tied to the support  
lifetimes of commercial vendors, forcing users to upgrade their (e.g.  
Windows) OS - but pushing us to upgrade our hardware as soon as  
something faster is out would be doing exactly that hardware-wise,  
without substantial reason.

As a user, I don't want to do dynamic retranslation. I still don't  
really understand how it works (seems more complicated than the JIT  
I'm working with). I just want to emulate a machine in my preferred  
environment, especially ppc64 and sparc64 targets for work on Open  
Source software. QEMU is the only emulator I know that is on its way  
there.

Flame me if you need to, but please stop this "everyone is using  
x86_64 anyway" argument; if you have improvements specific to that  
host, simply make them conditional, that's what configure is for.

With the gcc3 part I do agree.

Regards,

Andreas

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Alexander Graf]

On Jan 15, 2008, at 6:30 PM, Andreas Färber wrote:

>
> Am 15.01.2008 um 17:32 schrieb Alexander Graf:
>
>> Jamie Lokier wrote:
>>> Alexander Graf wrote:
>>>
>>>> I believe the 5% performance hit
>>>> that goes with them is no real problem, as most people should be  
>>>> using
>>>> x86_64 nowadays anyway.
>>>>
>>>
>>> *Boggle*!  x86_64 is only a few years old, and cheap low-power  
>>> x86_64
>>> laptops are relatively recent.
>>>
>>> -- Jamie
>>>
>>>
>> So you really want to do dynamic retranslation on ancient hardware?  
>> To
>> me emulated systems already feel slow on really recent machines, I
>> don't  want to go back to something even slower.
>> If you use kqemu there even is near no performance hit at all,  
>> which I
>> believe is the main use of qemu on i386 anyway. Furthermore x86_64 is
>> _way_ faster, as it provides a lot more registers.
>>
>> I think the benefit you get from cutting the gcc3 dependency is way  
>> more
>> important than a major performance hit that people will usually  
>> only see
>> on the next release of qemu, by which time things have shifted  
>> towards
>> x86_64 even more.
>
> One thing you don't seem to understand is that QEMU releases don't  
> upgrade our hardware, especially not from Apple. An x86_64 Mac Pro  
> is more than double the price for my PowerMac G5 back then. Don't  
> think about what people "should" be using in your opinion, look at  
> what they are actually using.

What I am actually talking about is that the only real gcc4 breakage I  
am aware of is on i386. I just built x86_64-softmmu on a POWER6 host  
with gcc4.1.2 and it "simply worked". Please tell me if there is  
anything broken for you on gcc4. I believe there isn't (please use  
gcc4.2+).

>
> People want to run software, including Q or QEMU, on their hard- and  
> software, which may include ppc hardware as well as Panther/Tiger  
> operating systems ... both much more "ancient" than Intel Core 2 Duo  
> based Macs. And yes, it's "slow". Does that stop me? No. And you  
> likely don't have a kqemu on your Mac either. Occasionally trying an  
> image does not justify buying VMware Fusion, and such commercial  
> products only do virtualization anyway and are incapable of  
> emulating different hardware. Just in case you forgot, Open Source  
> software in general usually has the benefit of not being tied to the  
> support lifetimes of commercial vendors, forcing users to upgrade  
> their (e.g. Windows) OS - but pushing us to upgrade our hardware as  
> soon as something faster is out would be doing exactly that hardware- 
> wise, without substantial reason.

I wasn't talking about PowerPC. I am really sorry if it looked that  
way, but it was neither my intention nor my belief to say anything  
against any platform but i386.

>
> As a user, I don't want to do dynamic retranslation. I still don't  
> really understand how it works (seems more complicated than the JIT  
> I'm working with). I just want to emulate a machine in my preferred  
> environment, especially ppc64 and sparc64 targets for work on Open  
> Source software. QEMU is the only emulator I know that is on its way  
> there.
>
> Flame me if you need to, but please stop this "everyone is using  
> x86_64 anyway" argument; if you have improvements specific to that  
> host, simply make them conditional, that's what configure is for.
>

I was saying "let's finally make qemu gcc4-save, so we can drop this  
gcc3 dependency. The only platform that might get a performance hit  
from that is i386 and I was trying to show why a small performance hit  
on i386 is no real problem if we can use gcc4 for every target instead.

> With the gcc3 part I do agree.

Thank you. ;-)

Regards,

Alex

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Alexander Graf]

On Jan 15, 2008, at 6:50 PM, Alexander Graf wrote:

>
> On Jan 15, 2008, at 6:30 PM, Andreas Färber wrote:
>
>>
>> Am 15.01.2008 um 17:32 schrieb Alexander Graf:
>>
>>> Jamie Lokier wrote:
>>>> Alexander Graf wrote:
>>>>
>>>>> I believe the 5% performance hit
>>>>> that goes with them is no real problem, as most people should be  
>>>>> using
>>>>> x86_64 nowadays anyway.
>>>>>
>>>>
>>>> *Boggle*!  x86_64 is only a few years old, and cheap low-power  
>>>> x86_64
>>>> laptops are relatively recent.
>>>>
>>>> -- Jamie
>>>>
>>>>
>>> So you really want to do dynamic retranslation on ancient  
>>> hardware? To
>>> me emulated systems already feel slow on really recent machines, I
>>> don't  want to go back to something even slower.
>>> If you use kqemu there even is near no performance hit at all,  
>>> which I
>>> believe is the main use of qemu on i386 anyway. Furthermore x86_64  
>>> is
>>> _way_ faster, as it provides a lot more registers.
>>>
>>> I think the benefit you get from cutting the gcc3 dependency is  
>>> way more
>>> important than a major performance hit that people will usually  
>>> only see
>>> on the next release of qemu, by which time things have shifted  
>>> towards
>>> x86_64 even more.
>>
>> One thing you don't seem to understand is that QEMU releases don't  
>> upgrade our hardware, especially not from Apple. An x86_64 Mac Pro  
>> is more than double the price for my PowerMac G5 back then. Don't  
>> think about what people "should" be using in your opinion, look at  
>> what they are actually using.
>
> What I am actually talking about is that the only real gcc4 breakage  
> I am aware of is on i386. I just built x86_64-softmmu on a POWER6  
> host with gcc4.1.2 and it "simply worked". Please tell me if there  
> is anything broken for you on gcc4. I believe there isn't (please  
> use gcc4.2+).
>

I'm sorry. Looks like I did not check this properly. It just broke for  
me - I will take a look at it tomorrow then.

Regards,

Alex

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Thiemo Seufer]

Alexander Graf wrote:
[snip]
> I was saying "let's finally make qemu gcc4-save, so we can drop this  
> gcc3 dependency. The only platform that might get a performance hit from 
> that is i386 and I was trying to show why a small performance hit on i386 
> is no real problem if we can use gcc4 for every target instead.

Keep in mind that there's a lot of i386 software out there (Windows for
a start) which needs as guest either hardware virtualization or kqemu.
kqemu needs a 32-bit host in that case. Also, old non-VT hardware will
stay around for a while, and 32-bit host OSes probably even longer.


Thiemo

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Alexander Graf]

On Jan 15, 2008, at 7:23 PM, Thiemo Seufer wrote:

> Alexander Graf wrote:
> [snip]
>> I was saying "let's finally make qemu gcc4-save, so we can drop this
>> gcc3 dependency. The only platform that might get a performance hit  
>> from
>> that is i386 and I was trying to show why a small performance hit  
>> on i386
>> is no real problem if we can use gcc4 for every target instead.
>
> Keep in mind that there's a lot of i386 software out there (Windows  
> for
> a start) which needs as guest either hardware virtualization or kqemu.
> kqemu needs a 32-bit host in that case. Also, old non-VT hardware will
> stay around for a while, and 32-bit host OSes probably even longer.
>

I completely agree on that. If you're using kqemu or VMX/SVM you don't  
get hit by the penality you get from using gcc4 over gcc3 on i386.  
This was about the only thing I wanted to stress here.

Alex

Re: [Qemu-devel] [PATCH] OSX x86_32 host support

[Andreas Färber]

Am 15.01.2008 um 18:50 schrieb Alexander Graf:

>
> On Jan 15, 2008, at 6:30 PM, Andreas Färber wrote:
>
>>
>> Am 15.01.2008 um 17:32 schrieb Alexander Graf:
>>
>>> Jamie Lokier wrote:
>>>> Alexander Graf wrote:
>>>>
>>>>> I believe the 5% performance hit
>>>>> that goes with them is no real problem, as most people should be  
>>>>> using
>>>>> x86_64 nowadays anyway.
>>>>>
>>>>
>>>> *Boggle*!  x86_64 is only a few years old, and cheap low-power  
>>>> x86_64
>>>> laptops are relatively recent.
>>>>
>>>> -- Jamie
>>>>
>>>>
>>> So you really want to do dynamic retranslation on ancient  
>>> hardware? To
>>> me emulated systems already feel slow on really recent machines, I
>>> don't  want to go back to something even slower.
>>> If you use kqemu there even is near no performance hit at all,  
>>> which I
>>> believe is the main use of qemu on i386 anyway. Furthermore x86_64  
>>> is
>>> _way_ faster, as it provides a lot more registers.
>>>
>>> I think the benefit you get from cutting the gcc3 dependency is  
>>> way more
>>> important than a major performance hit that people will usually  
>>> only see
>>> on the next release of qemu, by which time things have shifted  
>>> towards
>>> x86_64 even more.
>>
>> One thing you don't seem to understand is that QEMU releases don't  
>> upgrade our hardware, especially not from Apple. An x86_64 Mac Pro  
>> is more than double the price for my PowerMac G5 back then. Don't  
>> think about what people "should" be using in your opinion, look at  
>> what they are actually using.
>
> What I am actually talking about is that the only real gcc4 breakage  
> I am aware of is on i386. I just built x86_64-softmmu on a POWER6  
> host with gcc4.1.2 and it "simply worked". Please tell me if there  
> is anything broken for you on gcc4. I believe there isn't (please  
> use gcc4.2+).
>
>>
>> People want to run software, including Q or QEMU, on their hard-  
>> and software, which may include ppc hardware as well as Panther/ 
>> Tiger operating systems ... both much more "ancient" than Intel  
>> Core 2 Duo based Macs. And yes, it's "slow". Does that stop me? No.  
>> And you likely don't have a kqemu on your Mac either. Occasionally  
>> trying an image does not justify buying VMware Fusion, and such  
>> commercial products only do virtualization anyway and are incapable  
>> of emulating different hardware. Just in case you forgot, Open  
>> Source software in general usually has the benefit of not being  
>> tied to the support lifetimes of commercial vendors, forcing users  
>> to upgrade their (e.g. Windows) OS - but pushing us to upgrade our  
>> hardware as soon as something faster is out would be doing exactly  
>> that hardware-wise, without substantial reason.
>
> I wasn't talking about PowerPC. I am really sorry if it looked that  
> way, but it was neither my intention nor my belief to say anything  
> against any platform but i386.

I didn't get you wrong. You repeatedly said that virtually no-one were  
using i386 Macs any longer and that they were ancient. This implies  
that ppc Macs are pre-ancient by linearity of time.

I am not feeling personally insulted as a ppc and i386 user. I am  
simply trying to show that there are in fact even older things still  
in quite common use than what you called "ancient".


The important point to note here is that those i386 Macs need GCC4  
anyway, so there is no other option than some working GCC4 solution  
for i386 and x86_64 on Intel Macs. This seems to go missing when  
discussing availability of chips and PC laptops, where gcc3 is an  
option.
What we seem to agree on is that a performance hit on i386 Macs is  
better than not being able to run on Intel Macs at all - which is the  
current CVS situation.

To me as a relative outsider it appears (maybe that's wrong) that the  
core developers, who wrote the original code affected by GCC3/4 ABI  
changes don't know how to or don't see a pressing need to do the  
change. Then occasionally someone comes along presenting an all-new  
GCC4 patch in a hit-and-run manner, not leading to their patches  
applied or the problem solved...

Andreas