Is the MMU (Memory Management Unit) chip necessary for a processor to have virtual memory support?
Is it possible to emulate MMU functionality in software? (I am aware that it will probably have a big impact on performance).
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.Sign up to join this community
Any system emulator which emulates a system containing a MMU effectively emulates a MMU in software, so the answer to your question as stated is “yes”. However, virtual memory requires some way of enforcing memory access control, or at least address translation, so it needs either full software emulation of the CPU running the software being controlled, or it needs hardware assistance.
So you could conceivably build a system with no MMU, port QEMU to it, add the missing pieces to make virtual memory actually useful (e.g., add support for swap on the host system), and run a MMU-requiring operating system in QEMU, with all the protection you’d expect in the guest operating system (barring QEMU bugs).
One real, and old, example of an MMU-less “emulation” used to provide virtual memory is the Z-machine, which was capable of paging and swapping its code and data, on 8-bit systems in the late seventies and early eighties. This worked by emulating a virtual processor on the underlying real processor; that way, the interpreter keeps full control over the memory layout which the running program “sees”.
In practice, it’s generally considered that a MMU is required for virtual memory support, at least at the operating system level. As indicated MMU-less kernel?, it is possible to build the Linux kernel so that it can run on systems without a MMU, but the resulting configuration is very unusual and only appropriate for very specific use-cases (with no hostile software in particular). It might not support many scenarios requiring virtual memory (swapping,
It depends on exactly what you call virtual memory. An interesting model is the old Win16 model (best known from the old Windows 3.x, not Windows NT). In that model, you had
LocalUnlock functions. These were a form of cooperative, manual management of virtual memory. As this was done in (application) software, it didn't require an MMU. And memory was virtual in the sense that unlocked memory could be swapped to disk.
However, in the Win16 model there is no protection between different processes. If another process left data in memory, you could overwrite it. This is not a fundamental restriction. With fast SSD's these days, you could remove a non-running process from memory entirely, and do so in a reasonable time.
It's not necessary to have a hardware MMU, if you have software that can swap processes to and from the physical memory.
This was the mode of operation of early multi-tasking operating systems. Only one process is resident in memory at any given time, it is swapped out in its entirety when its time-slice expires (you can see that this becomes problematic with large processes). The memory contents seen by the currently-running process is not the same as that seen by any other process, and each has its own view of the address space.
Some hardware support is helpful - a notion of a "protected" memory area for the OS's own use (e.g. all addresses with MSB set are accessible only in supervisor mode) and a "break" value indicating the highest address in use, but memory management hardware is not a absolute requirement for virtual memory; it's just a particularly effective way to achieve it.
The original commercial machines to do VM did not have MMU – they had VM built into the processor. My current thinking is that MMUs are just an afterthought to put VM on top of non-VM processors. VM was developed at Manchester University, and Burroughs designers were convinced they should include it – although very innovative at the time.
The Burroughs B5000 (now Unisys MCP machines) used memory descriptors which enforce memory boundaries – go outside a boundary and your program gets dumped (respecting boundaries is the basis of a nice society, but some abuse the privilege, so boundaries must be enforced).
Descriptors hold a memory address, block length, and data type, but also the all-important P-bit, or presence bit. The p-bit indicates the block is in memory. A p-bit of zero means the block is on mass storage and the address is the storage address, either in the original program (code or data), or in VM (rolled-out data).
These machines implemented a hierarchical memory model. MMUs seem to be to make up for the deficiencies of flat memory, needing to map user objects into flat memory. J.K. Iliffe also designed ICL machines with this model:
The difference between these machines and most of those of today is that they address the complete system architecture, not just a CPU architecture.
So it seems that not only are MMUs not necessary, but systems are better off without them.
The majority of desktop, laptop, and server processors include one or more TLBs in the memory-management hardware, and it is nearly always present in any processor that utilizes paged or segmented virtual memory.
And then, read about Virtual Memory, and what it really is meant for. The huge virtual address space is not the main idea. Main idea is the caching/buffering, on many levels.
It is far from simple, but this TLB memory cache is an important piece of hardware the kernel's mm subsystem builds upon (otherwise VM would be largely overhead).
virtual memory OR virtual machine. Very different, very connected.
So answer is no, a MMU chip (a separate unit outside the CPU, on the mainboard) is not necessary.
Yes, some hardware MMU (in the CPU) is necessary to think about useful VM at all. (It started with this 8086 segmentation, for x86 platform)