Re:Microsoft Adds an OpenSSH Client to Windows 10
by sterlind on Tuesday December 12, 2017 @05:18PM
(#15910024)
both of you are correct:
on init, the Hyper-V driver hijacks the running Windows instance, schedules it as the 'root partition', and runs it like just another VM.
unlike 'child partitions', the root partition still has non-virtualized drivers, which run unimpeded by privileged instruction traps.
when a child partition (guest VM) is started, it's scheduled as a peer to the root. its Virtual Processors (VPs) run alongside the root partition's VPs.
when the child partition traps into the hypervisor, or uses one of the enlightened drivers, the hypervisor dispatches a bus request to the root partition, which handles the IRQ using a Virtual Service Provider implemented by the host Windows kernel.
so the hypervisor is kind of a bridge between the host Windows and the child VMs, but the host Windows actually runs as a sort of privileged VM itself, just one with full hardware access and scheduling priority.
on init, the Hyper-V driver hijacks the running Windows instance, schedules it as the 'root partition', and runs it like just another VM.
unlike 'child partitions', the root partition still has non-virtualized drivers, which run unimpeded by privileged instruction traps.
when a child partition (guest VM) is started, it's scheduled as a peer to the root. its Virtual Processors (VPs) run alongside the root partition's VPs.
when the child partition traps into the hypervisor, or uses one of the enlightened drivers, the hypervisor dispatches a bus request to the root partition, which handles the IRQ using a Virtual Service Provider implemented by the host Windows kernel.
so the hypervisor is kind of a bridge between the host Windows and the child VMs, but the host Windows actually runs as a sort of privileged VM itself, just one with full hardware access and scheduling priority.
* I work for MS, but not on any of these things.