From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH] KVM: VMX: Fix locking order in handle_invalid_guest_state Date: Wed, 29 Jul 2009 11:07:16 -0300 Message-ID: <20090729140716.GA18751@amt.cnet> References: <4A678A56.7050901@web.de> <20090723214553.GA10152@amt.cnet> <20090729122456.GA16868@amt.cnet> <4A704424.1090602@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kiszka , kvm-devel To: Avi Kivity , Gleb Natapov Return-path: Received: from mx2.redhat.com ([66.187.237.31]:39244 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750961AbZG2OHf (ORCPT ); Wed, 29 Jul 2009 10:07:35 -0400 Content-Disposition: inline In-Reply-To: <4A704424.1090602@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Wed, Jul 29, 2009 at 03:44:20PM +0300, Avi Kivity wrote: > On 07/29/2009 03:24 PM, Marcelo Tosatti wrote: >> On Thu, Jul 23, 2009 at 06:45:53PM -0300, Marcelo Tosatti wrote: >> >>> On Wed, Jul 22, 2009 at 11:53:26PM +0200, Jan Kiszka wrote: >>> >>>> Release and re-acquire preemption and IRQ lock in the same order as >>>> vcpu_enter_guest does. >>>> >>> This should happen in vcpu_enter_guest, before it decides to disable >>> preemption/irqs (so you consolidate the control there). >>> >>> Maybe add a new member to x86_ops? >>> >> >> Why don't do something like this ? >> > > The downside is that we're moving a vmx specific hack to common code. > > I think this could be simplified if interrupt injection happened outside > the critical section. This is needed anyway because emulated interrupt > injection needs to access guest memory (IVT and the stack). Why can't it happen now (outside of the critical section), other than the kvm_vcpu_kick thing? > > Something else I noticed, handle_invalid_guest_state() doesn't check > vcpu->requests; normal execution will exit due to the interrupt while > emulated execution will not. > > -- > error compiling committee.c: too many arguments to function