On 02/27/08 05:55, Hugh McIntyre wrote:
Peter Damron wrote:I don't know many of the details of this topic, but I think I can answer some of the high-level issues.The MMU is mapping pages from virtual to physical addresses. The minimum page size on SPARC is 8 KBytes, so the lowest 13 bits of the address is the offset into an 8K page. The MMU does not deal with those page offsets. The encoding you are seeing is that those lowest 13-bits are being used to hold other information. In this case that is the context id, which is probably identical to the getpid() value.Close. But it can't be exactly the pid, since 13 bits is only enough for 0-8191, but pids can go up to at least 30000. So there needs to be (and is) a mapping with not more than 8191 contexts resident in hardware at any one time. [*]
The sparc hardware supports 8192 contexts (well the sun4u hardware I know does, not actually sure of the sun4v stuff). Each unique address space is assigned a unique context number, and if there are more than 8192 address spaces (1 for kernel, > 8191 processes) then some threads may find they need to steal a context first. Recent'ish changes make it more complex than that for scalability reasons on many-cpu systems, but that's the general idea. Cache lines and the like that are virtually tagged (most caches on sparc are VIPT) include this context information. This tells us which lines belong to which context, even if the other virtual indexing info is the same. When a thread runs its assigned context number is written to the context register (there are actually two: primary and secondary context). The ASI used in an instruction access, implicit (uses %asi) or explicit (eg, ldxa) typically is the usual thing that determines which context register contents will be included in forming the combined VA + context etc address we present for translation and will match on in caches and the like (additional rules are spelled out in the architecture guide, eg "nucleus" code at TL>0 always uses context 0 etc). The ASI of 0x82 is usual for a thread running in userland. When a userland thread dives into the kernel (and once we've been through sys_trap to get back to TL0 for a syscall or similar) the primary context register will be 0 for the kernel as, while the secondary context will be that of the user process that made the syscall; we can then access userland addresses using an ASI such as ASI_AIUS "as-if usermode secondary context". Hope that helps Gavin
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
