Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
I currently have code that can execute a VMX guest VMs in protected mode (they start in pmode w/ paging provided by the host). This allows me the (somewhat useless) ability to spawn tasks of sorts to complete kernel functions in a VMX non-root guest successfully. I also have a VMM scheduler (round-robin) for the VMX "tasks". My question here is how on earth could I go about booting a full OS (from BIOS to kernel stages) in a VMX non-root guest? I'd imagine I'd need some sort of firmware/BIOS/EFI loaded by the kernel for use by VMs. But since VMX only allows guests to be as primitive as VM86 and not "real mode" traditionally I don't see how I could boot a full OS that generally starts in real mode. I also thought of trying to use the host's firmware/BIOS/EFI (what was used to boot the host) but I could see a few issues arising from that.
Here are a few things that worry me:
1: I need a host-loaded firmware for use by a guest.
2: The host might have to emulate all BIOS/interrupt calls when the guest has no IDT installed due to the guest being in VM86.
Any ideas? I find these extensions fascinating, but it's hard to dig up information besides what's in the Intel SDMs. At least the process of getting VMX setup initially are well documented.
For both the VM86 monitor (that is meant to be inside the guest to allow the guest to run real mode code) and the firmware/BIOS; you could probably have a minimal stub and do (almost) everything in host's context. For example, if/when the guest tries to use any BIOS service, it could just cause a VMEXIT and the hypervisor can emulate the BIOS function before doing a VMENTER.
01000101 wrote:I also have a VMM scheduler (round-robin) for the VMX "tasks".
You'd want to create the illusion that 1 second of time (from the guest's perspective) is the same as 1 second of time (from the host's perspective). Because of many things these may not be the same. In some cases "guest time" can suddenly skip ahead of "host time" - for example, if the guest decides to use software controlled throttling to halve the speed of it's virtual CPU, or if the guest does "HLT" (or enters a sleep state), or if the guest reads from an floppy drive (that's actually a file in RAM). In some cases "guest time" can fall behind - for example, if the host is handling other load and doesn't have spare CPU time to give the guest.
The VMM scheduler would want to give host CPU time to the guest that is the furtherest behind; and the scheduler should probably give the guest enough host CPU time to make the "guest time" slightly ahead of "host time". If all guests are ahead of host time, then you don't want to give any of them host CPU time for a little while. If the host is having trouble keeping up, then it can pretend the guest CPU/s are hot and emulate thermal throttling until the guest/s catch up.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
emulate thermal throttling, holy crap its so simple. this problem has been floating around in my head for months and this is the only one that comes close.
