From shivaram.upadhyayula at wipro.com Fri May 2 17:13:19 2003
From: shivaram.upadhyayula at wipro.com (Shivram U)
Date: Fri, 2 May 2003 20:43:19 +0530
Subject: [discuss]Problems with simnow
In-Reply-To: <20030430164704.GA24447@LaRive.suse.de>
Message-ID: <01e101c310bd$5d0221b0$bb09720a@shivram.wipro.com>
Hello,
Actually the problem was with the partitions i had on my hard disk. I
repartitioned the disk, keeping the boot partition to around 800 MB. Then i
created a diskimage of around 1GB. With this change, LILO starts fine,
however on choosing the bzImage for x86-64 i get the following error
"Your CPU does not support long mode. Use a 32bit distribution."
The kernel sources were of the daily cvs snapshots. There was another post
with the same problem for the bochs simulator. It seems that the SimNow
simulator might not work with newer kernels.
regards,
shivram
> -----Original Message-----
> From: Andreas Jaeger [mailto:aj at suse.de]
> Sent: Wednesday, April 30, 2003 10:17 PM
> To: Gustav H?llberg
> Cc: Andreas Jaeger; discuss at x86-64.org
> Subject: Re: Re: [discuss]Problems with simnow
>
>
> On Wed, Apr 30, 2003 at 05:57:38PM +0200, Gustav H?llberg wrote:
> > > > I am having problems with the simnow simulator. The
> problem i am facing is
> > > > when the diskimage file is greater than 2GB. I get an error
> by simnow saying
> > > > it is unable to open the disimage file.
> > > :
> > > This is impossible with simics - the functions use do not allow files
> > > larger than 2GB. For that the program has to be changed,
> >
> > Let me point out that Andreas probably meant to write something
> along the lines
> > of "this is impossible with simnow but works with Simics",
> since, as far as I
> > know, large files have been supported by Simics for a long time.
>
> You are right. Sorry I mixed up the two products in a bad way -
> I have used Simics too long ;-)
>
> Andreas
> --
> Andreas Jaeger
> SuSE Labs aj at suse.de
> private aj at arthur.inka.de
> http://www.suse.de/~aj
>
**************************Disclaimer************************************
Information contained in this E-MAIL being proprietary to Wipro Limited is
'privileged' and 'confidential' and intended for use only by the individual
or entity to which it is addressed. You are notified that any use, copying
or dissemination of the information contained in the E-MAIL in any manner
whatsoever is strictly prohibited.
***************************************************************************
From ak at suse.de Fri May 2 17:34:09 2003
From: ak at suse.de (Andi Kleen)
Date: Fri, 2 May 2003 17:34:09 +0200
Subject: [discuss]Problems with simnow
In-Reply-To: <01e101c310bd$5d0221b0$bb09720a@shivram.wipro.com>
References: <20030430164704.GA24447@LaRive.suse.de> <01e101c310bd$5d0221b0$bb09720a@shivram.wipro.com>
Message-ID: <20030502153409.GA31218@oldwotan.suse.de>
On Fri, May 02, 2003 at 08:43:19PM +0530, Shivram U wrote:
> Actually the problem was with the partitions i had on my hard disk. I
> repartitioned the disk, keeping the boot partition to around 800 MB. Then i
> created a diskimage of around 1GB. With this change, LILO starts fine,
> however on choosing the bzImage for x86-64 i get the following error
>
> "Your CPU does not support long mode. Use a 32bit distribution."
>
> The kernel sources were of the daily cvs snapshots. There was another post
> with the same problem for the bochs simulator. It seems that the SimNow
> simulator might not work with newer kernels.
Yes, it's failing the CPUID check. You can disable it in the kernel
when you comment out the code block in arch/x86_64/boot/setup.S
from the "loader_ok:" label to the instruction after "sse_ok:"
(directly before the "# Get memory size" comment)
Another alternative would be to use Bochs - it supports amd64 too these
days and has this bug fixed in its CVS version. And you'll likely find
more people on this list that know about it. Also I bet it's faster
than simnow.
-Andi
From alangrimes at starpower.net Fri May 2 19:09:34 2003
From: alangrimes at starpower.net (Alan Grimes)
Date: Fri, 02 May 2003 13:09:34 -0400
Subject: Hello/listCheck
Message-ID: <3EB2A64E.10406@starpower.net>
Hello,
I subscribed to this list a few days ago and had hoped to get a feel for
its culture before posting myself. Unfortunately there doesn't seem to
be any activity so I decided to post this to see wheather I was actually
subscribed and that the list software is functioning.
I finally realized that the decision to drop segmentation in the x86-64
architecture presents an awesome opportunity for an upstart OS developer
because it removes that much complexity from the task.
It is my hope that I can take advantage of this opportunity to break
free of unix, which is essentially a 12-bit operating system, and
implement my own design. =)
I will talk more about this when I get my dual Athlon back (which,
sadly, I had to RMA due to a problem with the multi-IO chip...).
From hpa at zytor.com Fri May 2 20:28:52 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 2 May 2003 11:28:52 -0700
Subject: [discuss] Hello/listCheck
References: <3EB2A64E.10406@starpower.net>
Message-ID:
Followup to: <3EB2A64E.10406 at starpower.net>
By author: Alan Grimes
In newsgroup: linux.ports.x86-64.discuss
>
> I finally realized that the decision to drop segmentation in the x86-64
> architecture presents an awesome opportunity for an upstart OS developer
> because it removes that much complexity from the task.
>
Hardly so. It doesn't remove any complexity that you can't remove
yourself. It just means the CPU doesn't have to implement a feature
noone wants.
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From mharris at www.linux.org.uk Sat May 3 23:03:32 2003
From: mharris at www.linux.org.uk (Mike A. Harris)
Date: Sat, 3 May 2003 17:03:32 -0400 (EDT)
Subject: [discuss] me
In-Reply-To: <20030503205446.40233.qmail@web10405.mail.yahoo.com>
Message-ID:
On Sat, 3 May 2003, Craig Likes wrote:
>Date: Sat, 3 May 2003 13:54:46 -0700 (PDT)
>From: Craig Likes
>To: discuss at x86-64.org
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: [discuss] me
>
>We need a moderator... these are becoming more and
>more common.
The simple solution is to only allow subscribed members to post
to the mailing list. Then the list admin just empties the crap
bucket once a week with a gang DELETE from the admin moderation
queue. Works great for me on the mailing lists I maintain. ;o)
--
Mike A. Harris
From richard.brunner at amd.com Sun May 4 08:34:46 2003
From: richard.brunner at amd.com (richard.brunner at amd.com)
Date: Sun, 4 May 2003 01:34:46 -0500
Subject: [discuss] me
Message-ID: <99F2150714F93F448942F9A9F112634C02B540F0@txexmtae.amd.com>
agree,
we'll see what we can do.
> -----Original Message-----
> From: Mike A. Harris [mailto:mharris at www.linux.org.uk]
> Sent: Saturday, May 03, 2003 4:04 PM
> To: Craig Likes
> Cc: discuss at x86-64.org
> Subject: Re: [discuss] me
>
>
> On Sat, 3 May 2003, Craig Likes wrote:
>
> >Date: Sat, 3 May 2003 13:54:46 -0700 (PDT)
> >From: Craig Likes
> >To: discuss at x86-64.org
> >Content-Type: text/plain; charset=us-ascii
> >Subject: Re: [discuss] me
> >
> >We need a moderator... these are becoming more and
> >more common.
>
> The simple solution is to only allow subscribed members to post
> to the mailing list. Then the list admin just empties the crap
> bucket once a week with a gang DELETE from the admin moderation
> queue. Works great for me on the mailing lists I maintain. ;o)
>
> --
> Mike A. Harris
>
>
>
From dewar at gnat.com Sun May 4 16:20:15 2003
From: dewar at gnat.com (Robert Dewar)
Date: Sun, 4 May 2003 10:20:15 -0400 (EDT)
Subject: [discuss] me
Message-ID: <20030504142015.83324F2D55@nile.gnat.com>
> The simple solution is to only allow subscribed members to post
> to the mailing list. Then the list admin just empties the crap
> bucket once a week with a gang DELETE from the admin moderation
> queue. Works great for me on the mailing lists I maintain. ;o)
What we do with the ACT report address is to insist on (very simple)
rules for the subject line. If we receive mail that does not follow
the rules, we send back a note outlining the rules. This works essentially
perfectly to eliminate spam. One of the good things about spam is that
there is no one intelligent at the other end :-)
From ak at suse.de Sun May 4 17:26:21 2003
From: ak at suse.de (Andi Kleen)
Date: Sun, 4 May 2003 17:26:21 +0200
Subject: [discuss] me
In-Reply-To: <99F2150714F93F448942F9A9F112634C02B540F0@txexmtae.amd.com>
References: <99F2150714F93F448942F9A9F112634C02B540F0@txexmtae.amd.com>
Message-ID: <20030504152621.GA30240@Wotan.suse.de>
On Sun, May 04, 2003 at 01:34:46AM -0500, Richard Brunner wrote:
> agree,
>
> we'll see what we can do.
I would prefer if the list was not closed to non subscribers. This makes
it impossible to put it into cc for discussions originating on other
mailing lists (like linux-kernel). This would result in interesting
mail not arriving on this list and not being archived etc.
Usual spam protection (using RBLs for known open relays on the mail server,
running spamassassin etc.) should be enough. Possible an occassional
spams will still slip through even with that, but that's the price
for an useful open mailing list.
-Andi
From andrebalsa at mailingaddress.org Sun May 4 21:26:47 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Mon, 5 May 2003 03:26:47 +0800
Subject: What is the status of NX bit in latest x86_64 2.4.21-rc1 kernel?
Message-ID: <200305050326.47557.andrebalsa@mailingaddress.org>
Hi,
With the recent patch/announcement by Ingo Molnar for i386, I was checking the
previous discussion (mainly between AK and HPA) on the subject, but checking
the code I cannot see what or where it is implemented.
So is the default (64 bit protects stack, etc, but 32-bit doesn?t) implemented
and enforced or not?
Thanks,
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From hpa at zytor.com Sun May 4 21:44:22 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 4 May 2003 12:44:22 -0700
Subject: [discuss] me
References: <20030503205446.40233.qmail@web10405.mail.yahoo.com>
Message-ID:
Followup to: <20030503205446.40233.qmail at web10405.mail.yahoo.com>
By author: Craig Likes
In newsgroup: linux.ports.x86-64.discuss
>
> We need a moderator... these are becoming more and
> more common.
>
Zeroeth order this group needs some hefty spam filtering on the head
end. On all the mailing lists I run I run SpamAssassin as well as
filter all html and multipart messages off to a moderation queue.
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From hpa at zytor.com Sun May 4 21:45:17 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 4 May 2003 12:45:17 -0700
Subject: [discuss] me
References: <20030503205446.40233.qmail@web10405.mail.yahoo.com>
Message-ID:
Followup to:
By author: "Mike A. Harris"
In newsgroup: linux.ports.x86-64.discuss
>
> The simple solution is to only allow subscribed members to post
> to the mailing list. Then the list admin just empties the crap
> bucket once a week with a gang DELETE from the admin moderation
> queue. Works great for me on the mailing lists I maintain. ;o)
>
As long as there is a way to whitelist legitimate non-mail posting
addresses. Mailman does this relatively well; you subscribe to the
list and select "no mail" for your posting address.
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From ak at suse.de Mon May 5 05:07:09 2003
From: ak at suse.de (Andi Kleen)
Date: Mon, 5 May 2003 05:07:09 +0200
Subject: [discuss] What is the status of NX bit in latest x86_64 2.4.21-rc1 kernel?
In-Reply-To: <200305050326.47557.andrebalsa@mailingaddress.org>
References: <200305050326.47557.andrebalsa@mailingaddress.org>
Message-ID: <20030505030709.GC21955@Wotan.suse.de>
On Mon, May 05, 2003 at 03:26:47AM +0800, Andrew Derrick Balsa wrote:
> With the recent patch/announcement by Ingo Molnar for i386, I was checking the
> previous discussion (mainly between AK and HPA) on the subject, but checking
> the code I cannot see what or where it is implemented.
>
> So is the default (64 bit protects stack, etc, but 32-bit doesn?t) implemented
> and enforced or not?
First "protection" is a bit too strong word. It helps slightly, but it is
nowhere near a real stack smashing protection.
Default currently is to always allow to execute everything for both 32bit
and 64bit. You can boot with noexec=on to make NX the default for 64bit
stack/data/heap, but some programs that require executable stack will not
work anymore (e.g. GNAT Ada programs/compiler). Also some other programs
that try to execute on stack/heap/data segment may break
One bug left is that with noexec=on you cannot execute on the stack
even after mprotect(). I have a patch for this now, but it is not
integrated yet.
For the Ada issues it will require an patch to gcc. I have some code
for this, but it's not integrated into gcc yet. It'll also require an
updated kernel.
For compat mode you cannot use NX currently.
-Andi
From andrebalsa at mailingaddress.org Mon May 5 05:55:28 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Mon, 5 May 2003 11:55:28 +0800
Subject: [discuss] What is the status of NX bit in latest x86_64 2.4.21-rc1 kernel?
In-Reply-To: <20030505030709.GC21955@Wotan.suse.de>
References: <200305050326.47557.andrebalsa@mailingaddress.org> <20030505030709.GC21955@Wotan.suse.de>
Message-ID: <200305051155.28514.andrebalsa@mailingaddress.org>
Hi,
On Monday 05 May 2003 11:07, Andi Kleen wrote:
...
> Default currently is to always allow to execute everything for both 32bit
> and 64bit. You can boot with noexec=on to make NX the default for 64bit
> stack/data/heap, but some programs that require executable stack will not
> work anymore (e.g. GNAT Ada programs/compiler). Also some other programs
> that try to execute on stack/heap/data segment may break
...
Reading the AMD specs, with NX set any attempt to execute code in
stack/data/heap should generate a page fault.
But looking at the code in linux/arch/x86-64/mm/fault.c, this fault is not
handled specifically: the process just gets killed (if I read it correctly).
It would be interesting to handle this fault in such a way that the fault is
reported in kernel log, with a message of the kind: ?NX page fault: attempt
to execute code in stack | heap | data in process pid xxxx.?
In contrast I have checked the exec-shield patch, and compared to the simple
mechanism in the x86_64 it looks very much like trying to retrofit a turbine
fire extinguisher on a motorcycle single-cylinder two-stroke engine. :-)
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From ak at suse.de Mon May 5 06:13:06 2003
From: ak at suse.de (Andi Kleen)
Date: Mon, 5 May 2003 06:13:06 +0200
Subject: [discuss] What is the status of NX bit in latest x86_64 2.4.21-rc1 kernel?
In-Reply-To: <200305051155.28514.andrebalsa@mailingaddress.org>
References: <200305050326.47557.andrebalsa@mailingaddress.org> <20030505030709.GC21955@Wotan.suse.de> <200305051155.28514.andrebalsa@mailingaddress.org>
Message-ID: <20030505041306.GB27021@Wotan.suse.de>
> But looking at the code in linux/arch/x86-64/mm/fault.c, this fault is not
> handled specifically: the process just gets killed (if I read it correctly).
Yes of course. What else should it do?
> It would be interesting to handle this fault in such a way that the fault is
> reported in kernel log, with a message of the kind: ?NX page fault: attempt
> to execute code in stack | heap | data in process pid xxxx.?
You can already see that. The kernel reports the error number and when it is
>= 15 (bit 4 set) it was an NX fault.
> In contrast I have checked the exec-shield patch, and compared to the simple
> mechanism in the x86_64 it looks very much like trying to retrofit a turbine
> fire extinguisher on a motorcycle single-cylinder two-stroke engine. :-)
exec shield does more too. it introduces the concept of an "ascii shield"
But on 64bit little endian you have the ASCII shield by default because
each address ends with two 0 bytes (48 byte address room), which are first
in memory. This cannot be created by a 0 terminated string.
It also has the concept of not allowing code pages to be written,
that's not in the 64bit kernel, but they're normally read only anyways.
-Andi
From andrebalsa at mailingaddress.org Mon May 5 06:24:54 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Mon, 5 May 2003 12:24:54 +0800
Subject: [discuss] What is the status of NX bit in latest x86_64 2.4.21-rc1 kernel?
In-Reply-To: <20030505030709.GC21955@Wotan.suse.de>
References: <200305050326.47557.andrebalsa@mailingaddress.org> <20030505030709.GC21955@Wotan.suse.de>
Message-ID: <200305051224.54303.andrebalsa@mailingaddress.org>
Hi,
On Monday 05 May 2003 11:07, Andi Kleen wrote:
...
> Default currently is to always allow to execute everything for both 32bit
> and 64bit. You can boot with noexec=on to make NX the default for 64bit
> stack/data/heap, but some programs that require executable stack will not
> work anymore (e.g. GNAT Ada programs/compiler). Also some other programs
> that try to execute on stack/heap/data segment may break
According to an anonymous user who tested his (unspecified) distribution with
the exec-shield patch for i386, these are some programs that break (his list,
not mine):
Mozilla
Evolution,
the Java VM and consequently any Java application,
UT2003 (??),
Duke Nukem 3D (??),
Xmms,
GNOME programs,
Galeon,
MySQL
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From andrebalsa at mailingaddress.org Mon May 5 06:42:48 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Mon, 5 May 2003 12:42:48 +0800
Subject: [discuss] What is the status of NX bit in latest x86_64 2.4.21-rc1 kernel?
In-Reply-To: <20030505041306.GB27021@Wotan.suse.de>
References: <200305050326.47557.andrebalsa@mailingaddress.org> <200305051155.28514.andrebalsa@mailingaddress.org> <20030505041306.GB27021@Wotan.suse.de>
Message-ID: <200305051242.48026.andrebalsa@mailingaddress.org>
Hi Andi,
On Monday 05 May 2003 12:13, Andi Kleen wrote:
> > But looking at the code in linux/arch/x86-64/mm/fault.c, this fault is
> > not handled specifically: the process just gets killed (if I read it
> > correctly).
>
> Yes of course. What else should it do?
Not execute the code but also not kill the ?victim? process?
The way it?s implemented right now (again, if I understand it correctly) if a
hacker finds a buffer overflow in e.g. sendmail he can kill sendmail on a
server -> DOS attack.
A more fine-grained page-fault handling for this specific error could be
implemented, say by using noexec=off|on|kill, where ?kill? would keep the
present behaviour, but ?on? would just report and prevent the execution of
the offending code.
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From ak at suse.de Mon May 5 06:42:48 2003
From: ak at suse.de (Andi Kleen)
Date: Mon, 5 May 2003 06:42:48 +0200
Subject: [discuss] What is the status of NX bit in latest x86_64 2.4.21-rc1 kernel?
In-Reply-To: <200305051242.48026.andrebalsa@mailingaddress.org>
References: <200305050326.47557.andrebalsa@mailingaddress.org> <200305051155.28514.andrebalsa@mailingaddress.org> <20030505041306.GB27021@Wotan.suse.de> <200305051242.48026.andrebalsa@mailingaddress.org>
Message-ID: <20030505044248.GC29714@Wotan.suse.de>
On Mon, May 05, 2003 at 12:42:48PM +0800, Andrew Derrick Balsa wrote:
> Hi Andi,
>
> On Monday 05 May 2003 12:13, Andi Kleen wrote:
> > > But looking at the code in linux/arch/x86-64/mm/fault.c, this fault is
> > > not handled specifically: the process just gets killed (if I read it
> > > correctly).
> >
> > Yes of course. What else should it do?
>
> Not execute the code but also not kill the ?victim? process?
There is nothing sensible that can be done. The kernel cannot jump
to a random location. It doesn't know where to continue the program.
That is why it kills it.
>
> The way it?s implemented right now (again, if I understand it correctly) if a
> hacker finds a buffer overflow in e.g. sendmail he can kill sendmail on a
> server -> DOS attack.
Yes, but he can crash it anyways by just writing garbage on the stack.
No need to execute anything.
-Andi
From andrebalsa at mailingaddress.org Mon May 5 08:46:36 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Mon, 5 May 2003 14:46:36 +0800
Subject: [discuss] What is the status of NX bit in latest x86_64 2.4.21-rc1 kernel?
In-Reply-To: <20030505044248.GC29714@Wotan.suse.de>
References: <200305050326.47557.andrebalsa@mailingaddress.org> <200305051242.48026.andrebalsa@mailingaddress.org> <20030505044248.GC29714@Wotan.suse.de>
Message-ID: <200305051446.37067.andrebalsa@mailingaddress.org>
Hi,
I found that the kNox patch provides for i386 in software something very close
to NX mechanism in x86_64 hardware.
http://www.isec.pl/projects/knox/knox.html
The kNox patch includes a demo.c program that effectively tests the no-exec
mechanism. I don?t have access to real x86_64 hardware, but I would be
curious to know the results of this test program on a recent x86_64 kernel
booted with noexec=on option.
Thanks,
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From ak at suse.de Mon May 5 10:02:47 2003
From: ak at suse.de (Andi Kleen)
Date: Mon, 5 May 2003 10:02:47 +0200
Subject: [discuss] What is the status of NX bit in latest x86_64 2.4.21-rc1 kernel?
In-Reply-To: <200305051446.37067.andrebalsa@mailingaddress.org>
References: <200305050326.47557.andrebalsa@mailingaddress.org> <200305051242.48026.andrebalsa@mailingaddress.org> <20030505044248.GC29714@Wotan.suse.de> <200305051446.37067.andrebalsa@mailingaddress.org>
Message-ID: <20030505080247.GA23214@Wotan.suse.de>
On Mon, May 05, 2003 at 02:46:36PM +0800, Andrew Derrick Balsa wrote:
> Hi,
>
> I found that the kNox patch provides for i386 in software something very close
> to NX mechanism in x86_64 hardware.
> http://www.isec.pl/projects/knox/knox.html
> The kNox patch includes a demo.c program that effectively tests the no-exec
> mechanism. I don?t have access to real x86_64 hardware, but I would be
> curious to know the results of this test program on a recent x86_64 kernel
> booted with noexec=on option.
> Thanks,
With the latest kernel (which has a few bugfixes) it gives:
esting exec on RW- stack GOOD page fault
Testing exec on RW- BSS GOOD page fault
Testing exec on RW- heap GOOD page fault
Testing exec on R-X page GOOD shellcode executed
Testing exec on R-- page GOOD page fault
Testing exec on RWX page WRONG shellcode executed
Testing read on --X page WRONG read from page
Testing trampoline call on RW- stack WRONG page fault
Looks all correct to me.
-Andi
From peter at jazz-1.trumpet.com.au Mon May 5 10:33:54 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Mon, 5 May 2003 18:33:54 +1000 (EST)
Subject: DPMI on AMD64
Message-ID:
I am investigating whether it might be possible to run DPMI applications on a
64 bit system.
It's technically possible to run 16 bit selectors while in long mode, but we
all know that V86 is not available.
Most DPMI apps actually start in real mode (or v86 mode) and then enter
protected mode by first querying the entry point and then calling it. Because
of this, DPMI apps which could potentially run would have to be emulated until
the relevant call to enter DPMI mode.
If there was another way to enter DPMI mode, it would save having to fire up an
emulator. Of course there would need to be a few assumptions made about the
purity of the code - it would have to be entirely protected mode code.
The only other alternative would be to use NE files which are assumed to be
pure DPMI, however there are many more assumptions made about such files and
the libraries needed to support them.
Has any thought been given to this?
Regards
Peter
P.S. no inane answers like "we don't care, we only run Linux here", I presume
this list is not restricted to Linux stuff.
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From hpa at zytor.com Mon May 5 10:47:58 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 5 May 2003 01:47:58 -0700
Subject: [discuss] What is the status of NX bit in latest x86_64 2.4.21-rc1 kernel?
References: <200305050326.47557.andrebalsa@mailingaddress.org> <20030505030709.GC21955@Wotan.suse.de> <200305051155.28514.andrebalsa@mailingaddress.org> <20030505041306.GB27021@Wotan.suse.de>
Message-ID:
Followup to: <20030505041306.GB27021 at Wotan.suse.de>
By author: Andi Kleen
In newsgroup: linux.ports.x86-64.discuss
>
> exec shield does more too. it introduces the concept of an "ascii shield"
> But on 64bit little endian you have the ASCII shield by default because
> each address ends with two 0 bytes (48 byte address room), which are first
> in memory. This cannot be created by a 0 terminated string.
>
Last in memory. Littleendian.
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From antoine64leca at hotmail.com Mon May 5 16:50:35 2003
From: antoine64leca at hotmail.com (Antoine Leca)
Date: Mon, 5 May 2003 16:50:35 +0200
Subject: [discuss] DPMI on AMD64
References:
Message-ID:
Peter Tattam wrote:
> I am investigating whether it might be possible to run DPMI applications
on a
> 64 bit system.
>
> Most DPMI apps actually start in real mode (or v86 mode) and then enter
> protected mode by first querying the entry point and then calling it.
In fact, all do that (that is the way DPMI works). The only shortcut might
be to
"exec" another DPMI app directly from a DPMI app. But in any case such a
function will not be provided by DPMI itself, but rather by the environment
that
runs over DPMI (usually a DOS extender).
However, a number of "DPMI app" are in fact built as 2 things: an app
(shipped
as NE .EXE or similar if 16-bit, and a wide variety if 32-bit), and a DOS
extender,
which may reside in a separate file (the runtime) or inside, perhaps as the
DOS MZ
bootstrap in the .EXE (as it works in DJGPP). If the app does not intend
"dirty"
things (in which case I believe there are not much things that may be done),
then
all the code that have to run in real/V86 mode, including the code that
execute
initially and switch to PM, will be in the DOS extender part, not in the
app.
The app is usually pure PM code.
> Because
> of this, DPMI apps which could potentially run would have to be emulated
until
> the relevant call to enter DPMI mode.
Furthermore, there is quite some code inside the extender that may have to
be
emulated, too... The bad thing is that for most app, the time spent in
real/V86
mode (including the time used for switching) is already a noticeable part of
the
total time, so if this get emulated (or virtualized), performance will
become... ugly.
> If there was another way to enter DPMI mode, it would save having to fire
up an
> emulator.
A solution may be to write "extender replacements", for example for the most
common runtime used (in 16-bit, Rationale/Tenberry DOS16M, PharLap 286DOS
and Borland RTM.EXE fill probably cover a very large part of the
spectrum...)
By the way, such a solution is not limited to AMD64: it can be easily, and
effectively,
used on "normal" IA32 architecture. The fact is that AMD64 *needs* this,
while
IA32 can do with the current vm86() hacks (like used in dosemu), so this way
had
not been researched so far (or perhaps this is too complex to be done ;^))
> The only other alternative would be to use NE files which are assumed to
be
> pure DPMI, however there are many more assumptions made about such files
and
> the libraries needed to support them.
Antoine
From mharris at www.linux.org.uk Mon May 5 20:27:25 2003
From: mharris at www.linux.org.uk (Mike A. Harris)
Date: Mon, 5 May 2003 14:27:25 -0400 (EDT)
Subject: [discuss] DPMI on AMD64
In-Reply-To:
Message-ID:
On Mon, 5 May 2003, Peter Tattam wrote:
>I am investigating whether it might be possible to run DPMI
>applications on a 64 bit system.
>
>It's technically possible to run 16 bit selectors while in long
>mode, but we all know that V86 is not available.
>
>Most DPMI apps actually start in real mode (or v86 mode) and
>then enter protected mode by first querying the entry point and
>then calling it. Because of this, DPMI apps which could
>potentially run would have to be emulated until the relevant
>call to enter DPMI mode.
>
>If there was another way to enter DPMI mode, it would save
>having to fire up an emulator. Of course there would need to be
>a few assumptions made about the purity of the code - it would
>have to be entirely protected mode code.
>
>The only other alternative would be to use NE files which are
>assumed to be pure DPMI, however there are many more assumptions
>made about such files and the libraries needed to support them.
I believe the only way to do this is to emulate, as there is
purposefully no /defined/ way to switch back and forth between
long mode and legacy mode.
--
Mike A. Harris
From parag at codegen.com Mon May 5 20:39:58 2003
From: parag at codegen.com (Parag Patel)
Date: Mon, 05 May 2003 11:39:58 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To: Message from "Mike A. Harris"
of "Mon, 05 May 2003 14:27:25 EDT."
Message-ID: <53542.1052159998@tenor.codegen.com>
>I believe the only way to do this is to emulate, as there is
>purposefully no /defined/ way to switch back and forth between
>long mode and legacy mode.
AMD x86-64 Architecture Vol 2 "Programmer's Manual" Pages 425-426
Section 14.7 "Leaving Long Mode". This describes how to return to
legacy protected mode from long mode which can be done with paging
enabled or disabled.
--
__
/__)_ _ _ _ Next to being shot at and missed, nothing is really quite
/ (// (/(/ as satisfying as an income tax refund. -- F. J. Raymond
_/
From mharris at www.linux.org.uk Mon May 5 20:54:35 2003
From: mharris at www.linux.org.uk (Mike A. Harris)
Date: Mon, 5 May 2003 14:54:35 -0400 (EDT)
Subject: [discuss] DPMI on AMD64
In-Reply-To: <53542.1052159998@tenor.codegen.com>
Message-ID:
On Mon, 5 May 2003, Parag Patel wrote:
>>I believe the only way to do this is to emulate, as there is
>>purposefully no /defined/ way to switch back and forth between
>>long mode and legacy mode.
>
>AMD x86-64 Architecture Vol 2 "Programmer's Manual" Pages 425-426
>Section 14.7 "Leaving Long Mode". This describes how to return to
>legacy protected mode from long mode which can be done with paging
>enabled or disabled.
And if you check this mailing list's archives, you will find that
AMD has categorically stated very clearly, that that is not a
supported thing and should not be relied upon by any software
whatsoever. It was also commented that future editions of the
manuals would have that section of the manual clarified so that
people aren't misled to believe that switching out of long mode
is something supported.
--
Mike A. Harris
From alangrimes at starpower.net Tue May 6 00:28:57 2003
From: alangrimes at starpower.net (Alan Grimes)
Date: Mon, 05 May 2003 15:28:57 -0700
Subject: [discuss] DPMI on AMD64
References:
Message-ID: <3EB6E5A9.581201BB@starpower.net>
As a long time and continuing! DOS user, I have quite a bit of insight
into how varrious applications use DPMI. I mentioned some of this in a
private response on a previous thread.
In my collection of mostly games there are roughly two "Regular" DOS
extenders and some number of "irregular" dos extenders which are rarely
used...
The most common extender is DOS4GW which was used with the Watcom C
compiler. There are at least two variants of this extender.
This extender is used with:
Duke Nukem 3D, Doom 1,2, Heritec, Hexen, Descent, The 11th Hour,
Warcraft II, Startrek TNG: A Final Unity, Lords of the Realm II, Mech
Warrior II, and Full Throttle -- And those are just the ones in my
collection... ;)
Chronomaster also uses a very old version of this extender but its
loading sequence is different making the stub very difficult to
replace...
1. The staticly linked variant which consists of a 200k "stub" which is
affixed to a .LE executable.
2. A dynamicly linked variant which consists of a 10k stub which looks
for an external file called "DOS4GW.EXE". This variant is also prepended
to a .LE executable.
The PMODE/W clone (I can give you a copy if you need it..) comes with a
utility which can strip either stub off of the executable...
Once the executable is stripped it can be loaded with:
dos4gw war2.le
A very good free clone is http://dos32a.sourceforge.net/ , which is 90%
compatible with DOS4GW...
The obvious approach for emulating these files is to write an int21h
handler and then write a custom loader to process stripped
executables...
The second "Regular" DOS extender is the one supplied with DJGPP. This
extender is used with QUAKE and some of the new free versions of Doom
such as Doom Legacy.
The presence of this extender is usually indicated by the presence of a
file CWSDPMI.exe. Programs that use this extender consist of a 16-bit
stub which detects the presence of a DPMI host. If detection fails, it
searches for a file called "CWSDPMI.EXE".
I do not know wheather this stub can be "de-linked" as the watcom stub
can be.
It would probably be easier to port and recompile the application rather
than attempt to re-link it....
Finally, there is an unknown number of "irregular" extenders.
These are OOOOOLLLD extenders such as DesQviewX which uses a variant of
DOS4/GW called DOS4/G. (or something similar...) A number of games such
as The 7th Guest use some kind of extender which is completely different
from the modern ones...
Ofcourse Windows 3.11 is a special case, it uses the VCPI interface and
it is WIERD !!!
I hope this inf0z is of some use to people...
--
Having never read a manual, it takes less effort to hack something
togeather with www.squeak.org than it does with C++ and five books.
http://users.rcn.com/alangrimes/
From parag at codegen.com Mon May 5 21:58:02 2003
From: parag at codegen.com (Parag Patel)
Date: Mon, 05 May 2003 12:58:02 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To: Message from "Mike A. Harris"
of "Mon, 05 May 2003 14:54:35 EDT."
Message-ID: <54207.1052164682@tenor.codegen.com>
>It was also commented that future editions of the
>manuals would have that section of the manual clarified so that
>people aren't misled to believe that switching out of long mode
>is something supported.
Hm - I'd heard this was changed recently, or that they just don't want
to deal with the support issues, but I could well be wrong. In any case
it does work at the moment. For the future, just get a dual-processor
board, run one CPU in 32-bit legacy mode and the other in 64-bit long! :)
--
__
/__)_ _ _ _ "The four building blocks of the universe are fire, water,
/ (// (/(/ gravel and vinyl." -- Dave Barry
_/
From hpa at zytor.com Mon May 5 23:28:43 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 5 May 2003 14:28:43 -0700
Subject: [discuss] DPMI on AMD64
References: <53542.1052159998@tenor.codegen.com>
Message-ID:
Followup to:
By author: "Mike A. Harris"
In newsgroup: linux.ports.x86-64.discuss
>
> And if you check this mailing list's archives, you will find that
> AMD has categorically stated very clearly, that that is not a
> supported thing and should not be relied upon by any software
> whatsoever. It was also commented that future editions of the
> manuals would have that section of the manual clarified so that
> people aren't misled to believe that switching out of long mode
> is something supported.
>
And if you checked the list archives further, you will find that
statement explicitly retracted in favour of "we recommend people don't
do this because it's tricky and the programmer can make mistakes."
Which is true, but it's not really any more tricky than the 32-bit
protected mode real mode transition, which is also complicated as
hell.
http://www.x86-64.org/lists/discuss/msg03333.html
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From mharris at www.linux.org.uk Tue May 6 00:10:57 2003
From: mharris at www.linux.org.uk (Mike A. Harris)
Date: Mon, 5 May 2003 18:10:57 -0400 (EDT)
Subject: [discuss] DPMI on AMD64
In-Reply-To: <54207.1052164682@tenor.codegen.com>
Message-ID:
On Mon, 5 May 2003, Parag Patel wrote:
>>It was also commented that future editions of the
>>manuals would have that section of the manual clarified so that
>>people aren't misled to believe that switching out of long mode
>>is something supported.
>
>Hm - I'd heard this was changed recently, or that they just don't want
>to deal with the support issues, but I could well be wrong. In any case
>it does work at the moment. For the future, just get a dual-processor
>board, run one CPU in 32-bit legacy mode and the other in 64-bit long! :)
Barring someone directly from AMD posting on this list that it is
going to be officially supported to switch from long mode back to
legacy mode, then as far as I'm concerned, it isn't supported, as
the last official comment about this from AMD on list was quite
clear - at least to me - that this would *NOT* be supported by
AMD and that people should not use it or their software could
very well break due to relying on undefined behaviour.
Can someone from AMD please restate AMD's official position on
switching from long mode back to legacy mode once again to
clarify this issue?
--
Mike A. Harris
From dewar at gnat.com Tue May 6 00:31:43 2003
From: dewar at gnat.com (Robert Dewar)
Date: Mon, 5 May 2003 18:31:43 -0400 (EDT)
Subject: [discuss] DPMI on AMD64
Message-ID: <20030505223143.46C1DF2941@nile.gnat.com>
> Barring someone directly from AMD posting on this list that it is
> going to be officially supported to switch from long mode back to
> legacy mode, then as far as I'm concerned, it isn't supported, as
> the last official comment about this from AMD on list was quite
> clear - at least to me - that this would *NOT* be supported by
> AMD and that people should not use it or their software could
> very well break due to relying on undefined behaviour.
It's amazing to me that AMD would repeat the mistake of the 286 (Intel thought
people would update immediately to virtual mode, who could *possibly* want to
go backwards and forwards?) :-)
From dbehman at ca.ibm.com Tue May 6 01:22:19 2003
From: dbehman at ca.ibm.com (Dan Behman)
Date: Mon, 5 May 2003 19:22:19 -0400
Subject: Floating Point Exception on AMD64
Message-ID:
Hi,
Can anyone explain why I get a SIGFPE when running the following program on
AMD64, where no signal is given on other 64bit platforms?
#include
int main( void )
{
signed long op1, op2, result;
op1 = 0xffffffffffffffff;
op2 = 0x8000000000000000;
result = op1*op2;
printf( "op1 = %lx\n", op1 );
printf( "op2 = %lx\n", op2 );
printf( "result = %lx\n", result );
if ( result/op1 != op2 ) // SIGFPE occurs during division on AMD64
{
printf ("Overflow, result/op1 = %lx\n", result/op1 );
}
else
{
printf ("No overflow, result/op1 = %lx\n", result/op1 );
}
}
----------
Dan Behman
DB2 UDB Development
----------
From ak at suse.de Tue May 6 01:31:14 2003
From: ak at suse.de (Andi Kleen)
Date: Tue, 6 May 2003 01:31:14 +0200
Subject: [discuss] DPMI on AMD64
In-Reply-To: <20030505223143.46C1DF2941@nile.gnat.com>
References: <20030505223143.46C1DF2941@nile.gnat.com>
Message-ID: <20030505233114.GA4979@Wotan.suse.de>
> It's amazing to me that AMD would repeat the mistake of the 286 (Intel thought
> people would update immediately to virtual mode, who could *possibly* want to
> go backwards and forwards?) :-)
The architecture manual says it is supported (volume 2, 14.7, "Leaving Long
Mode") and gives an procedure for it.
But I have no plans to support such a horror show in Linux.
-Andi
From ak at suse.de Tue May 6 01:37:56 2003
From: ak at suse.de (Andi Kleen)
Date: Tue, 6 May 2003 01:37:56 +0200
Subject: [discuss] Floating Point Exception on AMD64
In-Reply-To:
References:
Message-ID: <20030505233756.GB4979@Wotan.suse.de>
On Mon, May 05, 2003 at 07:22:19PM -0400, Dan Behman wrote:
> Hi,
>
> Can anyone explain why I get a SIGFPE when running the following program on
> AMD64, where no signal is given on other 64bit platforms?
x86 IDIV is defined this way. Overflow raises an exception.
x86-64 volume 3 page 139 in the IDIV description
"The instruction truncates non-integral results towards 0. The sign of
the remainder is always the same as the sign of the dividend, and the
absolute value of the remainder is less than the absolute value of the
divisor. An overflow generates a #DE (divide error) exception, rather
than setting the OF flag."
It also gives advice on how to avoid it:
"To avoid overflow problems, precede this instruction with a CBW, CWD,
CDQ, or CQO instruction to sign-extend the dividend."
But it looks like gcc doesn't do that. I don't know if it should.
Overflow for signed quantities is undefined in ISO C so gcc's behaviour
is certainly in the bounds of the spec.
As a workaround you could use inline assembly to add the CDQ or CQO.
-Andi
From peter at jazz-1.trumpet.com.au Tue May 6 01:52:53 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Tue, 6 May 2003 09:52:53 +1000 (EST)
Subject: [discuss] DPMI on AMD64
In-Reply-To: <20030505233114.GA4979@Wotan.suse.de>
Message-ID:
I did not want to reopen the debate on leaving long mode. For those in any
doubt, search the archives of this list for the official statement by AMD on
this particular issue.
Back to the main issue, it would seem that it is possible that some DPMI EXE's
might be supported, presumably those which look to be NE executables linked to
16 bit DLLs and runtimes such RTM.EXE and so forth.
I agree that using the runtimes bound to the EXEs is going to be a large
performance hit.
The only alternative I can see is to have a reduced DPMI support (i.e. no real
mode callbacks) and only support exes that pass a purity test (must be able to
strip runtime support and replace that runtime with a protected mode only
runtime from the host which is either 16 bit or 32 bit). If it doesn't get
that far, the application would have to be emulated - not that impossible if
the run time is smart enough to detect an external DPMI host.
Over time, I guess a compatibility list could be built up, but it would be
rather ad hoc.
The comment about rewriting any 16 bit program is valid for some cases, but
there are likely to be a wealth of DPMI programs out there which would be
impossible to port to a non-DPMI platform. I still think it's worth supporting
these, and I'll eandeavour to work out what could be done as it's likely that
such support will be requested in my own OS.
Peter
On Tue, 6 May 2003, Andi Kleen wrote:
> > It's amazing to me that AMD would repeat the mistake of the 286 (Intel thought
> > people would update immediately to virtual mode, who could *possibly* want to
> > go backwards and forwards?) :-)
>
> The architecture manual says it is supported (volume 2, 14.7, "Leaving Long
> Mode") and gives an procedure for it.
>
> But I have no plans to support such a horror show in Linux.
>
> -Andi
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From peter at jazz-1.trumpet.com.au Tue May 6 02:37:16 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Tue, 6 May 2003 10:37:16 +1000 (EST)
Subject: [discuss] Floating Point Exception on AMD64
In-Reply-To:
Message-ID:
the only problem I see with your program is that the multiply overflows. your
results after that would be undefined.
Peter
On Mon, 5 May 2003, Dan Behman wrote:
> Hi,
>
> Can anyone explain why I get a SIGFPE when running the following program on
> AMD64, where no signal is given on other 64bit platforms?
>
> #include
>
> int main( void )
> {
> signed long op1, op2, result;
>
> op1 = 0xffffffffffffffff;
> op2 = 0x8000000000000000;
>
> result = op1*op2;
>
> printf( "op1 = %lx\n", op1 );
> printf( "op2 = %lx\n", op2 );
> printf( "result = %lx\n", result );
>
> if ( result/op1 != op2 ) // SIGFPE occurs during division on AMD64
> {
> printf ("Overflow, result/op1 = %lx\n", result/op1 );
> }
> else
> {
> printf ("No overflow, result/op1 = %lx\n", result/op1 );
> }
> }
>
> ----------
> Dan Behman
> DB2 UDB Development
> ----------
>
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From hubicka at ucw.cz Tue May 6 11:24:55 2003
From: hubicka at ucw.cz (Jan Hubicka)
Date: Tue, 6 May 2003 11:24:55 +0200
Subject: [discuss] Floating Point Exception on AMD64
In-Reply-To: <20030505233756.GB4979@Wotan.suse.de>
References: <20030505233756.GB4979@Wotan.suse.de>
Message-ID: <20030506092455.GA2619@kam.mff.cuni.cz>
> On Mon, May 05, 2003 at 07:22:19PM -0400, Dan Behman wrote:
> > Hi,
> >
> > Can anyone explain why I get a SIGFPE when running the following program on
> > AMD64, where no signal is given on other 64bit platforms?
>
> x86 IDIV is defined this way. Overflow raises an exception.
>
> x86-64 volume 3 page 139 in the IDIV description
>
> "The instruction truncates non-integral results towards 0. The sign of
> the remainder is always the same as the sign of the dividend, and the
> absolute value of the remainder is less than the absolute value of the
> divisor. An overflow generates a #DE (divide error) exception, rather
> than setting the OF flag."
Yes, in general dividing *_MAX by -1 will give you exception for any
type. In C you won't get it for shorts and chars as these are
implicitly sign extended.
>
> It also gives advice on how to avoid it:
>
> "To avoid overflow problems, precede this instruction with a CBW, CWD,
> CDQ, or CQO instruction to sign-extend the dividend."
>
> But it looks like gcc doesn't do that. I don't know if it should.
> Overflow for signed quantities is undefined in ISO C so gcc's behaviour
> is certainly in the bounds of the spec.
>
> As a workaround you could use inline assembly to add the CDQ or CQO.
GCC should also understand if you simply extend the expression into
128bit integer. Then the overflow won't happen and the sign extension
will be produced automatically. 128bit division is of course more
expensive than 64bit.
Honza
>
> -Andi
From ebiederman at lnxi.com Tue May 6 11:59:58 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: 06 May 2003 03:59:58 -0600
Subject: [discuss] DPMI on AMD64
In-Reply-To:
References:
Message-ID:
Peter Tattam writes:
> I did not want to reopen the debate on leaving long mode. For those in any
> doubt, search the archives of this list for the official statement by AMD on
> this particular issue.
>
> Back to the main issue, it would seem that it is possible that some DPMI EXE's
> might be supported, presumably those which look to be NE executables linked to
> 16 bit DLLs and runtimes such RTM.EXE and so forth.
There are two cases with DPMI .exe's
1) Writing a dos extender.
2) Hosting a dpmi app under another OS.
For a dos extender it can simply not care about the Opteron, and
extending the horror that is DPMI for 64bit is probably not worth it.
For some roll your own dos extender cases you can simplfy the requirements
enough that switch modes is not a big deal. In etherboot the assumptions
are: Performance is secondary, and interrupts only occur in 16bit mode.
Hosting a dmpi app under a 64bit OS is as straight forward as
getting a 16bit emulator running to replace vm86 mode.
> The comment about rewriting any 16 bit program is valid for some cases, but
> there are likely to be a wealth of DPMI programs out there which would be
> impossible to port to a non-DPMI platform. I still think it's worth supporting
> these, and I'll eandeavour to work out what could be done as it's likely that
> such support will be requested in my own OS.
Have fun...
Eric
From peter at jazz-1.trumpet.com.au Tue May 6 13:49:55 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Tue, 6 May 2003 21:49:55 +1000 (EST)
Subject: [discuss] Floating Point Exception on AMD64
In-Reply-To: <20030506092455.GA2619@kam.mff.cuni.cz>
Message-ID:
I have investigated this with bochs (which uncovered a couple of bugs with
IMUL/IDIV :).
The results are that
0x8000000000000000 / 0xffffffffffffffff results in the following division
sign extended with CQO
0xffffffffffffffff8000000000000000 div 0xffffffffffffffff
the quotient ends up being
0x00000000000000008000000000000000
which then should overflow (because bits 64-127 should match the sign bit 64).
it then raises a divide by zero exception.
I hope my analysis is correct.
Peter
On Tue, 6 May 2003, Jan Hubicka wrote:
> > On Mon, May 05, 2003 at 07:22:19PM -0400, Dan Behman wrote:
> > > Hi,
> > >
> > > Can anyone explain why I get a SIGFPE when running the following program on
> > > AMD64, where no signal is given on other 64bit platforms?
> >
> > x86 IDIV is defined this way. Overflow raises an exception.
> >
> > x86-64 volume 3 page 139 in the IDIV description
> >
> > "The instruction truncates non-integral results towards 0. The sign of
> > the remainder is always the same as the sign of the dividend, and the
> > absolute value of the remainder is less than the absolute value of the
> > divisor. An overflow generates a #DE (divide error) exception, rather
> > than setting the OF flag."
>
> Yes, in general dividing *_MAX by -1 will give you exception for any
> type. In C you won't get it for shorts and chars as these are
> implicitly sign extended.
> >
> > It also gives advice on how to avoid it:
> >
> > "To avoid overflow problems, precede this instruction with a CBW, CWD,
> > CDQ, or CQO instruction to sign-extend the dividend."
> >
> > But it looks like gcc doesn't do that. I don't know if it should.
> > Overflow for signed quantities is undefined in ISO C so gcc's behaviour
> > is certainly in the bounds of the spec.
> >
> > As a workaround you could use inline assembly to add the CDQ or CQO.
>
> GCC should also understand if you simply extend the expression into
> 128bit integer. Then the overflow won't happen and the sign extension
> will be produced automatically. 128bit division is of course more
> expensive than 64bit.
>
> Honza
> >
> > -Andi
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From peter at jazz-1.trumpet.com.au Tue May 6 13:57:23 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Tue, 6 May 2003 21:57:23 +1000 (EST)
Subject: [discuss] Floating Point Exception on AMD64
In-Reply-To:
Message-ID:
typo...
On Tue, 6 May 2003, Peter Tattam wrote:
> which then should overflow (because bits 64-127 should match the sign bit 64).
SHOULD READ
which then should overflow (because bits 64-127 should match the sign bit 63).
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From antoine64leca at hotmail.com Tue May 6 14:11:22 2003
From: antoine64leca at hotmail.com (Antoine Leca)
Date: Tue, 6 May 2003 14:11:22 +0200
Subject: [discuss] DPMI on AMD64
References:
Message-ID:
Peter Tattam wrote:
> Back to the main issue, it would seem that it is possible that some DPMI
> EXE's might be supported, presumably those which look to be NE
> executables linked to 16 bit DLLs and runtimes such RTM.EXE and so
> forth.
Speaking about RTM.EXE in particular, I believe this one should be really
doable: The number of used (in BP, BC++, TD, Paradox, any more?) APIs
still to "reverse engineer" is low, less than 10 I believe. Then there are
about
10 API into RTM that are more or less documented (because they are used
in the runtime sources), and about 250 APIs that are "copied" from the
Windows16 API, which are available in "emulation" from the Wine project.
> If it doesn't get that far, the application would have to be emulated -
> not that impossible if the run time is smart enough to detect an external
> DPMI host.
I do not understand fully here. You mean, you are going to run, say, some
DOS4GW-extended app. The protected mode, being the app itself or the
DOS4GW "glue" code (that extends the DOS API to 32-bit) will run
"normal", in compatibility mode. Then, when the extender will call some
callbacks (be it inside itself, or in DOS memory "below it" in memory,
right?), then this code will have to be emulated. Do I get it right?
Part of this emulated code, in fact the DOS part, will probably be handled
by a back call toward the 64-bit OS (much like works Windows). So
more or less the part to be emulated is the code of the real/V86 mode
callbacks that is inside the extender, correct?
> The comment about rewriting any 16 bit program is valid for some
> cases, but there are likely to be a wealth of DPMI programs out there
> which would be impossible to port to a non-DPMI platform.
Well, I believe the problem is more that a segmented (protected) runtime,
being 16-bit DPMI or anything else, running on a "flat" modern OS (being
32- or 64-bit), does not seem to exist, at least freely available.
Of course there are WOW (16-bit Windows over Windows) or the
OS/2 personality of NT (now dead), but the source does not seem to
be available!
So either one writes some replacement, or the runtimes will need to be
emulated.
Antoine
From gerryg at ca.ibm.com Tue May 6 14:21:29 2003
From: gerryg at ca.ibm.com (Gerry Greenwood)
Date: Tue, 6 May 2003 08:21:29 -0400
Subject: [discuss] Floating Point Exception on AMD64
Message-ID:
That is exactly the case that we are checking. We are checking here to see
if we did overflow on the multiplication. The value that is in result
after the multiplication is valid, albeit incorrect. Our example has
been shortened to make it as simple as possible.
Essentially what we really do is the multiplication and then check the
result.
>From talking to a few of our compiler folks we should never get an FPE when
doing integer division, since we are not using reals or floats. After this
in our code we check for the boundary conditions, one way to alleviate the
problem would be to flip the condition, but then we would be comparing the
values everytime and not hitting this condition very often(more expensive)
Thanks,
Gerry
Gerry Greenwood, gerryg at ca.ibm.com
Manager, DB2 Unix Platform Development Group
8200 Warden Ave., Markham, Ontario
3C/843/8200/MKM, (905) 413-3466
Dan Behman
To: Yvonne Chan/Toronto/IBM at IBMCA, Gerry Greenwood/Toronto/IBM at IBMCA
05/05/2003 08:46 cc:
PM From: Dan Behman/Toronto/IBM at IBMCA
Subject: Re: [discuss] Floating Point Exception on AMD64
----------
Dan Behman
DB2 UDB Unix Development
IBM Software Development Lab, Office C4-432
Phone: (905) 413-4416 Email: dbehman at ca.ibm.com
Please send all DB2 Unix questions to our 'askDB2UnixDev' mailing list.
----------
----- Forwarded by Dan Behman/Toronto/IBM on 05/05/2003 08:46 PM -----
Peter Tattam
cc: discuss at x86-64.org
Subject: Re: [discuss] Floating Point Exception on AMD64
05/05/2003 08:37
PM
the only problem I see with your program is that the multiply overflows.
your
results after that would be undefined.
Peter
On Mon, 5 May 2003, Dan Behman wrote:
> Hi,
>
> Can anyone explain why I get a SIGFPE when running the following program
on
> AMD64, where no signal is given on other 64bit platforms?
>
> #include
>
> int main( void )
> {
> signed long op1, op2, result;
>
> op1 = 0xffffffffffffffff;
> op2 = 0x8000000000000000;
>
> result = op1*op2;
>
> printf( "op1 = %lx\n", op1 );
> printf( "op2 = %lx\n", op2 );
> printf( "result = %lx\n", result );
>
> if ( result/op1 != op2 ) // SIGFPE occurs during division on AMD64
> {
> printf ("Overflow, result/op1 = %lx\n", result/op1 );
> }
> else
> {
> printf ("No overflow, result/op1 = %lx\n", result/op1 );
> }
> }
>
> ----------
> Dan Behman
> DB2 UDB Development
> ----------
>
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From peter at jazz-1.trumpet.com.au Tue May 6 14:29:02 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Tue, 6 May 2003 22:29:02 +1000 (EST)
Subject: [discuss] DPMI on AMD64
In-Reply-To:
Message-ID:
On Tue, 6 May 2003, Antoine Leca wrote:
> Peter Tattam wrote:
> > Back to the main issue, it would seem that it is possible that some DPMI
> > EXE's might be supported, presumably those which look to be NE
> > executables linked to 16 bit DLLs and runtimes such RTM.EXE and so
> > forth.
>
> Speaking about RTM.EXE in particular, I believe this one should be really
> doable: The number of used (in BP, BC++, TD, Paradox, any more?) APIs
> still to "reverse engineer" is low, less than 10 I believe. Then there are
> about
> 10 API into RTM that are more or less documented (because they are used
> in the runtime sources), and about 250 APIs that are "copied" from the
> Windows16 API, which are available in "emulation" from the Wine project.
>
>
> > If it doesn't get that far, the application would have to be emulated -
> > not that impossible if the run time is smart enough to detect an external
> > DPMI host.
>
> I do not understand fully here. You mean, you are going to run, say, some
> DOS4GW-extended app. The protected mode, being the app itself or the
> DOS4GW "glue" code (that extends the DOS API to 32-bit) will run
> "normal", in compatibility mode. Then, when the extender will call some
> callbacks (be it inside itself, or in DOS memory "below it" in memory,
> right?), then this code will have to be emulated. Do I get it right?
>
> Part of this emulated code, in fact the DOS part, will probably be handled
> by a back call toward the 64-bit OS (much like works Windows). So
> more or less the part to be emulated is the code of the real/V86 mode
> callbacks that is inside the extender, correct?
>
> > The comment about rewriting any 16 bit program is valid for some
> > cases, but there are likely to be a wealth of DPMI programs out there
> > which would be impossible to port to a non-DPMI platform.
>
> Well, I believe the problem is more that a segmented (protected) runtime,
> being 16-bit DPMI or anything else, running on a "flat" modern OS (being
> 32- or 64-bit), does not seem to exist, at least freely available.
> Of course there are WOW (16-bit Windows over Windows) or the
> OS/2 personality of NT (now dead), but the source does not seem to
> be available!
I have a DPMI emulator running as a 32 bit flat application in my OS, which is
why I'm asking these questions. I can improve this by doing the NE linkage and
supporting the handle full of RTM.EXE/KERNEL.DLL calls. For the 64 bit
version,that would be a useful optimization provided it doesn't do any "dirty"
DPMI stuff like RM callbacks and stuff.
>
> So either one writes some replacement, or the runtimes will need to be
> emulated.
>
>
> Antoine
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From ak at suse.de Tue May 6 14:40:56 2003
From: ak at suse.de (Andi Kleen)
Date: 06 May 2003 14:40:56 +0200
Subject: [discuss] Floating Point Exception on AMD64
In-Reply-To:
References:
Message-ID: <1052224857.1181.46.camel@averell>
On Tue, 2003-05-06 at 14:21, Gerry Greenwood wrote:
> That is exactly the case that we are checking. We are checking here to see
> if we did overflow on the multiplication. The value that is in result
> after the multiplication is valid, albeit incorrect. Our example has
> been shortened to make it as simple as possible.
The cheapest solution is to just use an SIGFPE handler for the overflow
checking and siglongjmp back to the error handler.
Then you don't need to do the check because the hardware did it for you.
> From talking to a few of our compiler folks we should never get an FPE when
> doing integer division, since we are not using reals or floats. After this
On Unix/x86 #DE is mapped to SIGFPE.
And signed overflow is undefined.
-Andi
From gerryg at ca.ibm.com Tue May 6 14:56:47 2003
From: gerryg at ca.ibm.com (Gerry Greenwood)
Date: Tue, 6 May 2003 08:56:47 -0400
Subject: [discuss] Floating Point Exception on AMD64
Message-ID:
Andi,
How is going into a signal handler cheaper?
We already have a signal handler for FPE, but it would not suffice in this
instance. As it is used for other reasons.
Thanks,
Gerry
Gerry Greenwood, gerryg at ca.ibm.com
Manager, DB2 Unix Platform Development Group
8200 Warden Ave., Markham, Ontario
3C/843/8200/MKM, (905) 413-3466
Andi Kleen
To: Gerry Greenwood/Toronto/IBM at IBMCA
cc: Dan Behman/Toronto/IBM at IBMCA, discuss at x86-64.org, Yvonne
06/05/2003 08:40 Chan/Toronto/IBM at IBMCA
AM Subject: Re: [discuss] Floating Point Exception on AMD64
On Tue, 2003-05-06 at 14:21, Gerry Greenwood wrote:
> That is exactly the case that we are checking. We are checking here to
see
> if we did overflow on the multiplication. The value that is in result
> after the multiplication is valid, albeit incorrect. Our example has
> been shortened to make it as simple as possible.
The cheapest solution is to just use an SIGFPE handler for the overflow
checking and siglongjmp back to the error handler.
Then you don't need to do the check because the hardware did it for you.
> From talking to a few of our compiler folks we should never get an FPE
when
> doing integer division, since we are not using reals or floats. After
this
On Unix/x86 #DE is mapped to SIGFPE.
And signed overflow is undefined.
-Andi
From andrebalsa at mailingaddress.org Tue May 6 15:08:16 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Tue, 6 May 2003 21:08:16 +0800
Subject: [discuss] Floating Point Exception on AMD64
Message-ID: <200305062108.16164.andrebalsa@mailingaddress.org>
Hi,
...
> From talking to a few of our compiler folks we should never get an FPE when
> doing integer division, since we are not using reals or floats.
I think the answer is in Andi Kleen?s first reply. The point is that you are
getting a hardware fault # 0 (divide error), which is trapped as standard
POSIX signal SIGFPE by the kernel.
Hardware fault #0 is related to integer division, either a divide by zero or a
divide overflow will generate this fault. This is in the AMD64 manual Vol.2,
page 248.
Unfortunately, AFAIK there is no other way for the Linux kernel to tell your
program that an integer division error occured, so SIGFPE is used, as defined
in the x86-64 ABI. Perhaps POSIX should be revised to include a SIGIDIV
signal. ;)
Anyways, you just stumbled on an oddity from the 386 era, carried on to the
x86-64. Congratulations!
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From ak at suse.de Tue May 6 15:22:06 2003
From: ak at suse.de (Andi Kleen)
Date: 06 May 2003 15:22:06 +0200
Subject: [discuss] Floating Point Exception on AMD64
In-Reply-To:
References:
Message-ID: <1052227327.1189.52.camel@averell>
On Tue, 2003-05-06 at 14:56, Gerry Greenwood wrote:
> How is going into a signal handler cheaper?
Never mind :-)
I was thinking:
It's not cheaper for the overflow case, but cheaper for the likely more
common non overflowing path.
But when you don't check for overflow using division you will never get
the SIGFPE in the first place because the multiplication won't raise the
#DE. It will only set the OF bit, but that can be only tested for using
inline assembly (this would be the most efficient option)
But you can still do the siglongjmp back to do the division safely at
least. But longjmp already has some performance cost, if it's
performance critical better go the inline assembly route.
> We already have a signal handler for FPE, but it would not suffice in this
> instance. As it is used for other reasons.
Either check a global variable that is only set during the possibly
overflowing or the RIP range or the function from the signal frame.
-Andi
From antoine64leca at hotmail.com Tue May 6 15:22:20 2003
From: antoine64leca at hotmail.com (Antoine Leca)
Date: Tue, 6 May 2003 15:22:20 +0200
Subject: [discuss] Floating Point Exception on AMD64
References: <20030505233756.GB4979@Wotan.suse.de>
Message-ID:
Andi Kleen wrote:
> > Can anyone explain why I get a SIGFPE when running the following program
on
> > AMD64, where no signal is given on other 64bit platforms?
[stripped down version]
signed long op1, op2, result;
op1 = -1;
op2 = LONG_MIN;
result = LONG_MIN;
if ( result/op1 != op2 ) // SIGFPE occurs during division on AMD64
C99 says that "If the quotient a/b is representable, the expression
(a/b)*b + a%b shall equal a". But obviously here, the quotient
(- LONG_MIN, or LONG_MAX+1) is not representable.
So this is "acceptable".
What puzzles me is that IA64 does grok it without problem; furthermore
since I remember that Intel's did get it wrong on first try with the 8086,
and they modified it after, and very throughly documented this as a
"variation between processor generation". Probably the thing comes
from HP...
> x86 IDIV is defined this way. Overflow raises an exception.
> x86-64 volume 3 page 139 in the IDIV description
> An overflow generates a #DE (divide error) exception, rather
> than setting the OF flag."
>
> It also gives advice on how to avoid it:
>
> "To avoid overflow problems, precede this instruction with a CBW, CWD,
> CDQ, or CQO instruction to sign-extend the dividend."
This is incorrect. In this case, this does not help. The case when the
quotient is 0x80...0, so raises overflow, is well know for years, and
you can't avoid it using c?td.
In fact, you can't usefully use the IDIV operation if you do not use
the c?td operation before (or you fetch a double-sized dividend, but
can't occur in C, unless optimizing): IDIV will need the msb of %?dx
to know if the dividend is positive or negative...
> But it looks like gcc doesn't do that.
Huh? Fact is it does not use c?td (rather mov and sar).
But it certainly have to do it.
Antoine
From ak at suse.de Tue May 6 15:26:10 2003
From: ak at suse.de (Andi Kleen)
Date: 06 May 2003 15:26:10 +0200
Subject: [discuss] Floating Point Exception on AMD64
In-Reply-To: <200305062108.16164.andrebalsa@mailingaddress.org>
References: <200305062108.16164.andrebalsa@mailingaddress.org>
Message-ID: <1052227571.1181.57.camel@averell>
On Tue, 2003-05-06 at 15:08, Andrew Derrick Balsa wrote:
> Unfortunately, AFAIK there is no other way for the Linux kernel to tell your
> program that an integer division error occured, so SIGFPE is used, as defined
> in the x86-64 ABI. Perhaps POSIX should be revised to include a SIGIDIV
> signal. ;)
POSIX supplies the required information to distingush the cases in the
siginfo_t si_code. FPE_INTDIV vs other FPE_*
-Andi
From antoine64leca at hotmail.com Tue May 6 15:40:29 2003
From: antoine64leca at hotmail.com (Antoine Leca)
Date: Tue, 6 May 2003 15:40:29 +0200
Subject: [discuss] Floating Point Exception on AMD64
References:
Message-ID:
Gerry Greenwood wrote:
> From talking to a few of our compiler folks we should never get an FPE
when
> doing integer division
Sorry for a question from a veteran x86: the "other" machines did not raise
SIGFPE
when attempting a integer division by 0?
Not that I expect this to be sensible: it always puzzled me that Unix
(because this
traces back to V7, you know;-) probably because on the PDP they used the
numeric
unit to do divisions ;^> ) raises a "floating-point" signal for an integer
operation.
Antoine
From antoine64leca at hotmail.com Tue May 6 15:45:19 2003
From: antoine64leca at hotmail.com (Antoine Leca)
Date: Tue, 6 May 2003 15:45:19 +0200
Subject: [discuss] Floating Point Exception on AMD64
References: <200305062108.16164.andrebalsa@mailingaddress.org>
Message-ID:
Andrew Derrick Balsa wrote:
> Unfortunately, AFAIK there is no other way for the Linux kernel to tell
your
> program that an integer division error occured, so SIGFPE is used, as
defined
> in the x86-64 ABI. Perhaps POSIX should be revised to include a SIGIDIV
> signal. ;)
It already exists. It is named FPE_INTDIV. Check POSIX 2001 (SUSv3) on
unix.org.
Note that I think this is not mandated in all POSIX (rather for XPG6
conformance).
But this should not matter.
Antoine
From andrebalsa at mailingaddress.org Tue May 6 15:53:21 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Tue, 6 May 2003 21:53:21 +0800
Subject: [discuss] Floating Point Exception on AMD64
In-Reply-To: <1052227571.1181.57.camel@averell>
References: <200305062108.16164.andrebalsa@mailingaddress.org> <1052227571.1181.57.camel@averell>
Message-ID: <200305062153.21884.andrebalsa@mailingaddress.org>
On Tuesday 06 May 2003 21:26, Andi Kleen wrote:
...
> POSIX supplies the required information to distingush the cases in the
> siginfo_t si_code. FPE_INTDIV vs other FPE_*
Which is a nice oxymoron if I ever saw one. :)
But anyways, I guess that just about solves the issue, since the program in
question already has a signal handler: just check the siginfo code and handle
accordingly.
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From hpa at zytor.com Tue May 6 19:32:03 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 6 May 2003 10:32:03 -0700
Subject: [discuss] Floating Point Exception on AMD64
References:
Message-ID:
Followup to:
By author: "Antoine Leca"
In newsgroup: linux.ports.x86-64.discuss
>
> Gerry Greenwood wrote:
>
> > From talking to a few of our compiler folks we should never get an
> > FPE when doing integer division
>
> Sorry for a question from a veteran x86: the "other" machines did not raise
> SIGFPE when attempting a integer division by 0?
>
> Not that I expect this to be sensible: it always puzzled me that Unix
> (because this traces back to V7, you know;-) probably because on the PDP they used the
> numeric unit to do divisions ;^> ) raises a "floating-point" signal for an integer
> operation.
>
Nevertheless, it's the way things are. Quite a few architectures
(Alpha, ARM, SPARC...) actually have to explicitly raise the SIGFPE
since they do the division in software.
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From hpa at zytor.com Tue May 6 19:34:10 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 6 May 2003 10:34:10 -0700
Subject: [discuss] DPMI on AMD64
References: <54207.1052164682@tenor.codegen.com>
Message-ID:
Followup to:
By author: "Mike A. Harris"
In newsgroup: linux.ports.x86-64.discuss
>
> Barring someone directly from AMD posting on this list that it is
> going to be officially supported to switch from long mode back to
> legacy mode, then as far as I'm concerned, it isn't supported, as
> the last official comment about this from AMD on list was quite
> clear - at least to me - that this would *NOT* be supported by
> AMD and that people should not use it or their software could
> very well break due to relying on undefined behaviour.
>
You apparently missed exactly this thing actually happen.
> Can someone from AMD please restate AMD's official position on
> switching from long mode back to legacy mode once again to
> clarify this issue?
http://www.x86-64.org/lists/discuss/msg03333.html
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From mharris at www.linux.org.uk Wed May 7 03:48:37 2003
From: mharris at www.linux.org.uk (Mike A. Harris)
Date: Tue, 6 May 2003 21:48:37 -0400 (EDT)
Subject: [discuss] DPMI on AMD64
In-Reply-To:
Message-ID:
On 6 May 2003, H. Peter Anvin wrote:
>> Barring someone directly from AMD posting on this list that it is
>> going to be officially supported to switch from long mode back to
>> legacy mode, then as far as I'm concerned, it isn't supported, as
>> the last official comment about this from AMD on list was quite
>> clear - at least to me - that this would *NOT* be supported by
>> AMD and that people should not use it or their software could
>> very well break due to relying on undefined behaviour.
>>
>
>You apparently missed exactly this thing actually happen.
>
>> Can someone from AMD please restate AMD's official position on
>> switching from long mode back to legacy mode once again to
>> clarify this issue?
>
>http://www.x86-64.org/lists/discuss/msg03333.html
Thanks for the updated info hpa. Indeed I did not see that
posting from AMD. I did see all of the postings prior to that
where they claimed it was unsupported and not to rely on it.
Seems like just simple mixup.
Thanks for clarifying.
--
Mike A. Harris
From andrebalsa at mailingaddress.org Wed May 7 05:05:40 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Wed, 7 May 2003 11:05:40 +0800
Subject: Basic =?iso-8859-1?q?=A8HOWTO=20upgrade=20your=20Linux=20box=20to=2064?=
=?iso-8859-1?q?=20bits=A8=20?=
In-Reply-To: <1052227571.1181.57.camel@averell>
References: <200305062108.16164.andrebalsa@mailingaddress.org> <1052227571.1181.57.camel@averell>
Message-ID: <200305071105.41180.andrebalsa@mailingaddress.org>
Hi,
Just a simple, basic introduction to AMD64 Linux computing for the vast
majority (> 99%?) of Linux users who are still on x86 32-bit PC hardware:
http://www.tinyminds.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=62&page=1
I am thinking of expanding this document to a full fledged LDP HOWTO, but it?s
still a little early since AMD64 mainboards and servers are difficult to come
by these days...
(positive) comments welcome, flames > /dev/null as usual... ;)
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From pooh at msu.ru Wed May 7 13:33:38 2003
From: pooh at msu.ru (Andrey Slepuhin)
Date: Wed, 7 May 2003 15:33:38 +0400
Subject: Opteron and SCI performance problems
Message-ID: <20030507113338.GB25141@glade.nmd.msu.ru>
Hi,
We are trying to setup SCI connection between two Opteron boxes based on
Tyan S2880 motherboard. Unfortunately current point-to-point performance
is bounded by ~200MBytes/sec, while two Athlon-based boxes give
~285MBytes/sec. The same performance problems were observed with Newisys
boxes. BIOS HT settings are high enough to provide necessary bandwith.
We try to plug SCI cards to both PCI bridges - the same effect.
So we have two questions:
1) Are there any ideas what can be done to tune our boxes to improve
performance?
2) Does anybody else have experience with SCI or other high-performance
interconnect, e.g. Myrinet? What maximum performance numbers were obtained?
Best regards,
Andrey.
--
A right thing should be simple (tm)
From navin at students.iiit.net Wed May 7 14:54:12 2003
From: navin at students.iiit.net (navin)
Date: Wed, 7 May 2003 18:24:12 +0530 (IST)
Subject: Testing executables
Message-ID:
Hi,
I am doing a project on compilers. I need to create 64 bit
executables. I have created the a simple executable but can't test whether
it is the right output or not since i don't have the hardware.
1)
If anyone can tell me whether the exectuable runs and give me the output i
can assume that what i am doing is right.
2)
Also i wanted to use bochs .Can anyone tell me where can i find a simple
bochsrc or can any give me their minimal bochsrc.
Simnow is giving me errors like saying kdecore1.0 and qt1.0 when i give
--nodeps it just crashes.
3)
Any help on how to execute those things on my pentium III ?
Navin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.aout
Type: application/octet-stream
Size: 13294 bytes
Desc:
Url : http://www.x86-64.org/pipermail/discuss/attachments/20030507/44572132/attachment.obj
From andrebalsa at mailingaddress.org Wed May 7 15:25:52 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Wed, 7 May 2003 21:25:52 +0800
Subject: Opteron and SCI performance problems
Message-ID: <200305072125.52463.andrebalsa@mailingaddress.org>
Hi,
I am not aware of any production Opteron cluster with SCI interconnect; but
here are three links that you may or may not have checked already, where you
can find people with some experience with SCI:
http://www.bode.cs.tum.edu/Par/arch/smile/
http://www.dolphinics.com/products/benchmarks.html
http://hsi.web.cern.ch/HSI/sci/sci.html (partly disabled links, but check
anyways)
http://gears.aset.psu.edu/hpc/systems/lionxe/ (pentium III cluster with SCI)
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From andrebalsa at mailingaddress.org Wed May 7 15:45:18 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Wed, 7 May 2003 21:45:18 +0800
Subject: Testing executables
Message-ID: <200305072145.18852.andrebalsa@mailingaddress.org>
Hi,
1) Download bochs 2.0.2 source and x86-64 recent patches.
2) Compile it on your machine with the x86-64 option enabled.
3) Build a cross-toolchain for x86-64 target.
4) Cross-compile a recent kernel for x86-64 target (also apply most recent
patches).
5) Setup an empty partition image following the bochs documentation.
6) Install your x86-64 kernel in the new partition image.
7) Setup a minimal filesystem and populate with x86-64 binaries (e.g. use LFS
as a base).
8) Install gdb for x86_64-unknown-linux target.
9) Connect gdb on your Pentium III to your emulated system running inside
bochs.
10) Debug your executables.
G?luck,
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From arnd at arndb.de Wed May 7 15:46:40 2003
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 7 May 2003 15:46:40 +0200
Subject: [discuss] Testing executables
In-Reply-To:
References:
Message-ID: <200305071546.40118.arnd@arndb.de>
On Wednesday 07 May 2003 14:54, navin wrote:
> 2)
> Also i wanted to use bochs .Can anyone tell me where can i find a simple
> bochsrc or can any give me their minimal bochsrc.
> Simnow is giving me errors like saying kdecore1.0 and qt1.0 when i give
> --nodeps it just crashes.
Forget simnow, it's practically unusable anyway. If you want to run bochs,
you can use the bochs 2.0.2+20020419 packages in Debian (unstable).
I have a glibc binary package on http://www.arndb.de/debian/ that you
can install on a regular i386 debian testing or unstable system and that
will allow you to run both i386 binaries as well as amd64 binaries
when running in bochs.
Arnd <><
From ak at suse.de Wed May 7 16:21:24 2003
From: ak at suse.de (Andi Kleen)
Date: Wed, 7 May 2003 16:21:24 +0200
Subject: more NX options for x86-64
Message-ID: <20030507142124.GA26631@Wotan.suse.de>
This patch adds more non executable options for 32bit and 64bit executables
on x86-64. Also it ad
The default for 64bit is slightly changed now: previously the default was
to ignore PROT_EXEC completely (noexec=off), now all the mappings honor
PROT_EXEC, but everything default to being executable.
It also adds support for the ELF header flags supported by exec shield
and SolarDesigner's old patch.
Kernel options now for 64bit:
/* noexec=on|off
on Enable
off Disable
noforce (default) Don't enable by default for heap/stack/data,
but allow PROT_EXEC to be effective
*/
and for 32bit processes
/* noexec32=opt{,opt}
Control the no exec default for 32bit processes. Can be also overwritten
per executable using ELF header flags (e.g. needed for the X server)
Requires noexec=on or noexec=noforce to be effective.
Valid options:
all,on Heap,stack,data is non executable.
off (default) Heap,stack,data is executable
stack Stack is non executable, heap/data is.
force Don't imply PROT_EXEC for PROT_READ
compat (default) Imply PROT_EXEC for PROT_READ
*/
Patch against x86-64.org CVS
I'm not sure yet if I will integrate it into CVS, because it requires
some generic changes and overall is probably more hype than real feature.
Provided here in case someone wants to play with this.
-Andi
Index: arch/mips64/kernel/linux32.c
===================================================================
RCS file: /home/cvs/Repository/linux/arch/mips64/kernel/linux32.c,v
retrieving revision 1.8
diff -u -u -r1.8 linux32.c
--- arch/mips64/kernel/linux32.c 2002/11/30 04:20:57 1.8
+++ arch/mips64/kernel/linux32.c 2003/05/07 15:18:10
@@ -347,6 +347,7 @@
bprm.sh_bang = 0;
bprm.loader = 0;
bprm.exec = 0;
+ bprm.flags = 0;
if ((bprm.argc = count32(argv, bprm.p / sizeof(u32))) < 0) {
dput(dentry);
return bprm.argc;
Index: arch/parisc/kernel/sys_parisc32.c
===================================================================
RCS file: /home/cvs/Repository/linux/arch/parisc/kernel/sys_parisc32.c,v
retrieving revision 1.2
diff -u -u -r1.2 sys_parisc32.c
--- arch/parisc/kernel/sys_parisc32.c 2003/03/12 06:03:02 1.2
+++ arch/parisc/kernel/sys_parisc32.c 2003/05/07 15:18:10
@@ -194,6 +194,7 @@
bprm.sh_bang = 0;
bprm.loader = 0;
bprm.exec = 0;
+ bprm.flags = 0;
if ((bprm.argc = count32(argv, bprm.p / sizeof(u32))) < 0) {
allow_write_access(file);
fput(file);
Index: arch/ppc64/kernel/sys_ppc32.c
===================================================================
RCS file: /home/cvs/Repository/linux/arch/ppc64/kernel/sys_ppc32.c,v
retrieving revision 1.3
diff -u -u -r1.3 sys_ppc32.c
--- arch/ppc64/kernel/sys_ppc32.c 2003/02/11 07:58:26 1.3
+++ arch/ppc64/kernel/sys_ppc32.c 2003/05/07 15:18:11
@@ -3882,6 +3882,7 @@
bprm.sh_bang = 0;
bprm.loader = 0;
bprm.exec = 0;
+ bprm.flags = 0;
if ((bprm.argc = count32(argv, bprm.p / sizeof(u32))) < 0) {
allow_write_access(file);
fput(file);
Index: arch/s390x/kernel/linux32.c
===================================================================
RCS file: /home/cvs/Repository/linux/arch/s390x/kernel/linux32.c,v
retrieving revision 1.8
diff -u -u -r1.8 linux32.c
--- arch/s390x/kernel/linux32.c 2002/03/21 11:54:18 1.8
+++ arch/s390x/kernel/linux32.c 2003/05/07 15:18:13
@@ -2937,6 +2937,7 @@
bprm.sh_bang = 0;
bprm.loader = 0;
bprm.exec = 0;
+ bprm.flags = 0;
if ((bprm.argc = count32(argv)) < 0) {
allow_write_access(file);
fput(file);
Index: arch/sparc64/kernel/sys_sparc32.c
===================================================================
RCS file: /home/cvs/Repository/linux/arch/sparc64/kernel/sys_sparc32.c,v
retrieving revision 1.10
diff -u -u -r1.10 sys_sparc32.c
--- arch/sparc64/kernel/sys_sparc32.c 2003/02/11 07:58:27 1.10
+++ arch/sparc64/kernel/sys_sparc32.c 2003/05/07 15:18:15
@@ -3218,6 +3218,7 @@
bprm.sh_bang = 0;
bprm.loader = 0;
bprm.exec = 0;
+ bprm.flags = 0;
if ((bprm.argc = count32(argv, bprm.p / sizeof(u32))) < 0) {
allow_write_access(file);
fput(file);
Index: arch/x86_64/ia32/ia32_binfmt.c
===================================================================
RCS file: /home/cvs/Repository/linux/arch/x86_64/ia32/ia32_binfmt.c,v
retrieving revision 1.24
diff -u -u -r1.24 ia32_binfmt.c
--- arch/x86_64/ia32/ia32_binfmt.c 2003/05/05 09:18:34 1.24
+++ arch/x86_64/ia32/ia32_binfmt.c 2003/05/07 15:18:15
@@ -242,9 +242,12 @@
{
mpnt->vm_mm = current->mm;
mpnt->vm_start = PAGE_MASK & (unsigned long) bprm->p;
- mpnt->vm_end = IA32_STACK_TOP;
- /* XXX: make this dependent on ELF header flags */
+ mpnt->vm_end = IA32_STACK_TOP;
mpnt->vm_flags = vm_stack_flags32;
+ if (bprm->flags & EF_STACKNOEXEC)
+ mpnt->vm_flags &= ~VM_EXEC;
+ else if (bprm->flags & EF_STACKEXEC)
+ mpnt->vm_flags |= VM_EXEC;
mpnt->vm_page_prot = (mpnt->vm_flags & VM_EXEC) ?
PAGE_COPY_EXEC : PAGE_COPY;
mpnt->vm_ops = NULL;
Index: arch/x86_64/kernel/setup64.c
===================================================================
RCS file: /home/cvs/Repository/linux/arch/x86_64/kernel/setup64.c,v
retrieving revision 1.21
diff -u -u -r1.21 setup64.c
--- arch/x86_64/kernel/setup64.c 2003/05/05 09:18:34 1.21
+++ arch/x86_64/kernel/setup64.c 2003/05/07 15:18:17
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
char x86_boot_params[2048] __initdata = {0,};
@@ -33,38 +34,74 @@
/* When you change the default make sure the no EFER path below sets the
correct flags everywhere. */
-unsigned long __supported_pte_mask = ~0UL & ~_PAGE_NX;
-static int do_not_nx __initdata = 1;
+unsigned long __supported_pte_mask = ~0UL;
+static int do_not_nx __initdata = 0;
unsigned long vm_stack_flags = __VM_STACK_FLAGS;
unsigned long vm_stack_flags32 = __VM_STACK_FLAGS;
unsigned long vm_data_default_flags = __VM_DATA_DEFAULT_FLAGS;
unsigned long vm_data_default_flags32 = __VM_DATA_DEFAULT_FLAGS;
+unsigned long vm_force_exec32 = PROT_EXEC;
char boot_cpu_stack[IRQSTACKSIZE] __cacheline_aligned;
+/* noexec=on|off
+
+on Enable
+off Disable
+noforce (default) Don't enable by default for heap/stack/data,
+ but allow PROT_EXEC to be effective
+
+*/
+
static int __init nonx_setup(char *str)
{
- if (!strncmp(str,"off",3)) {
- __supported_pte_mask &= ~_PAGE_NX;
- do_not_nx = 1;
- } else if (!strncmp(str, "on",3)) {
+ if (!strncmp(str, "on",3)) {
__supported_pte_mask |= _PAGE_NX;
do_not_nx = 0;
vm_data_default_flags &= ~VM_EXEC;
vm_stack_flags &= ~VM_EXEC;
+ } else if (!strncmp(str, "noforce",7) || !strncmp(str,"off",3)) {
+ do_not_nx = (str[0] == 'o');
+ __supported_pte_mask |= _PAGE_NX;
+ vm_data_default_flags |= VM_EXEC;
+ vm_stack_flags |= VM_EXEC;
}
return 1;
}
+/* noexec=opt{,opt}
+
+Control the no exec default for 32bit processes. Can be also overwritten
+per executable using ELF header flags (e.g. needed for the X server)
+Requires noexec=on or noexec=noforce to be effective.
+
+Valid options:
+ all,on Heap,stack,data is non executable.
+ off (default) Heap,stack,data is executable
+ stack Stack is non executable, heap/data is.
+ force Don't imply PROT_EXEC for PROT_READ
+ compat (default) Imply PROT_EXEC for PROT_READ
+
+*/
static int __init nonx32_setup(char *str)
{
- if (!strncmp(str, "on",3)) {
- vm_data_default_flags32 &= ~VM_EXEC;
- vm_stack_flags32 &= ~VM_EXEC;
- } else if (!strncmp(str, "off",3)) {
- vm_data_default_flags32 |= VM_EXEC;
- vm_stack_flags32 |= VM_EXEC;
- }
+ char *s;
+ while ((s = strsep(&str, ",")) != NULL) {
+ if (!strcmp(s, "all") || !strcmp(s,"on")) {
+ vm_data_default_flags32 &= ~VM_EXEC;
+ vm_stack_flags32 &= ~VM_EXEC;
+ } else if (!strcmp(s, "off")) {
+ vm_data_default_flags32 |= VM_EXEC;
+ vm_stack_flags32 |= VM_EXEC;
+ } else if (!strcmp(s, "stack")) {
+ vm_data_default_flags32 |= VM_EXEC;
+ vm_stack_flags32 &= ~VM_EXEC;
+ } else if (!strcmp(s, "force")) {
+ vm_force_exec32 = 0;
+ } else if (!strcmp(s, "compat")) {
+ vm_force_exec32 = PROT_EXEC;
+ }
+ }
return 1;
}
Index: arch/x86_64/mm/init.c
===================================================================
RCS file: /home/cvs/Repository/linux/arch/x86_64/mm/init.c,v
retrieving revision 1.40
diff -u -u -r1.40 init.c
--- arch/x86_64/mm/init.c 2003/02/05 16:29:15 1.40
+++ arch/x86_64/mm/init.c 2003/05/07 15:18:17
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
mmu_gather_t mmu_gathers[NR_CPUS];
@@ -513,4 +514,15 @@
#else
free_bootmem(phys, len);
#endif
+}
+
+void setup_stack_vm(struct linux_binprm *bprm, struct vm_area_struct *vma)
+{
+ if (bprm->flags & EF_STACKEXEC) {
+ vma->vm_page_prot = PAGE_COPY_EXEC;
+ vma->vm_flags |= VM_EXEC;
+ } else if (bprm->flags & EF_STACKNOEXEC) {
+ vma->vm_page_prot = PAGE_COPY_NOEXEC;
+ vma->vm_flags &= ~VM_EXEC;
+ }
}
Index: fs/binfmt_elf.c
===================================================================
RCS file: /home/cvs/Repository/linux/fs/binfmt_elf.c,v
retrieving revision 1.14
diff -u -u -r1.14 binfmt_elf.c
--- fs/binfmt_elf.c 2002/10/17 11:11:28 1.14
+++ fs/binfmt_elf.c 2003/05/07 15:18:23
@@ -608,6 +608,8 @@
/* Do this so that we can load the interpreter, if need be. We will
change some of these later */
current->mm->rss = 0;
+
+ bprm->flags = elf_ex.e_flags;
retval = setup_arg_pages(bprm);
if (retval < 0) {
send_sig(SIGKILL, current, 0);
Index: fs/exec.c
===================================================================
RCS file: /home/cvs/Repository/linux/fs/exec.c,v
retrieving revision 1.11
diff -u -u -r1.11 exec.c
--- fs/exec.c 2003/04/03 09:47:24 1.11
+++ fs/exec.c 2003/05/07 15:18:23
@@ -338,8 +338,11 @@
mpnt->vm_mm = current->mm;
mpnt->vm_start = PAGE_MASK & (unsigned long) bprm->p;
mpnt->vm_end = STACK_TOP;
- mpnt->vm_page_prot = PAGE_COPY;
mpnt->vm_flags = VM_STACK_FLAGS;
+ mpnt->vm_page_prot = PAGE_COPY;
+#ifdef SETUP_STACK_VM
+ SETUP_STACK_VM(bprm, mpnt);
+#endif
mpnt->vm_ops = NULL;
mpnt->vm_pgoff = 0;
mpnt->vm_file = NULL;
@@ -900,6 +903,7 @@
bprm.sh_bang = 0;
bprm.loader = 0;
bprm.exec = 0;
+ bprm.flags = 0;
if ((bprm.argc = count(argv, bprm.p / sizeof(void *))) < 0) {
allow_write_access(file);
fput(file);
Index: include/asm-x86_64/elf.h
===================================================================
RCS file: /home/cvs/Repository/linux/include/asm-x86_64/elf.h,v
retrieving revision 1.14
diff -u -u -r1.14 elf.h
--- include/asm-x86_64/elf.h 2002/07/31 12:07:17 1.14
+++ include/asm-x86_64/elf.h 2003/05/07 15:18:26
@@ -125,4 +125,8 @@
#endif
+/* ELF header flags. compatible with "ExecShield" and older i386 patches */
+#define EF_STACKEXEC 1 /* Executable stack area forced */
+#define EF_STACKNOEXEC 2 /* non-executable stack area forced */
+
#endif
Index: include/asm-x86_64/page.h
===================================================================
RCS file: /home/cvs/Repository/linux/include/asm-x86_64/page.h,v
retrieving revision 1.41
diff -u -u -r1.41 page.h
--- include/asm-x86_64/page.h 2003/05/05 09:18:33 1.41
+++ include/asm-x86_64/page.h 2003/05/07 15:18:26
@@ -67,6 +67,7 @@
extern unsigned long vm_stack_flags, vm_stack_flags32;
extern unsigned long vm_data_default_flags, vm_data_default_flags32;
+extern unsigned long vm_force_exec32;
#endif /* !__ASSEMBLY__ */
Index: include/asm-x86_64/pgalloc.h
===================================================================
RCS file: /home/cvs/Repository/linux/include/asm-x86_64/pgalloc.h,v
retrieving revision 1.11
diff -u -u -r1.11 pgalloc.h
--- include/asm-x86_64/pgalloc.h 2002/08/07 18:33:41 1.11
+++ include/asm-x86_64/pgalloc.h 2003/05/07 15:18:27
@@ -216,4 +216,10 @@
flush_tlb_mm(mm);
}
+
+struct linux_binprm;
+struct vm_area_struct;
+extern void setup_stack_vm(struct linux_binprm *bprm, struct vm_area_struct *vma);
+#define SETUP_STACK_VM(bprm,vma) setup_stack_vm(bprm,vma)
+
#endif /* _X86_64_PGALLOC_H */
Index: include/asm-x86_64/pgtable.h
===================================================================
RCS file: /home/cvs/Repository/linux/include/asm-x86_64/pgtable.h,v
retrieving revision 1.34
diff -u -u -r1.34 pgtable.h
--- include/asm-x86_64/pgtable.h 2003/02/25 10:18:48 1.34
+++ include/asm-x86_64/pgtable.h 2003/05/07 15:18:27
@@ -231,8 +231,8 @@
#define PAGE_NONE __pgprot(_PAGE_PROTNONE | _PAGE_ACCESSED)
#define PAGE_SHARED __pgprot(_PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED)
#define PAGE_SHARED_NOEXEC __pgprot(_PAGE_NX | _PAGE_PRESENT | _PAGE_RW | _PAGE_USER | _PAGE_ACCESSED)
-#define PAGE_COPY __pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED | _PAGE_NX)
-
+#define PAGE_COPY_NOEXEC __pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED | _PAGE_NX)
+#define PAGE_COPY PAGE_COPY_NOEXEC
#define PAGE_COPY_EXEC \
__pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED)
#define PAGE_READONLY __pgprot(_PAGE_PRESENT | _PAGE_USER | _PAGE_ACCESSED | _PAGE_NX)
Index: include/linux/binfmts.h
===================================================================
RCS file: /home/cvs/Repository/linux/include/linux/binfmts.h,v
retrieving revision 1.2
diff -u -u -r1.2 binfmts.h
--- include/linux/binfmts.h 2002/10/17 11:11:28 1.2
+++ include/linux/binfmts.h 2003/05/07 15:18:29
@@ -30,6 +30,7 @@
int argc, envc;
char * filename; /* Name of binary */
unsigned long loader, exec;
+ int flags;
};
/*
From richard.brunner at amd.com Wed May 7 18:02:25 2003
From: richard.brunner at amd.com (richard.brunner at amd.com)
Date: Wed, 7 May 2003 11:02:25 -0500
Subject: [discuss] DPMI on AMD64
Message-ID: <99F2150714F93F448942F9A9F112634C02B5414F@txexmtae.amd.com>
I agree with the last statement I made which says you can use it,
just be careful not to shoot yourself. Have a nice day.
-Rich Brunner
AMD
> -----Original Message-----
> From: Mike A. Harris [mailto:mharris at www.linux.org.uk]
> Sent: Tuesday, May 06, 2003 8:49 PM
> To: H. Peter Anvin
> Cc: discuss at x86-64.org
> Subject: Re: [discuss] DPMI on AMD64
>
>
> On 6 May 2003, H. Peter Anvin wrote:
>
> >> Barring someone directly from AMD posting on this list that it is
> >> going to be officially supported to switch from long mode back to
> >> legacy mode, then as far as I'm concerned, it isn't supported, as
> >> the last official comment about this from AMD on list was quite
> >> clear - at least to me - that this would *NOT* be supported by
> >> AMD and that people should not use it or their software could
> >> very well break due to relying on undefined behaviour.
> >>
> >
> >You apparently missed exactly this thing actually happen.
> >
> >> Can someone from AMD please restate AMD's official position on
> >> switching from long mode back to legacy mode once again to
> >> clarify this issue?
> >
> >http://www.x86-64.org/lists/discuss/msg03333.html
>
> Thanks for the updated info hpa. Indeed I did not see that
> posting from AMD. I did see all of the postings prior to that
> where they claimed it was unsupported and not to rely on it.
> Seems like just simple mixup.
>
> Thanks for clarifying.
>
>
> --
> Mike A. Harris
>
>
>
From cloos at jhcloos.com Wed May 7 19:41:40 2003
From: cloos at jhcloos.com (James H. Cloos Jr.)
Date: 07 May 2003 13:41:40 -0400
Subject: gcc
Message-ID:
Am I correct that current versions of gcc can do both ia32 and amd64
out of the box (using the -m32 and -m64 flags), and only 64bit
versions of binutils and the libraries are needed to cross-compile
for amd64 on a (bleeding edge) ia32 (linux) box?
-JimC
From arnd at arndb.de Wed May 7 20:02:10 2003
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 7 May 2003 20:02:10 +0200
Subject: [discuss] gcc
In-Reply-To:
References:
Message-ID: <200305072002.10882.arnd@arndb.de>
On Wednesday 07 May 2003 19:41, James H. Cloos Jr. wrote:
> Am I correct that current versions of gcc can do both ia32 and amd64
> out of the box (using the -m32 and -m64 flags), and only 64bit
> versions of binutils and the libraries are needed to cross-compile
> for amd64 on a (bleeding edge) ia32 (linux) box?
Almost. The amd64 gcc supports both ia32 and amd64 binaries with
the -m32/-m64 options. The ia32 gcc by default does not support
amd64 output, but that can be changed with a mostly-trivial patch:
http://www.arndb.de/debian/gcc-3.2_3.2.3ds7-0pre8.biarch1.diff.gz
will create a file debian/patches/i386-biarch.dpatch that
does the necessary changes for a recent gcc-3.3 snapshot.
You need extra 64 bit versions of the libraries, but binutils are
different in that you can build them for multiple architectures at
once. Just include amd64 support when building your regular binutils.
Arnd <><
From aj at suse.de Wed May 7 20:16:02 2003
From: aj at suse.de (Andreas Jaeger)
Date: Wed, 07 May 2003 20:16:02 +0200
Subject: [discuss] gcc
In-Reply-To: (James H. Cloos, Jr.'s
message of "07 May 2003 13:41:40 -0400")
References:
Message-ID:
"James H. Cloos Jr." writes:
> Am I correct that current versions of gcc can do both ia32 and amd64
> out of the box (using the -m32 and -m64 flags), and only 64bit
> versions of binutils and the libraries are needed to cross-compile
> for amd64 on a (bleeding edge) ia32 (linux) box?
A compiler configured for x86-64 supports both. But a compiler setup
for x86 will only offer compilation of 32-bit x86 binaries. If you
like to develop x86-64 code on x86, you need a cross compiler.
If you have an AMD64 system, you can easily build 32-bit x86 and
64-bit AMD64 applications.
Btw. I uploaded some older cross compiler, gcc and binutils to
ftp.suse.com/pub/people/aj,
Andreas
--
Andreas Jaeger
SuSE Labs aj at suse.de
private aj at arthur.inka.de
http://www.suse.de/~aj
From ak at suse.de Wed May 7 23:02:28 2003
From: ak at suse.de (Andi Kleen)
Date: Wed, 7 May 2003 23:02:28 +0200
Subject: [discuss] gcc
In-Reply-To: <200305072002.10882.arnd@arndb.de>
References: <200305072002.10882.arnd@arndb.de>
Message-ID: <20030507210228.GA2877@Wotan.suse.de>
On Wed, May 07, 2003 at 08:02:10PM +0200, Arnd Bergmann wrote:
> On Wednesday 07 May 2003 19:41, James H. Cloos Jr. wrote:
> > Am I correct that current versions of gcc can do both ia32 and amd64
> > out of the box (using the -m32 and -m64 flags), and only 64bit
> > versions of binutils and the libraries are needed to cross-compile
> > for amd64 on a (bleeding edge) ia32 (linux) box?
>
> Almost. The amd64 gcc supports both ia32 and amd64 binaries with
> the -m32/-m64 options. The ia32 gcc by default does not support
> amd64 output, but that can be changed with a mostly-trivial patch:
> http://www.arndb.de/debian/gcc-3.2_3.2.3ds7-0pre8.biarch1.diff.gz
> will create a file debian/patches/i386-biarch.dpatch that
> does the necessary changes for a recent gcc-3.3 snapshot.
It will make your 32bit gcc a lot slower though. The amd64 gcc
does many things internally with 64bit long long instead of 32bit long, and
gcc generates significantly worse code for long long on 32bit
than for 32bit long. This slows it down.
So probably you don't want that for your "standard" 32bit gcc.
Better is it to have a separate cross compiler that you only use
when you really need amd64 executables.
On a amd64 host of course it's no issue because long long is fast.
-Andi
From arnd at arndb.de Wed May 7 23:36:43 2003
From: arnd at arndb.de (Arnd Bergmann)
Date: Wed, 7 May 2003 23:36:43 +0200
Subject: [discuss] gcc
In-Reply-To: <20030507210228.GA2877@Wotan.suse.de>
References: <200305072002.10882.arnd@arndb.de> <20030507210228.GA2877@Wotan.suse.de>
Message-ID: <200305072336.43015.arnd@arndb.de>
On Wednesday 07 May 2003 23:02, Andi Kleen wrote:
> It will make your 32bit gcc a lot slower though. The amd64 gcc
> does many things internally with 64bit long long instead of 32bit long, and
> gcc generates significantly worse code for long long on 32bit
> than for 32bit long. This slows it down.
Do you have actual performance numbers on this? I just tried a kernel
build with an i386 gcc-3.2 and a biarch gcc-3.3 with -m32. The gcc-3.3
is only 1% slower, which is less slowdown than what I expected from
moving to 3.2 to 3.3 anyway.
Arnd <><
From ak at suse.de Thu May 8 00:01:54 2003
From: ak at suse.de (Andi Kleen)
Date: Thu, 8 May 2003 00:01:54 +0200
Subject: [discuss] gcc
In-Reply-To: <200305072336.43015.arnd@arndb.de>
References: <200305072002.10882.arnd@arndb.de> <20030507210228.GA2877@Wotan.suse.de> <200305072336.43015.arnd@arndb.de>
Message-ID: <20030507220154.GC2877@Wotan.suse.de>
On Wed, May 07, 2003 at 11:36:43PM +0200, Arnd Bergmann wrote:
> On Wednesday 07 May 2003 23:02, Andi Kleen wrote:
>
> > It will make your 32bit gcc a lot slower though. The amd64 gcc
> > does many things internally with 64bit long long instead of 32bit long, and
> > gcc generates significantly worse code for long long on 32bit
> > than for 32bit long. This slows it down.
>
> Do you have actual performance numbers on this? I just tried a kernel
> build with an i386 gcc-3.2 and a biarch gcc-3.3 with -m32. The gcc-3.3
> is only 1% slower, which is less slowdown than what I expected from
> moving to 3.2 to 3.3 anyway.
Just informal data from watching kernel compiles. My cross builds are usually
much slower than a native i386 build on my 900Mhz Athlon. May not be very accurate.
Of course x86-64 also has differnet include files which could also slightly
distort things.
In general my experience from reading code is that the gcc long long code is
not very efficient. gcc always puts long long into aligned register pairs, so on i386
with frame pointer you can only have three variables at best in registers
at one time. It is spills galore.
The original i386 gcc after 3.0 defaulted to biarch btw, but Jakub Jelinek
removed it. I assume he did some numbers too back then.
-Andi
From peter at jazz-1.trumpet.com.au Thu May 8 00:52:30 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Thu, 8 May 2003 08:52:30 +1000 (EST)
Subject: [discuss] Testing executables
In-Reply-To:
Message-ID:
I might be able to help you get bochs running. That would sound like your best
solution. Do you know how to use CVS, and do you have 64 bit OS images at your
disposal?
Peter
On Wed, 7 May 2003, navin wrote:
> Hi,
> I am doing a project on compilers. I need to create 64 bit
> executables. I have created the a simple executable but can't test whether
> it is the right output or not since i don't have the hardware.
>
> 1)
> If anyone can tell me whether the exectuable runs and give me the output i
> can assume that what i am doing is right.
>
> 2)
> Also i wanted to use bochs .Can anyone tell me where can i find a simple
> bochsrc or can any give me their minimal bochsrc.
> Simnow is giving me errors like saying kdecore1.0 and qt1.0 when i give
> --nodeps it just crashes.
>
> 3)
> Any help on how to execute those things on my pentium III ?
>
> Navin
>
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From peter at jazz-1.trumpet.com.au Thu May 8 03:52:17 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Thu, 8 May 2003 11:52:17 +1000 (EST)
Subject: [Bochs-developers] xfer patches break x86-64 (fwd)
Message-ID:
FYI. I will fix this by tomorrow, reason being that I have my day job to
attend to. For anyone testing with bochs revert back to version 1.21 of
cpu/data_xfer32.cc
Regards
Peter
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
---------- Forwarded message ----------
Date: Thu, 8 May 2003 09:44:37 +1000 (EST)
From: Peter Tattam
To: Paul Brook
Cc: bochs-developers at lists.sourceforge.net
Subject: Re: [Bochs-developers] xfer patches break x86-64
thanks for the warning. I'll take a look to see what's changed.
The problem is in data_xfer32.cc. Any write to a 32 bit register must be zero
extended to 64 bits. You must use the BX_WRITE_32BIT_REGZ macro to do this
properly.
Also, I am not sure the CMOV change is correct. If the condition is false, it
will avoid the read which is ok, but if the address is not valid, you won't
generate #PF or #GP
Peter
On Wed, 7 May 2003, Paul Brook wrote:
> The changes to cpu/data_xfer_*.cc in May 03 break x86-64 support. After
> these changes x86-64 kernels fail to boot.
>
> I've tried several different (known good) kernels, all die the same way.
> I've attached a transcritpt of a failed boot in case this is any use.
>
> Paul Brook
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
_______________________________________________
bochs-developers mailing list
bochs-developers at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bochs-developers
From ak at suse.de Thu May 8 08:26:33 2003
From: ak at suse.de (Andi Kleen)
Date: Thu, 8 May 2003 08:26:33 +0200
Subject: x86_64-2.5.69-1
Message-ID: <20030508062633.GA19453@Wotan.suse.de>
ftp://ftp.x86-64.org/pub/linux/v2.5/x86_64-2.5.69-1.bz2
0ff3d048c9007a307f92a830f856d562 x86_64-2.5.69-1.bz2
Mainly it makes everything compile again. Starts with the dwarf2
vsyscall implementation for 32bit. Also lots of warning fixes
and some cleanups.
Known bigger problems (see ftp://ftp.x86-64.org/pub/linux/RELEASE-NOTES
for a full list)
- IOMMU pci_free_consistent causes memory corruption (often happens at
shutdown). This is only a problem when you use CONFIG_IOMMU_DEBUG /
iommu=force or have a machine with more than 4GB of RAM and devices
that do not support DAC.
- AT_GID/AT_UID elf env vectors contain garbage. This breaks some
debugging setups for root programs because the program thinks it is
running suid/sgid.
- /dev/agpgart is not fully usable because of problems with change_page_attr
- Bug fixes/changes from 2.4 still missing.
Full changelog:
- Disable sign compare warnings for gcc 3.3-hammer
- Use DSO for 32bit vsyscalls and dump it in core dumps. Add dwarf2
information for the vsyscalls.
Thanks to Richard Henderson for helping me with the nasty parts of it.
I had to do some changes over his patch and it's currently only
lightly tested. Handle with care. This only affects 32bit programs
that use a glibc 3.2 with sysenter support.
- Security fixes for the 32bit ioctl handlers. Also some simplications/speedups.
- gcc 3.3-hammer compile fixes for inline assembly
- Remove acpi.c file corpse.
- Lots of warning fixes
- Disable some Dprintks to make the bootup quieter again
- Clean up ptrace a bit (together with warning fixes)
- Merge with i386 (handle ACPI dynamic irq entries properly)
- Disable change_page_attr in pci-gart for now. Strictly that's incorrect,
need to do more testing for the root cause of the current IOMMU problems.
- Update defconfig
- Disable first prefetch in copy_user that is likely to trigger Opteron
Errata #91
- More irqreturn_t fixes
- Add pte_user and fix the vsyscall ptrace hack in generic code.
It's still partly broken
- Port verbose MCE handler from 2.4
-Andi
From andrebalsa at mailingaddress.org Thu May 8 12:08:07 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Thu, 8 May 2003 18:08:07 +0800
Subject: Can you explain lib + lib64 glibc installation?
Message-ID: <200305081808.07743.andrebalsa@mailingaddress.org>
Hi,
I now have a relatively stable x86_64 cross-compilation toolchain, kernel and
bochs setup which I am testing on my Athlon machine.
My latest disk image boots with Grub, a 64-bit kernel (based on 2.4.21-rc1),
and I have setup the following 64-bit compiled binaries with static linking
(against glibc-2.3.1):
- Busybox-0.60.5
- Sysinit-2.85 (w/o sulogin)
- Tinylogin-1.4
I now would like to move the glibc libraries to my target bochs/AMD64 disk
image (since, as you can imagine, the statically linked files are huge...).
Presently I have my glibc for cross-compilation in
/opt/x86-64/x86_64-unknown-linux/lib and
/opt/x86-64/x86_64-unknown-linux /lib64
Question: can I just copy these to my new directory tree in my bochs/AMD64
disk image?
Should I do a make install PREFIX=path_to_disk_image?
Also: why is e.g libcrypt-2.3.1.so in /lib and not in /lib64? Shouldn?t all
the 64-bit libraries be in /lib64?
Thanks for your guidance,
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From aj at suse.de Thu May 8 12:14:29 2003
From: aj at suse.de (Andreas Jaeger)
Date: Thu, 08 May 2003 12:14:29 +0200
Subject: [discuss] Can you explain lib + lib64 glibc installation?
In-Reply-To: <200305081808.07743.andrebalsa@mailingaddress.org> (Andrew
Derrick Balsa's message of "Thu, 8 May 2003 18:08:07 +0800")
References: <200305081808.07743.andrebalsa@mailingaddress.org>
Message-ID:
Andrew Derrick Balsa writes:
> Hi,
>
> I now have a relatively stable x86_64 cross-compilation toolchain, kernel and
> bochs setup which I am testing on my Athlon machine.
>
> My latest disk image boots with Grub, a 64-bit kernel (based on 2.4.21-rc1),
> and I have setup the following 64-bit compiled binaries with static linking
> (against glibc-2.3.1):
>
> - Busybox-0.60.5
> - Sysinit-2.85 (w/o sulogin)
> - Tinylogin-1.4
>
> I now would like to move the glibc libraries to my target bochs/AMD64 disk
> image (since, as you can imagine, the statically linked files are huge...).
>
> Presently I have my glibc for cross-compilation in
> /opt/x86-64/x86_64-unknown-linux/lib and
> /opt/x86-64/x86_64-unknown-linux /lib64
>
> Question: can I just copy these to my new directory tree in my bochs/AMD64
> disk image?
> Should I do a make install PREFIX=path_to_disk_image?
The paths might be wrong for the dynamic loader, check with readelf:
readelf -l /lib64/libc.so.6
Elf file type is DYN (Shared object file)
Entry point 0x1d6c0
There are 7 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x0000000000000188 0x0000000000000188 R E 8
INTERP 0x000000000011b2a0 0x000000000011b2a0 0x000000000011b2a0
0x000000000000001c 0x000000000000001c R 10
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
If this is the case, you can easily do it.
> Also: why is e.g libcrypt-2.3.1.so in /lib and not in /lib64? Shouldn?t all
> the 64-bit libraries be in /lib64?
Don't know how you setup the stuff, everything should be in /lib64
> Thanks for your guidance,
Andreas
--
Andreas Jaeger
SuSE Labs aj at suse.de
private aj at arthur.inka.de
http://www.suse.de/~aj
From andrebalsa at mailingaddress.org Thu May 8 16:43:52 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Thu, 8 May 2003 22:43:52 +0800
Subject: Can you explain lib + lib64 glibc installation?
Message-ID: <200305082243.52431.andrebalsa@mailingaddress.org>
Hi,
> The paths might be wrong for the dynamic loader, check with readelf:
> readelf -l /lib64/libc.so.6
I followed ***very exactly*** the instructions here:
http://www.x86-64.org/documentation_folder/build
I have just rebuilt the whole toolchain, with the latest versions of binutils,
gcc and glibc-2.3.1 (glibc-2.3.2 does not cross-compile).
1) This time I didn?t get any lib64 directory created in
/opt/x86-64/x86_64-unknown-linux
2) When I test using readelf, I get:
[root at andrew lib]# readelf -l ./libc-2.3.1.so
Elf file type is DYN (Shared object file)
Entry point 0x1e750
There are 6 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x0000000000000150 0x0000000000000150 R E 8
INTERP 0x00000000001186e0 0x00000000001186e0 0x00000000001186e0
0x000000000000003a 0x000000000000003a R 20
[Requesting program interpreter:
/opt/x86-64/x86_64-unknown-linux/lib/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000011871a 0x000000000011871a R E 100000
LOAD 0x0000000000119000 0x0000000000219000 0x0000000000219000
0x000000000001f0d8 0x0000000000025be0 RW 100000
DYNAMIC 0x00000000001374b8 0x00000000002374b8 0x00000000002374b8
0x00000000000001b0 0x00000000000001b0 RW 8
NOTE 0x0000000000000190 0x0000000000000190 0x0000000000000190
0x0000000000000020 0x0000000000000020 R 4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_d
.gnu.v ersion_r .rela.dyn .rela.plt .plt .text .fini
.rodata .interp
03 .data __libc_subfreeres __libc_atexit .eh_frame .dynamic .ctors
.dtors .got .bss
04 .dynamic
05 .note.ABI-tag
3) Is this correct? Why didn?t the glibc ?make install? create a lib64
directory?
4) My Mandrake 9.2 (Cooker) libc-2.3.2.so i586 file is just 1,251,020 bytes,
whereas the libc-2.3.1.so for AMD64 file that I just compiled is 10,978 KB.
Seems something is wrong here...
Thanks for any help/tips/hints,
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From aj at suse.de Thu May 8 16:46:53 2003
From: aj at suse.de (Andreas Jaeger)
Date: Thu, 08 May 2003 16:46:53 +0200
Subject: [discuss] Re: Can you explain lib + lib64 glibc installation?
In-Reply-To: <200305082243.52431.andrebalsa@mailingaddress.org> (Andrew
Derrick Balsa's message of "Thu, 8 May 2003 22:43:52 +0800")
References: <200305082243.52431.andrebalsa@mailingaddress.org>
Message-ID:
Andrew Derrick Balsa writes:
> Hi,
>
>> The paths might be wrong for the dynamic loader, check with readelf:
>> readelf -l /lib64/libc.so.6
>
> I followed ***very exactly*** the instructions here:
> http://www.x86-64.org/documentation_folder/build
>
> I have just rebuilt the whole toolchain, with the latest versions of binutils,
> gcc and glibc-2.3.1 (glibc-2.3.2 does not cross-compile).
>
> 1) This time I didn?t get any lib64 directory created in
> /opt/x86-64/x86_64-unknown-linux
You only get lib64 directories if you use --prefix=/usr
> 2) When I test using readelf, I get:
> [root at andrew lib]# readelf -l ./libc-2.3.1.so
>
> Elf file type is DYN (Shared object file)
> Entry point 0x1e750
> There are 6 program headers, starting at offset 64
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
> 0x0000000000000150 0x0000000000000150 R E 8
> INTERP 0x00000000001186e0 0x00000000001186e0 0x00000000001186e0
> 0x000000000000003a 0x000000000000003a R 20
> [Requesting program interpreter:
> /opt/x86-64/x86_64-unknown-linux/lib/ld-linux-x86-64.so.2]
So, this is setup for installation in that dir.
If you like to have files compiled for /usr/lib64 and /lib64, run
--prefix=/usr and then make install install_prefix=/somewhere - and
then copy them to your bochs partition.
Or copy /opt/x86-64/... to boch with this path exactly. This has the
advantage that you can easier crosscompile.
>
> 3) Is this correct? Why didn?t the glibc ?make install? create a lib64
> directory?
Yes, it's correct.
> 4) My Mandrake 9.2 (Cooker) libc-2.3.2.so i586 file is just 1,251,020 bytes,
> whereas the libc-2.3.1.so for AMD64 file that I just compiled is 10,978 KB.
> Seems something is wrong here...
I guess your i586 glibc is strippeed.
the file sizes (stripped) should be similar, here are results from
2.3.2:
-rwxr-xr-x 1 root root 1491599 Mar 14 00:33 /lib/libc.so.6
-rwxr-xr-x 1 root root 1554461 Mar 23 10:39 /lib64/libc.so.6
My unstripped libc.so has a size of 7821365 bytes (but this depends on
compiler version, newer compiler produce more compact debugging info).
> Thanks for any help/tips/hints,
Andreas
--
Andreas Jaeger
SuSE Labs aj at suse.de
private aj at arthur.inka.de
http://www.suse.de/~aj
From richard.brunner at amd.com Thu May 8 17:52:14 2003
From: richard.brunner at amd.com (richard.brunner at amd.com)
Date: Thu, 8 May 2003 10:52:14 -0500
Subject: [discuss] DPMI on AMD64
Message-ID: <99F2150714F93F448942F9A9F112634C02B54178@txexmtae.amd.com>
Just to be paranoid. Everyone on the same page now, right?
You can go back and forth between longmode. It works, it is validated
it is supported by AMD. PLease just be careful when using.
Thanks!
> -----Original Message-----
> From: Brunner, Richard
> Sent: Wednesday, May 07, 2003 11:02 AM
> To: mharris at www.linux.org.uk; hpa at zytor.com
> Cc: discuss at x86-64.org
> Subject: RE: [discuss] DPMI on AMD64
>
>
> I agree with the last statement I made which says you can use it,
> just be careful not to shoot yourself. Have a nice day.
>
> -Rich Brunner
> AMD
>
> > -----Original Message-----
> > From: Mike A. Harris [mailto:mharris at www.linux.org.uk]
> > Sent: Tuesday, May 06, 2003 8:49 PM
> > To: H. Peter Anvin
> > Cc: discuss at x86-64.org
> > Subject: Re: [discuss] DPMI on AMD64
> >
> >
> > On 6 May 2003, H. Peter Anvin wrote:
> >
> > >> Barring someone directly from AMD posting on this list
> that it is
> > >> going to be officially supported to switch from long
> mode back to
> > >> legacy mode, then as far as I'm concerned, it isn't
> supported, as
> > >> the last official comment about this from AMD on list was quite
> > >> clear - at least to me - that this would *NOT* be supported by
> > >> AMD and that people should not use it or their software could
> > >> very well break due to relying on undefined behaviour.
> > >>
> > >
> > >You apparently missed exactly this thing actually happen.
> > >
> > >> Can someone from AMD please restate AMD's official position on
> > >> switching from long mode back to legacy mode once again to
> > >> clarify this issue?
> > >
> > >http://www.x86-64.org/lists/discuss/msg03333.html
> >
> > Thanks for the updated info hpa. Indeed I did not see that
> > posting from AMD. I did see all of the postings prior to that
> > where they claimed it was unsupported and not to rely on it.
> > Seems like just simple mixup.
> >
> > Thanks for clarifying.
> >
> >
> > --
> > Mike A. Harris
> >
> >
> >
>
>
From hpa at zytor.com Thu May 8 18:27:26 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Thu, 08 May 2003 09:27:26 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To: <99F2150714F93F448942F9A9F112634C02B54178@txexmtae.amd.com>
References: <99F2150714F93F448942F9A9F112634C02B54178@txexmtae.amd.com>
Message-ID: <3EBA856E.1070801@zytor.com>
richard.brunner at amd.com wrote:
> Just to be paranoid. Everyone on the same page now, right?
>
> You can go back and forth between longmode. It works, it is validated
> it is supported by AMD. PLease just be careful when using.
>
I sure hope so :)
-hpa
From andrebalsa at mailingaddress.org Thu May 8 18:54:03 2003
From: andrebalsa at mailingaddress.org (Andrew Derrick Balsa)
Date: Fri, 9 May 2003 00:54:03 +0800
Subject: [discuss] Can you explain lib + lib64 glibc installation?
Message-ID: <200305090054.03932.andrebalsa@mailingaddress.org>
Hi,
Thank you, Andreas. I followed your advice and it seems I am getting there:
readelf produces the desired result.
I had to copy the files manually, though, to my bochs disk image, and it seems
some files in my Mandrake setup got hosed in the process... :o(
Two more questions:
1) What should /etc/ld.so.conf look like for a mixed 32/64 bit system?
2) If I decide to only run 64-bit executables, can I just get rid of the /lib
and/usr/lib directories, or should something always be there?
Thanks,
--
Andr? Derrick Balsa (Andrew)
andrebalsa at mailingaddress.org
From parag at codegen.com Thu May 8 18:49:15 2003
From: parag at codegen.com (Parag Patel)
Date: Thu, 08 May 2003 09:49:15 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To: Message from richard.brunner@amd.com
of "Thu, 08 May 2003 10:52:14 CDT." <99F2150714F93F448942F9A9F112634C02B54178@txexmtae.amd.com>
Message-ID: <92316.1052412555@tenor.codegen.com>
>You can go back and forth between longmode. It works, it is validated
>it is supported by AMD. PLease just be careful when using.
Yes, thanks. It works just fine for SmartFirmware. We switch back to
32-bit legacy mode before launching Linux or BSD kernels, which then
switch to long-mode. SF switches to long-mode as early as it can. It's
definitely handy to access the entire address space directly from Forth.
(In the longer-term, we will add proper 64-bit entrypoints and directly
support SF within BSD and Linux, but we still have a lot of other work
to do first...)
--
__
/__)_ _ _ _ The human mind treats a new idea the way the body treats a
/ (// (/(/ strange protein -- it rejects it. -- P. Medawar
_/
From hpa at zytor.com Thu May 8 18:54:27 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Thu, 08 May 2003 09:54:27 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To: <92316.1052412555@tenor.codegen.com>
References: <92316.1052412555@tenor.codegen.com>
Message-ID: <3EBA8BC3.5070404@zytor.com>
Parag Patel wrote:
>>You can go back and forth between longmode. It works, it is validated
>>it is supported by AMD. PLease just be careful when using.
>
>
> Yes, thanks. It works just fine for SmartFirmware. We switch back to
> 32-bit legacy mode before launching Linux or BSD kernels, which then
> switch to long-mode. SF switches to long-mode as early as it can. It's
> definitely handy to access the entire address space directly from Forth.
>
> (In the longer-term, we will add proper 64-bit entrypoints and directly
> support SF within BSD and Linux, but we still have a lot of other work
> to do first...)
While we're on this subject, I would really like AMD to lean on BIOS
people to support INT 15h AX=2401h (enable A20), and if the A20 gate is
supported at all also support INT 15h AX=2400h (disable A20). The lack
of this BIOS call and therefore having to rely on controlling A20 by
"voodoo" is in my experience the single biggest reason why darting in
and out of protected mode doesn't work -- longmode, obviously, has the
same issue.
-hpa
From arnd at arndb.de Thu May 8 22:25:22 2003
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 8 May 2003 22:25:22 +0200
Subject: [discuss] Can you explain lib + lib64 glibc installation?
In-Reply-To: <200305090054.03932.andrebalsa@mailingaddress.org>
References: <200305090054.03932.andrebalsa@mailingaddress.org>
Message-ID: <200305082225.23250.arnd@arndb.de>
On Thursday 08 May 2003 18:54, Andrew Derrick Balsa wrote:
> Two more questions:
> 1) What should /etc/ld.so.conf look like for a mixed 32/64 bit system?
You should put both 32 and 64 bit directories in there, the dynamic linker
will ignore any libraries that don't match the binary format.
> 2) If I decide to only run 64-bit executables, can I just get rid of the
> /lib and/usr/lib directories, or should something always be there?
There are some files in /lib that don't get moved to /lib64 and are still
needed. Examples:
/lib/modules/*
/lib/cpp
/usr/lib/gcc-lib/
/usr/lib/rpm/
However, if you don't want to run any 32 bit binaries, you can make lib or
lib64 a symlink to the other one.
Arnd <><
From mharris at www.linux.org.uk Thu May 8 23:13:38 2003
From: mharris at www.linux.org.uk (Mike A. Harris)
Date: Thu, 8 May 2003 17:13:38 -0400 (EDT)
Subject: [discuss] DPMI on AMD64
In-Reply-To: <99F2150714F93F448942F9A9F112634C02B54178@txexmtae.amd.com>
Message-ID:
On Thu, 8 May 2003 richard.brunner at amd.com wrote:
>Date: Thu, 8 May 2003 10:52:14 -0500
>From: richard.brunner at amd.com
>To: mharris at www.linux.org.uk, hpa at zytor.com
>Cc: discuss at x86-64.org
>Content-Type: text/plain;
> charset=us-ascii
>Subject: RE: [discuss] DPMI on AMD64
>
>Just to be paranoid. Everyone on the same page now, right?
Yeppers.
>You can go back and forth between longmode. It works, it is validated
>it is supported by AMD. PLease just be careful when using.
And those implementing or considering implementing the switch,
should also be sure to take their fun pills. ;o)
Thanks Richard,
TTYL
--
Mike A. Harris
From tjm at codegen.com Thu May 8 23:29:57 2003
From: tjm at codegen.com (Thomas J. Merritt)
Date: Thu, 08 May 2003 14:29:57 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To: Your message of Thu, 08 May 2003 17:13:38 -0400.
Message-ID: <200305082129.h48LTvHR094831@tenor.codegen.com>
|<><><><><> Original message from "Mike A. Harris" <><><><><>
|On Thu, 8 May 2003 richard.brunner at amd.com wrote:
|
|>Date: Thu, 8 May 2003 10:52:14 -0500
|>From: richard.brunner at amd.com
|>To: mharris at www.linux.org.uk, hpa at zytor.com
|>Cc: discuss at x86-64.org
|>Content-Type: text/plain;
|> charset=us-ascii
|>Subject: RE: [discuss] DPMI on AMD64
|>
|>Just to be paranoid. Everyone on the same page now, right?
|
|Yeppers.
|
|>You can go back and forth between longmode. It works, it is validated
|>it is supported by AMD. PLease just be careful when using.
|
|And those implementing or considering implementing the switch,
|should also be sure to take their fun pills. ;o)
Switching between long-mode with interrupts disabled and protected-mode
with paging-off and interrupts disabled isn't too difficult. Switching
between long-mode with interrupts enabled and protected-mode with
paging-on and interrupts enabled will be a lot more fun. The first
works just fine in SmartFirmware, the later would be necessary to
make use of the legacy modes in an operating system. I expect that
eventually someone will write the code to prove that it is possible to
do.
TJ Merritt
tjm at codegen.com
1-925-462-4300 x115
From hpa at zytor.com Thu May 8 23:36:43 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Thu, 08 May 2003 14:36:43 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To: <200305082129.h48LTvHR094831@tenor.codegen.com>
References: <200305082129.h48LTvHR094831@tenor.codegen.com>
Message-ID: <3EBACDEB.9070302@zytor.com>
Thomas J. Merritt wrote:
>
> Switching between long-mode with interrupts disabled and protected-mode
> with paging-off and interrupts disabled isn't too difficult. Switching
> between long-mode with interrupts enabled and protected-mode with
> paging-on and interrupts enabled will be a lot more fun. The first
> works just fine in SmartFirmware, the later would be necessary to
> make use of the legacy modes in an operating system. I expect that
> eventually someone will write the code to prove that it is possible to
> do.
>
It's not really any worse than performing the equivalent operation
between real mode and protected mode. This is part of why I utterly
despise AMD's use of the term legacy mode -- the machine really has
three operating modes: real mode, protected mode, and long mode, the
latter two of which have submodes: protected mode has 32-bit, 16-bit,
and V86; long mode has 64-bit and compatibility mode.
-hpa
From hpa at zytor.com Thu May 8 23:41:12 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Thu, 08 May 2003 14:41:12 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To: <200305082129.h48LTvHR094831@tenor.codegen.com>
References: <200305082129.h48LTvHR094831@tenor.codegen.com>
Message-ID: <3EBACEF8.3060208@zytor.com>
Thomas J. Merritt wrote:
>
> Switching between long-mode with interrupts disabled and protected-mode
> with paging-off and interrupts disabled isn't too difficult. Switching
> between long-mode with interrupts enabled and protected-mode with
> paging-on and interrupts enabled will be a lot more fun. The first
> works just fine in SmartFirmware, the later would be necessary to
> make use of the legacy modes in an operating system. I expect that
> eventually someone will write the code to prove that it is possible to
> do.
>
The basic principle of any of this is that you have to set up interrupt
handling thunks in the "guest mode"; those interrupt thunks then invoke
a transition code and then invokes the interrupt handler in the "target
mode". It's slow as hell and tricky to get right, but it's quite
doable; this is for example how you'd make a 32-bit bootloader allow the
BIOS to take interrupts.
-hpa
From cloos at jhcloos.com Thu May 8 23:47:25 2003
From: cloos at jhcloos.com (James H. Cloos Jr.)
Date: 08 May 2003 17:47:25 -0400
Subject: [discuss] gcc
In-Reply-To: <20030507210228.GA2877@Wotan.suse.de>
References:
<200305072002.10882.arnd@arndb.de>
<20030507210228.GA2877@Wotan.suse.de>
Message-ID:
>>>>> "Andi" == Andi Kleen writes:
Andi> [the biarch patch for gcc] will make your 32bit gcc a lot slower
Andi> though. The amd64 gcc does many things internally with 64bit
Andi> long long instead of 32bit long, and gcc generates significantly
Andi> worse code for long long on 32bit than for 32bit long. This
Andi> slows it down.
Does the biarch patch -- or the amd64 version in general -- compile
separate cc1{,obj,plus} f771 and jc1 binaries for each target, or
does a single binary do for both?
If the biarch only uses 64-bit ints for -m64 then there is no need to
worry about a slowdown. Since the frontend can choose which backends
to run based on the -m switches, such a division should be feasible.
-JimC
From arnd at arndb.de Thu May 8 23:56:07 2003
From: arnd at arndb.de (Arnd Bergmann)
Date: Thu, 8 May 2003 23:56:07 +0200
Subject: [discuss] gcc
In-Reply-To:
References: <20030507210228.GA2877@Wotan.suse.de>
Message-ID: <200305082356.07081.arnd@arndb.de>
On Thursday 08 May 2003 23:47, James H. Cloos Jr. wrote:
> Does the biarch patch -- or the amd64 version in general -- compile
> separate cc1{,obj,plus} f771 and jc1 binaries for each target, or
> does a single binary do for both?
>
> If the biarch only uses 64-bit ints for -m64 then there is no need to
> worry about a slowdown. Since the frontend can choose which backends
> to run based on the -m switches, such a division should be feasible.
No, there is only one backend per language in the biarch compiler, the
-m64 switch handed through to the backend.
Arnd <><
From ak at suse.de Fri May 9 04:50:37 2003
From: ak at suse.de (Andi Kleen)
Date: Fri, 9 May 2003 04:50:37 +0200
Subject: [discuss] DPMI on AMD64
In-Reply-To: <200305082129.h48LTvHR094831@tenor.codegen.com>
References: <200305082129.h48LTvHR094831@tenor.codegen.com>
Message-ID: <20030509025037.GE15829@Wotan.suse.de>
> Switching between long-mode with interrupts disabled and protected-mode
> with paging-off and interrupts disabled isn't too difficult. Switching
I was considering doing it for Linux too now to speed up warm reboot
(important time metric during kernel development ;)
Currently it is always doing a triple fault to reboot and some of the
BIOS take an awful long time to go through POST again. There is
the "simple boot flag" spec from Microsoft for this too, but
the BIOS do not seem to support that properly.
The idea was to switch back to real mode and call some BIOS call
to do a quick reboot without POST.
Of course kexec would be even faster, but it requires much more changes
and would be harder to merge.
-Andi
From ebiederman at lnxi.com Fri May 9 05:03:47 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: 08 May 2003 21:03:47 -0600
Subject: [discuss] DPMI on AMD64
In-Reply-To: <20030509025037.GE15829@Wotan.suse.de>
References:
<200305082129.h48LTvHR094831@tenor.codegen.com>
<20030509025037.GE15829@Wotan.suse.de>
Message-ID:
Andi Kleen writes:
> > Switching between long-mode with interrupts disabled and protected-mode
> > with paging-off and interrupts disabled isn't too difficult. Switching
>
> I was considering doing it for Linux too now to speed up warm reboot
> (important time metric during kernel development ;)
>
> Currently it is always doing a triple fault to reboot and some of the
> BIOS take an awful long time to go through POST again. There is
> the "simple boot flag" spec from Microsoft for this too, but
> the BIOS do not seem to support that properly.
>
> The idea was to switch back to real mode and call some BIOS call
> to do a quick reboot without POST.
>
> Of course kexec would be even faster, but it requires much more changes
> and would be harder to merge.
You mean you haven't gotten Stefan Reinauer to give you a working LinuxBIOS
port yet?
As for kexec Andrew Morton has a version merged into his 2.5.x tree. There
is a little more work to be done for x86-64 but it should be a fairly simple
variation on the x86 version. Since you don't support a 64bit entry point yet
the user space should not be too difficult to port.
If you are interested I will see if I can make the time to work on it.
Eric
From ak at suse.de Fri May 9 05:05:43 2003
From: ak at suse.de (Andi Kleen)
Date: Fri, 9 May 2003 05:05:43 +0200
Subject: [discuss] DPMI on AMD64
In-Reply-To:
References: <200305082129.h48LTvHR094831@tenor.codegen.com> <20030509025037.GE15829@Wotan.suse.de>
Message-ID: <20030509030543.GF15829@Wotan.suse.de>
> As for kexec Andrew Morton has a version merged into his 2.5.x tree. There
> is a little more work to be done for x86-64 but it should be a fairly simple
> variation on the x86 version. Since you don't support a 64bit entry point yet
> the user space should not be too difficult to port.
>
> If you are interested I will see if I can make the time to work on it.
I would be interested for 2.5, but I cannot carry a large patchkit outside
arch/x86_64 for logistic reasons. Best would be if the main parts
are merged to Linus first.
The reboot to realmode thing would be mainly for 2.4 (where still most
development is happening) where kexec is probably not suitable.
-Andi
From ak at suse.de Fri May 9 05:23:57 2003
From: ak at suse.de (Andi Kleen)
Date: Fri, 9 May 2003 05:23:57 +0200
Subject: possible FP register leak in 2.4/2.5 x86-64
Message-ID: <20030509032357.GA30057@Wotan.suse.de>
In some obscure circumstances (lazy fp switch and a signal handler
restoring an invalid FPU state) the FPU could keep the old XMM/x87
register contents. Also in another similar circumstance the CPU could try
to restore uninitialized kernel memory. That's a security leak.
This patch fixes it.
-Andi
Index: linux/include/asm-x86_64/i387.h
===================================================================
RCS file: /home/cvs/Repository/linux/include/asm-x86_64/i387.h,v
retrieving revision 1.10
diff -u -u -r1.10 i387.h
--- linux/include/asm-x86_64/i387.h 2003/03/14 16:06:35 1.10
+++ linux/include/asm-x86_64/i387.h 2003/05/09 04:38:12
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
extern void init_fpu(struct task_struct *child);
extern int save_i387(struct _fpstate *buf);
@@ -85,6 +86,8 @@
".previous"
: [err] "=r" (err)
: [fx] "r" (fx), "0" (0));
+ if (unlikely(err))
+ init_fpu(current);
return err;
}
@@ -103,6 +106,8 @@
".previous"
: [err] "=r" (err)
: [fx] "r" (fx), "0" (0));
+ if (unlikely(err))
+ __clear_user(fx, sizeof(struct i387_fxsave_struct));
return err;
}
From hpa at zytor.com Fri May 9 05:54:01 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Thu, 08 May 2003 20:54:01 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To: <20030509025037.GE15829@Wotan.suse.de>
References: <200305082129.h48LTvHR094831@tenor.codegen.com> <20030509025037.GE15829@Wotan.suse.de>
Message-ID: <3EBB2659.4020109@zytor.com>
Andi Kleen wrote:
>>Switching between long-mode with interrupts disabled and protected-mode
>>with paging-off and interrupts disabled isn't too difficult. Switching
>
>
> I was considering doing it for Linux too now to speed up warm reboot
> (important time metric during kernel development ;)
>
> Currently it is always doing a triple fault to reboot and some of the
> BIOS take an awful long time to go through POST again. There is
> the "simple boot flag" spec from Microsoft for this too, but
> the BIOS do not seem to support that properly.
>
> The idea was to switch back to real mode and call some BIOS call
> to do a quick reboot without POST.
>
This is completely unnecessary. All you need to do is to poke in the
correct value in memory before triple-faulting. This is a standard
option in Linux/i386 already.
-hpa
From ak at suse.de Fri May 9 05:56:42 2003
From: ak at suse.de (Andi Kleen)
Date: Fri, 9 May 2003 05:56:42 +0200
Subject: [discuss] DPMI on AMD64
In-Reply-To: <3EBB2659.4020109@zytor.com>
References: <200305082129.h48LTvHR094831@tenor.codegen.com> <20030509025037.GE15829@Wotan.suse.de> <3EBB2659.4020109@zytor.com>
Message-ID: <20030509035642.GG15829@Wotan.suse.de>
> This is completely unnecessary. All you need to do is to poke in the
> correct value in memory before triple-faulting. This is a standard
> option in Linux/i386 already.
What value and where exactly ?
If you mean the simple boot flag thing that doesn't seem to work on my
test boxes.
-Andi
From hpa at zytor.com Fri May 9 06:00:38 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Thu, 08 May 2003 21:00:38 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To: <20030509035642.GG15829@Wotan.suse.de>
References: <200305082129.h48LTvHR094831@tenor.codegen.com> <20030509025037.GE15829@Wotan.suse.de> <3EBB2659.4020109@zytor.com> <20030509035642.GG15829@Wotan.suse.de>
Message-ID: <3EBB27E6.3010503@zytor.com>
Andi Kleen wrote:
>>This is completely unnecessary. All you need to do is to poke in the
>>correct value in memory before triple-faulting. This is a standard
>>option in Linux/i386 already.
>
>
> What value and where exactly ?
>
> If you mean the simple boot flag thing that doesn't seem to work on my
> test boxes.
>
No, this is something that dates back to the IBM XT.
Poke 0x1234 into physical address 0x0472.
-hpa
From ak at suse.de Fri May 9 06:05:49 2003
From: ak at suse.de (Andi Kleen)
Date: Fri, 9 May 2003 06:05:49 +0200
Subject: [discuss] DPMI on AMD64
In-Reply-To: <3EBB27E6.3010503@zytor.com>
References: <200305082129.h48LTvHR094831@tenor.codegen.com> <20030509025037.GE15829@Wotan.suse.de> <3EBB2659.4020109@zytor.com> <20030509035642.GG15829@Wotan.suse.de> <3EBB27E6.3010503@zytor.com>
Message-ID: <20030509040549.GI15829@Wotan.suse.de>
On Thu, May 08, 2003 at 09:00:38PM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >>This is completely unnecessary. All you need to do is to poke in the
> >>correct value in memory before triple-faulting. This is a standard
> >>option in Linux/i386 already.
> >
> >
> >What value and where exactly ?
> >
> >If you mean the simple boot flag thing that doesn't seem to work on my
> >test boxes.
> >
>
> No, this is something that dates back to the IBM XT.
>
> Poke 0x1234 into physical address 0x0472.
The code does this already (see arch/x86_64/kernel/process.c:machine_restart),
but all BIOS i've seen yet still did a full POST after this.
-Andi
From peter at jazz-1.trumpet.com.au Fri May 9 06:31:24 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Fri, 9 May 2003 14:31:24 +1000 (EST)
Subject: [discuss] DPMI on AMD64
In-Reply-To: <20030509040549.GI15829@Wotan.suse.de>
Message-ID:
On Fri, 9 May 2003, Andi Kleen wrote:
> On Thu, May 08, 2003 at 09:00:38PM -0700, H. Peter Anvin wrote:
> > Andi Kleen wrote:
> > >>This is completely unnecessary. All you need to do is to poke in the
> > >>correct value in memory before triple-faulting. This is a standard
> > >>option in Linux/i386 already.
> > >
> > >
> > >What value and where exactly ?
> > >
> > >If you mean the simple boot flag thing that doesn't seem to work on my
> > >test boxes.
> > >
> >
> > No, this is something that dates back to the IBM XT.
> >
> > Poke 0x1234 into physical address 0x0472.
>
> The code does this already (see arch/x86_64/kernel/process.c:machine_restart),
> but all BIOS i've seen yet still did a full POST after this.
>
> -Andi
>
triple fault does a hardware reset which most bioses would interpret as full
POST.
You have to do the above but then jump to FFFF:0 in real mode to get a warm
boot. Means getting back to real mode though - have fun :)
Peter
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From hpa at zytor.com Fri May 9 06:44:14 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Thu, 08 May 2003 21:44:14 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To:
References:
Message-ID: <3EBB321E.4090502@zytor.com>
Peter Tattam wrote:
>
> triple fault does a hardware reset which most bioses would interpret as full
> POST.
>
Triplefault should *NOT* hardware reset. If it does, it's a severe
chipset or BIOS bug (a hardware reset implies loss of caches which means
data loss.) It should be an INIT.
> You have to do the above but then jump to FFFF:0 in real mode to get a warm
> boot. Means getting back to real mode though - have fun :)
F000:FFF0 is the correct address.
-hpa
From peter at jazz-1.trumpet.com.au Fri May 9 06:57:52 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Fri, 9 May 2003 14:57:52 +1000 (EST)
Subject: [discuss] DPMI on AMD64
In-Reply-To: <3EBB321E.4090502@zytor.com>
Message-ID:
On Thu, 8 May 2003, H. Peter Anvin wrote:
> Peter Tattam wrote:
> >
> > triple fault does a hardware reset which most bioses would interpret as full
> > POST.
> >
>
> Triplefault should *NOT* hardware reset. If it does, it's a severe
> chipset or BIOS bug (a hardware reset implies loss of caches which means
> data loss.) It should be an INIT.
>
> > You have to do the above but then jump to FFFF:0 in real mode to get a warm
> > boot. Means getting back to real mode though - have fun :)
>
> F000:FFF0 is the correct address.
yes you are right. it was just off the top of my head. sorry :)
>
> -hpa
>
>
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From hpa at zytor.com Fri May 9 06:59:06 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Thu, 08 May 2003 21:59:06 -0700
Subject: [discuss] DPMI on AMD64
In-Reply-To:
References:
Message-ID: <3EBB359A.8090907@zytor.com>
Peter Tattam wrote:
>>
>>F000:FFF0 is the correct address.
>
> yes you are right. it was just off the top of my head. sorry :)
>
However, the fact still remains that properly functioning BIOSes should
handle INIT the same way (as a soft restart.)
-hpa
From ak at suse.de Fri May 9 07:13:36 2003
From: ak at suse.de (Andi Kleen)
Date: Fri, 9 May 2003 07:13:36 +0200
Subject: x86_64-2.5.69-2 - bugfix release and IOMMU tunings
Message-ID: <20030509051336.GJ15829@Wotan.suse.de>
I was a productive bunny and fixed quite a lot of bugs in 2.5.69.
Result is in:
ftp://ftp.x86-64.org/pub/linux/v2.5/x86_64-2.5.69-2.bz2
c0e89ecc2c1a23cfccefe5e31bcef3b2 x86_64-2.5.69-2.bz2
The biggest change is that the "bad page state" crash on shutdown on
IOMMU machines is gone now. Also I implemented the long planned
IOMMU optimization of only flushing the GART when the IOMMU area
wraps. I haven't benchmarked it yet, but the old code had a 10-15%
overhead for network traffic. I expect this to be much smaller now.
The change allowed some other cleanups and speedups in the IOMMU code.
I would be interested in feedback on this.
Two potential security fixes.
Also some bug fixes from 2.4 forward ported (others still missing)
As usual see ftp://ftp.x86-64.org/pub/linux/v2.5/RELEASE-NOTES for the
bug list. I also filed most of them into http://bugzilla.kernel.org
now, which can be queried for component x86-64.
Full changelog:
- IOMMU tuning: only flush the GART TLB when the IOMMU aperture area allocation
wraps. Also don't clear entries until needed.
This should increase IO performance for IOMMU devices greatly.
Still a bit experimental, handle with care.
- Unmap the IOMMU aperture from kernel mapping to prevent unwanted CPU prefetches
- Make IOMMU_LEAK_TRACE depend on IOMMU_DEBUG
- Fix minor bug in pci_alloc_consistent - always check against the dma mask
of the device, not 0xffffffff.
- Remove streamining mapping delayed flush in IOMMU: not needed anymore and
didn't work correctly in 2.5 anyways.
- Fix the bad pte warnings caused by the SMP/APIC bootup.
- Forward port 2.4 fix: ioperm was changing the wrong io ports in some cases.
- Minor cleanups
- Some cleanups in pageattr.c (still buggy)
- Fix some bugs in the AGP driver.
- Forward port from 2.4: mask all reserved bits in debug register in ptrace.
Previously gdb could crash the kernel by passing invalid values.
- Security fix: make sure FPU is in a defined state after an FXSAVE/FXRSTOR
exception occurred.
- Eats keys on panic (works around a buggy KVM)
- Make user.h user includeable.
-Andi
From ak at suse.de Fri May 9 08:49:54 2003
From: ak at suse.de (Andi Kleen)
Date: Fri, 9 May 2003 08:49:54 +0200
Subject: [discuss] Re: discuss Digest 9 May 2003 05:49:46 -0000 Issue 317
In-Reply-To: <20030509060242.87728.qmail@web20902.mail.yahoo.com>
References: <1052459386.5399.ezmlm@x86-64.org> <20030509060242.87728.qmail@web20902.mail.yahoo.com>
Message-ID: <20030509064954.GM15829@Wotan.suse.de>
On Thu, May 08, 2003 at 11:02:42PM -0700, Byrd Kernel wrote:
> > From: "H. Peter Anvin"
> >
> > While we're on this subject, I would really like AMD to lean on BIOS
> > people to support INT 15h AX=2401h (enable A20), and if the A20 gate is
> > supported at all also support INT 15h AX=2400h (disable A20).
> (snip)
>
> While we're at it, how about the entire AX=24__h series of functions? I know
> it'd make my life easier.
Rule number #1: never trust the BIOS. If you started using them you
would surely find some BIOS on some obscure machine that crashes as
soon as you call any of this ("because windows 95 does not use this")
-Andi
From ebiederman at lnxi.com Fri May 9 09:25:43 2003
From: ebiederman at lnxi.com (Eric W. Biederman)
Date: 09 May 2003 01:25:43 -0600
Subject: [discuss] Re: discuss Digest 9 May 2003 05:49:46 -0000 Issue 317
In-Reply-To: <20030509060242.87728.qmail@web20902.mail.yahoo.com>
References: <20030509060242.87728.qmail@web20902.mail.yahoo.com>
Message-ID:
Byrd Kernel writes:
> > From: "H. Peter Anvin"
> >
> > While we're on this subject, I would really like AMD to lean on BIOS
> > people to support INT 15h AX=2401h (enable A20), and if the A20 gate is
> > supported at all also support INT 15h AX=2400h (disable A20).
> (snip)
>
> While we're at it, how about the entire AX=24__h series of functions? I know
> it'd make my life easier.
>
> >From RBIL (Ralf Brown's Interrupt List):
> AX = 2400h - DISABLE A20 GATE
> AX = 2401h - ENABLE A20 GATE
> AX = 2402h - GET A20 GATE STATUS
> AX = 2403h - QUERY A20 GATE SUPPORT
If you want a BIOS that works there is one very reliable solution.
Work on ADLO (aka the bochs BIOS fixed to work under LinuxBIOS).
And the port LinuxBIOS to the boards you care about.
Or at least present it to motherboard manufactures as a solution.
Sure it's a compatibility layer. But there is no reason we can't
do an OS/2 and create a better BIOS than the BIOS manufacturers.
Eric
From aj at suse.de Fri May 9 09:26:32 2003
From: aj at suse.de (Andreas Jaeger)
Date: Fri, 09 May 2003 09:26:32 +0200
Subject: [discuss] Can you explain lib + lib64 glibc installation?
In-Reply-To: <200305090054.03932.andrebalsa@mailingaddress.org> (Andrew
Derrick Balsa's message of "Fri, 9 May 2003 00:54:03 +0800")
References: <200305090054.03932.andrebalsa@mailingaddress.org>
Message-ID:
Andrew Derrick Balsa writes:
> Hi,
>
> Thank you, Andreas. I followed your advice and it seems I am getting there:
> readelf produces the desired result.
>
> I had to copy the files manually, though, to my bochs disk image, and it seems
> some files in my Mandrake setup got hosed in the process... :o(
>
> Two more questions:
> 1) What should /etc/ld.so.conf look like for a mixed 32/64 bit system?
Parts of mine are:
/lib64
/lib
/usr/lib64
/usr/lib
/usr/local/lib64
/usr/openwin/lib64
/opt/kde/lib64
/opt/kde2/lib64
/opt/kde3/lib64
/opt/gnome/lib64
/opt/gnome2/lib64
ldconfig and ld.so know about 32-bit and 64-bit libraries:
$ /sbin/ldconfig -p |grep libc.so
libc.so.6 (libc6,x86-64, OS ABI: Linux 2.4.1) => /lib64/libc.so.6
libc.so.6 (libc6, OS ABI: Linux 2.2.5) => /lib/libc.so.6
> 2) If I decide to only run 64-bit executables, can I just get rid of the /lib
> and/usr/lib directories, or should something always be there?
/lib/modules exists on my system - and some non-library files are
always installed in /usr/lib. So, you can get rid of the libs in
there but I would look at the rest before deleting it,
Andreas
--
Andreas Jaeger
SuSE Labs aj at suse.de
private aj at arthur.inka.de
http://www.suse.de/~aj
From aj at suse.de Fri May 9 09:28:18 2003
From: aj at suse.de (Andreas Jaeger)
Date: Fri, 09 May 2003 09:28:18 +0200
Subject: [discuss] gcc
In-Reply-To: (James H. Cloos, Jr.'s
message of "08 May 2003 17:47:25 -0400")
References:
<200305072002.10882.arnd@arndb.de>
<20030507210228.GA2877@Wotan.suse.de>
Message-ID:
"James H. Cloos Jr." writes:
>>>>>> "Andi" == Andi Kleen writes:
>
> Andi> [the biarch patch for gcc] will make your 32bit gcc a lot slower
> Andi> though. The amd64 gcc does many things internally with 64bit
> Andi> long long instead of 32bit long, and gcc generates significantly
> Andi> worse code for long long on 32bit than for 32bit long. This
> Andi> slows it down.
>
> Does the biarch patch -- or the amd64 version in general -- compile
> separate cc1{,obj,plus} f771 and jc1 binaries for each target, or
> does a single binary do for both?
A common binary for both architectures,
Andreas
--
Andreas Jaeger
SuSE Labs aj at suse.de
private aj at arthur.inka.de
http://www.suse.de/~aj
From antoine64leca at hotmail.com Fri May 9 11:09:48 2003
From: antoine64leca at hotmail.com (Antoine Leca)
Date: Fri, 9 May 2003 11:09:48 +0200
Subject: [discuss] DPMI on AMD64
References: <3EBB321E.4090502@zytor.com>
Message-ID:
H. Peter Anvin wrote:
> Peter Tattam wrote:
> > You have to do the above but then jump to FFFF:0 in real mode to get a
warm
> > boot. Means getting back to real mode though - have fun :)
>
> F000:FFF0 is the correct address.
Well, FFFF:0 was the correct address back at XT times (which is the
version of the API we are talking about). For example, it is implemented
in almost any KEYBxx driver before IBM DOS 3.3, to handle Ctrl-Alt-Del.
And for compatibility reasons, any AT bios is forced to handle it
with a far jump (instead of a relative jump below in memory), which
has the net effect to purge instantaneously the CS cache, and
to clear the upper bits if doing a processor RESET.
Antoine
From ak at suse.de Fri May 9 11:24:45 2003
From: ak at suse.de (Andi Kleen)
Date: Fri, 9 May 2003 11:24:45 +0200
Subject: [discuss] DPMI on AMD64
In-Reply-To:
References: <3EBB321E.4090502@zytor.com>
Message-ID: <20030509092445.GC5463@Wotan.suse.de>
> Well, FFFF:0 was the correct address back at XT times (which is the
> version of the API we are talking about). For example, it is implemented
> in almost any KEYBxx driver before IBM DOS 3.3, to handle Ctrl-Alt-Del.
32bit Linux uses ffff:0 for reboot=w. Is that wrong ?
-andi
From davej at suse.de Fri May 9 13:34:57 2003
From: davej at suse.de (Dave Jones)
Date: Fri, 9 May 2003 13:34:57 +0200
Subject: [discuss] x86_64-2.5.69-2 - bugfix release and IOMMU tunings
In-Reply-To: <20030509051336.GJ15829@Wotan.suse.de>; from ak@suse.de on Fri, May 09, 2003 at 07:13:36AM +0200
References: <20030509051336.GJ15829@Wotan.suse.de>
Message-ID: <20030509133457.A19972@suse.de>
On Fri, May 09, 2003 at 07:13:36AM +0200, Andi Kleen wrote:
> ftp://ftp.x86-64.org/pub/linux/v2.5/x86_64-2.5.69-2.bz2
>
> Full changelog:
> - Fix some bugs in the AGP driver.
Please don't push this bit to Linus, the first bug was already fixed
differently in the agpgart tree, and I've just added a variant on your
second fix there too.
I've already asked Linus to pull from the agpgart bk tree, so they
should turn up in mainline sometime soon.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
From antoine64leca at hotmail.com Fri May 9 14:10:03 2003
From: antoine64leca at hotmail.com (Antoine Leca)
Date: Fri, 9 May 2003 14:10:03 +0200
Subject: [discuss] DPMI on AMD64
References: <3EBB321E.4090502@zytor.com> <20030509092445.GC5463@Wotan.suse.de>
Message-ID:
Andi Kleen wrote:
> > Well, FFFF:0 was the correct address back at XT times (which is the
> > version of the API we are talking about). For example, it is implemented
> > in almost any KEYBxx driver before IBM DOS 3.3, to handle Ctrl-Alt-Del.
>
> 32bit Linux uses ffff:0 for reboot=w. Is that wrong ?
Well, as I wrote, it would work, becaquse of backward compatibility.
But it better have to be 0xF000:0xFFF0 to be in line with
Intel/AMD's specs, as showed correctly Peter earlier
(since of course Linux needs a 80386 or better).
Antoine
From ak at suse.de Fri May 9 17:05:57 2003
From: ak at suse.de (Andi Kleen)
Date: Fri, 9 May 2003 17:05:57 +0200
Subject: Warm reboot for x86-64 linux
Message-ID: <20030509150557.GA6010@Wotan.suse.de>
Following the discussions yesterday in the "DPMI" thread I implemented
warm reboot now. It switches from long mode to real mode using a mix
of the procedures recommended by AMD and Intel in the x86-64 and IA32
architecture manuals.
It seems to work here - the BIOS still does a few long winded things, but
at least skips the memory checking now.
It's off by default similar to 32bit linux, but can be enabled by booting
with reboot=warm
I used 0xffff:0x0000 for now as reboot vector.
Only tested on a single machine.
Also includes some cleanups/fixes for the SMP reboot.
Comments/Feedback welcome.
-Andi
Index: linux/arch/x86_64/kernel/Makefile
===================================================================
RCS file: /home/cvs/Repository/linux/arch/x86_64/kernel/Makefile,v
retrieving revision 1.24
diff -u -u -r1.24 Makefile
--- linux/arch/x86_64/kernel/Makefile 2002/09/12 12:50:51 1.24
+++ linux/arch/x86_64/kernel/Makefile 2003/05/09 16:12:14
@@ -20,7 +20,7 @@
obj-y := process.o semaphore.o signal.o entry.o traps.o irq.o \
ptrace.o i8259.o ioport.o ldt.o setup.o time.o sys_x86_64.o \
pci-dma.o x8664_ksyms.o i387.o syscall.o vsyscall.o \
- setup64.o acpitable.o e820.o
+ setup64.o acpitable.o e820.o warmreboot.o
ifdef CONFIG_PCI
obj-y += pci-x86_64.o
Index: linux/arch/x86_64/kernel/head.S
===================================================================
RCS file: /home/cvs/Repository/linux/arch/x86_64/kernel/head.S,v
retrieving revision 1.55
diff -u -u -r1.55 head.S
--- linux/arch/x86_64/kernel/head.S 2003/02/11 12:29:15 1.55
+++ linux/arch/x86_64/kernel/head.S 2003/05/09 16:12:14
@@ -340,7 +340,7 @@
.align 64 /* cacheline aligned, keep this synchronized with asm/desc.h */
ENTRY(gdt_table)
.quad 0x0000000000000000 /* This one is magic */
- .quad 0x0000000000000000 /* unused */
+ .quad 0x00af9a000000ffff ^ (1<<21) /* __KERNEL_COMPAT32_CS */
.quad 0x00af9a000000ffff /* __KERNEL_CS */
.quad 0x00cf92000000ffff /* __KERNEL_DS */
.quad 0x00cffe000000ffff /* __USER32_CS */
Index: linux/arch/x86_64/kernel/process.c
===================================================================
RCS file: /home/cvs/Repository/linux/arch/x86_64/kernel/process.c,v
retrieving revision 1.65
diff -u -u -r1.65 process.c
--- linux/arch/x86_64/kernel/process.c 2003/04/26 01:10:55 1.65
+++ linux/arch/x86_64/kernel/process.c 2003/05/09 16:12:15
@@ -159,34 +159,15 @@
__setup("idle=", idle_setup);
static long no_idt[3];
-static int reboot_mode;
+static int flag_warm_reboot;
-#ifdef CONFIG_SMP
-int reboot_smp = 0;
-static int reboot_cpu = -1;
-#endif
static int __init reboot_setup(char *str)
{
while(1) {
switch (*str) {
case 'w': /* "warm" reboot (no memory testing etc) */
- reboot_mode = 0x1234;
- break;
- case 'c': /* "cold" reboot (with memory testing etc) */
- reboot_mode = 0x0;
- break;
-#ifdef CONFIG_SMP
- case 's': /* "smp" reboot by executing reset on BSP or other CPU*/
- reboot_smp = 1;
- if (isdigit(str[1]))
- sscanf(str+1, "%d", &reboot_cpu);
- else if (!strncmp(str,"smp",3))
- sscanf(str+3, "%d", &reboot_cpu);
- /* we will leave sorting out the final value
- when we are ready to reboot, since we might not
- have set up boot_cpu_id or smp_num_cpu */
+ flag_warm_reboot = 1;
break;
-#endif
}
if((str = strchr(str,',')) != NULL)
str++;
@@ -198,6 +179,35 @@
__setup("reboot=", reboot_setup);
+/* overwrites random kernel memory. Should not be kernel .text */
+#define WARMBOOT_TRAMP 0x1000UL
+
+void reboot_warm(void)
+{
+ extern unsigned char warm_reboot[], warm_reboot_end[];
+ printk("warm reboot\n");
+
+ __cli();
+
+ /* restore identity mapping */
+ init_level4_pgt[0] = __pml4(__pa(level3_ident_pgt) | 7);
+ __flush_tlb_all();
+
+ /* yes we want warm reboot */
+ *((unsigned short *)0x472) = 0x1234;
+
+ memcpy(__va(WARMBOOT_TRAMP), warm_reboot, warm_reboot_end - warm_reboot);
+
+ asm volatile( " pushq $0\n" /* ss */
+ " pushq $0x2000\n" /* rsp */
+ " pushfq\n" /* eflags */
+ " pushq %[cs]\n"
+ " pushq %[target]\n"
+ " iretq" ::
+ [cs] "i" (__KERNEL_COMPAT32_CS),
+ [target] "b" (WARMBOOT_TRAMP));
+}
+
static inline void kb_wait(void)
{
int i;
@@ -210,47 +220,37 @@
void machine_restart(char * __unused)
{
#if CONFIG_SMP
- int cpuid;
-
- cpuid = GET_APIC_ID(apic_read(APIC_ID));
-
- if (reboot_smp) {
-
- /* check to see if reboot_cpu is valid
- if its not, default to the BSP */
- if ((reboot_cpu == -1) ||
- (reboot_cpu > (NR_CPUS -1)) ||
- !(phys_cpu_present_map & (1<
+
+#define R(x) x-warm_reboot(%ebx)
+#define R64(x) x-warm_reboot(%rbx)
+
+ /* running in identity mapping and in the first 64k of memory
+ and in compatibility mode. This must be position independent */
+
+ /* Follows 14.7 "Leaving Long Mode" in the AMD x86-64 manual, volume 2
+ and 8.9.2 "Switching Back to Real-Address Mode" in the Intel IA32
+ manual, volume 2 */
+
+ /* ebx: self pointer to warm_reboot */
+
+ .globl warm_reboot
+warm_reboot:
+ addl %ebx, R64(real_mode_desc) /* relocate tables */
+ addl %ebx,2+R64(warm_gdt_desc)
+
+ movq %cr0,%rax
+ btr $31,%rax
+ movq %rax,%cr0 /* disable paging */
+ jmp 1f /* flush prefetch queue */
+
+ .code32
+1: movl $MSR_EFER,%ecx
+ rdmsr
+ andl $~((1<
References: <200305090054.03932.andrebalsa@mailingaddress.org>
Message-ID:
>>>>> "Andreas" == Andreas Jaeger writes:
Andreas> Parts of mine are:
Andreas> /lib64
Andreas> /lib
Andreas> /usr/lib64
Andreas> /usr/lib
It's too bad ld.so.conf cannot take globs or regexen.
Using ?/lib{,64} would simplify things, yes?
-JimC
From aj at suse.de Fri May 9 17:55:24 2003
From: aj at suse.de (Andreas Jaeger)
Date: Fri, 09 May 2003 17:55:24 +0200
Subject: [discuss] Can you explain lib + lib64 glibc installation?
In-Reply-To: (James H. Cloos, Jr.'s
message of "09 May 2003 11:29:41 -0400")
References: <200305090054.03932.andrebalsa@mailingaddress.org>
Message-ID:
"James H. Cloos Jr." writes:
>>>>>> "Andreas" == Andreas Jaeger writes:
>
> Andreas> Parts of mine are:
> Andreas> /lib64
> Andreas> /lib
> Andreas> /usr/lib64
> Andreas> /usr/lib
>
> It's too bad ld.so.conf cannot take globs or regexen.
> Using ?/lib{,64} would simplify things, yes?
It might but then it could also add /home/aj/lib64/libc.so.6 and if
that one would be used instead of the default glibc, we would have a
security hole. So, better to list every path directly and know what's
needed.
But ldconfig is part of glibc and comes with source, so you can extend
it,
Andreas
--
Andreas Jaeger
SuSE Labs aj at suse.de
private aj at arthur.inka.de
http://www.suse.de/~aj
From alangrimes at starpower.net Fri May 9 21:04:29 2003
From: alangrimes at starpower.net (Alan Grimes)
Date: Fri, 09 May 2003 12:04:29 -0700
Subject: [discuss] DPMI on AMD64 -- Callbacks...
References: <3EBB321E.4090502@zytor.com> <20030509092445.GC5463@Wotan.suse.de>
Message-ID: <3EBBFBBD.504C63EC@starpower.net>
It seems that many of you are missing the point of realmode callbacks...
The only reason to implement them is when you are running 32-bit code in
a 16-bit environment.
If Linux were DOS, a linux extender would implement an in80 callback....
There is absolutly no reason at all why the int21h interfaces couldn't
be implemented directly in 32-bit mode (or any other mode for that
matter..)
As for the problem of mixed-code apps, that is a concern though they are
probably rare... (I hope -- there's no easy way to test this...)
--
Having never read a manual, it takes less effort to hack something
togeather with www.squeak.org than it does with C++ and five books.
http://users.rcn.com/alangrimes/
From antoine64leca at hotmail.com Fri May 9 19:48:09 2003
From: antoine64leca at hotmail.com (Antoine Leca)
Date: Fri, 9 May 2003 19:48:09 +0200
Subject: [discuss] DPMI on AMD64 -- Callbacks...
References: <3EBB321E.4090502@zytor.com> <20030509092445.GC5463@Wotan.suse.de> <3EBBFBBD.504C63EC@starpower.net>
Message-ID:
Alan Grimes wrote:
> It seems that many of you are missing the point of realmode callbacks...
>
> The only reason to implement them is when you are running 32-bit code in
> a 16-bit environment.
Or 16-bit PM code in a 16-bit real mode environment (which is the point
H. Peter Anvin is trying to make these days: RM != PM)
Or even 64-bit code in a 16-bit, real mode, environment (why not
dreaming? after all, Ghost is still a DOS product... and yes I know
about EtherBoot etc.)
> There is absolutly no reason at all why the int21h interfaces couldn't
> be implemented directly in 32-bit mode (or any other mode for that
> matter..)
Except if DOS need _any_ driver that run in real mode and that
you do not want to/cannot emulate.
This point is very well explained in Andrew Schulman's
"Unauthorized Windows 95": between Windows for Workgroups 3.11
and Windows 95, MS *added* more support for the code running
in real mode (called via callbacks), in order to deal with compatibility
issues created by some TSR that was not "called" from the VMM.
(This is why there is the IFSHLP.SYS driver, if you did ask yourself
for it, by the way).
If the problem is to run an ordinary app, such as for example
Lotus 1-2-3, then of course there are no problems. But you are
not seeking to use 16-bit DOS to run such an app, are you?
(Old) games, which OTOH are a large part of the use, neither need
very much help. That is a good point.
But there are other uses, like the need to run an old app that was
licensed code-only, is not maintained any more, and is used to
drive this strange machine at the 2nd row in the mechanical room...
If you have dealt with Y2K problems, you know what I mean!
And this class of devices do require some sort of TSR driver
support and low-level support...
> As for the problem of mixed-code apps, that is a concern though they
> are probably rare... (I hope -- there's no easy way to test this...)
I agree (from the beginning) that mixed-code apps are not the
biggest problem. Which is why I advocate to replace (i.e. to have
equivalent code running in the native environment) as much as
possible the runtime "below" the extended application, rather
than to have to run it under RM emulation/simulation. More or
less this seems to be the same as you are proposing.
Antoine
From hpa at zytor.com Fri May 9 20:04:36 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 9 May 2003 11:04:36 -0700
Subject: [discuss] DPMI on AMD64
References: <3EBB321E.4090502@zytor.com>
Message-ID:
Followup to:
By author: "Antoine Leca"
In newsgroup: linux.ports.x86-64.discuss
> >
> > F000:FFF0 is the correct address.
>
> Well, FFFF:0 was the correct address back at XT times (which is the
> version of the API we are talking about). For example, it is implemented
> in almost any KEYBxx driver before IBM DOS 3.3, to handle Ctrl-Alt-Del.
>
Nope. F000:FFF0 was always the correct address. However, because a
number of people including yourself has this incorrect, there is a far
jump at that address (and because some other people used the address
it jumped *to*, the far jump always points to the same address.)
> And for compatibility reasons, any AT bios is forced to handle it
> with a far jump (instead of a relative jump below in memory), which
> has the net effect to purge instantaneously the CS cache, and
> to clear the upper bits if doing a processor RESET.
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From hpa at zytor.com Fri May 9 20:05:51 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 9 May 2003 11:05:51 -0700
Subject: [discuss] Re: discuss Digest 9 May 2003 05:49:46 -0000 Issue 317
References: <1052459386.5399.ezmlm@x86-64.org> <20030509060242.87728.qmail@web20902.mail.yahoo.com>
Message-ID:
Followup to: <20030509060242.87728.qmail at web20902.mail.yahoo.com>
By author: Byrd Kernel
In newsgroup: linux.ports.x86-64.discuss
>
> > From: "H. Peter Anvin"
> >
> > While we're on this subject, I would really like AMD to lean on BIOS
> > people to support INT 15h AX=2401h (enable A20), and if the A20 gate is
> > supported at all also support INT 15h AX=2400h (disable A20).
> (snip)
>
> While we're at it, how about the entire AX=24__h series of functions? I know
> it'd make my life easier.
>
> From RBIL (Ralf Brown's Interrupt List):
> AX = 2400h - DISABLE A20 GATE
> AX = 2401h - ENABLE A20 GATE
> AX = 2402h - GET A20 GATE STATUS
> AX = 2403h - QUERY A20 GATE SUPPORT
>
Absolutely, but 2401h is absolutely crucial.
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From cloos at jhcloos.com Fri May 9 20:07:45 2003
From: cloos at jhcloos.com (James H. Cloos Jr.)
Date: 09 May 2003 14:07:45 -0400
Subject: [discuss] Can you explain lib + lib64 glibc installation?
In-Reply-To:
References: <200305090054.03932.andrebalsa@mailingaddress.org>
Message-ID:
>>>>> "Andreas" == Andreas Jaeger writes:
>> Using ?/lib{,64} would simplify things, yes?
Andreas> It might but then it could also add /home/aj/lib64/libc.so.6
Appologies for the confusion. I did not mean having ? itself in the
file, but was only using it as shorthand for the email?.
So, something like:
/lib{,64}
/usr{,/local,/X11}/lib{,64}
/opt/lib{,64}
plus other explicit paths. Paths like /home/aj/lib64 would only be
searched if explicitly specified in the file.
Of course, given a minute to think about it, automation in the editor
is probably better?.
-Jimc
From hpa at zytor.com Fri May 9 20:08:43 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 9 May 2003 11:08:43 -0700
Subject: [discuss] Re: discuss Digest 9 May 2003 05:49:46 -0000 Issue 317
References: <1052459386.5399.ezmlm@x86-64.org> <20030509060242.87728.qmail@web20902.mail.yahoo.com> <20030509064954.GM15829@Wotan.suse.de>
Message-ID:
Followup to: <20030509064954.GM15829 at Wotan.suse.de>
By author: Andi Kleen
In newsgroup: linux.ports.x86-64.discuss
>
> On Thu, May 08, 2003 at 11:02:42PM -0700, Byrd Kernel wrote:
> > > From: "H. Peter Anvin"
> > >
> > > While we're on this subject, I would really like AMD to lean on BIOS
> > > people to support INT 15h AX=2401h (enable A20), and if the A20 gate is
> > > supported at all also support INT 15h AX=2400h (disable A20).
> > (snip)
> >
> > While we're at it, how about the entire AX=24__h series of functions? I know
> > it'd make my life easier.
>
> Rule number #1: never trust the BIOS. If you started using them you
> would surely find some BIOS on some obscure machine that crashes as
> soon as you call any of this ("because windows 95 does not use this")
>
**** BZZZZT ****
Rule #2: Trusting the BIOS is a lot better than trusting the board
manufacturer.
Rule #3: REALLY don't trust the BIOS to do the right thing (think
suspend here) when you have mucked with the hardware yourself.
Linux has been using INT 15h AX=24xxh preferrentially for about two
years now, and we have had much fewer failures than we had before.
INT 15h AX=24xxh seem to either not be supported at all (and return
failure) or supported correctly.
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From hpa at zytor.com Fri May 9 20:09:24 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 9 May 2003 11:09:24 -0700
Subject: [discuss] Warm reboot for x86-64 linux
References: <20030509150557.GA6010@Wotan.suse.de>
Message-ID:
Followup to: <20030509150557.GA6010 at Wotan.suse.de>
By author: Andi Kleen
In newsgroup: linux.ports.x86-64.discuss
>
>
> Following the discussions yesterday in the "DPMI" thread I implemented
> warm reboot now. It switches from long mode to real mode using a mix
> of the procedures recommended by AMD and Intel in the x86-64 and IA32
> architecture manuals.
>
> It seems to work here - the BIOS still does a few long winded things, but
> at least skips the memory checking now.
>
> It's off by default similar to 32bit linux, but can be enabled by booting
> with reboot=warm
>
> I used 0xffff:0x0000 for now as reboot vector.
>
It should be 0xf000:0xfff0.
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From pavel at suse.cz Fri May 9 20:31:30 2003
From: pavel at suse.cz (Pavel Machek)
Date: Fri, 9 May 2003 20:31:30 +0200
Subject: ioctl32: more preparations
Message-ID: <20030509183130.GA1111@elf.ucw.cz>
Hi!
This does some more preparations before moving to common code: it
turns all types into they compat_XXX counterparts. Please apply,
Pavel
--- linux.clean/arch/x86_64/ia32/ia32_ioctl.c 2003-05-09 13:00:01.000000000 -0700
+++ linux/arch/x86_64/ia32/ia32_ioctl.c 2003-05-09 12:42:12.000000000 -0700
@@ -159,10 +159,10 @@
}
struct video_tuner32 {
- s32 tuner;
- u8 name[32];
- u32 rangelow, rangehigh;
- u32 flags;
+ compat_int_t tuner;
+ char name[32];
+ compat_ulong_t rangelow, rangehigh;
+ u32 flags; /* It is really u32 in videodev.h */
u16 mode, signal;
};
@@ -199,8 +199,8 @@
}
struct video_buffer32 {
- /* void * */ u32 base;
- s32 height, width, depth, bytesperline;
+ compat_caddr_t base;
+ compat_int_t height, width, depth, bytesperline;
};
static int get_video_buffer32(struct video_buffer *kp, struct video_buffer32 *up)
@@ -231,14 +231,14 @@
}
struct video_clip32 {
- s32 x, y, width, height;
- /* struct video_clip32 * */ u32 next;
+ s32 x, y, width, height; /* Its really s32 in videodev.h */
+ compat_caddr_t next;
};
struct video_window32 {
u32 x, y, width, height, chromakey, flags;
- /* struct video_clip32 * */ u32 clips;
- s32 clipcount;
+ compat_caddr_t clips;
+ compat_int_t clipcount;
};
static void free_kvideo_clips(struct video_window *kp)
@@ -417,8 +417,8 @@
}
struct ifmap32 {
- u32 mem_start;
- u32 mem_end;
+ compat_ulong_t mem_start;
+ compat_ulong_t mem_end;
unsigned short base_addr;
unsigned char irq;
unsigned char dma;
@@ -438,17 +438,18 @@
struct sockaddr ifru_netmask;
struct sockaddr ifru_hwaddr;
short ifru_flags;
- int ifru_ivalue;
- int ifru_mtu;
+ compat_int_t ifru_ivalue;
+ compat_int_t ifru_mtu;
struct ifmap32 ifru_map;
char ifru_slave[IFNAMSIZ]; /* Just fits the size */
char ifru_newname[IFNAMSIZ];
compat_caddr_t ifru_data;
+ /* XXXX? ifru_settings should be here */
} ifr_ifru;
};
struct ifconf32 {
- int ifc_len; /* size of buffer */
+ compat_int_t ifc_len; /* size of buffer */
compat_caddr_t ifcbuf;
};
@@ -874,23 +875,23 @@
struct fb_fix_screeninfo32 {
char id[16];
compat_caddr_t smem_start;
- __u32 smem_len;
- __u32 type;
- __u32 type_aux;
- __u32 visual;
- __u16 xpanstep;
- __u16 ypanstep;
- __u16 ywrapstep;
- __u32 line_length;
+ u32 smem_len;
+ u32 type;
+ u32 type_aux;
+ u32 visual;
+ u16 xpanstep;
+ u16 ypanstep;
+ u16 ywrapstep;
+ u32 line_length;
compat_caddr_t mmio_start;
- __u32 mmio_len;
- __u32 accel;
- __u16 reserved[3];
+ u32 mmio_len;
+ u32 accel;
+ u16 reserved[3];
};
struct fb_cmap32 {
- __u32 start;
- __u32 len;
+ u32 start;
+ u32 len;
compat_caddr_t red;
compat_caddr_t green;
compat_caddr_t blue;
@@ -1028,11 +1029,11 @@
}
struct floppy_struct32 {
- unsigned int size;
- unsigned int sect;
- unsigned int head;
- unsigned int track;
- unsigned int stretch;
+ compat_uint_t size;
+ compat_uint_t sect;
+ compat_uint_t head;
+ compat_uint_t track;
+ compat_uint_t stretch;
unsigned char gap;
unsigned char rate;
unsigned char spec1;
@@ -1042,51 +1043,51 @@
struct floppy_drive_params32 {
char cmos;
- u32 max_dtr;
- u32 hlt;
- u32 hut;
- u32 srt;
- u32 spinup;
- u32 spindown;
+ compat_ulong_t max_dtr;
+ compat_ulong_t hlt;
+ compat_ulong_t hut;
+ compat_ulong_t srt;
+ compat_ulong_t spinup;
+ compat_ulong_t spindown;
unsigned char spindown_offset;
unsigned char select_delay;
unsigned char rps;
unsigned char tracks;
- u32 timeout;
+ compat_ulong_t timeout;
unsigned char interleave_sect;
struct floppy_max_errors max_errors;
char flags;
char read_track;
short autodetect[8];
- int checkfreq;
- int native_format;
+ compat_int_t checkfreq;
+ compat_int_t native_format;
};
struct floppy_drive_struct32 {
signed char flags;
- u32 spinup_date;
- u32 select_date;
- u32 first_read_date;
+ compat_ulong_t spinup_date;
+ compat_ulong_t select_date;
+ compat_ulong_t first_read_date;
short probed_format;
short track;
short maxblock;
short maxtrack;
- int generation;
- int keep_data;
- int fd_ref;
- int fd_device;
- int last_checked;
+ compat_int_t generation;
+ compat_int_t keep_data;
+ compat_int_t fd_ref;
+ compat_int_t fd_device;
+ compat_int_t last_checked;
compat_caddr_t dmabuf;
- int bufblocks;
+ compat_int_t bufblocks;
};
struct floppy_fdc_state32 {
- int spec1;
- int spec2;
- int dtr;
+ compat_int_t spec1;
+ compat_int_t spec2;
+ compat_int_t dtr;
unsigned char version;
unsigned char dor;
- u32 address;
+ compat_ulong_t address;
unsigned int rawcmd:2;
unsigned int reset:1;
unsigned int need_configure:1;
@@ -1098,11 +1099,11 @@
struct floppy_write_errors32 {
unsigned int write_errors;
- u32 first_error_sector;
- int first_error_generation;
- u32 last_error_sector;
- int last_error_generation;
- unsigned int badness;
+ compat_ulong_t first_error_sector;
+ compat_int_t first_error_generation;
+ compat_ulong_t last_error_sector;
+ compat_int_t last_error_generation;
+ compat_uint_t badness;
};
#define FDSETPRM32 _IOW(2, 0x42, struct floppy_struct32)
@@ -1508,8 +1509,8 @@
}
struct sock_fprog32 {
- __u16 len;
- __u32 filter;
+ unsigned short len;
+ compat_caddr_t filter;
};
#define PPPIOCSPASS32 _IOW('t', 71, struct sock_fprog32)
@@ -1543,8 +1544,8 @@
struct ppp_option_data32 {
compat_caddr_t ptr;
- __u32 length;
- int transmit;
+ u32 length;
+ compat_int_t transmit;
};
#define PPPIOCSCOMPRESS32 _IOW('t', 77, struct ppp_option_data32)
@@ -1620,40 +1621,40 @@
struct mtget32 {
- __u32 mt_type;
- __u32 mt_resid;
- __u32 mt_dsreg;
- __u32 mt_gstat;
- __u32 mt_erreg;
+ compat_long_t mt_type;
+ compat_long_t mt_resid;
+ compat_long_t mt_dsreg;
+ compat_long_t mt_gstat;
+ compat_long_t mt_erreg;
compat_daddr_t mt_fileno;
compat_daddr_t mt_blkno;
};
#define MTIOCGET32 _IOR('m', 2, struct mtget32)
struct mtpos32 {
- __u32 mt_blkno;
+ compat_long_t mt_blkno;
};
#define MTIOCPOS32 _IOR('m', 3, struct mtpos32)
struct mtconfiginfo32 {
- __u32 mt_type;
- __u32 ifc_type;
- __u16 irqnr;
- __u16 dmanr;
- __u16 port;
- __u32 debug;
- __u32 have_dens:1;
- __u32 have_bsf:1;
- __u32 have_fsr:1;
- __u32 have_bsr:1;
- __u32 have_eod:1;
- __u32 have_seek:1;
- __u32 have_tell:1;
- __u32 have_ras1:1;
- __u32 have_ras2:1;
- __u32 have_ras3:1;
- __u32 have_qfa:1;
- __u32 pad1:5;
+ compat_long_t mt_type;
+ compat_long_t ifc_type;
+ unsigned short irqnr;
+ unsigned short dmanr;
+ unsigned short port;
+ compat_ulong_t debug;
+ compat_uint_t have_dens:1;
+ compat_uint_t have_bsf:1;
+ compat_uint_t have_fsr:1;
+ compat_uint_t have_bsr:1;
+ compat_uint_t have_eod:1;
+ compat_uint_t have_seek:1;
+ compat_uint_t have_tell:1;
+ compat_uint_t have_ras1:1;
+ compat_uint_t have_ras2:1;
+ compat_uint_t have_ras3:1;
+ compat_uint_t have_qfa:1;
+ compat_uint_t pad1:5;
char reserved[10];
};
#define MTIOCGETCONFIG32 _IOR('m', 4, struct mtconfiginfo32)
@@ -1743,25 +1744,25 @@
}
struct cdrom_read32 {
- int cdread_lba;
+ compat_int_t cdread_lba;
compat_caddr_t cdread_bufaddr;
- int cdread_buflen;
+ compat_int_t cdread_buflen;
};
struct cdrom_read_audio32 {
union cdrom_addr addr;
- u_char addr_format;
- int nframes;
- compat_caddr_t buf;
+ u8 addr_format;
+ compat_int_t nframes;
+ compat_caddr_t buf;
};
struct cdrom_generic_command32 {
- unsigned char cmd[CDROM_PACKET_SIZE];
+ unsigned char cmd[CDROM_PACKET_SIZE];
compat_caddr_t buffer;
- unsigned int buflen;
- int stat;
+ compat_uint_t buflen;
+ compat_int_t stat;
compat_caddr_t sense;
- compat_caddr_t reserved[3];
+ compat_caddr_t reserved[3]; /* Oops? it has data_direction, quiet and timeout fields? */
};
static int cdrom_ioctl_trans(unsigned int fd, unsigned int cmd, unsigned long arg)
@@ -1834,18 +1835,18 @@
}
struct loop_info32 {
- int lo_number; /* ioctl r/o */
+ compat_int_t lo_number; /* ioctl r/o */
compat_dev_t lo_device; /* ioctl r/o */
- unsigned int lo_inode; /* ioctl r/o */
+ compat_ulong_t lo_inode; /* ioctl r/o */
compat_dev_t lo_rdevice; /* ioctl r/o */
- int lo_offset;
- int lo_encrypt_type;
- int lo_encrypt_key_size; /* ioctl w/o */
- int lo_flags; /* ioctl r/o */
- char lo_name[LO_NAME_SIZE];
- unsigned char lo_encrypt_key[LO_KEY_SIZE]; /* ioctl w/o */
- unsigned int lo_init[2];
- char reserved[4];
+ compat_int_t lo_offset;
+ compat_int_t lo_encrypt_type;
+ compat_int_t lo_encrypt_key_size; /* ioctl w/o */
+ compat_int_t lo_flags; /* ioctl r/o */
+ char lo_name[LO_NAME_SIZE];
+ unsigned char lo_encrypt_key[LO_KEY_SIZE]; /* ioctl w/o */
+ compat_ulong_t lo_init[2];
+ char reserved[4];
};
static int loop_status(unsigned int fd, unsigned int cmd, unsigned long arg)
@@ -1926,7 +1927,7 @@
struct consolefontdesc32 {
unsigned short charcount; /* characters in font (256 or 512) */
unsigned short charheight; /* scan lines per character (1-32) */
- u32 chardata; /* font data in expanded form */
+ compat_caddr_t chardata; /* font data in expanded form */
};
static int do_fontx_ioctl(unsigned int fd, int cmd, struct consolefontdesc32 *user_cfd, struct file *file)
@@ -1977,11 +1978,11 @@
}
struct console_font_op32 {
- unsigned int op; /* operation code KD_FONT_OP_* */
- unsigned int flags; /* KD_FONT_FLAG_* */
- unsigned int width, height; /* font size */
- unsigned int charcount;
- u32 data; /* font data with height fixed to 32 */
+ compat_uint_t op; /* operation code KD_FONT_OP_* */
+ compat_uint_t flags; /* KD_FONT_FLAG_* */
+ compat_uint_t width, height; /* font size */
+ compat_uint_t charcount;
+ compat_caddr_t data; /* font data with height fixed to 32 */
};
static int do_kdfontop_ioctl(unsigned int fd, unsigned int cmd, struct console_font_op32 *fontop, struct file *file)
@@ -2009,7 +2010,7 @@
struct unimapdesc32 {
unsigned short entry_ct;
- u32 entries;
+ compat_caddr_t entries;
};
static int do_unimap_ioctl(unsigned int fd, unsigned int cmd, struct unimapdesc32 *user_ud, struct file *file)
@@ -2049,14 +2050,14 @@
}
struct atmif_sioc32 {
- int number;
- int length;
- compat_caddr_t arg;
+ compat_int_t number;
+ compat_int_t length;
+ compat_caddr_t arg;
};
struct atm_iobuf32 {
- int length;
- compat_caddr_t buffer;
+ compat_int_t length;
+ compat_caddr_t buffer;
};
#define ATM_GETLINKRATE32 _IOW('a', ATMIOC_ITF+1, struct atmif_sioc32)
@@ -2232,10 +2233,10 @@
}
struct blkpg_ioctl_arg32 {
- int op;
- int flags;
- int datalen;
- u32 data;
+ compat_int_t op;
+ compat_int_t flags;
+ compat_int_t datalen;
+ compat_caddr_t data;
};
static int blkpg_ioctl_trans(unsigned int fd, unsigned int cmd, struct blkpg_ioctl_arg32 *arg)
@@ -2294,7 +2295,7 @@
struct raw32_config_request
{
- int raw_minor;
+ compat_int_t raw_minor;
__u64 block_major;
__u64 block_minor;
} __attribute__((packed));
@@ -2386,7 +2387,7 @@
}
struct dirent32 {
- unsigned int d_ino;
+ compat_int_t d_ino;
compat_off_t d_off;
unsigned short d_reclen;
char d_name[256]; /* We must not include limits.h! */
@@ -2492,13 +2493,13 @@
#define BNEPGETCONNINFO _IOR('B', 211, int)
struct usbdevfs_ctrltransfer32 {
- __u8 bRequestType;
- __u8 bRequest;
- __u16 wValue;
- __u16 wIndex;
- __u16 wLength;
- __u32 timeout; /* in milliseconds */
- __u32 data;
+ u8 bRequestType;
+ u8 bRequest;
+ u16 wValue;
+ u16 wIndex;
+ u16 wLength;
+ u32 timeout; /* in milliseconds */
+ compat_caddr_t data;
};
#define USBDEVFS_CONTROL32 _IOWR('U', 0, struct usbdevfs_ctrltransfer32)
@@ -2556,10 +2557,10 @@
}
struct usbdevfs_bulktransfer32 {
- unsigned int ep;
- unsigned int len;
- unsigned int timeout; /* in milliseconds */
- __u32 data;
+ compat_uint_t ep;
+ compat_uint_t len;
+ compat_uint_t timeout; /* in milliseconds */
+ compat_caddr_t data;
};
#define USBDEVFS_BULK32 _IOWR('U', 2, struct usbdevfs_bulktransfer32)
@@ -2657,18 +2658,18 @@
*/
#if 0
struct usbdevfs_urb32 {
- __u8 type;
- __u8 endpoint;
- __s32 status;
- __u32 flags;
- __u32 buffer;
- __s32 buffer_length;
- __s32 actual_length;
- __s32 start_frame;
- __s32 number_of_packets;
- __s32 error_count;
- __u32 signr;
- __u32 usercontext; /* unused */
+ unsigned char type;
+ unsigned char endpoint;
+ compat_int_t status;
+ compat_uint_t flags;
+ compat_caddr_t buffer;
+ compat_int_t buffer_length;
+ compat_int_t actual_length;
+ compat_int_t start_frame;
+ compat_int_t number_of_packets;
+ compat_int_t error_count;
+ compat_uint_t signr;
+ compat_caddr_t usercontext; /* unused */
struct usbdevfs_iso_packet_desc iso_frame_desc[0];
};
@@ -2840,8 +2841,8 @@
}
struct usbdevfs_disconnectsignal32 {
- unsigned int signr;
- u32 context;
+ compat_int_t signr;
+ compat_caddr_t context;
};
#define USBDEVFS_DISCSIGNAL32 _IOR('U', 14, struct usbdevfs_disconnectsignal32)
@@ -2871,9 +2872,9 @@
}
struct mtd_oob_buf32 {
- u32 start;
- u32 length;
- u32 ptr; /* unsigned char* */
+ u_int32_t start;
+ u_int32_t length;
+ compat_caddr_t ptr; /* unsigned char* */
};
#define MEMWRITEOOB32 _IOWR('M',3,struct mtd_oob_buf32)
@@ -2918,17 +2919,17 @@
struct mtrr_sentry32
{
- unsigned int base; /* Base address */
- unsigned int size; /* Size of region */
- unsigned int type; /* Type of region */
+ compat_ulong_t base; /* Base address */
+ compat_uint_t size; /* Size of region */
+ compat_uint_t type; /* Type of region */
};
struct mtrr_gentry32
{
- unsigned int regnum; /* Register number */
- unsigned int base; /* Base address */
- unsigned int size; /* Size of region */
- unsigned int type; /* Type of region */
+ compat_ulong_t regnum; /* Register number */
+ compat_uint_t base; /* Base address */
+ compat_uint_t size; /* Size of region */
+ compat_uint_t type; /* Type of region */
};
#define MTRR_IOCTL_BASE 'M'
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
From pavel at suse.cz Fri May 9 21:30:18 2003
From: pavel at suse.cz (Pavel Machek)
Date: Fri, 9 May 2003 21:30:18 +0200
Subject: [discuss] Warm reboot for x86-64 linux
In-Reply-To: <20030509150557.GA6010@Wotan.suse.de>
References: <20030509150557.GA6010@Wotan.suse.de>
Message-ID: <20030509193018.GB1168@elf.ucw.cz>
Hi!
> Comments/Feedback welcome.
> --- linux/arch/x86_64/kernel/head.S 2003/02/11 12:29:15 1.55
> +++ linux/arch/x86_64/kernel/head.S 2003/05/09 16:12:14
> @@ -340,7 +340,7 @@
> .align 64 /* cacheline aligned, keep this synchronized with asm/desc.h */
> ENTRY(gdt_table)
> .quad 0x0000000000000000 /* This one is magic */
> - .quad 0x0000000000000000 /* unused */
> + .quad 0x00af9a000000ffff ^ (1<<21) /* __KERNEL_COMPAT32_CS */
Could you evalueate that number?
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
From david.christie at amd.com Fri May 9 21:39:12 2003
From: david.christie at amd.com (david.christie at amd.com)
Date: Fri, 9 May 2003 14:39:12 -0500
Subject: [discuss] Warm reboot for x86-64 linux
Message-ID: <99F2150714F93F448942F9A9F112634C050E4706@txexmtae.amd.com>
> -----Original Message-----
> From: H. Peter Anvin [mailto:hpa at zytor.com]
> Sent: Friday, May 09, 2003 1:09 PM
> To: discuss at x86-64.org
> Subject: Re: [discuss] Warm reboot for x86-64 linux
>
>
> Followup to: <20030509150557.GA6010 at Wotan.suse.de>
> By author: Andi Kleen
> In newsgroup: linux.ports.x86-64.discuss
> >
> >
[snip]
> >
> > I used 0xffff:0x0000 for now as reboot vector.
> >
>
> It should be 0xf000:0xfff0.
>
> -hpa
Yes. Maybe a little explanation is in order:
The reason is that ffff:0000 is the value that CS:IP gets
loaded with by reset on an 8086 processor, and f000:fff0
is what you get on a 286 and above. While both resolve to
the same linear address, the difference in CS value can be
visible to the code at that location, so when you go there
via a far jump on any given processor, you need to do so using
the same CS value that a hard reset loads for that processor.
On a typical PC platform, where that code consists of just
a far jump to the real BIOS entrypoint, the CS value doesn't
really matter since it gets immediately reloaded with the
correct value anyway by the far jump. There are 4094 other
CS:IP combinations that would work equally well. But if
you want to be sure of correctly executing that reset code
regardless of what it might be now or in the future, the
correct value to use is f000:fff0.
Dave Christie
AMD
> --
> at work, in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x
> sh v850 x86-64
>
From hpa at zytor.com Fri May 9 22:59:02 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Fri, 09 May 2003 13:59:02 -0700
Subject: [discuss] Warm reboot for x86-64 linux
In-Reply-To: <99F2150714F93F448942F9A9F112634C050E4706@txexmtae.amd.com>
References: <99F2150714F93F448942F9A9F112634C050E4706@txexmtae.amd.com>
Message-ID: <3EBC1696.7050008@zytor.com>
david.christie at amd.com wrote:
>
> Yes. Maybe a little explanation is in order:
>
> The reason is that ffff:0000 is the value that CS:IP gets
> loaded with by reset on an 8086 processor,
>
Are you sure about that? That doesn't match my recollection, but I
don't have an 8086 data book handy :-/
-hpa
From erich at uruk.org Fri May 9 23:24:21 2003
From: erich at uruk.org (erich at uruk.org)
Date: Fri, 09 May 2003 14:24:21 -0700
Subject: [discuss] Warm reboot for x86-64 linux
In-Reply-To: Your message of "Fri, 09 May 2003 13:59:02 PDT."
<3EBC1696.7050008@zytor.com>
Message-ID:
"H. Peter Anvin" wrote:
> david.christie at amd.com wrote:
> >
> > Yes. Maybe a little explanation is in order:
> >
> > The reason is that ffff:0000 is the value that CS:IP gets
> > loaded with by reset on an 8086 processor,
> >
>
> Are you sure about that? That doesn't match my recollection, but I
> don't have an 8086 data book handy :-/
HPA's doubt is correct. For the sake of argument I'm
reading from an AMD K8 guide, but I think it's the same on
all x86's. (zero-extend if you want the 64-bit values ;-)
EIP = 0000_FFF0h
CS.Selector = F000h
CS.Base = FFFF_0000h
CS.Limit = FFFFh
Since the ROM is located at both (FFFF_FFFFh - ROMSize + 1) and
(000F_FFFF - ROMSize + 1) in PCs by architecture definition, you can
just use 16-bit f000:fff0 and get the same result.
--
Erich Stefan Boleyn http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
From hpa at zytor.com Fri May 9 23:25:58 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Fri, 09 May 2003 14:25:58 -0700
Subject: [discuss] Warm reboot for x86-64 linux
In-Reply-To:
References:
Message-ID: <3EBC1CE6.6030607@zytor.com>
erich at uruk.org wrote:
> "H. Peter Anvin" wrote:
>
>
>>david.christie at amd.com wrote:
>>
>>>Yes. Maybe a little explanation is in order:
>>>
>>>The reason is that ffff:0000 is the value that CS:IP gets
>>>loaded with by reset on an 8086 processor,
>>>
>>
>>Are you sure about that? That doesn't match my recollection, but I
>>don't have an 8086 data book handy :-/
>
>
> HPA's doubt is correct. For the sake of argument I'm
> reading from an AMD K8 guide, but I think it's the same on
> all x86's. (zero-extend if you want the 64-bit values ;-)
>
Oh, there is no question F000:FFF0 is right for anything 286 or newer.
I'm pretty sure it applied even to the 8086, though.
-hpa
From erich at uruk.org Fri May 9 23:59:50 2003
From: erich at uruk.org (erich at uruk.org)
Date: Fri, 09 May 2003 14:59:50 -0700
Subject: [discuss] Warm reboot for x86-64 linux
In-Reply-To: Your message of "Fri, 09 May 2003 14:25:58 PDT."
<3EBC1CE6.6030607@zytor.com>
Message-ID:
"H. Peter Anvin" wrote:
> >>Are you sure about that? That doesn't match my recollection, but I
> >>don't have an 8086 data book handy :-/
> >
> >
> > HPA's doubt is correct. For the sake of argument I'm
> > reading from an AMD K8 guide, but I think it's the same on
> > all x86's. (zero-extend if you want the 64-bit values ;-)
> >
>
> Oh, there is no question F000:FFF0 is right for anything 286 or newer.
> I'm pretty sure it applied even to the 8086, though.
I looked in an old Intel 8086 PDF I have, and while it describes the
reset sequence in some detail, they don't list the initial register
state and just say it starts at FFFF0h.
Several other web-sniffable resources say CS=FFFFh,IP=0 for the 8086,
and I'd guess David has Real Documentation to that effect.
My memory from my Intel days (I work at AMD now ;-) was that this
was done on purpose to make it have similar behavior to if it
accidentally executed beyond FFFFFh.
Not like this matters other than curiousity, though...
--
Erich Stefan Boleyn http://www.uruk.org/
"Reality is truly stranger than fiction; Probably why fiction is so popular"
From hpa at zytor.com Sat May 10 00:10:01 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Fri, 09 May 2003 15:10:01 -0700
Subject: [discuss] Warm reboot for x86-64 linux
In-Reply-To:
References:
Message-ID: <3EBC2739.6030808@zytor.com>
erich at uruk.org wrote:
>
> My memory from my Intel days (I work at AMD now ;-) was that this
> was done on purpose to make it have similar behavior to if it
> accidentally executed beyond FFFFFh.
>
No, that's the A20 gate you're thinking of.
An 8086 running at FFFF:0010 would fetch from 00000 not F0000.
> Not like this matters other than curiousity, though...
Indeed.
-hpa
From hpa at zytor.com Sat May 10 01:31:48 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 9 May 2003 16:31:48 -0700
Subject: [discuss] Re: discuss Digest 9 May 2003 05:49:46 -0000 Issue 317
References: <20030509064954.GM15829@Wotan.suse.de> <20030509224124.44795.qmail@web20914.mail.yahoo.com>
Message-ID:
Followup to: <20030509224124.44795.qmail at web20914.mail.yahoo.com>
By author: Byrd Kernel
In newsgroup: linux.ports.x86-64.discuss
>
> I would just like BIOS manufacturers to add the AX=24nnh functions to that list
> of "has to work". After all, A20 is pretty simple, and who's going to know
> better how to turn it on for a given motherboard than the BIOS manufacturer?
>
In my experience (SYSLINUX and Linux/i386) INT 15h AX=24xxh work if
they're provided. It's just that sometimes they aren't provided.
-hpa
--
at work, in private!
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
From peter at jazz-1.trumpet.com.au Sat May 10 01:38:23 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Sat, 10 May 2003 09:38:23 +1000 (EST)
Subject: [discuss] Re: discuss Digest 9 May 2003 05:49:46 -0000 Issue 317
In-Reply-To:
Message-ID:
On 9 May 2003, H. Peter Anvin wrote:
> Followup to: <20030509060242.87728.qmail at web20902.mail.yahoo.com>
> By author: Byrd Kernel
> In newsgroup: linux.ports.x86-64.discuss
> >
> > > From: "H. Peter Anvin"
> > >
> > > While we're on this subject, I would really like AMD to lean on BIOS
> > > people to support INT 15h AX=2401h (enable A20), and if the A20 gate is
> > > supported at all also support INT 15h AX=2400h (disable A20).
> > (snip)
> >
> > While we're at it, how about the entire AX=24__h series of functions? I know
> > it'd make my life easier.
> >
> > From RBIL (Ralf Brown's Interrupt List):
> > AX = 2400h - DISABLE A20 GATE
> > AX = 2401h - ENABLE A20 GATE
> > AX = 2402h - GET A20 GATE STATUS
> > AX = 2403h - QUERY A20 GATE SUPPORT
> >
>
> Absolutely, but 2401h is absolutely crucial.
My experience is that these calls are non-existent on practically every machine
I have ever tested, so I have had to work around them (which sadly has been one
of the biggest sources of angst for me in the boot loading process).
Peter
>
> -hpa
> --
> at work, in private!
> "Unix gives you enough rope to shoot yourself in the foot."
> Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From hpa at zytor.com Sat May 10 01:43:19 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Fri, 09 May 2003 16:43:19 -0700
Subject: [discuss] Re: discuss Digest 9 May 2003 05:49:46 -0000 Issue
317
In-Reply-To:
References:
Message-ID: <3EBC3D17.7020600@zytor.com>
Peter Tattam wrote:
>
> My experience is that these calls are non-existent on practically every machine
> I have ever tested, so I have had to work around them (which sadly has been one
> of the biggest sources of angst for me in the boot loading process).
>
That doesn't agree with my assessment. It's certainly so that you can't
rely on them, however, but lots of machines do have them.
SYSLINUX, and the Linux kernel, currently use the following algorithm:
if a20 enabled, set mode := a20_none
if a20 enabled, set mode := a20_bios
if a20 enabled, set mode := a20_kbc
if a20 enabled, set mode := a20_port92
Otherwise fail.
For undoing A20 (before calling the BIOS again) use the same method as
was detected.
This seems to work on the vast majority of all systems. The main
exception are AMD ?lan-based systems (assuming the BIOS doesn't provide
support), which use a completely nonstandard (and unsafe on other
platforms) way to control A20 in the hardware.
-hpa
From peter at jazz-1.trumpet.com.au Sat May 10 01:48:46 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Sat, 10 May 2003 09:48:46 +1000 (EST)
Subject: [discuss] Re: discuss Digest 9 May 2003 05:49:46 -0000 Issue 317
In-Reply-To: <3EBC3D17.7020600@zytor.com>
Message-ID:
On Fri, 9 May 2003, H. Peter Anvin wrote:
> Peter Tattam wrote:
> >
> > My experience is that these calls are non-existent on practically every machine
> > I have ever tested, so I have had to work around them (which sadly has been one
> > of the biggest sources of angst for me in the boot loading process).
> >
>
> That doesn't agree with my assessment. It's certainly so that you can't
> rely on them, however, but lots of machines do have them.
Yes - I should add that I use them if they are there. I've just never seen the
code exercised :) I revert to keyboard A20 but give up after that as the docs
are scant (or were when I wrote the boot loader). I notice a few more
resources around these days describing the process. I guess I'll get it right
one day :) BTW, how do you test A20 without resorting to hardware assistance?
Do you poke some memory above 1 meg and see if it's changed?
Peter
>
> SYSLINUX, and the Linux kernel, currently use the following algorithm:
>
>
> if a20 enabled, set mode := a20_none
>
>
>
> if a20 enabled, set mode := a20_bios
>
>
>
> if a20 enabled, set mode := a20_kbc
>
>
>
> if a20 enabled, set mode := a20_port92
>
> Otherwise fail.
>
> For undoing A20 (before calling the BIOS again) use the same method as
> was detected.
>
> This seems to work on the vast majority of all systems. The main
> exception are AMD ?lan-based systems (assuming the BIOS doesn't provide
> support), which use a completely nonstandard (and unsafe on other
> platforms) way to control A20 in the hardware.
>
> -hpa
>
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From hpa at zytor.com Sat May 10 01:50:44 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Fri, 09 May 2003 16:50:44 -0700
Subject: [discuss] Re: discuss Digest 9 May 2003 05:49:46 -0000 Issue
317
In-Reply-To:
References:
Message-ID: <3EBC3ED4.6010501@zytor.com>
Peter Tattam wrote:
>
> Yes - I should add that I use them if they are there. I've just never seen the
> code exercised :) I revert to keyboard A20 but give up after that as the docs
> are scant (or were when I wrote the boot loader). I notice a few more
> resources around these days describing the process. I guess I'll get it right
> one day :) BTW, how do you test A20 without resorting to hardware assistance?
> Do you poke some memory above 1 meg and see if it's changed?
>
Yes; look at the code.
-hpa
From david.christie at amd.com Sat May 10 02:35:37 2003
From: david.christie at amd.com (david.christie at amd.com)
Date: Fri, 9 May 2003 19:35:37 -0500
Subject: [discuss] Warm reboot for x86-64 linux
Message-ID: <99F2150714F93F448942F9A9F112634C050E4707@txexmtae.amd.com>
> From: H. Peter Anvin [mailto:hpa at zytor.com]
>
> david.christie at amd.com wrote:
> >
> > Yes. Maybe a little explanation is in order:
> >
> > The reason is that ffff:0000 is the value that CS:IP gets
> > loaded with by reset on an 8086 processor,
> >
>
> Are you sure about that? That doesn't match my recollection, but I
> don't have an 8086 data book handy :-/
>
> -hpa
>
Yes. I'm just pointing out that there is a factual
basis for the notion that the reset vector is ffff:0000.
I guess the fact that it still works on most systems, due
to a far jump commonly being used at 0xffff0, has helped
keep that notion alive.
Dave
From hpa at zytor.com Sat May 10 02:42:40 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: Fri, 09 May 2003 17:42:40 -0700
Subject: [discuss] Warm reboot for x86-64 linux
In-Reply-To: <99F2150714F93F448942F9A9F112634C050E4707@txexmtae.amd.com>
References: <99F2150714F93F448942F9A9F112634C050E4707@txexmtae.amd.com>
Message-ID: <3EBC4B00.2070400@zytor.com>
david.christie at amd.com wrote:
>>From: H. Peter Anvin [mailto:hpa at zytor.com]
>>
>>david.christie at amd.com wrote:
>>
>>>Yes. Maybe a little explanation is in order:
>>>
>>>The reason is that ffff:0000 is the value that CS:IP gets
>>>loaded with by reset on an 8086 processor,
>>>
>>
>>Are you sure about that? That doesn't match my recollection, but I
>>don't have an 8086 data book handy :-/
>>
>
> Yes. I'm just pointing out that there is a factual
> basis for the notion that the reset vector is ffff:0000.
> I guess the fact that it still works on most systems, due
> to a far jump commonly being used at 0xffff0, has helped
> keep that notion alive.
>
"Yes" meaning what in this context?
-hpa
From peter at jazz-1.trumpet.com.au Sat May 10 03:01:39 2003
From: peter at jazz-1.trumpet.com.au (Peter Tattam)
Date: Sat, 10 May 2003 11:01:39 +1000 (EST)
Subject: [discuss] DPMI on AMD64 -- Callbacks...
In-Reply-To: <3EBBFBBD.504C63EC@starpower.net>
Message-ID:
On Fri, 9 May 2003, Alan Grimes wrote:
> It seems that many of you are missing the point of realmode callbacks...
>
> The only reason to implement them is when you are running 32-bit code in
> a 16-bit environment.
>
> If Linux were DOS, a linux extender would implement an in80 callback....
>
> There is absolutly no reason at all why the int21h interfaces couldn't
> be implemented directly in 32-bit mode (or any other mode for that
> matter..)
I already take this approach in my dos emulation subsystem. Mind you I am not
sure it's as fast as having a real/v86 driver to handler the DOS calls. I was
planning to explore using a native DOS driver (in v86 mode), but given the
resulting v86 mode issues we are discussiong, that's like to be be a bad idea
for future compatibility.
>
> As for the problem of mixed-code apps, that is a concern though they are
> probably rare... (I hope -- there's no easy way to test this...)
Tough call. most of the DPMI apps out there use a dos extender which
invariably have an API which could be simulated, and I suppose people avoid
jumping into real mode because it's such a huge performance hit, so if it
happens, it's like to be infrequent.
>
>
> --
> Having never read a manual, it takes less effort to hack something
> togeather with www.squeak.org than it does with C++ and five books.
> http://users.rcn.com/alangrimes/
>
--
Peter R. Tattam peter at trumpet.com
Managing Director, Trumpet Software International Pty Ltd
Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210
From ak at suse.de Sat May 10 03:08:05 2003
From: ak at suse.de (Andi Kleen)
Date: Sat, 10 May 2003 03:08:05 +0200
Subject: [discuss] Warm reboot for x86-64 linux
In-Reply-To: <99F2150714F93F448942F9A9F112634C050E4706@txexmtae.amd.com>
References: <99F2150714F93F448942F9A9F112634C050E4706@txexmtae.amd.com>
Message-ID: <20030510010805.GB14046@Wotan.suse.de>
Thanks for the comments to everybody. I changed the code now to 0xf000:0fff0.
gas seems to have some problems with 16bit ljmp, so I wrote it with
nasm and copied the bytes. Can someone confirm that
ea f0 ff 00 f0
is the correct byte sequence for the 16bit ljmp? (objdump -S
unfortunately doesn't work with 16bit code)
use16
jmp 0xf000:0xfff0
Another question while I'm on it: the current code does a wbinvd
before going to that vector. I copied this from 32bit Linux.
Is this needed or should this reboot be already cache coherent ?
-Andi
From hpa at zytor.com Sat May 10 03:41:39 2003
From: hpa at zytor.com (H. Peter Anvin)
Date: 9 May 2003 18:41:39 -0700
Subject: [discuss] Warm reboot for x86-64 linux
References: <99F2150714F93F448942F9A9F112634C050E4706@txexmtae.amd.com> <20030510010805.GB14046@Wotan.suse.de>
Message-ID:
Followup to: <20030510010805.GB14046 at Wotan.suse.de>
By author: Andi Kleen
In newsgroup: linux.ports.x86-64.discuss
>
>
> Thanks for the comments to everybody. I changed the code now to 0xf000:0fff0.
>
> gas seems to have some problems with 16bit ljmp, so I wrote it with
> nasm and copied the bytes. Can someone confirm that
>
> ea f0 ff 00 f0
>
> is the correct byte sequence for the 16bit ljmp? (objdump -S
> unfortunately doesn't work with 16bit code)
>
Yup, that's correct. You can use ndisasm -b 16 if you need to check.
-hpa
--
at work,