* [PATCH 14/21] i386 Apm is on cpu zero only
@ 2005-11-08 4:33 Zachary Amsden
2005-11-08 7:33 ` Ingo Molnar
0 siblings, 1 reply; 6+ messages in thread
From: Zachary Amsden @ 2005-11-08 4:33 UTC (permalink / raw)
To: Andrew Morton, Chris Wright, Linus Torvalds,
Linux Kernel Mailing List, Virtualization Mailing List,
H. Peter Anvin, Zwane Mwaikambo, Martin Bligh,
Pratap Subrahmanyam, Christopher Li, Eric W. Biederman,
Ingo Molnar, Zachary Amsden, 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.
Signed-off-by: Zachary Amsden <zach@vmware.com>
Index: linux-2.6.14-zach-work/arch/i386/kernel/apm.c
===================================================================
--- linux-2.6.14-zach-work.orig/arch/i386/kernel/apm.c 2005-11-07 10:17:45.000000000 -0800
+++ linux-2.6.14-zach-work/arch/i386/kernel/apm.c 2005-11-07 13:36:05.000000000 -0800
@@ -2170,8 +2170,8 @@ static struct dmi_system_id __initdata a
static 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)
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH 14/21] i386 Apm is on cpu zero only
2005-11-08 4:33 [PATCH 14/21] i386 Apm is on cpu zero only Zachary Amsden
@ 2005-11-08 7:33 ` Ingo Molnar
2005-11-08 12:53 ` Zachary Amsden
2005-11-08 14:51 ` H. Peter Anvin
0 siblings, 2 replies; 6+ messages in thread
From: Ingo Molnar @ 2005-11-08 7:33 UTC (permalink / raw)
To: Zachary Amsden
Cc: Andrew Morton, Chris Wright, Linus Torvalds,
Linux Kernel Mailing List, Virtualization Mailing List,
H. Peter Anvin, Zwane Mwaikambo, Martin Bligh,
Pratap Subrahmanyam, Christopher Li, Eric W. Biederman
* Zachary Amsden <zach@vmware.com> wrote:
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 14/21] i386 Apm is on cpu zero only
2005-11-08 7:33 ` Ingo Molnar
@ 2005-11-08 12:53 ` Zachary Amsden
2005-11-08 13:54 ` Alan Cox
2005-11-08 14:51 ` H. Peter Anvin
1 sibling, 1 reply; 6+ messages in thread
From: Zachary Amsden @ 2005-11-08 12:53 UTC (permalink / raw)
To: Ingo Molnar
Cc: Andrew Morton, Chris Wright, Linus Torvalds,
Linux Kernel Mailing List, Virtualization Mailing List,
H. Peter Anvin, Zwane Mwaikambo, Martin Bligh,
Pratap Subrahmanyam, Christopher Li, Eric W. Biederman
Ingo Molnar wrote:
>* Zachary Amsden <zach@vmware.com> wrote:
>
>
>
>>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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 14/21] i386 Apm is on cpu zero only
2005-11-08 12:53 ` Zachary Amsden
@ 2005-11-08 13:54 ` Alan Cox
2005-11-08 13:26 ` Ingo Molnar
0 siblings, 1 reply; 6+ messages in thread
From: Alan Cox @ 2005-11-08 13:54 UTC (permalink / raw)
To: Zachary Amsden
Cc: Ingo Molnar, Andrew Morton, Chris Wright, Linus Torvalds,
Linux Kernel Mailing List, Virtualization Mailing List,
H. Peter Anvin, Zwane Mwaikambo, Martin Bligh,
Pratap Subrahmanyam, Christopher Li, Eric W. Biederman
On Maw, 2005-11-08 at 04:53 -0800, Zachary Amsden wrote:
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 14/21] i386 Apm is on cpu zero only
2005-11-08 13:54 ` Alan Cox
@ 2005-11-08 13:26 ` Ingo Molnar
0 siblings, 0 replies; 6+ messages in thread
From: Ingo Molnar @ 2005-11-08 13:26 UTC (permalink / raw)
To: Alan Cox
Cc: Zachary Amsden, Andrew Morton, Chris Wright, Linus Torvalds,
Linux Kernel Mailing List, Virtualization Mailing List,
H. Peter Anvin, Zwane Mwaikambo, Martin Bligh,
Pratap Subrahmanyam, Christopher Li, Eric W. Biederman
* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-11-08 at 04:53 -0800, Zachary Amsden wrote:
> > 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 14/21] i386 Apm is on cpu zero only
2005-11-08 7:33 ` Ingo Molnar
2005-11-08 12:53 ` Zachary Amsden
@ 2005-11-08 14:51 ` H. Peter Anvin
1 sibling, 0 replies; 6+ messages in thread
From: H. Peter Anvin @ 2005-11-08 14:51 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zachary Amsden, Andrew Morton, Chris Wright, Linus Torvalds,
Linux Kernel Mailing List, Virtualization Mailing List,
Zwane Mwaikambo, Martin Bligh, Pratap Subrahmanyam,
Christopher Li, Eric W. Biederman
Ingo Molnar wrote:
> * Zachary Amsden <zach@vmware.com> wrote:
>
>
>>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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-11-08 14:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-08 4:33 [PATCH 14/21] i386 Apm is on cpu zero only Zachary Amsden
2005-11-08 7:33 ` Ingo Molnar
2005-11-08 12:53 ` Zachary Amsden
2005-11-08 13:54 ` Alan Cox
2005-11-08 13:26 ` Ingo Molnar
2005-11-08 14:51 ` H. Peter Anvin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox