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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
