Re: [PATCH 0/30] nVMX: Nested VMX, v9

[Gleb Natapov <gleb@redhat.com>]

On Thu, May 12, 2011 at 07:31:15PM +0300, Nadav Har'El wrote:
> Hi,
> 
> On Thu, May 12, 2011, Gleb Natapov wrote about "Re: [PATCH 0/30] nVMX: Nested VMX, v9":
> > 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).
> 
> But if my interpretation of the code is correct, SVM isn't much closer
> than VMX to the goal of moving this logic to x86.c. When some logic is
> moved there, both SVM and VMX code will need to change - perhaps even
> considerably. So how will it be helpful to make VMX behave exactly like
> SVM does now, when the latter will also need to change considerably?
> 
SVM design is much close to the goal of moving the logic into x86.c
because IIRC it does not bypass parsing of IDT vectoring info into arch
independent structure. VMX code uses vmx->idt_vectoring_info directly.
SVM is much close to working migration with nested guests for the same
reason.

> It sounds to me that working to move some nested-interrupt-injection related
> logic to x86.c is a worthy effort (and I'd be happy to start some discussion
> on how to best design it), but working to duplicate the exact idiosyncrasies
> of the current SVM implementation in the VMX code is not as productive.
> But as usual, I'm open to arguments (or dictums ;-)) that I'm wrong here.
> 
> By the way, I hope that I'm being fair to the nested SVM implementation when
> I call some of the code there, after only a short review, idiosyncrasies.
> Basically I am working under the assumption that some of the modifications
> there (I gave examples in my previous post) were done in the way they were
> just to fit the mold of x86.c, and that it would have been possible to alter
> x86.c in a way that could make the nested SVM code simpler - and quite
> different (in the area of interrupt injection).
I think (haven't looked at the code for a long time) it can benefit
from additional x86 ops callbacks, but it would be silly to add one set
of callbacks to support SVM way of doing things and another set for VMX,
not because archs are so different that unification is impossible (they
are not, they are very close in this area in fact), but because two
implementations are different.

> 
> > All I am asking is to make this step now, before merge,
> > while the code is still actively developed.
> 
> The code will continue to be actively developed even after the merge :-)
> 
Amen! :)

--
			Gleb.