On Wed, Sep 19, 2012, Steven wrote about "Re: Guest mode question": > thanks for your reply. My question is regarding the the normal > single-level virtualization. > Suppose that the physical machine has only one core and 2 VMs. > Each VM has one vcpu, so there are two vcpu threads running with the > hypervisor. > Does your answer mean these two VMs can not be in the guest mode at > the same time? Like I said, there is no such thing (in non-nested context) as a VM being in "guest mode". Rather, it is the CPU which is in guest mode. When the CPU is at the moment running guest instructions (of any of the guests) it is in guest mode. When it isn't, it's in so-called "root mode". So your question becomes moot. > For example, when the hypervisor schedules one VM, the > running VM must have a vmexit call first and then the hypervisor can > issue vmrun call to the other VM. Indeed. Virtualization hardware doesn't magically create additional hardware threads (cores/hyperthreads). The CPU can only run one thread of execution, and in particular cannot run two VMs concurrently. To switch between two VMs, the CPU needs to first exit from running the first VM (go from guest mode back to root mode), then decide which other VM to run, and VMLAUNCH/VMRUN it. The first VM might exit because of "natural causes" (i.e., a sensitive instruction), or it might be forced to exit because of, e.g., a physical timer interrupt (normally, any physical interrupt causes a guest to exit, so the host can handle it). After each exit, the hypervisor resumes running at might decide (using Linux's normal scheduling policies) to schedule a different process or VM instead of the one that just exited. -- Nadav Har'El | Wednesday, Sep 19 2012, 3 Tishri 5773 nyh@xxxxxxxxxxxxxxxxxxx |----------------------------------------- Phone +972-523-790466, ICQ 13349191 |Evening news begins with 'Good evening', http://nadav.harel.org.il |and then proceeds to say why it isn't. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
