a guestOS process occupies VCPU at any given time?
Recently i`ve been studying something about hardware-supported virtualization.
I read about 3 states of host cpu ,thus the most common userspace,kernelspace and A New Guest State.And as i can see from the ps command,there is a process for the vm i started,and some 'sub'-threads for each cpu owned by the virtual machine.Also i noticed when the vm runs some io related program,some more threads will be created on the host,which i guess might be the responses of qemu for hardware emulation.
So here comes my question:For any certain time(time in guest state,not the other two),does a vcpu thread represent a guestOS process running(i mean 'occupy' and 'exclusively')?just the same as a physical cpu,for any given time in userspace,a user process is running on it.
This may sound a little stupid,I just want to figure it out for further research.
To make this question simple:
is the vcpu thread which runs on host machine associated with some guestOS process at any given time?
To further simplify it:
is it right when i say the guestOS processes are actually running on the host CPU directly and scheduled as ordinary host-processes?the difference between the two kinds of process being what we called virtualization?
Maybe i need another threads to solve some questions about guestOS process switching,but before that,hope you guys can help me with this one.
If you're talking about kvm, then a vcpu thread represents a vcpu. At any given time it can be idle, or executing an execution slot for an in-guest process, same as a physical cpu can either be idle, or be executing an execution slot for the host
I should have make it clear that i was talking about kvm this time.And i myself have noticed that it is quite another situation in xen---there`ll be no extra threads spawned when i/o calls issued.I`m told xen simply uses the mechanism of qemu rather than the qemu itsefl(though i dunno what this mechanism refers to),this might explain why kvm and xen have difference behaviors.
This is because Xen's vCPU processes are not in the Dom-0. There are a couple of good diagrams at the bottom of this article: http://chucknology.com/2012/02/02/kv...ux-xen-is-not/
|All times are GMT -5. The time now is 01:23 AM.|