From: Zachary Amsden <zach@vmware.com>
To: Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Zwane Mwaikambo <zwane@arm.linux.org.uk>,
Pratap Subrahmanyam <pratap@vmware.com>,
Christopher Li <chrisl@vmware.com>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Ingo Molnar <mingo@elte.hu>, Zachary Amsden <zach@vmware.com>
Subject: [PATCH 9/10] Apm is on cpu zero only
Date: Wed, 9 Nov 2005 16:45:40 -0800 [thread overview]
Message-ID: <200511100045.jAA0je3B028402@zach-dev.vmware.com> (raw)
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/arch/i386/kernel/apm.c
===================================================================
--- linux-2.6.14.orig/arch/i386/kernel/apm.c 2005-11-09 06:37:47.000000000 -0800
+++ linux-2.6.14/arch/i386/kernel/apm.c 2005-11-09 06:38:29.000000000 -0800
@@ -2203,8 +2203,8 @@
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);
@@ -2295,18 +2295,17 @@
* 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.
- */
- 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));
- }
+ *
+ * Note we only set APM segments on CPU zero, since we pin the APM
+ * code to that CPU.
+ */
+ 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)
reply other threads:[~2005-11-10 0:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200511100045.jAA0je3B028402@zach-dev.vmware.com \
--to=zach@vmware.com \
--cc=akpm@osdl.org \
--cc=chrisl@vmware.com \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pratap@vmware.com \
--cc=torvalds@osdl.org \
--cc=zwane@arm.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome