From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM: kvm_vcpu_block task state race Date: Sun, 11 May 2008 17:26:06 +0300 Message-ID: <482701FE.2000707@qumranet.com> References: <20080508224701.GA6175@dmt> <4823FFFF.3040005@qumranet.com> <20080509142101.GA11591@dmt> <48246935.50603@qumranet.com> <20080509192208.GA13579@dmt> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel To: Marcelo Tosatti Return-path: In-Reply-To: <20080509192208.GA13579@dmt> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org Marcelo Tosatti wrote: >> The best practice is to issue all vcpu ioctls from the thread that >> created the vcpu; this becomes mandatory if we ever switch to a syscall >> interface and remove the mutex. >> > > For things like register dumps I don't believe its worthwhile. Much > simpler to stop the vcpu with SIG_IPI, retrieve registers, and run it > again (now that you mention the busy-spin, it is broken right now, if a > vcpu is spinning without exiting to userspace). > > So do you want to give wait_event_interruptible() a try or wait for that > change until userspace never issues vcpu ioctl's to a possibly busy vcpu > (and go with the patch above)? > Do we have anything critical that issues vcpu ioctls outside its thread? While I much prefer wait_event_interruptible(), I don't want to break existing userspace. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone