3

this is with reference to machine virtualization. I am going through virtualization and got to know that With hardware assisted virtualization technique, privileged instructions are identified by trap-fault method and replaced with equivalent user-level instructions on the fly. but how is/was virtualization achieved in absence of hardware support? prior to Intel VTi or AMD-V, how was privileged instrutions trapped on the fly by software itself? everywhere the :"binary translation" term is used which is fine as far as replacing the privileged instruction with user instructions is concerned but how the privileged instructions ran by guest os is identified by virtualization tool(hypervisor/vmm)

edit: some people are thinking that this question does not show research effort and are down-voting. These are some of the papers that I went through

overview : https://www.vmware.com/pdf/virtualization.pdf

intel doc: https://software.intel.com/sites/default/files/m/d/4/1/d/8/An_Introduction_to_Virtualization.pdf

Intorduction: http://www.kernelthread.com/publications/virtualization/

x86 virtualization http://en.wikipedia.org/wiki/X86_virtualization

comparison of hw sf virtualization: http://www.vmware.com/pdf/asplos235_adams.pdf

nuts and bolts: http://www.anandtech.com/show/2480

paravirtualization: http://en.wikipedia.org/wiki/Paravirtualization

if anyone has any paper/source which can answer the question asked above and I might have missed kindly respond.

Himanshu Sourav
  • 700
  • 1
  • 10
  • 35
  • Trapping privileged instructions is the standard technique. No replacement is necessary, the kernel can simply execute the equivalent operation and increment the instruction pointer to allow the program to continue. – Hans Passant Jun 05 '15 at 09:06
  • @HansPassant can you elaborate in steps what happens between when guest OS issues a privileged instruction till next instruction in-line starts execution..? – Himanshu Sourav Jun 05 '15 at 09:30

2 Answers2

3

In the absence of hardware support, paravirtualization can be used. Guest operating systems are modified so that instead of accessing certain hardware resources directly, calls are made to virtual machine manager (VMM) or hypervisor.

For example, a guest operating system on x86 cannot be allowed to disable interrupts on the actual CPU. Instead, the guest OS makes a call to the VMM to simulate disabling interrupts.

Another alternative is native virtualization. In native virtualization, the instructions of the guest OS and its processes are emulated. The emulation layer allows privileged instructions like cli to be handled by the virtualization software. Thus native virtualization requires neither hardware support nor modifying the guest OS.

Craig S. Anderson
  • 6,966
  • 4
  • 33
  • 46
  • that's correct, however my question is not that. how is it achieved when guest OS cannot be modified for instance windows-xp..? – Himanshu Sourav Jun 08 '15 at 04:13
  • thanks though that was of some value addition, "This approach, often called "native virtualization", is different from mere emulation. With that approach, as performed by programs such as BOCHS, guest code is not allowed to run directly on the host. Instead, every single machine instruction is translated ("emulated")."- agreed. my question is how it identifies when guest is issuing privileged instructions and selectively emulates them instead of emulating each and individual instruction issued by guest..? – Himanshu Sourav Jun 09 '15 at 08:53
  • 1
    Essentially the emulator has a big table that indicates whether an opcode is privileged or not. The table values are determined by the instruction set architecture. – Craig S. Anderson Jun 09 '15 at 09:47
  • would it be correct to say that 1. guest OS address ranges are known and any of the opcode originating from those address ranges can be segregated based on the address. 2.opcode from guest os address ranges are compared to the "big table" and then its decided on further course of action. thanks @Craig, would you be able to point to some material/resources which will allow me to go into more details of this implementation at lower abstraction level. specifically the table et al. – Himanshu Sourav Jun 09 '15 at 09:53
  • 1
    #1 - Yes, the guest OS address ranges are known. Also the guest OS is usually executing in the processor's kernel or privileged mode. #2 - yes that is right. #3. I would look at emulation papers. Start with http://www.cs.washington.edu/research/compiler/papers.d/shade.html – Craig S. Anderson Jun 09 '15 at 16:31
  • "In native virtualization, the instructions of the guest OS and its processes are emulated." The VirtualBox page linked to says exactly the opposite. It compares native virtualization" with "emulation". In emulation the instructions are emulated. – Andrew J. Brehm Sep 12 '19 at 14:03
1

If you do not have hardware virtualization and you do not want to consider paravirtualization the other option is binary translation. The problem with x86 (I'm assuming were are talking about x86) is that there are certain sensative instructions that are not privileged (See Popek and Goldberg virtualization requirements). By privileged in this sense I mean that it will cause a trap from user to kernel mode. Since these instructions are found in the guest kernel (which runs with userspace privileges as guest) but do not cause an exit they can be a problem. For example, popf behaves differently depending on whether it is invoked in user or kernel (Intel reference manual volume 2, see section on popf). Therefore when the guest executes popf we want the VM to exit but it won't. In binary translation we basically scan the kernel binary and replace all machine code that corresponds to sensitive unprivileged instructions with machine code that will perform the correct emulation or more likely cause a VM exit so the hypervisor can intervene. A little bit of this can be found in this VMware document. Most of the other documents I can find that explain binary translation in any depth are behind paywalls.

Ohad Eytan
  • 8,114
  • 1
  • 22
  • 31
missimer
  • 4,022
  • 1
  • 19
  • 33