BOOT_CS
Anyone happen to know of any legitimate reason not to reload %cs in head.S? I think the following would be a lot cleaner, as well as a lot safer (the jump and indirect branch aren't guaranteed to have the proper effects, although technically neither should be required due to the %cr0 write):
@@ -117,10 +147,7 @@
movl %cr0,%eax
orl $0x80000000,%eax
movl %eax,%cr0 /* ..and set paging (PG) bit */
- jmp 1f /* flush the prefetch-queue */
-1:
- movl $1f,%eax
- jmp *%eax /* make sure eip is relocated */
+ ljmp $__BOOT_CS,$1f /* Clear prefetch and normalize %eip
*/
1:
/* Set up the stack pointer */
lss stack_start,%espI've been doing some cleanups in head.S after making the early page tables dynamic.
-hpa
Quoted 21 lines · H. Peter Anvin
Anyone happen to know of any legitimate reason not to reload %cs in
head.S? I think the following would be a lot cleaner, as well as a lot safer (the jump and indirect branch aren't guaranteed to have the proper effects, although technically neither should be required due to the %cr0 write):(quoted diff) +1
-4@@ -117,10 +147,7 @@ movl %cr0,%eax orl $0x80000000,%eax movl %eax,%cr0 /* ..and set paging (PG) bit */ - jmp 1f /* flush the prefetch-queue */ -1: - movl $1f,%eax - jmp *%eax /* make sure eip is relocated */ + ljmp $__BOOT_CS,$1f /* Clear prefetch and normalize %eip */ 1: /* Set up the stack pointer */lss stack_start,%esp
Quoted 5 lines
I've been doing some cleanups in
head.Safter making the early page tables dynamic.-hpa
-
IMHO, why bother to re-reload %cs again?
In setup.S, %cs is reloaded already. The enable paging code maps the address identically, so %cs already contains the proper selector.
Coywolf
Signature · 2 lines
Coywolf Qi Hunt Admin of http://GreatCN.org and http://LoveCN.org
Quoted 9 lines · Coywolf Qi Hunt
Quoted 3 lines
(the jump and indirect branch aren't guaranteed to have the proper effects, although technically neither should be required due to the %cr0 write):
IMHO, why bother to re-reload %cs again?
In
setup.S, %cs is reloaded already. The enable paging code maps the address identically, so %cs already contains the proper selector.
It's to flush the instruction prefetch queue: that's one of the side effects of ljmp.
I recall an Intel manual that said ljmp is required when switching between real and protected modes, to flush the prefetch queue.
Unfortunately I don't remember what that manual said about just setting PG.
I'd guess that current generation CPUs don't care about ljmp when changing modes, but older ones certainly do.
-- Jamie
Quoted 5 lines · Jamie Lokier
Quoted 3 lines · Coywolf Qi Hunt
Quoted 3 lines
(the jump and indirect branch aren't guaranteed to have the proper effects, although technically neither should be required due to the %cr0 write):
???
Quoted 10 lines
Quoted 6 lines
IMHO, why bother to re-reload %cs again?
In
setup.S, %cs is reloaded already. The enable paging code maps the address identically, so %cs already contains the proper selector.It's to flush the instruction prefetch queue: that's one of the side effects of ljmp.
Re-loading %cs and flushing prefetch queue are two different things.
Quoted 3 lines
I recall an Intel manual that said ljmp is required when switching between real and protected modes, to flush the prefetch queue.
Not necessarily ljmp, imho
Quoted 8 lines
Unfortunately I don't remember what that manual said about just setting PG.
I'd guess that current generation CPUs don't care about ljmp when changing modes, but older ones certainly do.
-- Jamie
FYI, intel's example code located in STARTUP.ASM Listing arround line 180, chapter 9, IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide
Please consider my patch for this issue.
Coywolf
Signature · 2 lines
Coywolf Qi Hunt Admin of http://GreatCN.org and http://LoveCN.org
head.S renamed from head.S.orig +2 -4
@@ -115,10 +115,8 @@ movl %cr0,%eax orl $0x80000000,%eax movl %eax,%cr0 /* ..and set paging (PG) bit */ - jmp 1f /* flush the prefetch-queue */ -1: - movl $1f,%eax - jmp *%eax /* make sure eip is relocated */ + pushl $1f /* flush the prefetch-queue */ + ret /* and normalize $eip */ 1: /* Set up the stack pointer */ lss stack_start,%esp
Quoted 4 lines · Coywolf Qi Hunt
Quoted 2 lines
It's to flush the instruction prefetch queue: that's one of the side effects of ljmp.
Re-loading %cs and flushing prefetch queue are two different things.
Yes, they are.
Quoted 3 lines
FYI, intel's example code located in STARTUP.ASM Listing arround line 180, chapter 9, IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide
Thanks.
Quoted 1 line
Please consider my patch for this issue.
I don't have the ability to look at that manual right now.
Your patch uses two instructions to flush the queue (push+ret) instead of one (jmp or ljmp). Is that documented as reliable? I can easily imagine an implementation which decodes one instruction after a mode change predictably, but not two.
I doubt that it makes a difference - we're setting PG, not changing the instruction format - but I'd like us to be sure it cannot fail on things like 386s and 486s, and similar non-Intel chips.
-- Jamie
Quoted 2 lines · Jamie Lokier
Your patch uses two instructions to flush the queue (push+ret) instead of one (jmp or ljmp). Is that documented as reliable?
No. The current arch manuals seem to say nothing definite, but Intel's 386 manual (ie, the cpu, not the arch) from 1986 explicitly says "after setting PG, a jump must follow immediately".
Quoted 5 lines
I can easily imagine an implementation which decodes one instruction after a mode change predictably, but not two.
I doubt that it makes a difference - we're setting PG, not changing the instruction format - but I'd like us to be sure it cannot fail on
things like 386s and 486s, and similar non-Intel chips.
I believe you should either keep it as is, do the long jump (although I don't believe that to be necessary: setup.s already long jumped to us) or only delete the indirect jump (we've just been longjumped to, and identity-mapped, so everything would seem to be normalised already).
In any case, please jump directly after setting PG.
Rene.
PATCH 1/1 Remove the extra jmp
In reply to Jamie LokierQuoted 9 lines · Jamie Lokier
Your patch uses two instructions to flush the queue (push+ret) instead of one (jmp or ljmp). Is that documented as reliable? I can easily imagine an implementation which decodes one instruction after a mode change predictably, but not two.
I doubt that it makes a difference - we're setting PG, not changing the instruction format - but I'd like us to be sure it cannot fail on things like 386s and 486s, and similar non-Intel chips.
push+ret is encouraged/borrowed/stolen from FreeBSD ;) it should be reliable. And also, old linux uses ret. Since old linux runs on 386, it is quite reliable. If you still doubt, we can push before PG.
Hello Anvin,
Please either take the push+ret patch or take the one near jmp patch enclosed in this email. thanks
Coywolf
Signature · 2 lines
Coywolf Qi Hunt Admin of http://GreatCN.org and http://LoveCN.org
head.S renamed from head.S.orig +0 -3
@@ -117,9 +117,6 @@ movl %eax,%cr0 /* ..and set paging (PG) bit */ jmp 1f /* flush the prefetch-queue */ 1: - movl $1f,%eax - jmp *%eax /* make sure eip is relocated */ -1: /* Set up the stack pointer */ lss stack_start,%esp
Re: [PATCH] Remove the extra jmp
Quoted 30 lines · Coywolf Qi Hunt
Quoted 9 lines · Jamie Lokier
Your patch uses two instructions to flush the queue (push+ret) instead of one (jmp or ljmp). Is that documented as reliable? I can easily imagine an implementation which decodes one instruction after a mode change predictably, but not two.
I doubt that it makes a difference - we're setting PG, not changing the instruction format - but I'd like us to be sure it cannot fail on things like 386s and 486s, and similar non-Intel chips.
push+ret is encouraged/borrowed/stolen from FreeBSD ;) it should be reliable. And also, old linux uses ret. Since old linux runs on 386, it is quite reliable. If you still doubt, we can push before PG.
Hello Anvin,
Please either take the push+ret patch or take the one near jmp patch enclosed in this email. thanks
Coywolf
------------------------------------------------------------------------
head.S line 122
Quoted 9 lines
head.S renamed from head.S.orig +0
-3@@ -117,9 +117,6 @@ movl %eax,%cr0 /* ..and set paging (PG) bit */ jmp 1f /* flush the prefetch-queue */ 1: - movl $1f,%eax - jmp *%eax /* make sure eip is relocated */ -1: /* Set up the stack pointer */ lss stack_start,%esp
This won't work, because the indirect jump is what adds PAGE_OFFSET to %eip (remember, call/jump use relative addressing). Either keep just the indirect jump, or use "jmp __PAGE_OFFSET+1f".
--
Brian Gerst
Re: [PATCH] Remove the extra jmp
Quoted 30 lines · Brian Gerst
Quoted 28 lines · Coywolf Qi Hunt
Quoted 9 lines · Jamie Lokier
Your patch uses two instructions to flush the queue (push+ret) instead of one (jmp or ljmp). Is that documented as reliable? I can easily imagine an implementation which decodes one instruction after a mode change predictably, but not two.
I doubt that it makes a difference - we're setting PG, not changing the instruction format - but I'd like us to be sure it cannot fail on things like 386s and 486s, and similar non-Intel chips.
push+ret is encouraged/borrowed/stolen from FreeBSD ;) it should be reliable. And also, old linux uses ret. Since old linux runs on 386, it is quite reliable. If you still doubt, we can push before PG.
Hello Anvin,
Please either take the push+ret patch or take the one near jmp patch enclosed in this email. thanks
Coywolf
------------------------------------------------------------------------
Quoted 16 lines
head.S 2004-02-24 11:08:34.000000000 +0800 line 122
Quoted 12 lines
head.S 2004-02-24 11:08:34.000000000 +0800 renamed from head.S.orig 2004-02-18 11:57:16.000000000 +0800 +0
-3@@ -117,9 +117,6 @@ movl %eax,%cr0 /* ..and set paging (PG) bit */ jmp 1f /* flush the prefetch-queue */ 1: - movl $1f,%eax - jmp *%eax /* make sure eip is relocated */ -1: /* Set up the stack pointer */ lss stack_start,%espThis won't work, because the indirect jump is what adds
PAGE_OFFSETto %eip (remember, call/jump use relative addressing). Either keep just the indirect jump, or use "jmp __PAGE_OFFSET+1f".
Any jump works. But I think you did explain very well the reason that the author carelessly or over carefully left the two jumps there.
Coywolf
Signature · 2 lines
Coywolf Qi Hunt Admin of http://GreatCN.org and http://LoveCN.org
Quoted 2 lines · [email protected] (H. Peter Anvin) writes:
Anyone happen to know of any legitimate reason not to reload %cs in
head.S?
Other than the fact it is strongly rude and error prone to depend on the contents of a global descriptor table you did not setup?
If we did the lgdt boot_gdt before hand I don't see any problems though.
But at the point we could as easily do lgdt cpu_gdt_descr, and use __KERNEL_CS which is better anyway.
Quoted 20 lines
I think the following would be a lot cleaner, as well as a lot safer (the jump and indirect branch aren't guaranteed to have the proper effects, although technically neither should be required due to the %cr0 write):
(quoted diff) +1
-4@@ -117,10 +147,7 @@ movl %cr0,%eax orl $0x80000000,%eax movl %eax,%cr0 /* ..and set paging (PG) bit */ - jmp 1f /* flush the prefetch-queue */ -1: - movl $1f,%eax - jmp *%eax /* make sure eip is relocated */ + ljmp $__BOOT_CS,$1f /* Clear prefetch and normalize %eip */ 1: /* Set up the stack pointer */lss stack_start,%esp
Quoted 2 lines
I've been doing some cleanups in
head.Safter making the early page tables dynamic.
That is almost nice. Care to export where the bottom of the page tables or even better where the bottom of the kernel is for those folks who want to place their ramdisk as low in memory as possible?
Eric
Quoted 8 lines · Eric W. Biederman
Quoted 2 lines · [email protected] (H. Peter Anvin) writes:
Anyone happen to know of any legitimate reason not to reload %cs in
head.S?Other than the fact it is strongly rude and error prone to depend on the contents of a global descriptor table you did not setup?
We already do that, as you might have noticed (we set all the data registers to __BOOT_DS; CS is the only that is changed.)
Quoted 5 lines
That is almost nice. Care to export where the bottom of the page tables or even better where the bottom of the kernel is for those folks who want to place their ramdisk as low in memory as possible?
The problem is that you don't know until it's too late, since it can depend on dynamic factors. This is part of why your insistence of putting the ramdisk in the "most incorrect" position is simply wrong.
-hpa
Quoted 11 lines · H. Peter Anvin
Quoted 7 lines · Eric W. Biederman
Quoted 2 lines · [email protected] (H. Peter Anvin) writes:
Anyone happen to know of any legitimate reason not to reload %cs in
head.S?Other than the fact it is strongly rude and error prone to depend on the contents of a global descriptor table you did not setup?
We already do that, as you might have noticed (we set all the data registers to
__BOOT_DS; CS is the only that is changed.)
Right and it would be a cleanup not to touch __BOOT_DS. We have already reloaded it in arch/i386/boot/compressed/head.S anyway.
Quoted 8 lines
Quoted 4 lines
That is almost nice. Care to export where the bottom of the page tables or even better where the bottom of the kernel is for those folks who want to place their ramdisk as low in memory as possible?
The problem is that you don't know until it's too late, since it can depend on dynamic factors. This is part of why your insistence of putting the ramdisk in the "most incorrect" position is simply wrong.
Nope. On other architectures where the bootloader has access to vmlinux this works just fine, all dynamic factors can be contained in the bss. We don't go very long before we reserve memory after all. It is only on x86 where there is not enough information that it is problematic.
Putting the ramdisk right after the kernel (text + data + bss) is the "most correct" position. Anything else is likely to break when the firmware changes. This has already happened 2 or 3 times on x86.
When putting the ramdisk right after the kernel if anything breaks you will notice it immediately, and the kernel will be fixed.
If I truly put an initrd at the top of memory the kernel would not even be able to read the ramdisk.
Eric
Does Flushing the Queue after PG REALLY a Necessity?
In reply to H. Peter AnvinQuoted 5 lines · H. Peter Anvin
Anyone happen to know of any legitimate reason not to reload %cs in
head.S? I think the following would be a lot cleaner, as well as a lot safer (the jump and indirect branch aren't guaranteed to have the proper effects, although technically neither should be required due to the %cr0 write):
Anyone happen to know of any legitimate reason to flush the prefetch queue after enabling paging?
I've read the intel manual volume 3 thoroughly. It only says that after entering protected mode, flushing is required, but never says specifically about whether to do flushing after enabling paging.
Furthermore the intel example code enables protected mode and paging at the same time. So does FreeBSD. There's really no more references to check.
From the cpu's internal view, flushing for PE is to flush the prefetch
queue as well as re-load the %cs, since the protected mode is just about to begin. But no reason to flushing for PG, since linux maps the addresses *identically*.
If no any reason, please remove the after paging flushing queue code, two near jump.
Coywolf
(patch enclosed)
Signature · 2 lines
Coywolf Qi Hunt Admin of http://GreatCN.org and http://LoveCN.org
head-cy.S renamed from head.S +1 -5
@@ -115,11 +115,7 @@ movl %cr0,%eax orl $0x80000000,%eax movl %eax,%cr0 /* ..and set paging (PG) bit */ - jmp 1f /* flush the prefetch-queue */ -1: - movl $1f,%eax - jmp *%eax /* make sure eip is relocated */ -1: + /* Set up the stack pointer */ lss stack_start,%esp
Re: Does Flushing the Queue after PG REALLY a Necessity?
Quoted 7 lines · Coywolf Qi Hunt
Quoted 5 lines · H. Peter Anvin
Anyone happen to know of any legitimate reason not to reload %cs in
head.S? I think the following would be a lot cleaner, as well as a lot safer (the jump and indirect branch aren't guaranteed to have the proper effects, although technically neither should be required due to the %cr0 write):
jump is sufficent when setting PG and required with cpu where cr0 write does not serialize.
Quoted 10 lines
Anyone happen to know of any legitimate reason to flush the prefetch queue after enabling paging?
I've read the intel manual volume 3 thoroughly. It only says that after entering protected mode, flushing is required, but never says specifically about whether to do flushing after enabling paging.
Furthermore the intel example code enables protected mode and paging at the same time. So does FreeBSD. There's really no more references to check.
Quoted 7 lines
From the cpu's internal view, flushing for PE is to flush the prefetch
queue as well as re-load the %cs, since the protected mode is just about to begin. But no reason to flushing for PG, since linux maps the addresses *identically*.If no any reason, please remove the after paging flushing queue code, two near jump.
See IA32 vol 3 7.4 and 18.27.3
Anyway this code is known to work on dozen of intel/non intel processor, how can you know if changing this code will not break an obscure clone ?
regards,
Phil
Re: Does Flushing the Queue after PG REALLY a Necessity?
Quoted 13 lines · Philippe Elie
Quoted 8 lines · Coywolf Qi Hunt
Quoted 5 lines · H. Peter Anvin
Anyone happen to know of any legitimate reason not to reload %cs in
head.S? I think the following would be a lot cleaner, as well as a lot safer (the jump and indirect branch aren't guaranteed to have the proper effects, although technically neither should be required due to the %cr0 write):
Quoted 2 lines
jump is sufficent when setting PG and required with cpu where cr0 write does not serialize.
The problem is there's two jumps in the kernel. Intel's manual only asks for "Execute a near JMP instruction".
Quoted 17 lines
Quoted 17 lines
Anyone happen to know of any legitimate reason to flush the prefetch queue after enabling paging?
I've read the intel manual volume 3 thoroughly. It only says that after entering protected mode, flushing is required, but never says specifically about whether to do flushing after enabling paging.
Furthermore the intel example code enables protected mode and paging at the same time. So does FreeBSD. There's really no more references to check.
From the cpu's internal view, flushing for PE is to flush the prefetch queue as well as re-load the %cs, since the protected mode is just about to begin. But no reason to flushing for PG, since linux maps the addresses *identically*.
Quoted 8 lines
Quoted 2 lines
If no any reason, please remove the after paging flushing queue code, two near jump.
See IA32 vol 3 7.4 and 18.27.3
Anyway this code is known to work on dozen of intel/non intel processor, how can you know if changing this code will not break an obscure clone ?
Right, I also think removing the flush code is risky. Thanks very much, chapter 18 is what i was looking for. I recalled in an old intel booklet, named like something 386 system guide, says JMP after PG as well as PE. But I didn't have that book at hand and didn't find any e-doc.
However, in 18.27.3, "The sequence bounded by the MOV and JMP instructions should be identity" implies no JMP is also viable practically. But we needn't to be that pedantic.
If no any reason for the two jumps, the code should be fixed to remains only ONE near jump.
Coywolf
Signature · 2 lines
Coywolf Qi Hunt Admin of http://GreatCN.org and http://LoveCN.org
Re: Does Flushing the Queue after PG REALLY a Necessity?
Quoted 3 lines · Coywolf Qi Hunt
The problem is there's two jumps in the kernel. Intel's manual only asks for "Execute a near JMP instruction".
A far JMP is definitely sufficient, and serves to normalize EIP as well.
I have uploaded a patch which also preinitializes the GDT, which may make the VISWS code a bit less of a special case.
ftp://ftp.kernel.org/pub/linux/kernel/people/hpa/earlymem-4.diff
Quoted 1 line
If no any reason for the two jumps, the code should be fixed to remains only ONE near jump.
Why are you so obsessed with minimality? The performance of this code matters not one bit.
-hpa
Re: Does Flushing the Queue after PG REALLY a Necessity?
In reply to Coywolf Qi HuntOn Tue, 24 Feb 2004 10:36:07 +0800 Coywolf Qi Hunt <[email protected]> wrote:
| Philippe Elie wrote: | | > On Mon, 23 Feb 2004 at 18:27 +0000, Coywolf Qi Hunt wrote: | > | > | >>H. Peter Anvin wrote: | >> | >> | >>>Anyone happen to know of any legitimate reason not to reload %cs in | >>>head.S? I think the following would be a lot cleaner, as well as a | >>>lot safer (the jump and indirect branch aren't guaranteed to have the | >>>proper effects, although technically neither should be required due to | >>>the %cr0 write): | > | > | > jump is sufficent when setting PG and required with cpu where cr0 write | > does not serialize. | | The problem is there's two jumps in the kernel. Intel's manual only asks | for "Execute a near JMP instruction". | | > | > | >>Anyone happen to know of any legitimate reason to flush the prefetch | >>queue after enabling paging? | >> | >>I've read the intel manual volume 3 thoroughly. It only says that after | >>entering protected mode, flushing is required, but never says | >>specifically about whether to do flushing after enabling paging. | >> | >>Furthermore the intel example code enables protected mode and paging at | >>the same time. So does FreeBSD. There's really no more references to check. | >> | >> From the cpu's internal view, flushing for PE is to flush the prefetch | >>queue as well as re-load the %cs, since the protected mode is just about | >>to begin. But no reason to flushing for PG, since linux maps the | >>addresses *identically*. | >> | >>If no any reason, please remove the after paging flushing queue code, | >>two near jump. | > | > | > See IA32 vol 3 7.4 and 18.27.3 | > | > Anyway this code is known to work on dozen of intel/non intel processor, | > how can you know if changing this code will not break an obscure clone ? | | Right, I also think removing the flush code is risky. Thanks very much, | chapter 18 is what i was looking for. I recalled in an old intel | booklet, named like something 386 system guide, says JMP after PG as | well as PE. But I didn't have that book at hand and didn't find any e-doc.
I guess that's the 80386 System Software Writer's Guide. Ch. 6: Initialization.
Yes, it does JMP after setting PE and after enabling PG. Any JMP.
| However, in 18.27.3, "The sequence bounded by the MOV and JMP | instructions should be identity" implies no JMP is also viable | practically. But we needn't to be that pedantic. | | If no any reason for the two jumps, the code should be fixed to remains | only ONE near jump.
--
~Randy
Re: Does Flushing the Queue after PG REALLY a Necessity?
Quoted 8 lines · Randy.Dunlap
On Tue, 24 Feb 2004 10:36:07 +0800 Coywolf Qi Hunt wrote:
| Right, I also think removing the flush code is risky. Thanks very much, | chapter 18 is what i was looking for. I recalled in an old intel | booklet, named like something 386 system guide, says JMP after PG as | well as PE. But I didn't have that book at hand and didn't find any e-doc.
I guess that's the 80386 System Software Writer's Guide. Ch. 6: Initialization.
Yes, it does JMP after setting PE and after enabling PG. Any JMP.
Yes, it's that booklet, very thin.
Quoted 3 lines
| However, in 18.27.3, "The sequence bounded by the MOV and JMP | instructions should be identity" implies no JMP is also viable | practically. But we needn't to be that pedantic. | | If no any reason for the two jumps, the code should be fixed to remains | only ONE near jump.
Btw, could you please do not show others email address when you reply? Change your mail client's configuration. I don't like my this email address be grabbed by spammers. thanks
Coywolf
Signature · 2 lines
Coywolf Qi Hunt Admin of http://GreatCN.org and http://LoveCN.org
Re: Does Flushing the Queue after PG REALLY a Necessity?
Quoted 3 lines · Coywolf Qi Hunt
Btw, could you please do not show others email address when you reply? Change your mail client's configuration. I don't like my this email address be grabbed by spammers. thanks
hmm, ever heard of the evil From: header?
best,
Herbert
Quoted 10 lines
Coywolf
Signature · 7 lines
Coywolf Qi Hunt Admin of http://GreatCN.org and http://LoveCN.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Does Flushing the Queue after PG REALLY a Necessity?
Quoted 7 lines · Herbert Poetzl
Quoted 1 line · Coywolf Qi Hunt
Btw, could you please do not show others email address when you reply? Change your mail client's configuration. I don't like my this email address be grabbed by spammers. thanks
hmm, ever heard of the evil From: header?
The mail address got in the body, and all the lkml archives show it in html pages. Then more spammers ...
Coywolf
Signature · 2 lines
Coywolf Qi Hunt Admin of http://GreatCN.org and http://LoveCN.org