Re: [PATCH 0/24] Nested VMX, v5

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 17, 2010, Avi Kivity wrote about "Re: [PATCH 0/24] Nested VMX, v5":
> >patch. In short, try running the L0 kernel with the "nosmp" option,
> What are the problems with smp?

Unfortunately, there appears to be a bug which causes KVM with nested VMX to
hang when SMP is enabled, even if you don't try to use more than one CPU for
the guest. I still need to debug this to figure out why.

> >  give the
> >"-cpu host" option to qemu,
> 
> Why is this needed?

Qemu has a list of cpu types, and for each type it lists its features. The
problem is that Qemu doesn't list the "VMX" feature for any of the CPUs,
even those (like core 2 duo). I have a trivial patch to qemu to add the "VMX"
feature to those CPUs, which is harmless even if KVM doesn't support nested
VMX (qemu will drop features which KVM doesn't support). But until I send
such a patch to qemu, the easiest workaround is just to use "-cpu host" -
which will (among other things) tell qemu to emulate a machine which has vmx,
just like the host does.

(I also explained this in the intro to v6 of the patch).

> 
> >and the "nested=1 ept=0 vpid=0" options to the
> >kvm-intel module in L0.
> 
> Why are those needed?  Seems trivial to support a nonept guest on an ept 
> host - all you do is switch cr3 during vmentry and vmexit.

nested=1 is needed because you asked for it *not* to be the default :-)

You're right, ept=1 on the host *could* be supported even before nested ept
is supported (this is the mode we called "shadow on ept" in the paper).
But at the moment, I believe it doesn't work correctly. I'll add making this
case work to my TODO list.

I'm not sure why vpid=0 is needed (but I verified that you get a failed entry
if you don't use it). I understood that there was some discussion on what is
the proper way to do nested vpid, and that in the meantime it isn't supported,
but I agree that it should have been possible to use vpid normally to run L1's
but avoid using it when running L2's. Again, I'll need to debug this issue
to understand how difficult it would be to fix this case.

Nadav.

-- 
Nadav Har'El                        |      Sunday, Oct 17 2010, 9 Heshvan 5771
nyh@xxxxxxxxxxxxxxxxxxx             |-----------------------------------------
Phone +972-523-790466, ICQ 13349191 |Strike not only while the iron is hot,
http://nadav.harel.org.il           |make the iron hot by striking it.
--
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


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux