From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH] execute kvm_init_vcpu in the end of pc_new_cpu Date: Wed, 6 May 2009 11:03:20 -0300 Message-ID: <20090506140320.GC26401@poweredge.glommer> References: <1241579779-17974-1-git-send-email-glommer@redhat.com> <20090506135306.GC10705@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kvm@vger.kernel.org, avi@redhat.com To: Marcelo Tosatti Return-path: Received: from mx2.redhat.com ([66.187.237.31]:36591 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754133AbZEFN6Z (ORCPT ); Wed, 6 May 2009 09:58:25 -0400 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n46DwQHj002094 for ; Wed, 6 May 2009 09:58:26 -0400 Content-Disposition: inline In-Reply-To: <20090506135306.GC10705@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, May 06, 2009 at 10:53:06AM -0300, Marcelo Tosatti wrote: > On Tue, May 05, 2009 at 11:16:19PM -0400, Glauber Costa wrote: > > When we create a new vcpu, we need to make sure that > > all of the state it is going to use (apic state, for example) > > already exists. We can do it nicely by making sure kvm_init_vcpu > > is executed after everything else in cpu creation. > > > > After that, the first call to KVM_SET_LAPIC ioctl will not find an > > existant vcpu. So we introduce a function that tell us that the vcpu > > is already initialized, and is it safe to call the ioctl. Otherwise, > > just don't botter. > > Why did you decide to drop the additional wait vcpu->inited thing you > had in the previous patch? I think its nice to make the synchronization > explicit. Explicit is good. Not needed is even better. If we make sure to call kvm_vcpu_init() after everything is already initialized, we avoid the need to have any kind of sync at all, since it serializes naturally. > > Isnt your current solution somewhat trickier? I believe it is simpler. > > And if you disagree with me (which you should avoid for safety reasons), > you need to regenerate the patch since it'll reject against qemu-kvm.git > as of today. I can do that happily (both disagreeing with you, and regenerating the patch)