Re: [Xen-devel] Fwd: [PATCH 0/18] Nested Virtualization: Overview

[Qing He <qing.he@xxxxxxxxx>]

On Thu, 2010-04-15 at 21:20 +0800, Christoph Egger wrote:
> This patch series brings Nested Virtualization to Xen.
> I have attached two documents Nested_Virtualization.pdf and XenNestedHVM.pdf.
> 

This code is NOT generic and doesn't fit for vmx, although it is placed in hvm
directory.

For example, the structure v->arch.hvm_vcpu.nestedhvm is filled with
svm specific registers and concepts, so is the arch/x86/hvm/nestedhvm.c,
this file even includes vmcb_struct, as well as things like cpuids and efer.
A vmx adaption to this nestedhvm would be way too difficult if not impossible.

These files should go to arch/x86/hvm/svm instead since they are really svm
specific, so is the struct nestedhvm, v->arch.hvm_svm fits better.


In fact, I even doubt whether a generic nested arch should be made for vmx
and svm. When the HVM abstraction was made, it was largely because the targets
are the same, the x86 VM. However, the emulation target of nested virtualization
is either vmx or svm, which have much more differences, including
the capability reporting, the access of control structures, control registers,
interrupt delivery (idt vectoring), optimization options, guest format of hap
and etc.

Not much is common except the similarity of control flow (which is
not abstracted even in HVM: vmx_do_resume and svm_do_resume). Given the
complexity of the two HVM extensions, an abstraction may create more
overhead and quirkness than benefit.

Moreover, a l2 guest is not context complete by itself, some of it logically
belongs to l1 guest. This makes things more complicated that VMExit handling
is interlaced. I notice that the patchset uses a separate flow path other than
hvm/{vmx,svm}/entry.S, this means, for at least vmx side, many things already
there need to be duplicated to the new path, this is both error prone and makes
maintenance more difficult.


I have a nested vmx implementation in hand that supports major features
(shadow-on-shadow, shadow and ept on ept, x86_64, smp), however, several weeks
are still needed for some additional cleanup before I can send it to the list
for RFC. The patch, in contrast, lies almost fully in arch/x86/hvm/vmx,
and only adds two memebers to v->arch.hvm_vcpu, nesting_avail and in_nesting.

Thanks,
Qing



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel