On 03.09.2009, at 08:01, Muli Ben-Yehuda wrote:
On Wed, Sep 02, 2009 at 05:57:39PM +0200, Alexander Graf wrote:
Am 02.09.2009 um 17:38 schrieb oritw@xxxxxxxxxx:
The following patches implement nested VMX support. The patches
enable a guest to use the VMX APIs in order to run its own nested
guest (i.e., enable running other hypervisors which use VMX under
KVM).
Copl! Great job here. I was expecting vmcs load/stores to kill
performance, but apparently I was wrong. How did you get those fast?
Are you asking about vmptrld (switching the VMCS's) or the costs of
trapping vmread/vmwrites?
vmprtld shouldn't really be too much of a problem. Just handle it as
reset of the shadow vmcs and you're good.
No, what I was wondering about was vmread & vmwrite. Those probably
trap quite a lot and from what I've seen with nested SVM, trapping on
the VMEXIT path is horribly slow, especially on shadow shadow paging,
because you just get so many of them.
SMP support was fixed. Reworking EPT support to mesh cleanly with
the current shadow paging design per Avi's comments is a
work-in-progress.
The current patches only support a single nested hypervisor
Why?
See above---no fundamental limitation---but needs more work. Bug
reports happily accepted, patches even more so :-)
Well, maybe I understand the wording. Does "a single nested
hypervisor" mean "one user of VMX per VCPU"?
If so, it's only vmptrld that's not really well implemented.
It does sound as if you only support one nested hypervisor throughout
all VMs which wouldn't make sense, since all nested data should be
vcpu local.
How about Hyper-V and Xen?
We haven't tried them.
It might be worth giving Xen a try. I found it being the second
easiest target (after KVM).
Again, great job and congratulations on making this work!
Thank you, your patches were very useful!
It's good to see that they inspired you. In fact I even saw quite some
structure resemblances in the source code :-).
Will you be at the LPC where I'll be giving a talk about nested SVM?
I'd love to get you on the stage so you get a chance of telling people
that this even works for VMX. Last time I gave a talk on that topic I
could merely say that no such thing existed.
Alex
--
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
