home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / sys / sun / misc / 3734 < prev    next >
Encoding:
Text File  |  1992-08-17  |  5.1 KB  |  112 lines
  1. Path: sparky!uunet!wupost!cs.utexas.edu!wotan.compaq.com!moxie!texsun!cronkite.Central.Sun.COM!news2me.ebay.sun.com!exodus.Eng.Sun.COM!nonsequitur!narad
  2. From: narad@nonsequitur.Eng.Sun.COM (Chuck Narad)
  3. Newsgroups: comp.sys.sun.misc
  4. Subject: Re: SPARC virtual to physical address translation
  5. Message-ID: <l8vrtbINN38q@exodus.Eng.Sun.COM>
  6. Date: 17 Aug 92 18:27:55 GMT
  7. References: <Bt3z0L.7K3@gumby.ocs.com>
  8. Reply-To: narad@nonsequitur.Eng.Sun.COM
  9. Organization: Sun Microsystems
  10. Lines: 99
  11. NNTP-Posting-Host: nonsequitur
  12.  
  13. In article 7K3@gumby.ocs.com, obi@gumby.ocs.com (Kuryan "Obi" Thomas) writes:
  14. >Would some kind netperson please explain (by email if possible) how 32-bit
  15. >virtual addresses are translated into physical addresses using the SPARC
  16. >"reference MMU," whatever that is? I understand there is a two-level
  17. >translation scheme, using a segment map and a page map. There's also
  18. >something called a "context register." I'm clueless beyond this point.
  19. >
  20. >What I'd like to know specifically is:
  21. >
  22. >1. What is the context register? Is it something that establishes how a
  23. >   particular process's virtual addresses are translated to physical?
  24. >
  25. >2. How does the two-level translation take place?
  26. >
  27. >3. What is the segment map? The page map? What is a page map entry group
  28. >   (PMEG) and why are page map entries grouped?
  29. >
  30. >4. How are the 32 bits of a virtual address mapped to 32 bits of physical
  31. >   address? (E.g., the low-order 12 bits is the offset in a page, the next
  32. >   5 bits are the page number...that sort of thing).
  33. >
  34. >5. Any other nuggets of info you care to share.
  35. >
  36. >I'm just a curious user, so any level of detail and partial answers are
  37. >welcome. I've been reading some of the papers in "The SPARC Technical
  38. >Papers," (Springer-Verlag 1991) and I'm now more confused than I was
  39. >before.
  40. >
  41. >Thank you for any and all responses. I'll post a summary if there's enough
  42. >excitement.
  43.  
  44.  
  45. First of all, the 2-level scheme that you describe is the 'Sun' MMU
  46. which was used in Sun-2, Sun-3, Sun-4, and sun4c machines.  The MMU
  47. was actually a cascaded set of SRAM which parsed the virtual address 
  48. into segments and pages (and in one implementation a larger area
  49. called regions).  The split among region, segment, and page was
  50. implementation-specific.  These tables were manged by SW as a 
  51. set of multi-level TLB's, and any miss or protection violation was
  52. handled by the VM code in the OS.  Page sizes were 2K, 8K, and 4K
  53. in different generations.
  54.  
  55. The PMEG was the intermediate index between the first and second
  56. level of SRAM.
  57.  
  58. The Context Register allows each running process to have its own address
  59. space.  Entries in the MMU are tagged by context number, and the current
  60. context (value in the register) is used as part of the parsing information.
  61. This allows the MMU to have the translations for several processes resident
  62. at any time, thus supporting rapid switching between contexts.  Typical
  63. implementations have 8-64 hardware contexts.  The OS must manage
  64. removing a process from a context and assigning the context number
  65. to a different process if that resource (number of contexts) runs dry.
  66.  
  67. The SPARC Reference MMU (SRMMU) was introduced along with SPARC V.8.
  68. It is a TLB-based MMU design that uses tables in main memory to support
  69. translation, and a set of TLB's in the processor to hold the current working
  70. set of tranlsations.  The SRMMU takes a 32-bit virtual address and translates
  71. it to a 36-bit physical address.  Included in the translation is a rich
  72. set of protection modes, attributes such as 'cacheable', and referenced
  73. and modified status.
  74.  
  75. SRMMU supports a large number of contexts, since that is no longer limited
  76. by the size of fast SRAM.  Implementations in use today support 4K to 64K
  77. active contexts.  The SRMMU supports 4 levels of table; if we correlate
  78. those with the old Sun MMU we see:
  79.  
  80.     LEVEL    Sun MMU EQUIV    INDEX WITH
  81.     -----------------------------------------------
  82.     Level 0:    Context base pointer    Context #
  83.     Level 1:    Region table        VA<31:24>
  84.     Level 2:    Segment table        VA<23:18>
  85.     Level 3:    Page table        VA<17:12>
  86.         page offset        VA<11:0>
  87.  
  88. At any level the SRMMU can encounter a Page Table Pointer (PTP) or a Page
  89. Table Entry (PTE) which contains the translation, protection, etc.
  90.  
  91. Depending at which level the PTP is encountered the page size varies; 
  92. a PTE at level 3 maps a 4K page, at level 2 maps a 256K page, at level
  93. 1 maps a 16 MB page, and at level 0 maps a 4GB page.
  94.  
  95. A register called the Context Table Pointer tells the MMU where to find
  96. the first table in the MMU.  TLB misses are serviced by the hardware doing
  97. a 'table walk' to find the translation; if no translation is found, the VM
  98. code is called for service (page fault).
  99.  
  100. A detailed description of the SRMMU can be found in the SPARC Architecture
  101. Manual version 8, available from SPARC International.
  102.  
  103. Sun is using the SRMMU in the SS600MP family and in SS10.  Machines using
  104. the SRMMU at Sun are all in the Sun-4m family, which is a system architecture
  105. utilizing multiple processors, SRMMU, and other new features.
  106.  
  107. The SRMMU is also used by other SPARC vendors in their products; some
  108. are shipping today.
  109.  
  110. chas/
  111. #include <std.disclaimer>: speaking for myself, not my employer
  112.