Follow us on Twitter
Follow us on FacebookHow AMD's Pacifica handles memory
@ 2005/06/08* YOU CAN FIND the first part of this article on AMD Pacifica, here. Part Three will be published tomorrow.
FIRST A LITTLE primer on memory management on x86 hardware, vastly simplified for sanity and brevity. In the good old days, you could only run a single program on a computer at once, and life was easy. Soon someone had the bright idea of running multiple programs on the same machine at the same time, which led to all sorts of problems. If you had a program that needed 1MB of memory, and you had 1MB of memory, all went smoothly. If you had 2MB of memory, you used 1MB, and the other 1MB just sat there.
Now, if you have 2MB of memory, and you run two programs that each need 1MB of memory, you should be OK, right? Well, theory and reality often don't mix well and in this case, they tended not to mix well at first. If a program thinks it is alone in the world, and allocates memory starting at 0 and running to 1MB, that is just fine. When the second program starts up and tries to allocate memory at 0 to 1MB, bad things happen.
This was soon fixed by giving a program enough awareness to allocate space where others were not rather than over the top of their neighbors. This worked well enough to prevent immediate crashes, but if a program had a bug, or it tried to write to an address owned by the other guy, much crashing ensued. It was a volatile mess.
Along came the answer - the Memory Management Unit (MMU). What this did is allowed the programs to request whatever memory they needed, and then translated that into whatever was actually available. Whenever the program requested memory, the MMU simply translated the request to where it put the needed pages earlier.
Using the earlier example, the MMU would take the first program and give it 0 to 1MB. When the second program requested the same 1MB starting at 0, the MMU would give it 1MB to 2MB, and in effect lie to the second app so it thought it was getting 0 to 1MB. The MMU not only translated the requests on the fly, but also kept each program in its own sandbox. You were stuck in your own space, and could not go into the other program's area even if you wanted to.
There is a register in x86 called CR3, and again vastly simplifying, it keeps tabs on what real memory address a program goes to when it is being redirected. If a program asks for an address starting at 1MB, and the MMU redirects it to start at 4MB, CR3 contains the address that the information resides, in this case, it would be 4MB. This is the job of the OS running in ring 0, ring 3 programs should not see or modify this.
The new modes add on to this, and of the two, Shadow Page Tables (SPT) does less in hardware, and requires more software intervention from a VMM. The page tables are not really virtualised in hardware, they are kept up by the VMM in software, and there is only one set of them. The host has complete control over CR3, and the guest is locked out.
The VMM does this by setting all of the guest's page tables to read only, and intercepts all calls to CR3. If a guest OS wants to write to CR3, the VMM is called, and it figures out what the guest should be seeing, and does it for the guest. Instead of a doing a single call, there is a VM_Exit, lots of calls, and lots of calculations. In case it is not all that obvious, this is not the fastest solution in the world.
What it does however is provide the guest OS with its own little world. The guest can do everything it needs to, and the illusion that it is running all by itself is maintained. It does require a lot of programming and a lot of overhead to accomplish.
FIRST A LITTLE primer on memory management on x86 hardware, vastly simplified for sanity and brevity. In the good old days, you could only run a single program on a computer at once, and life was easy. Soon someone had the bright idea of running multiple programs on the same machine at the same time, which led to all sorts of problems. If you had a program that needed 1MB of memory, and you had 1MB of memory, all went smoothly. If you had 2MB of memory, you used 1MB, and the other 1MB just sat there.
Now, if you have 2MB of memory, and you run two programs that each need 1MB of memory, you should be OK, right? Well, theory and reality often don't mix well and in this case, they tended not to mix well at first. If a program thinks it is alone in the world, and allocates memory starting at 0 and running to 1MB, that is just fine. When the second program starts up and tries to allocate memory at 0 to 1MB, bad things happen.
This was soon fixed by giving a program enough awareness to allocate space where others were not rather than over the top of their neighbors. This worked well enough to prevent immediate crashes, but if a program had a bug, or it tried to write to an address owned by the other guy, much crashing ensued. It was a volatile mess.
Along came the answer - the Memory Management Unit (MMU). What this did is allowed the programs to request whatever memory they needed, and then translated that into whatever was actually available. Whenever the program requested memory, the MMU simply translated the request to where it put the needed pages earlier.
Using the earlier example, the MMU would take the first program and give it 0 to 1MB. When the second program requested the same 1MB starting at 0, the MMU would give it 1MB to 2MB, and in effect lie to the second app so it thought it was getting 0 to 1MB. The MMU not only translated the requests on the fly, but also kept each program in its own sandbox. You were stuck in your own space, and could not go into the other program's area even if you wanted to.
There is a register in x86 called CR3, and again vastly simplifying, it keeps tabs on what real memory address a program goes to when it is being redirected. If a program asks for an address starting at 1MB, and the MMU redirects it to start at 4MB, CR3 contains the address that the information resides, in this case, it would be 4MB. This is the job of the OS running in ring 0, ring 3 programs should not see or modify this.
The new modes add on to this, and of the two, Shadow Page Tables (SPT) does less in hardware, and requires more software intervention from a VMM. The page tables are not really virtualised in hardware, they are kept up by the VMM in software, and there is only one set of them. The host has complete control over CR3, and the guest is locked out.
The VMM does this by setting all of the guest's page tables to read only, and intercepts all calls to CR3. If a guest OS wants to write to CR3, the VMM is called, and it figures out what the guest should be seeing, and does it for the guest. Instead of a doing a single call, there is a VM_Exit, lots of calls, and lots of calculations. In case it is not all that obvious, this is not the fastest solution in the world.
What it does however is provide the guest OS with its own little world. The guest can do everything it needs to, and the illusion that it is running all by itself is maintained. It does require a lot of programming and a lot of overhead to accomplish.
