From owner-freebsd-smp Fri Jul 5 12:06:38 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id MAA27005 for smp-outgoing; Fri, 5 Jul 1996 12:06:38 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id MAA26999 for ; Fri, 5 Jul 1996 12:06:35 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id MAA15216; Fri, 5 Jul 1996 12:02:49 -0700 From: Terry Lambert Message-Id: <199607051902.MAA15216@phaeton.artisoft.com> Subject: Re: Running SMP To: peter@spinner.dialix.com (Peter Wemm) Date: Fri, 5 Jul 1996 12:02:49 -0700 (MST) Cc: terry@lambert.org, erich@uruk.org, freebsd-smp@freebsd.org In-Reply-To: <199607050242.KAA18450@spinner.DIALix.COM> from "Peter Wemm" at Jul 5, 96 10:42:23 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > However, Bruce Evans is/was working in a different direction. He wants to > remove the 'struct i386tss' from the process context and use a much > smaller structure. The structure that holds the user process context at > interrupt would be instead be in a static place and itself context > switched on traps etc. If I understand what he's doing, this will make SMP > support harder, and makes VM86, user_ldt etc stuff harder too, because > some processes will need a full i386tss, while others will use the shared > one etc, and as well, for SMP, you need a shared tss per cpu, and need to > figure out which one you are using at trap/context switch time etc. I'm > not sold on Bruce's idea yet, I've got my "wait and see" hat on, to see > how much work it'll cause us on SMP. On the other hand, it will make it portable to non-TSS-using systems. I'm really torn on this, because I want real VM86 support. 8-(. > - Safe boot straps of the non-booting cpus (ie: generate a PTD with the > 0MB P==V mapping) > - this PTD is used on a per-cpu basis for the idle loop (yes, it's back!) With a real halt? > Does anybody have documentation on the IO apic? I've got enough detail on > the local apic, but the IO apic is a real problem. We're stuck in the > painful "dumb" mode where all cpus get all interrupts in parallel with > each other until we can get some details on the IO apic. (somebody > pointed me to something from intel, but I can't find the reference anymore) I thought I had pointed you to the www.intel.com page for the IO chip, and there's now a 1.2 MP document on their site, which goes into more detail on virtual wire (the mode I think we want to use to anonymize which procesor has to take which interrupt). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.