On Sun, May 22, 2011 at 10:32:39PM +0300, Nadav Har'El wrote: > At the risk of sounding blasphemous, I'd like to make the case that perhaps > the current nested-VMX design - regarding the IDT-vectoring-info-field > handling - is actually closer than nested-SVM to the goal of moving clean > nested-supporting logic into x86.c, instead of having ad-hoc, unnatural, > workarounds. Well, the nested SVM implementation is certainly not perfect in this regard :) > Therefore, I believe that the clean solution isn't to leave the original > non-nested logic that always queues the idt-vectoring-info assuming it will > be injected, and then if it shouldn't (because we want to exit during entry) > we need to skip the entry once as a "trick" to avoid this wrong injection. > > Rather, a clean solution is, I think, to recognize that in nested > virtualization, idt-vectoring-info is a different kind of beast than regular > injected events, and it needs to be saved at exit time in a different field > (which will of course be common to SVM and VMX). Only at entry time, after > the regular injection code (which may cause a nested exit), we can call a > x86_op to handle this special injection. Things are complicated either way. If you keep the vectoring-info seperate from the kvm exception queue you need special logic to combine the vectoring-info and the queue. For example, imagine something is pending in idt-vectoring info and the intercept causes another exception for the guest. KVM needs to turn this into the #DF then. When we just queue the vectoring-info into the exception queue we get this implicitly without extra code. This is a cleaner way imho. On the other side, when using the exception queue we need to keep extra-information for nesting in the queue because an event which is just re-injected into L2 must not cause a nested vmexit, even if the exception vector is intercepted by L1. But this is the same for SVM and VMX so we can do this in generic x86 code. This is not the case when keeping track of idt-vectoring info seperate in architecture code. Regards, 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
