From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 0/30] nVMX: Nested VMX, v9 Date: Thu, 12 May 2011 19:08:59 +0300 Message-ID: <4DCC061B.5070504@redhat.com> References: <1304842511-nyh@il.ibm.com> <4DC7CD81.2070305@redhat.com> <20110511082027.GG19019@redhat.com> <20110512154228.GA7943@fermat.math.technion.ac.il> <20110512155727.GA20193@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Nadav Har'El" , kvm@vger.kernel.org, abelg@il.ibm.com To: Gleb Natapov Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60622 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757426Ab1ELQJH (ORCPT ); Thu, 12 May 2011 12:09:07 -0400 In-Reply-To: <20110512155727.GA20193@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 05/12/2011 06:57 PM, Gleb Natapov wrote: > On Thu, May 12, 2011 at 06:42:28PM +0300, Nadav Har'El wrote: > > So I guess my question is, and Avi and Gleb I'd love your comments about this > > question: Is it really beneficial that I rewrite the "ugly" nested-VMX > > injection code to be somewhat-ugly in exactly the same way that nested-SVM > > injection code? Won't it be more beneficial to rewrite *both* codes to > > be cleaner? This would probably mean changes to the common x86.c, that both > > will use. For example, x86.c's injection code could check the nested case > > itself, perhaps calling a special x86_op to handle the nested injection (exit, > > set interrupt window, etc.) instead of calling the regular > > interrupt_allowed/enable_irq_window and forcing those to be modified in > > mysterious ways. > > > That is exactly what should be done and what I have in mind when I am > asking to change VMX code to be SVM like. To achieve what you outlined > above gradually we need to move common VMX and SVM logic into x86.c > and then change the logic to be more nested friendly. If VMX will have > different interrupt handling logic we will have to have additional step: > making SVM and VMX code similar (so it will be possible to move it > into x86.c). All I am asking is to make this step now, before merge, > while the code is still actively developed. > I don't think it's fair to ask Nadav to do a unification right now. Or productive - there's a limit to the size of a patchset that can be carried outside. Also it needs to be done in consideration with future changes to interrupt injection, like using the svm interrupt queue to avoid an interrupt window exit. Are there vmx-only changes that you think can help? -- error compiling committee.c: too many arguments to function