[Qemu-devel] x86_64 target

[Qemu-devel] x86_64 target

[Fabrice Bellard]

Hi,

As a small gift for this new year, here is an initial implementation of 
the x86_64 target in QEMU. It is a "work in progress" as usual, but it 
works enough to boot an x86_64 Linux kernel (I used the one available at 
http://bochs.sourceforge.net/guestos/linux.x86-64.bzImage).

Although the x86_64 target works correctly on 32 bit hosts, it is 
designed to have the best performances on 64 bit hosts, such as x86_64 
or ppc64. The current speed is poor relatively to the i386 emulation 
because I did not enable register usage on 64 bit hosts (no time to test 
it yet).

The biggest missing part is a full implementation of SSE - I only added 
the minimal subset for the Linux kernel. I won't work again on the 
x86_64 target in the near future (as I said earlier most of my time is 
dedicated on improving the x86 on x86 speed), but anyone is free to 
submit patches.

Fabrice.

Re: [Qemu-devel] x86_64 target

[Karl Magdsick]

Wohoo!  

Of course, AMD changed the architecture name from x86-64 to amd64 and
Intel has their own 64-bit implementation that overlaps the amd64
instruction set, called EMT (Extended Memory Technology, not to be
confused with Intel's ESMA/PSE36 36-bit technology).  For Linux,
x86_64 was used instead of x86-64 because the dash was used as a
seperator in Linux naming conventions and Linus opted not to migrate
architecture names when AMD changed the name to amd64.  Some Linux
distributions name their distributions amd64 after the official
architecture name and some name them x86_64 or x86-64 after the Linux
kernel/historical architecture name.

The EMT Xeons implement all of the amd64 instructions that were in an
early release of the instruction set reference, so I think a single
64-bit Linux kernel can boot and run on both amd64 and EMT Xeon chips.
 The EMT Xeons may implement all of the instructions announced before
the name switch to amd64, but I'm not sure exactly when the name
change occured and when the newer instructions were announced.

Am I correct in assuming that the QEMU x86_64 is intended to track the
amd64 instruction set?
If you intend to track the EMT instruction set and emulate EMT Xeons,
you may have to implement ESMA/PSE36 36-bit addressing.

Are you implementing the 40-bit internal addressing scheme used in
current generation amd64 chips?


-Karl

On Tue, 04 Jan 2005 01:18:03 +0100, Fabrice Bellard <fabrice@bellard.org> wrote:
> Hi,
> 
> As a small gift for this new year, here is an initial implementation of
> the x86_64 target in QEMU. It is a "work in progress" as usual, but it
> works enough to boot an x86_64 Linux kernel (I used the one available at
> http://bochs.sourceforge.net/guestos/linux.x86-64.bzImage).
> 
> Although the x86_64 target works correctly on 32 bit hosts, it is
> designed to have the best performances on 64 bit hosts, such as x86_64
> or ppc64. The current speed is poor relatively to the i386 emulation
> because I did not enable register usage on 64 bit hosts (no time to test
> it yet).
> 
> The biggest missing part is a full implementation of SSE - I only added
> the minimal subset for the Linux kernel. I won't work again on the
> x86_64 target in the near future (as I said earlier most of my time is
> dedicated on improving the x86 on x86 speed), but anyone is free to
> submit patches.
> 
> Fabrice.
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>

Re: [Qemu-devel] x86_64 target

[Paul Brook]

On Tuesday 04 January 2005 02:15, Karl Magdsick wrote:
> The EMT Xeons implement all of the amd64 instructions that were in an
> early release of the instruction set reference, so I think a single
> 64-bit Linux kernel can boot and run on both amd64 and EMT Xeon chips.
>  The EMT Xeons may implement all of the instructions announced before
> the name switch to amd64, but I'm not sure exactly when the name
> change occured and when the newer instructions were announced.

The Intel chips actually implement all the instructions except 3DNOW and add 
SSE3, same as p4 vs. AthlonXP. These are the only instruction set 
differences, and the only differences that are visible from userspace.

The other differences in the implementations are that the current generation 
of Intel chips don't implement the NX bit, or have an IOMMU. I think there 
are also differences in how pagetables are setup/managed though I'm not sure 
about the details.

Paul

Re: [Qemu-devel] x86_64 target

[Jeebs]

From: "Paul Brook"

> On Tuesday 04 January 2005 02:15, Karl Magdsick wrote:
>> The EMT Xeons implement all of the amd64 instructions that were in an
>> early release of the instruction set reference, so I think a single
> 
> The Intel chips actually implement all the instructions except 3DNOW and add 
> SSE3, same as p4 vs. AthlonXP. These are the only instruction set 
> differences, and the only differences that are visible from userspace.

Actually, I thought the Intel chips did *not* implement the full x86-64 instruction set.  That's what a few early reports were saying.

They made their 64 bit version using a draft of the initial 64 bit specs, but AMD made some changes right at the end, and as a result the Intel chips (and AMD's own initial batch of chips) don't fully support the x86-64 instruction set.

I haven't been keeping track, but I haven't heard of any changes from Intel to implement the missing instruction(s).

[Qemu-devel] Re: x86_64 target

[Alexander E. Patrakov]

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

Fabrice Bellard wrote:

> Hi,
> 
> As a small gift for this new year, here is an initial implementation of
> the x86_64 target in QEMU. It is a "work in progress" as usual, but it
> works enough to boot an x86_64 Linux kernel (I used the one available at
> http://bochs.sourceforge.net/guestos/linux.x86-64.bzImage).
> 
> Although the x86_64 target works correctly on 32 bit hosts, it is
> designed to have the best performances on 64 bit hosts, such as x86_64
> or ppc64. The current speed is poor relatively to the i386 emulation
> because I did not enable register usage on 64 bit hosts (no time to test
> it yet).
> 
> The biggest missing part is a full implementation of SSE - I only added
> the minimal subset for the Linux kernel. I won't work again on the
> x86_64 target in the near future (as I said earlier most of my time is
> dedicated on improving the x86 on x86 speed), but anyone is free to
> submit patches.

I booted an existing win2k image with the new qemu-system-x86_64 emulator
(just to check that there are no i386 regressions) and the result is a
bluescreen (GOCR'ed and attached).

-- 
Alexander E. Patrakov

[-- Attachment #2: crash.txt --]
[-- Type: text/plain, Size: 860 bytes --]

*** STOP: 0x0000001E (0xC000001D,0x80432AC9,0xE1008A98,0xF74lB99C)
KMODE_EXCEPTION_NOT_HANDLED

*** Address 80432AC9 base at 80400000, DateStamp 384d9bl7 - ntoskrnl.exe

If this is the first time gou've seen this Stop error screen,
restart gour computer. If this screen appears again, follow
these steps:

Check to be sure gou have adequate disk space. If a driver is
identified in the Stop Message, disable the driver or check
with the manufacturer for driver updates. Try changing video
adapters.

Check with gour hardware vendor for ang BIOS updates. Disable
BIOS memorg options such as caching or shadowing. If gou need
to use Safe Mode to reMove or disable components, restart gour
computer, press F8 to select Advanced Startup Options, and then
select Safe Mode.

Refer to gour Getting Started manual for more information on
troubleshooting Stop errors.

Re: [Qemu-devel] Re: x86_64 target

[Fabrice Bellard]

Hi,

I noticed the problem too, but hopefully it is not a regression: for 
x86_64, I added more features in the CPUID so that Linux accepts to 
switch to 64 bit, but I did not implement or test them all (SSE, MMX, 
APIC and PAE). So if you want to make regression tests, the easiest is 
to diable that in target-i386/helper2.c:109:

--
         env->cpuid_version = (family << 8) | (model << 4) | stepping;
         env->cpuid_features = (CPUID_FP87 | CPUID_DE | CPUID_PSE |
                                CPUID_TSC | CPUID_MSR | CPUID_MCE |
                                CPUID_CX8 | CPUID_PGE | CPUID_CMOV);
#if defined(TARGET_X86_64) && 0
         /* currently not enabled for std i386 because not fully tested */
         env->cpuid_features |= CPUID_APIC | CPUID_FXSR | CPUID_PAE |
             CPUID_SSE | CPUID_SSE2;
#endif
     }
--


I was able to boot win2k succefully with the x86_64 target. The most 
likely regressions (I am sure there are still some) must be caused by 
the fact that some values are not properly extended from 32 bits to 64 
bits with zeros.

Fabrice.

Alexander E. Patrakov wrote:
> Fabrice Bellard wrote:
> 
> 
>>Hi,
>>
>>As a small gift for this new year, here is an initial implementation of
>>the x86_64 target in QEMU. It is a "work in progress" as usual, but it
>>works enough to boot an x86_64 Linux kernel (I used the one available at
>>http://bochs.sourceforge.net/guestos/linux.x86-64.bzImage).
>>
>>Although the x86_64 target works correctly on 32 bit hosts, it is
>>designed to have the best performances on 64 bit hosts, such as x86_64
>>or ppc64. The current speed is poor relatively to the i386 emulation
>>because I did not enable register usage on 64 bit hosts (no time to test
>>it yet).
>>
>>The biggest missing part is a full implementation of SSE - I only added
>>the minimal subset for the Linux kernel. I won't work again on the
>>x86_64 target in the near future (as I said earlier most of my time is
>>dedicated on improving the x86 on x86 speed), but anyone is free to
>>submit patches.
> 
> 
> I booted an existing win2k image with the new qemu-system-x86_64 emulator
> (just to check that there are no i386 regressions) and the result is a
> bluescreen (GOCR'ed and attached).
> 
> 
> 
> ------------------------------------------------------------------------
> 
> *** STOP: 0x0000001E (0xC000001D,0x80432AC9,0xE1008A98,0xF74lB99C)
> KMODE_EXCEPTION_NOT_HANDLED
> 
> *** Address 80432AC9 base at 80400000, DateStamp 384d9bl7 - ntoskrnl.exe
> 
> If this is the first time gou've seen this Stop error screen,
> restart gour computer. If this screen appears again, follow
> these steps:
> 
> Check to be sure gou have adequate disk space. If a driver is
> identified in the Stop Message, disable the driver or check
> with the manufacturer for driver updates. Try changing video
> adapters.
> 
> Check with gour hardware vendor for ang BIOS updates. Disable
> BIOS memorg options such as caching or shadowing. If gou need
> to use Safe Mode to reMove or disable components, restart gour
> computer, press F8 to select Advanced Startup Options, and then
> select Safe Mode.
> 
> Refer to gour Getting Started manual for more information on
> troubleshooting Stop errors.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] x86_64 target

[Lennert Buytenhek]

On Tue, Jan 04, 2005 at 01:18:03AM +0100, Fabrice Bellard wrote:

> As a small gift for this new year, here is an initial implementation of 
> the x86_64 target in QEMU. It is a "work in progress" as usual, but it 
> works enough to boot an x86_64 Linux kernel (I used the one available at 
> http://bochs.sourceforge.net/guestos/linux.x86-64.bzImage).

It seems to boot the Fedora Core 3 x86_64 kernel fine as well (which
is based on 2.6.9-something.)  Now to test userland..


--L

Re: [Qemu-devel] x86_64 target

[Lennert Buytenhek]

On Thu, Jan 06, 2005 at 01:10:24PM +0100, Lennert Buytenhek wrote:

> > As a small gift for this new year, here is an initial implementation of 
> > the x86_64 target in QEMU. It is a "work in progress" as usual, but it 
> > works enough to boot an x86_64 Linux kernel (I used the one available at 
> > http://bochs.sourceforge.net/guestos/linux.x86-64.bzImage).
> 
> It seems to boot the Fedora Core 3 x86_64 kernel fine as well (which
> is based on 2.6.9-something.)  Now to test userland..

When trying to start bash (init=/bin/bash) it spews endless numbers of
these just after 'Freeing unused kernel memory:'

sh[1]: segfault at ffffffff95560b9a rip ffffffff95560b9a rsp 0000007fbffff7f0 error 4


--L

[Qemu-devel] Re: x86_64 target

[Ronald]

Le Thu, 06 Jan 2005 13:42:34 +0100, Lennert Buytenhek a écrit :

> On Thu, Jan 06, 2005 at 01:10:24PM +0100, Lennert Buytenhek wrote:
> 
>> > As a small gift for this new year, here is an initial implementation
>> > of the x86_64 target in QEMU. It is a "work in progress" as usual, but
>> > it works enough to boot an x86_64 Linux kernel (I used the one
>> > available at
>> > http://bochs.sourceforge.net/guestos/linux.x86-64.bzImage).
>> 
>> It seems to boot the Fedora Core 3 x86_64 kernel fine as well (which is
>> based on 2.6.9-something.)  Now to test userland..
> 
> When trying to start bash (init=/bin/bash) it spews endless numbers of
> these just after 'Freeing unused kernel memory:'
> 
> sh[1]: segfault at ffffffff95560b9a rip ffffffff95560b9a rsp
> 0000007fbffff7f0 error 4
> 
> 

I get segfault too with dynamicaly linked binaries, but static ones run,
not sure if it's qemu or if it's my glibc that is faulty.

> --L