On Wed, Sep 22, 2010 at 07:49:43PM +0200, Nadav Har'El wrote: > I believe that in the current state of the code, nested VMX adds little > complexity to the non-nested code - just a few if's. Of course, it also > adds a lot of new code, but none of this code gets run in the non-nested > case. As it is with Nested-SVM. > The maintenance issues I see are the other way around - i.e., once > in a while when non-nested changes are made to KVM, nested stops working and > needs to be fixed. A prime example of this was the lazy FPU loading added in > the beginning of the year, which broke our assumption that L0's > CR0_GUEST_HOST_MASK always has all its bits on, making nested stop working > until I fixed it (it wasn't easy debugging these problems ;-)). > I wholeheartedly agree that if nobody continues to maintain nested VMX, > it can and will become "stale" and may stop working after unrelated code > in KVM is modified. Adding tests can help here (so that when someone modifies > some non-nested KVM feature he will at least know that he broke nested), but > definitely, we'll need to continue having someone who is interested in > keeping the nested VMX working. In the forseeable future, I'll volunteer > to be that someone. I know very well what you are talking about. It has happend a couple of times to nested SVM that it broke because of other unrelated patches. I also had to fix nested SVM when the new lazy FPU switching code was merged. The best way to cope with that in the future is to restructure the code to that it is more unlikely to break. One example: I had bugs where the generic KVM code called into SVM specific parts which intended to changed state in the L1 VMCB. But since L2 was running this was changed in the VMCB of L2 and got lost when the next vmexit was emulated (which is really bad for tsc_offset for example). Another thing is intercepts. When KVM wants to change the intercept masks for L1 you have to recalculate the merged intercept masks for L2. The best strategy to cope with that is to add accessor functions which change L1 state and which are aware of nesting. Joerg -- 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
