Author: Martin Ruckert
The problem of virtualizing is the transition from an Application running on a true OS, running on real Hardware, to an Application running on a Virtual OS, running itself on an OS, making it look like the Virtual OS would run directly on the real (or virtual) hardware.
There are two separate issues to consider:
Finally, MMIX supporting virtualization, implies
Achieving 1. with MMIX is not very difficult. The interface is limited to forced and dynamic TRAPS and RESUME 1. With some help by the host operating system, TRAPS from the application can lead to a RESUME 1 into the Virtual OS, just as if the TRAP had directly been routed there.
A RESUME 1 by the Virtual OS will TRAP by itself, since RESUME 1 is reserved for the host OS. The host OS can redirect the attempted RESUME 1 to the application.
Achieving 2. with MMIX requires some changes:
a) The virtual OS needs to run in the negative address space. This is currently not possible and requires an extension to the handling of virtual addresses.
b) The virtual OS will write to special registers (rI, rK, rQ, rT, rU, rV, and rTT) with the permission bit in rK set and it will change other special registers (rBB, rWW, rXX, rYY, rZZ) unaware that these might change any time due to a dynamic trap. It will further read these registers and expect the values it has written there.
c) The virtual OS wants to organize the page tables for the application.
d) The virtual OS expects dynamic traps to occur when e.g. the virtual devices trigger the respective interrupts.
a) Negative addresses, while not normally used, are allowed for applications and are considered virtual addresses in a separate segment, if the protection bit in rK is set.
b) A virtual machine monitor build into the host OS can allow the virtual guest OS to write its own copies of the protected special registers: When the PUT instruction issues a protection fault, the host OS gets control and can store the value intended for the special register in RAM. To allow also reading these private copies, also the corresponding GET instruction should cause a trap (preferably with ropcode=2). The virtual machine monitor in the host OS can then retrieve the private copy and return it. This mechanism should be extended to registers that currently do not cause a protection fault (rWW, rXX, rYY, rZZ) because these might change unexpectedly due to a dynamic trap and hence the host OS needs to maintain private copies. The present mode of operation, where these registers are readable and writable by the application can easily be restored by an OS that installs an appropriate TRAP handler moving the values given by the application in and out of the special registers.
c) While the virtual OS will maintain the page tables for the application, the host OS needs ultimate control over the page tables. Two mappings are involved in this process: The host OS will use mapping f1 to map the guest OS addresses to physical addresses and the guest OS will establish a mapping f2 to map application addresses to its own virtual addresses. To be efficient, the host OS must compute the composition of f1 and f2 and run the application with page tables representing this composition.
d) A dynamic trap in the host OS might occur at three locations: inside the host OS, inside the guest OS or inside the application. In any case control is transferred to the host OS and control can return normally to the location before the interrupt. There is one special case. The interrupt might lead to a virtual interrupt that the host OS need to generate for the guest OS. The host OS can then set the appropriate bit in the guest OS private copy of rQ and depending on the private rK transfer control to the guest OS trap handler (according to its private copy of rT).
Achieving 3. with MMIX requires fast forwarding of traps and updates to page tables. All the rest is probably not too relevant for overall performance.
To forward a TRAP from the application to the guest OS requires:
SETH $255,#8000 OS RAM ORMH $255,#0001 OS RAM LDO $255,$255,CurrentTask get address of task control block STO $0,$255,#00 scratch GET $0,rBB store private copies STO $0,$255,#08 GET $0,rWW STO $0,$255,#10 GET $0,rXX STO $0,$255,#18 GET $0,rYY STO $0,$255,#20 GET $0,rZZ STO $0,$255,#28 GET $0,rYY LDO $0,$255,#30 PUT rV,$0 load runtime environment for guest OS LDO $0,$255,#38 PUT rT,$0 LDO $0,$255,#40 PUT rTT,$0 LDO $0,$255,#48 private rT PUT rWW,$0 jump there on resume LDO $0,$255,#00 restore $0 LDO $255,$255,#50 this will become rK for guest OS RESUME 1
To forward a RESUME 1 from the guest OS to the application requires:
A TRAP from the guest OS is typically due to a protection violation in a PUT or GET. Handling such a TRAP requires:
Another source of TRAPS from the guest OS are store operations to the applications page tables. Handling requires:
Application and guest OS actually share the applications page table. The guest OS just has an extended version containing mappings for negative addresses. So sharing should be possible. If a guest OS runs several applications, all these applications have different tables for the non negative addresses. More sharing would be possible, if the root for the page table covering the negative addresses would be located independent of the regular page table. It would just need another special register with at least 27 bit. Then the rV register could remain as it is now.
Other TRAPs from the guest OS are possible, because the guest OS can save away its special registers and use TRAP instructions. These must be forwarded back to the guest OS in the same way as TRAPS from the application. There is just the additional need to dispatch the TRAP to the proper handler.
So all in all, it is mostly a few load and store operations. (if only we had one more register available at the time a trap occurs, since two registers would be enough for store operations).
Ideas for efficiency
mail comments to firstname.lastname@example.org
Please help to keep this site up to date! If you want to point out important material or projects that are not listed here, if you find errors or want to suggest improvements, please send email to