i386 Apm is on cpu zero only
PATCH 14/21 i386 Apm is on cpu zero only
APM BIOS code has a protective wrapper that runs it only on CPU zero. Thus, no need to set APM BIOS segments in the GDT for other CPUs.
arch/i386/kernel/apm.c +11 -12
@@ -2170,8 +2170,8 @@ static struct dmi_system_id __initdata astatic int __init apm_init (void ) {struct proc_dir_entry *apm_proc; +struct desc_struct *gdt;int ret; -int i;dmi_check_system (apm_dmi_table);
@@ -2253,18 +2253,17 @@ static int __init apm_init(void)* not restrict themselves to their claimed limit. When this happens, * they will cause a segmentation violation in the kernel at boot time. * Most BIOS's, however, will respect a 64k limit, so we use that. +* +* Note we only set APM segments on CPU zero, since we pin the APM +* code to that CPU. */ -for (i =0 ; i <NR_CPUS ; i++) { -struct desc_struct *gdt =get_cpu_gdt_table (i); -if (!gdt) -continue ; -set_base (&gdt[APM_CS >>3 ], -__va ((unsigned long )apm_info.bios.cseg <<4 )); -set_base (&gdt[APM_CS_16 >>3 ], -__va ((unsigned long )apm_info.bios.cseg_16 <<4 )); -set_base (&gdt[APM_DS >>3 ], -__va ((unsigned long )apm_info.bios.dseg <<4 )); - } + gdt =get_cpu_gdt_table (0 ); +set_base (&gdt[APM_CS >>3 ], +__va ((unsigned long )apm_info.bios.cseg <<4 )); +set_base (&gdt[APM_CS_16 >>3 ], +__va ((unsigned long )apm_info.bios.cseg_16 <<4 )); +set_base (&gdt[APM_DS >>3 ], +__va ((unsigned long )apm_info.bios.dseg <<4 )); apm_proc =create_proc_info_entry ("apm" ,0 ,NULL , apm_get_info);if (apm_proc)
Quoted 2 lines · Zachary Amsden
APM BIOS code has a protective wrapper that runs it only on CPU zero. Thus, no need to set APM BIOS segments in the GDT for other CPUs.
hm, do we want (need) to have that CPU#0 assumption forever?
Ingo
Quoted 11 lines · Ingo Molnar
Quoted 3 lines · Zachary Amsden
APM BIOS code has a protective wrapper that runs it only on CPU zero. Thus, no need to set APM BIOS segments in the GDT for other CPUs.
hm, do we want (need) to have that CPU#0 assumption forever?
Can't hurt, and APM is largely obsolete because of ACPI, so I'm only concerned with trimming and keeping adequate protection of the kernel from APM code while maintaining correctness. I don't have a nice set of old machines with enough wacky APM BIOSen to validate that unpinning the CPU is ok.
Zach
Quoted 5 lines · Zachary Amsden
Can't hurt, and APM is largely obsolete because of ACPI, so I'm only concerned with trimming and keeping adequate protection of the kernel from APM code while maintaining correctness. I don't have a nice set of old machines with enough wacky APM BIOSen to validate that unpinning the CPU is ok.
A large number of SMP machines, probably the majority of APM based ones require that APM calls occur on CPU#0. As I understand it from a BIOS engineer involved in debugging that problem Redmond always does APM from CPU #0 and may even guarantee it.
Alan
Quoted 11 lines · Alan Cox
Quoted 5 lines · Zachary Amsden
Can't hurt, and APM is largely obsolete because of ACPI, so I'm only concerned with trimming and keeping adequate protection of the kernel from APM code while maintaining correctness. I don't have a nice set of old machines with enough wacky APM BIOSen to validate that unpinning the CPU is ok.
A large number of SMP machines, probably the majority of APM based ones require that APM calls occur on CPU#0. As I understand it from a BIOS engineer involved in debugging that problem Redmond always does APM from CPU #0 and may even guarantee it.
ok, then i'm all for making that more explicit - i.e. Zachary's patch is the right one.
Ingo
Quoted 7 lines · Ingo Molnar
Quoted 1 line · Zachary Amsden
APM BIOS code has a protective wrapper that runs it only on CPU zero. Thus, no need to set APM BIOS segments in the GDT for other CPUs.
hm, do we want (need) to have that CPU#0 assumption forever?
APM BIOS should only ever run on the BSP, and I believe in Linux the BSP is always 0. Since APM is obsolete, there is no future to consider.
-hpa