Czy układ MMU (Memory Management Unit) jest niezbędny, aby procesor mógł obsługiwać pamięć wirtualną?
Czy można emulować funkcjonalność MMU w oprogramowaniu? (Jestem świadomy, że prawdopodobnie będzie to miało duży wpływ na wydajność).
14
Odpowiedzi:
Każdy emulator systemu, który emuluje system zawierający MMU, skutecznie emuluje MMU w oprogramowaniu, więc odpowiedź na zadane pytanie brzmi „tak”. Jednakże , pamięć wirtualna wymaga jakiś sposób egzekwowania kontroli dostępu w pamięci, lub przynajmniej translacji adresów, więc musi albo pełną emulację oprogramowania CPU uruchomiony program jest kontrolowany, czy potrzebuje pomocy sprzętowej.
Możesz więc zbudować system bez MMU, podłączyć do niego QEMU , dodać brakujące elementy, aby pamięć wirtualna rzeczywiście się przydała ( np. Dodać obsługę wymiany w systemie hosta), i uruchomić system operacyjny wymagający MMU w QEMU, z całą ochroną, jakiej można oczekiwać w systemie operacyjnym gościa (z wyjątkiem błędów QEMU).
Jednym z prawdziwych i starych przykładów „emulacji” bez MMU wykorzystywanej do zapewnienia pamięci wirtualnej jest maszyna Z , która była zdolna do stronicowania i wymiany swojego kodu i danych w systemach 8-bitowych na przełomie lat siedemdziesiątych i osiemdziesiątych . Działa to poprzez emulację wirtualnego procesora na prawdziwym procesorze bazowym; w ten sposób interpreter zachowuje pełną kontrolę nad układem pamięci, który „widzi” uruchomiony program.
W praktyce powszechnie uważa się, że do obsługi pamięci wirtualnej wymagana jest jednostka MMU, przynajmniej na poziomie systemu operacyjnego. Jak wskazano jądro bez MMU? , możliwe jest zbudowanie jądra Linux, aby mogło działać na systemach bez MMU, ale wynikowa konfiguracja jest bardzo nietypowa i odpowiednia tylko w bardzo specyficznych przypadkach użycia (w szczególności bez wrogiego oprogramowania). Może nie obsługiwać wielu scenariuszy wymagających pamięci wirtualnej (zamiana,
mmap...).źródło
Zależy to dokładnie od tego, co nazywamy pamięcią wirtualną. Ciekawym modelem jest stary model Win16 (najlepiej znany ze starego Windows 3.x, a nie Windows NT). W tym modelu, trzeba było
GlobalLockiGlobalUnlock,LocalLockiLocalUnlockfunkcje. Były one formą kooperacyjnego, ręcznego zarządzania pamięcią wirtualną. Ponieważ zostało to zrobione w oprogramowaniu (aplikacyjnym), nie wymagało MMU. Pamięć była wirtualna w tym sensie, że odblokowaną pamięć można było zamienić na dysk.Jednak w modelu Win16 nie ma ochrony między różnymi procesami. Jeśli inny proces pozostawił dane w pamięci, możesz je zastąpić. To nie jest podstawowe ograniczenie. Dzięki szybkim dyskom SSD możesz całkowicie usunąć niedziałający proces z pamięci i zrobić to w rozsądnym czasie.
źródło
Sprzętowe MMU nie jest konieczne, jeśli masz oprogramowanie, które może zamieniać procesy do iz pamięci fizycznej.
Był to tryb działania wczesnych wielozadaniowych systemów operacyjnych. W danym momencie w pamięci znajduje się tylko jeden proces, jest on zamieniany w całości po upływie przedziału czasu (widać, że staje się to problematyczne w przypadku dużych procesów). Zawartość pamięci widziana przez aktualnie działający proces nie jest taka sama jak widziane przez jakikolwiek inny proces i każdy ma swój własny widok przestrzeni adresowej.
Pomocna jest część wsparcia sprzętowego - pojęcie „chronionego” obszaru pamięci na własny użytek systemu operacyjnego (np. Wszystkie adresy z ustawionym zestawem MSB są dostępne tylko w trybie superwizora) oraz wartość „przerwy” wskazująca najwyższy używany adres, ale zarządzanie pamięcią sprzęt nie jest bezwzględnym wymogiem dla pamięci wirtualnej; to tylko wyjątkowo skuteczny sposób na osiągnięcie tego.
źródło
Oryginalne maszyny komercyjne do wykonywania VM nie miały MMU - miały wbudowaną VM w procesor. Moje obecne myślenie jest takie, że MMU to tylko refleksja, aby umieścić VM na procesorach innych niż VM. VM został opracowany na Uniwersytecie w Manchesterze, a projektanci Burroughs byli przekonani, że powinni go uwzględnić - choć w tamtym czasie bardzo innowacyjni.
Burroughs B5000 (obecnie maszyny Unisys MCP) używał deskryptorów pamięci, które wymuszają granice pamięci - wychodzą poza granice, a twój program zostaje zrzucony (przestrzeganie granic jest podstawą ładnego społeczeństwa, ale niektórzy nadużywają przywileju, więc granice muszą być egzekwowane).
Deskryptory przechowują adres pamięci, długość bloku i typ danych, ale także najważniejszy bit P lub bit obecności. Bit p oznacza, że blok jest w pamięci. P-bit zero oznacza, że blok jest w pamięci masowej, a adresem jest adres pamięci, albo w oryginalnym programie (kod lub dane), albo w maszynie wirtualnej (dane rozwijane).
Te maszyny zaimplementowały hierarchiczny model pamięci. MMU wydają się uzupełniać braki w płaskiej pamięci, ponieważ muszą mapować obiekty użytkownika w płaską pamięć. JK Iliffe zaprojektował również maszyny ICL z tym modelem:
http://www.computerconservationsociety.org/resurrection/res74.htm#f
https://en.wikipedia.org/wiki/Burroughs_large_systems
Różnica między tymi maszynami a większością dzisiejszych polega na tym, że dotyczą one pełnej architektury systemu, a nie tylko architektury procesora.
Wygląda więc na to, że MMU nie tylko nie są konieczne, ale bez nich lepiej jest mieć systemy.
źródło
Translation_lookaside_buffer
Następnie przeczytaj o pamięci wirtualnej i jej przeznaczeniu. Ogromna wirtualna przestrzeń adresowa nie jest główną ideą. Główną ideą jest buforowanie / buforowanie na wielu poziomach.
Nie jest to wcale proste, ale ta pamięć podręczna TLB jest ważnym sprzętem, na którym opiera się podsystem mm jądra (w przeciwnym razie VM byłby w dużej mierze narzutem).
VM =
pamięć wirtualna LUB maszyna wirtualna. Bardzo różne, bardzo powiązane.
Więc odpowiedź brzmi: nie znaczy, MMU Chip (oddzielna jednostka poza CPU na płycie głównej) nie jest konieczne.
Tak, niektóre sprzętowe MMU (w CPU) są konieczne, aby w ogóle pomyśleć o użytecznej maszynie wirtualnej. (Zaczęło się od tej segmentacji 8086 , dla platformy x86)
źródło