On 11/10/2011 11:58 AM, Nadav Har'El wrote: > Add a module option "nested_ept" determining whether to enable Nested EPT. > > Nested EPT means emulating EPT for an L1 guest so that L1 can use EPT when > running a nested guest L2. When L1 uses EPT, it allows the L2 guest to set > its own cr3 and take its own page faults without either of L0 or L1 getting > involved. This often significanlty improves L2's performance over the > previous two alternatives (shadow page tables over ept, and shadow page > tables over shadow page tables). > > nested_ept is currently enabled by default (when nested VMX is enabled), > unless L0 doesn't have EPT or disabled it with ept=0. > > Users would not normally want to explicitly disable this option. One reason > why one might want to disable it is to force L1 to make due without the EPT > capability, when anticipating a future need to migrate this L1 to another > host which doesn't have EPT. Note that currently there is no API to turn off > nested EPT for just a single L1 guest. However, obviously, an individual L1 > guest may choose not to use EPT - the nested_cpu_has_ept() checks if L1 > actually used EPT when running L2. > > In the future, we can support emulation of EPT for L1 *always*, even when L0 > itself doesn't have EPT. This so-called "EPT on shadow page tables" mode > has some theoretical advantages over the baseline "shadow page tables on > shadow page tables" mode typically used when EPT is not available to L0 - > namely that L2's cr3 changes and page faults can be handled in L0 and do not > need to be propagated to L1. However, currently we do not support this mode, > and it is becoming less interesting as newer processors all support EPT. > > I think we can live without this. But we do need a way to control what features are exposed to the guest, for compatibility and live migration purposes, as we do with cpuid. So we need some way for host userspace to write to the vmx read-only feature reporting MSRs. -- error compiling committee.c: too many arguments to function -- 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
