From owner-freebsd-hackers Tue Jun 30 15:10:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA14584 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 15:10:59 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp01.primenet.com (daemon@smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA14578 for ; Tue, 30 Jun 1998 15:10:56 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id PAA00381; Tue, 30 Jun 1998 15:10:56 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd000345; Tue Jun 30 15:10:51 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA22715; Tue, 30 Jun 1998 15:10:50 -0700 (MST) From: Terry Lambert Message-Id: <199806302210.PAA22715@usr02.primenet.com> Subject: Re: Trap types and AST To: bf20761@binghamton.edu (zhihuizhang) Date: Tue, 30 Jun 1998 22:10:50 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: from "zhihuizhang" at Jun 30, 98 04:16:39 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I am trying to trace down how the vm_fault() gets called via trap > mechanism and I find something do not understand: > > (1) The value of T_PAGEFLT is 12 not 14. Why trap type definitions in > trap.h do not conform to the trap numbers defined in 80386 hardware > terminology (one more example is T_NMI which is defined as 19 not 2). I believe this is because of the Pentium bug workaround. > (2) The setidt() in file machdep.c set the DPL for page fault as SEL_KPL. > This will prevent a normal process from handling page fault, only kernel > process can. Why is the case? (this question requires the understanding > of gate descriptors). A process can handle page faults for pages not assigned to it by the kernel: it does this by establishing a handler for SIGSEGV. For pages that are part of the process virtual address space, it does not make sense for the fault to be taken by the process, since the process can not be sure that the pages needed to handle the fault will not, themselves, need to be paged in. Is your intent to implement MACH "external pagers"? I would discourage this, since it is very heavy-weight to have to swap in another process in order to swap in/out your pages. This is because the FreeBSD kernel does not support kernel preemption (ie: it is not fully thread reentrant -- equivalent to SMP reentrant), a facility for dealing with hard realtime. You would need your pager swapped in *now*, not later, when the quantum clock fired one or more times. In general, this would be better accomplished with a "kernel process", such as is used by the existing VM system. It exists to provide a kernel stack and an accounting context, for the most part. If the intent is to support a VMM (Virtual Machine Manager), you would be better off putting that code in the kernel, as part of the VM86 code. How to do this is well documented in: Protected Mode Software Architecture Tom Shanley MindShare, Inc. PC System Architecture Series ISBN: 0-201-55447-X Which basically documents everything you need to consider to implement a VMM capable of *efficiently* running DOS programs or using BIOS based drivers under a protected mode OS. > (3) I come across many occurrences of AST, such as SWI_AST_MASK. Clearly, > AST does not stand for the PC manufacturer here. I read in Mailing list > that AST is an event. Can anyone tell me what does AST stand for and how > it is used? Asynchronous System Trap. The terminology comes from RT11/RSX/VMS/etc. family OS's from DEC. It means an interrupt callback to kernel code; in VMS, it means a supervisor callback to user space code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message