On Wed, Sep 22, 2010 at 06:29:00PM +0200, Nadav Har'El wrote: > On Wed, Sep 22, 2010, Gleb Natapov wrote about "Re: KVM call minutes for Sept 21": > > There is only one outstanding serious issue from my point of view: event > > injection path. I want it to be similar to how nested SVM handles it. I > > don't see why it can't be done the same way for VMX too. The way nested SVM > > does it looks cleaner and making code paths similar will allow us to > > consolidate the logic in common code later. This issue is too > > fundamental to be fixed after merge IMHO. Other nitpicks about missing > > checks that real HW does, but emulation doesn't can be fixed any time > > after merge. > > I'll try my best to accomodate your request, but I tried to explain in my > previous mails (and so dir Orit Wasserman in her mails last year, by the way - > I found a long thread in the mailing list...) that there appears to be a > fundemental additional complexity in VMX that doesn't exist in SVM. In VMX, > you might have to inject another exception (IDT_VECTORING_INFO_FIELD) at the > same time that you're already trying to inject a page fault to L1, and this > doesn't appear (?) to exist in SVM. exitintinfo. Really SVM and VMX event injection are practically identical. > However, since I didn't write this code myself, and didn't encounter all the > problems myself, I still want to try to see whether I can get "cleaner" code > to actually work. But I want it to be really cleaner - not just remove one > somewhat-ugly intervention from vmx_complete_interrupts() and move it to an > even uglier intervention somewhere else. > > In any case, while I obviously agree that it's your prerogative not to merge > code that you consider ugly, I still don't see any particular problem to start > with the current, working, code, and fix it later. It's not like we can never > change this code after it's in - it's clearly marked with if(nested) and > doesn't effect anything in the non-nested path. > After code it merged there is much less incentive to change things drastically. -- Gleb. -- 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
