On Wed, Nov 6, 2013 at 1:01 PM, Paul Mackerras <paulus@xxxxxxxxx> wrote: > On Tue, Nov 05, 2013 at 03:42:42PM +0800, Liu Ping Fan wrote: >> After the primary vcpu changes vcore_state to VCORE_RUNNING, there is >> very little chance to schedule to secondary vcpu. So if we change the > > Why do you say there is very little chance to run the secondary vcpu? > >> code sequence around set vcore_state to VCORE_RUNNING and disable >> preemption, we lost little. But we simplify the entering logi, based on >> the fact that if primary vcpu runs, the secondary vcpu can not be scheduled. > > If a vcpu does a hypercall or something else that requires the host > (kernel or userspace) to do something, that can happen in the context > of the vcpu task for that vcpu. That vcpu task can run on another > core (unless it has been pinned). When it is finished we would like > the vcpu to continue executing in the guest as soon as possible. The > code that you remove in this patch enables that to happen without > having to wait until the other threads exit the guest. So I don't > think it is a good idea to remove this code. > Yes, you are right. Thanks and regards, Pingfan > Regards, > Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
