From owner-freebsd-arch Fri Dec 28 23:28:46 2001 Delivered-To: freebsd-arch@freebsd.org Received: from femail11.sdc1.sfba.home.com (femail11.sdc1.sfba.home.com [24.0.95.107]) by hub.freebsd.org (Postfix) with ESMTP id 91DD037B436 for ; Fri, 28 Dec 2001 23:28:24 -0800 (PST) Received: from laptop.baldwin.cx ([24.2.39.156]) by femail11.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011229072824.CBLQ2594.femail11.sdc1.sfba.home.com@laptop.baldwin.cx>; Fri, 28 Dec 2001 23:28:24 -0800 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20011222055111.C28FA38CC@overcee.netplex.com.au> Date: Fri, 28 Dec 2001 23:28:12 -0800 (PST) From: John Baldwin To: Peter Wemm Subject: Re: blurk! KSE vs the X86 Cc: arch@FreeBSD.ORG, Julian Elischer Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 22-Dec-01 Peter Wemm wrote: > Julian Elischer wrote: >> >> Ok so we have this wonderful thing called a TSS >> there is one per CPU by default, but you can ask that your process has it >> own.. that would be one per process.. it has such things as the address >> to load the system stack pointer from when running your process and take a >> trap e.g. syscall. >> >> This is in the PCB extension area. At this time there is only the >> capacity to set an extension into the single thread that would want it, >> and it isn't associated with the process as such via the proc structure, >> just via the PCB extension pointer. So since threads are transient in KSE >> processes when the thread migrates away (almost immediatly in some cases) >> you have no trace of your extension area (hense TSS) so at teh next >> swtch() it'll be gone again.. >> the QUICK answer is to say that vm86 and KSE can't be mixed, but >> is that the best solution we can do? > > Do not worry about the "best" yet. Lets get a functional baseline > code set that can actually do an upcall and actually do something useful > before worrying about this sort of thing. > > ie: until we have something functional in the tree, the policy should > be: KSE is not allowed with {VM86, local LDT, PCB extensions [io port > access], etc.} > > The "best" solution will be apparent after we have got the basics > working. LDT is already fine. TSS will be harder as you need a per-process TSS template that each thread builds its TSS from (possibly on the fly on each kernel entry/exit). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message