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 -- 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
