Date: Sun, 1 Dec 1996 16:23:22 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: toor@dyson.iquest.net (John S. Dyson) Cc: msmith@atrad.adelaide.edu.au, imp@village.org, platforms@freebsd.org, dyson@freebsd.org Subject: Re: FreeBSD/MIPS anybody Message-ID: <199612012323.QAA09228@phaeton.artisoft.com> In-Reply-To: <199611300612.BAA09955@dyson.iquest.net> from "John S. Dyson" at Nov 30, 96 01:12:36 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I do think that problems with previous port attempts > are due to a lack of understanding of how the code works. The code > is subtile^2. > > There are some X86 optimizations, but those are implemented mostly > in the pmap code. Those routines should be noops on architectures > like R4000, where they have software managed TLB's. We don't really > need the reference bit, and our performance will degrade under heavy > load without it. But, NO OS is going to do as well without that bit. Is there any way you can seperate the consumer interface code from the implementation interface code? Specifically, I'd like to see some abstract objects, and documentation (I'm willing to help out writing it, but as John points out, the VM system is, to a large degree, a black box) such as: ======================================================================= ... 4.0.0 Porting This section describes the necessary steps for porting the VM services to other architectures. ... 4.1.0 Prerequisites Each architecture that will support the VM system will need to support the following logical abstractions: ... ... ... 4.1.1 Functional abstraction The VM system is abstracted by ... . This allows the use of a layered "pseudo-VM" to hide architectural crudities from the user of the VM system (for example, the VFS). An example of this might be the abstractions necessary to support SMP on Intel processors. Any dependencies here should be hidden below the VM so that upper level code will not have to change when the underlying architecture is changed. Restated, this means the the VM functional abstraction is a very important part of the FreeBSD HAL (Hardware Abstration Layer). 4.2.0 A porting example To port the VM system to the Motorolla PPC603 (as used in the Apple PowerMac, Motorolla Ultra, Arrow Electronics OEM, FirePower OEM, and BeBOX), the following functions will need to be defined: ... ... ... 4.2.1 Emulating hardware function in software Because the PPC603 does not support ..., the following will need to be emulated in software: ... ... ... To do this, we can rely on the ... feature of the PPC to trigger pseudo-events when the following conditions occur: ... ... ... The upper layer code does not distinguish between events (real events) and emulated events resulting from software detection (pseudo events). Remember back in section 3.1.2 where we discussed emulation of the write protect bit when copying data from user space to kernel space, and section 3.1.4 where we discussed emulation of a write protect that works in kernel mode for kernel-kernel copying, for all Intel processors. ... ... ... ... 4.3.5 L1 and L2 Cache interaction and MP In section 4.3.3, we introduced the idea of page coloring. Some architectures, however, can not support MP an an L2 cache simultaneously. A specific example is the BeBox, which replaces the L2 cache with the second processor. This is because it can not support distributed cache coherency -- it simply does not have the necessary pins to notify the processor of a cache event. The discussion of MESI noted the situations in which SMP interactions can cause conditions requiring intervention, and how these events can be generated in hardware, or how they may be emulated as pseudo-events, so that cache coherency can be maintained across several processors. Our example port, the PPC 603, can not support this. Instead, an SMP design for the PPC603 can handle processor coherency requests as L2 cache coherency requests. This means that you can't have an L2 cache at the same time you support more than one processor. We intentionally picked the PPC 603 as our example, not only because of its use of soft page structures and how they must be emulated in software, but because there is an existing PPC 603 implementation of SMP using L2 cache replacement. This implementation is the BeBox. Remember how MESI works... clearly, the L2 cache can not initiate events as if it were a processor... it's not an equal citizin. In particular, out of "MESI", it can't support "S" ... "Shared". Instead, the BeBox uses an MEI (Modified Exclusive Invalid) architecture. This means some changes for the VM system. Consider the following: ... ... ... ... ======================================================================= Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612012323.QAA09228>