At 10:32 +0100 on 16 Apr (1271413945), Christoph Egger wrote:
> > 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.
>
> Well, that is what I expected from noone else than Intel :-)
>
> Please read the XenNestedHVM.pdf paper, particularly the section "Software 
> Architecture". This describes how this is made to be generic and what needs
> to be done to adapt to Intel.
Your PDFs suggest that even on Intel CPUs, the nested hypervisor should
always see SVM, not VMX. You shouldn't be surprised or offended if that
isn't popular with Intel. :)
I would like to see some reasonable discussion of exactly how much of
the nested virtualization logic can be shared. With HVM it has turned
out to be quite a lot, but it's taken years of reshuffling to pull code
out into common HVM routines (and we're not there yet). I don't think
either of the suggested approaches (common code == SVM, or common code
== nothing) will be the right one.
Cheers,
Tim.
-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel