Skip to contentSkip to conversation

x86: fix smp_stacktop on 32-bit

PATCH Applied Nadav Amit 2 participants 3 messages Jun 24, 2020 – Jun 25, 2020 KVM

lore
Share & tools
lore

Nadav Amit

author
#0 lore raw

PATCH 1/1 x86: fix smp_stacktop on 32-bit

smp_stacktop in 32-bit is fixed to some magic address. Use the address of the memory that was reserved for the stack instead.

Signed-off-by Nadav Amit <[email protected]>
---
 x86/cstart.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
x86/cstart.S +1 -1
index 1d8b8ac..a072aed 100644
@@ -134,7 +134,7 @@ prepare_32:
 	mov %eax, %cr0
 	ret
 
-smp_stacktop:	.long 0xa0000
+smp_stacktop:	.long stacktop - 4096
 
 save_id:
 	movl $(APIC_DEFAULT_PHYS_BASE + APIC_ID), %eax
Signature · 1 line
2.20.1
maintainer Applied
#1 lore raw
Quoted 14 lines · Nadav Amit

smp_stacktop in 32-bit is fixed to some magic address. Use the address of the memory that was reserved for the stack instead.

Signed-off-by Nadav Amit <[email protected]>
---
 x86/cstart.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
x86/cstart.S +0 -0
index 1d8b8ac..a072aed 100644

x86/cstart.S prepare_32: · line 140

Quoted 8 lines
x86/cstart.S +1 -1
@@ -134,7 +134,7 @@ prepare_32:
 	mov %eax, %cr0
 	ret
 
-smp_stacktop:	.long 0xa0000
+smp_stacktop:	.long stacktop - 4096
 
 save_id:
 	movl $(APIC_DEFAULT_PHYS_BASE + APIC_ID), %eax

Queued, thanks.

Paolo

maintainer
#2 lore raw
In reply to Nadav Amit
Quoted 14 lines · Nadav Amit

smp_stacktop in 32-bit is fixed to some magic address. Use the address of the memory that was reserved for the stack instead.

Signed-off-by Nadav Amit <[email protected]>
---
 x86/cstart.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
x86/cstart.S +0 -0
index 1d8b8ac..a072aed 100644

x86/cstart.S prepare_32: · line 140

Quoted 8 lines
x86/cstart.S +1 -1
@@ -134,7 +134,7 @@ prepare_32:
 	mov %eax, %cr0
 	ret
 
-smp_stacktop:	.long 0xa0000
+smp_stacktop:	.long stacktop - 4096
 
 save_id:
 	movl $(APIC_DEFAULT_PHYS_BASE + APIC_ID), %eax

This uncovers a latent bug for which I've just sent a patch ("x86: fix stack pointer after call").

Paolo