I imagine the process includes watching for some specific pattern in the virtualized memory, and changing it, but I'm wondering how exactly it works. Perhaps a new bios call of sorts? (Similar to the OS querying the time from the RTC.) I'm interested because I'm wondering if I could hook into it myself for arbitrary data communication between host and client.
6
-
"Perhaps a new bios call of sorts?' - This absolutely does not happen. VirtualBox is a Type-2 Hypervisor, how a guest OS communicates with the host os, is well documented.– RamhoundCommented Feb 2, 2017 at 22:25
-
Thanks for the insight on the Type-2 Hypervisor bit, really led me to the more details on how VMs are ran. However it still doesn't explain how data such as screen geometry, clipboard, drag-and-drop etc is transferred between the two. I understand things like the mouse and keyboard can be transferred through the OS layer, but what about that extra data? Especially when the Host and Guest OS differ, you can't 1:1 replicate those OS calls.– TheWhoAreYouPersonCommented Feb 2, 2017 at 23:12
-
There is a software layer. VirtualBox just communicates with that layer. It also can communicate with the hardware itself if the virtualization extensions are supported– RamhoundCommented Feb 2, 2017 at 23:41
-
I intended for my question to ask how the guest communicates with the host, being the technology involved, not just the fact that it can. Presumably, VBox/others have multiple layers (what vbox calls 'Guest Additions above the guest VM', the guest, the VMM provided BIOS (which presumably is the part that communicates with the OS, being the screen/mouse/keyboard/IO port 'forwarder'), the OS, etc. I understand the VMM communicating hardware/screen/etc through that custom BIOS, but where is the custom data sent? Some custom 'physical' (virtual) port? Memory Manipulation? etc.– TheWhoAreYouPersonCommented Feb 2, 2017 at 23:52
-
"I understand the VMM communicating hardware/screen/etc through that custom BIOS, but where is the custom data sent" - This is false. That isn't how x86 Virtualization Extensions work.– RamhoundCommented Feb 3, 2017 at 0:09
|
Show 1 more comment
1 Answer
First understand that Virtualbox is a program installed on the host OS, so it ships executables and libraries and other resources. Many of these libraries will call host OS functions and services to do their work.
Virtualbox also installs drivers into the OS kernel. These drivers define how the kernel can provide hardware interfaces to Virtualbox's Virtual Hardware layer.
The virtual hardware layer sits between the Host OS and the Guest. To the Host it is just another program, but to the Guest, it appears to be real hardware.
Its important to understand that Virtualbox as a program is executing while the guest is, but the two are doing entirely different things. Virtualbox is working with the host on presenting a fake computer to the Guest, whereas the guest is just running as an OS on the fake hardware.
OS drivers are not usually right for the Guest, or present extremely limited functionality. The Guest doesn't know that it is a VM, and can't ask the host questions. Thats why we need Guest Tools.
Guest Tools upgrade the system drivers with those appropriate to the virtualized hardware, and communicates with the fake hardware to ask questions like "what is my max resolution". VBox in turn asks the OS, and reports back to the guest.
Guest Tools also enable other features like share folder mapping, by installing software in the guest that can communicate with VBox. VBox then uses OS technologies like named pipes or ole (in windows) or network IPC (Linux) to pass data back and forth between itself and the host os.
The important takeaway here is that the guest doesn't know its a VM, and the host doesn't know its running VMs. Vbox sits between the two and brokers all communication. There is no extraordinary reliance on the physical BIOS.
What may be making you think of the BIOS is the Virtualization Extensions. Please understand that VT is a set of CPU instructions, and is unreleated to the BIOS. VBox runs code that has been compiled into VT instruction calls (when appropriate) so that it can execute optimized instructions related to virtual operations. Once again, the host OS has little to do with that.
answered Feb 3, 2017 at 1:56
-
(I was referring to i.imgur.com/Ary3JSW.png when I said BIOS, btw. I see now that that isn't accurate. Confused me since it appears to be a BIOS at first glance, and flashes off) From reading up a bit about this a little before hand, I figured there must have been a few CPU instructions relating to running a VM, but I had no idea they also dealt with data, just perms. As far as I can tell (starting from Wikipedia) the process of Guest-Hypervisor communication is basically a few instructions to get/set data, and a few to instr. to move the exec. context. Please correct me if i'm wrong :) Commented Feb 3, 2017 at 2:56
