Re: KVM call minutes for Sept 21

[Gleb Natapov <gleb@redhat.com>]

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.