La puce MMU (Memory Management Unit) est-elle nécessaire pour qu'un processeur prenne en charge la mémoire virtuelle?

14

Est-il possible d'émuler la fonctionnalité MMU dans un logiciel? (Je suis conscient que cela aura probablement un impact important sur les performances).

— yoyo_fun
source

Tout ordinateur pleinement capable peut émuler n'importe quel autre ordinateur avec suffisamment de performances. Ou émulez n'importe quel matériel. La seule question est l'ampleur de la performance atteinte.

— Vality du

chaque processeur a aujourd'hui besoin d'un TLB, il a donc une unité MM intégrée.

— rastafile

22

Tout émulateur de système qui émule un système contenant une MMU émule efficacement une MMU dans un logiciel, donc la réponse à votre question, comme indiqué, est «oui». pourtant , la mémoire virtuelle nécessite un moyen d'imposer un contrôle d'accès à la mémoire, ou au moins une traduction d'adresse, elle nécessite donc soit une émulation logicielle complète du processeur exécutant le logiciel contrôlé, soit une assistance matérielle.

Ainsi, vous pourriez concevoir un système sans MMU, y porter QEMU , ajouter les pièces manquantes pour rendre la mémoire virtuelle réellement utile ( par exemple, , ajouter la prise en charge du swap sur le système hôte) et exécuter un système d'exploitation nécessitant une MMU dans QEMU, avec toute la protection que vous attendez du système d'exploitation invité (à l'exception des bogues QEMU).

Un exemple réel et ancien d'une «émulation» sans MMU utilisée pour fournir de la mémoire virtuelle est la machine Z , qui était capable de paginer et d'échanger son code et ses données, sur des systèmes 8 bits à la fin des années 70 et au début des années 80. . Cela a fonctionné en émulant un processeur virtuel sur le processeur réel sous-jacent; De cette façon, l'interpréteur garde le contrôle total sur la disposition de la mémoire que le programme en cours «voit».

En pratique, on considère généralement qu'une MMU est requise pour la prise en charge de la mémoire virtuelle, au moins au niveau du système d'exploitation. Comme indiqué noyau sans MMU? , il est possible de construire le noyau Linux pour qu'il puisse fonctionner sur des systèmes sans MMU, mais la configuration résultante est très inhabituelle et ne convient que pour des cas d'utilisation très spécifiques (sans logiciel hostile en particulier). Il peut ne pas prendre en charge de nombreux scénarios nécessitant de la mémoire virtuelle (échange, mmap...).

— Stephen Kitt
source

les applications de machine virtuelle ont donc également un composant émulateur MMU?

— yoyo_fun

Oui - pas nécessairement en tant que composant séparé, mais ils ont le support nécessaire dans l'émulation.

— Stephen Kitt

7

@JenniferAnderson: Certains processeurs modernes ont des fonctionnalités qui permettent à l'émulateur de décharger (partiellement) l'émulation MMU vers la MMU elle-même. Par exemple, un programme exécuté à l'intérieur d'un émulateur utilisera lui-même plusieurs pages de mémoire émulées, ces pages de mémoire sont bien sûr "imbriquées" dans les pages de mémoire utilisées par l'émulateur. Les nouveaux processeurs Intel et AMD haut de gamme prennent en charge les tables de pages imbriquées, qui permettent à l'émulateur d'exprimer cette imbrication au sein de la MMU elle-même, au lieu de devoir (cher) l'émuler.

— Jörg W Mittag

@ Jörg en effet, merci pour la clarification. La plupart des hyperviseurs incluent toujours un certain niveau d'émulation logicielle, de sorte qu'ils fonctionnent sans le support matériel supplémentaire. J'ai été aveuglé par l'aspect «Est-ce possible» de la question ;-).

— Stephen Kitt

3

@JenniferAnderson: Oui, cette fonctionnalité a été spécifiquement introduite pour la para-virtualisation. (Notez qu'il n'y a rien de nouveau, la para-virtualisation assistée par matériel existe dans le monde du mainframe depuis le début des années 1960.) Il s'avère cependant qu'elle peut également être utilisée pour d'autres applications intéressantes, telles que l'accélération de Garbage Collection (voir le collecteur C4 dans la JVM Zing d'Azul pour un exemple). Cependant, notez que tout cela fonctionne dans les deux sens: de la même manière que l' extension des MMU avec prise en charge de la virtualisation n'est rien de plus qu'une optimisation des performances et de la virtualisation…

— Jörg W Mittag

7

Cela dépend exactement de ce que vous appelez la mémoire virtuelle. Un modèle intéressant est l'ancien modèle Win16 (mieux connu de l'ancien Windows 3.x, pas de Windows NT). Dans ce modèle, vous aviez GlobalLocket GlobalUnlock, LocalLocket les LocalUnlockfonctions. Il s'agissait d'une forme de gestion coopérative et manuelle de la mémoire virtuelle. Comme cela était fait dans un logiciel (d'application), cela ne nécessitait pas de MMU. Et la mémoire était virtuelle dans le sens où la mémoire déverrouillée pouvait être échangée sur le disque.

Cependant, dans le modèle Win16, il n'y a pas de protection entre différents processus. Si un autre processus laissait des données en mémoire, vous pouviez les écraser. Ce n'est pas une restriction fondamentale. Avec les SSD rapides de nos jours, vous pouvez supprimer complètement un processus non en cours d'exécution de la mémoire, et le faire dans un délai raisonnable.

— MSalters
source

7

Il n'est pas nécessaire d'avoir une MMU matérielle, si vous avez un logiciel qui peut échanger des processus vers et depuis la mémoire physique.

C'était le mode de fonctionnement des premiers systèmes d'exploitation multitâche. Un seul processus réside dans la mémoire à un moment donné, il est échangé dans son intégralité à l'expiration de sa tranche de temps (vous pouvez voir que cela devient problématique avec les grands processus). Le contenu de la mémoire vu par le processus en cours d'exécution n'est pas le même que celui vu par tout autre processus, et chacun a sa propre vue de l'espace d'adressage.

Une prise en charge matérielle est utile - une notion de zone de mémoire "protégée" pour le propre usage du système d'exploitation (par exemple, toutes les adresses avec un ensemble MSB sont accessibles uniquement en mode superviseur) et une valeur de "rupture" indiquant l'adresse la plus élevée utilisée, mais la gestion de la mémoire le matériel n'est pas une exigence absolue pour la mémoire virtuelle; c'est juste un moyen particulièrement efficace pour y parvenir.

— Toby Speight
source

2

Ce n'est pas vraiment de la mémoire virtuelle, c'est juste un échange de processus ... (Nous aurions vraiment besoin de définir la «mémoire virtuelle» pour une bonne réponse à cette question!)

— Stephen Kitt

Chaque processus a sa propre vue de l'espace d'adressage - je vais modifier pour clarifier la définition que j'utilise.

— Toby Speight

C'est vrai, mais c'est le même mappage un à un pour tous les processus. (Du point de vue des processus, il n'y a pas beaucoup de différence, donc il n'y a pas vraiment d'argument là-bas ...)

— Stephen Kitt

0

Les machines commerciales d'origine pour faire de la VM n'avaient pas de MMU - elles avaient une VM intégrée dans le processeur. Ma pensée actuelle est que les MMU ne sont qu'une réflexion après coup pour mettre la VM au-dessus des processeurs non-VM. La VM a été développée à l'Université de Manchester, et les concepteurs de Burroughs étaient convaincus qu'ils devraient l'inclure - bien que très innovant à l'époque.

Les Burroughs B5000 (maintenant les machines Unisys MCP) ont utilisé des descripteurs de mémoire qui appliquent les limites de la mémoire - sortez des limites et votre programme est vidé (le respect des limites est la base d'une société agréable, mais certains abusent du privilège, donc les limites doivent être appliquées).

Les descripteurs contiennent une adresse mémoire, une longueur de bloc et un type de données, mais également le bit P le plus important ou le bit de présence. Le p-bit indique que le bloc est en mémoire. Un p-bit de zéro signifie que le bloc est sur le stockage de masse et que l'adresse est l'adresse de stockage, soit dans le programme d'origine (code ou données), soit dans VM (données déployées).

Ces machines ont implémenté un modèle de mémoire hiérarchique. Les MMU semblent compenser les carences de la mémoire plate, nécessitant de mapper les objets utilisateur en mémoire plate. JK Iliffe a également conçu des machines ICL avec ce modèle:

http://www.computerconservationsociety.org/resurrection/res74.htm#f

https://en.wikipedia.org/wiki/Burroughs_large_systems

La différence entre ces machines et la plupart de celles d'aujourd'hui est qu'elles traitent de l'architecture système complète, et pas seulement d'une architecture CPU.

Il semble donc que non seulement les MMU ne sont pas nécessaires, mais les systèmes sont mieux sans eux.

— user3717661
source

-1

La majorité des processeurs de bureau, portables et serveurs incluent un ou plusieurs TLB dans le matériel de gestion de la mémoire, et il est presque toujours présent dans tout processeur qui utilise une mémoire virtuelle paginée ou segmentée .

Translation_lookaside_buffer

Et puis, lisez à propos de la mémoire virtuelle et à quoi elle est vraiment destinée. L'énorme espace d'adressage virtuel n'est pas l'idée principale. L'idée principale est la mise en cache / tampon, à plusieurs niveaux.

C'est loin d'être simple, mais ce cache de mémoire TLB est un élément matériel important sur lequel le sous-système mm du noyau s'appuie (sinon VM serait largement surchargé).

VM =

mémoire virtuelle OU machine virtuelle. Très différent, très connecté.

La réponse est donc non, une puce MMU (une unité séparée en dehors du CPU, sur la carte mère) n'est pas nécessaire.

Oui, certains MMU matériels (dans le CPU) sont nécessaires pour penser à une VM utile. (Cela a commencé avec cette segmentation 8086 , pour la plate-forme x86)

— rastafile
source