cpu - Virtual Memory and MMU: when are they used and when not?
2014-04
iMineLink
I'm wondering about how a Virtual Memory system could be managed alongside with a MMU when there's the need to mantain some "fixed" addresses in the address space.
For example, when a machine boots up, the CPU starts reading the first instruction from a fixed address (that is mapped to some kind of ROM), then gives addresses to pheriperals (if the Memory Mapped I/O system is used), and then the OS is bootstrapped. I also know that interrupt routines and such things need to be at "fixed" position in memory, and these things are loaded by the OS.
I may think that MMU is disabled in such a process and then it is enabled after the OS loaded.
I may think that the processes above uses system address space and that the system address space is not virtualized, despite the user address space actually is.
This will result in a pool of physical addresses that remains the same in order to access I/O peripherals, interrupt routines and so on, and a virtual user space managed by the MMU, where the processes can elaborate all the data they needs to elaborate, demanding to the OS the access to I/O peripherals.
But i'm not sure of these things. So I ask you, when the MMU is actually enabled? Does it deal with all the addresses, or only with the ones of the user space? Is it true that some addresses can bypass the MMU even when the system is running, in order to access fixed memory positions? Or am I missing some important clues?
ultrasawblade
x86 CPUs boot up in a "real mode" - basically, 16-bit mode where the CPU can only see the first 1MB of RAM. One of the first tasks of a BIOS bootloader (or UEFI may do this directly) is to switch the CPU into "protected" mode. Protected memory is available in this mode, and the CPU has privilege levels in this mode - generally "kernel" and "user."
I'm a bit fuzzy on this, but how the MMU maps memory is controlled by the Global Descriptor Table (GDT). Kernel mode can change the GDT, user mode cannot.
So when kernel mode is entered, it can set the GDT to a memory mapping that either identity maps all memory (i.e. acts like it's not mapped at all) or maps it in a way that gives it access to all devices, etc. When it returns to user mode, it can load more restrictive GDT before handing control back.
I might be wrong - it may be when the CPU enters kernel mode it simply disables the MMU but I do believe it can be used by kernel mode as well in this fashion.
Shaul
Possible Duplicate:
Memory sticks, 32 and 64 Bit OS
I have a VMWare virtual machine on my computer (Host: Win7 x64, VM: Win7 x86). The host has 8GB, of which I've allocated 4GB to the VM, as you can see in the below screen shot:
But when I go to the VM itself, the computer seems to think it only has 3 GB - see screenshot from Task Manager:
Note the total physical memory of 3071 GB. I have tried powering down the VM and restarting, but it still doesn't use the extra memory.
See also my screen shot of the system:
Is this a limitation of VMWare? Or is there some secret switch I need to flip?
Andrew J. Brehm
Generally a 32 bit operating system can only see 4 GB of memory, including devices (graphics card etc.). This results in the OS seeing 3 GB of physical memory, even if more than 3 GB is installed. This is true for physical machines and VMs.
32 bit Windows XP, like Windows 2003 Server and later, supported PAE (Physical Address Extensions) which allowed it to use more than 4 GB of physical memory. Windows Vista and Windows 7 do not support PAE any more because of driver incompatibilities that were already present in Windows XP.
Thus generally only 64 bit Windows supports more than 3 GB of physical memory plus 32 bit versions of Windows supporting PAE (Windows 2000, Windows XP, Windows Server 2003, Windows Server 2008); while 32 bit versions of Windows that do not support PAE (Windows Vista, Windows 7) cannot usually see more than 3 GB of physical memory.
Again note that memory assigned to a VM counts as "physical memory" for the OS running in the VM.
Zack Bloom
32 bit machines may only address (see) 3 GB of ram. Your VM may be granting it 4 GB, but it can only use 3 GB of it. If you wish to use the remaining space, install a 64 bit OS in the VM.
Mokubai
Chances are that the VM is running in the host OS as a 32-bit program so that it can properly support a 32-bit guest. This means that it is subject to 32-bit limitations and as such the memory it can allocate is subject to the 3GB Virtual Address Space and 1GB Kernel Space limitations that are placed on 32-bit programs.
A nice blog about it: http://blogs.technet.com/b/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx
From that page your address space for the hosting program would look like this:
And your VM would be locked into the 3GB space as the final GB is required for the 32 bit program to have access to the system drivers on your host.
paradroid
If you see this happening with 64-bit VMs, it's because some VMware products, like ESX/ESXi and Workstation can overcommit RAM to virtual machines.
This allows several VMs to run with more RAM allocated to them than the host machine physically has. While the RAM is overcommited to them, they only actually receive the RAM dynamically once they actually need it.