[Qemu-devel] x86-64 port

[Qemu-devel] x86-64 port

[Nick Snellock]

Is anyone working on an x86-64 port?

Nick

Re: [Qemu-devel] x86-64 port

[Fabrice Bellard]

Nick Snellock wrote:
> Is anyone working on an x86-64 port?

Not me :-) An x86-64 host port would be very interesting because the 64 
bit host MMU could be used to remap the whole emulated 4GB address space.

I think that there is also a lot of potential for a "code-copy" mode 
converting x86-32 to x86-64 code (look at what I did for . Along with 
the 4GB space remapping, it would give close to native performances 
without requiring any potentially unsafe kernel module (unlike the 
popular virtualizers).

Fabrice.

Re: [Qemu-devel] x86-64 port

[Gwenole Beauchesne]

Hi,

> Nick Snellock wrote:
>> Is anyone working on an x86-64 port?
>
> Not me :-) An x86-64 host port would be very interesting because the 
> 64 bit host MMU could be used to remap the whole emulated 4GB address 
> space.

Fabrice, remember that I posted AMD64 support bits to the list some 
time ago? ;-) This works for user mode applications. As for the soft 
mmu, the current code is not 64-bit clean. I had some patches but they 
were not enough and are in a dormant state since. So remapping the 
whole 4GB address space is probably a faster and simpler fix indeed.

> I think that there is also a lot of potential for a "code-copy" mode 
> converting x86-32 to x86-64 code (look at what I did for . Along with 
> the 4GB space remapping, it would give close to native performances 
> without requiring any potentially unsafe kernel module (unlike the 
> popular virtualizers).

The popular virtualizers don't officially support AMD64 host systems 
yet. Vmware 4.5 is expected to do so though.

Re: [Qemu-devel] x86-64 port

[Fabrice Bellard]

Gwenole Beauchesne wrote:
> Hi,
> 
>> Nick Snellock wrote:
>>
>>> Is anyone working on an x86-64 port?
>>
>>
>> Not me :-) An x86-64 host port would be very interesting because the 
>> 64 bit host MMU could be used to remap the whole emulated 4GB address 
>> space.
> 
> 
> Fabrice, remember that I posted AMD64 support bits to the list some time 
> ago? ;-) This works for user mode applications. As for the soft mmu, the 
> current code is not 64-bit clean. I had some patches but they were not 
> enough and are in a dormant state since. So remapping the whole 4GB 
> address space is probably a faster and simpler fix indeed.

Sorry - I should have merged it before ! If you can generate a new patch 
against the current CVS I'll merge it (if you don't have time I can 
begin to look at it - I am looking now at the version you posted). If 
the user mode is working, most of the work is done.

>> I think that there is also a lot of potential for a "code-copy" mode 
>> converting x86-32 to x86-64 code (look at what I did for . Along with 
>> the 4GB space remapping, it would give close to native performances 
>> without requiring any potentially unsafe kernel module (unlike the 
>> popular virtualizers).
> 
> 
> The popular virtualizers don't officially support AMD64 host systems 
> yet. Vmware 4.5 is expected to do so though.

OK. So this is even better for QEMU :-)

Fabrice.

Re: [Qemu-devel] x86-64 port

[Fabrice Bellard]

Fabrice Bellard wrote:
> Gwenole Beauchesne wrote:
> 
>> Hi,
>>
>>> Nick Snellock wrote:
>>>
>>>> Is anyone working on an x86-64 port?
>>>
>>>
>>>
>>> Not me :-) An x86-64 host port would be very interesting because the 
>>> 64 bit host MMU could be used to remap the whole emulated 4GB address 
>>> space.
>>
>>
>>
>> Fabrice, remember that I posted AMD64 support bits to the list some 
>> time ago? ;-) This works for user mode applications. As for the soft 
>> mmu, the current code is not 64-bit clean. I had some patches but they 
>> were not enough and are in a dormant state since. So remapping the 
>> whole 4GB address space is probably a faster and simpler fix indeed.
> 
> 
> Sorry - I should have merged it before ! If you can generate a new patch 
> against the current CVS I'll merge it (if you don't have time I can 
> begin to look at it - I am looking now at the version you posted). If 
> the user mode is working, most of the work is done.

It seems easy to merge... so I am merging it now.

Fabrice.

Re: [Qemu-devel] x86-64 port

[Fabrice Bellard]

Gwenole Beauchesne wrote:
> Hi,
> 
>> Nick Snellock wrote:
>> 
>>> Is anyone working on an x86-64 port?
>> 
>> 
>> Not me :-) An x86-64 host port would be very interesting because
>> the 64 bit host MMU could be used to remap the whole emulated 4GB
>> address space.
> 
> 
> Fabrice, remember that I posted AMD64 support bits to the list some
> time ago? ;-) This works for user mode applications. As for the soft
> mmu, the current code is not 64-bit clean. I had some patches but
> they were not enough and are in a dormant state since. So remapping
> the whole 4GB address space is probably a faster and simpler fix
> indeed.

The x86-64 patch is now commited, except for the 'code_gen_buffer' patch
(can you explain it ?). Can you also explain what are the problems with
the soft MMU ?

Fabrice.

[Qemu-devel] Re: x86-64 port

[Andi Kleen]

Fabrice Bellard <fabrice@bellard.org> writes:

> Nick Snellock wrote:
>> Is anyone working on an x86-64 port?
>
> Not me :-) An x86-64 host port would be very interesting because the
> 64 bit host MMU could be used to remap the whole emulated 4GB address
> space.

I tried to run it recently in 32bit emulation on the 64bit kernel,
but it just produced a lot of segfaults. Even when I forced the
address room to 3GB. Most likely it triggers bugs in the 32bit emulation
layer. I wasn't able to look into it yet.

> I think that there is also a lot of potential for a "code-copy" mode
> converting x86-32 to x86-64 code (look at what I did for . Along with
> the 4GB space remapping, it would give close to native performances
> without requiring any potentially unsafe kernel module (unlike the
> popular virtualizers).

Yes, and you may even get better code in the result (you have 16 registers
to play with instead of 8) 

There is one problem however: currently there are a few system calls
that know if they are executing in 32bit or 64bit and act accordingly.
You can call the 32bit int 0x80 system call handler from a 64bit process,
but you would probably run into smaller issues. This may need a few kernel
fixes. For example the environment and some other pointers are 64bit.
Should be all fixable though.

-Andi