On 11/10/2011 11:57 AM, Nadav Har'El wrote:
> The following patches add nested EPT support to Nested VMX.
>
> Nested EPT means emulating EPT for an L1 guest, allowing it 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. In many workloads this significanlty improves L2's performance over
> the previous two alternatives (shadow page tables over ept, and shadow page
> tables over shadow page tables). Our paper [1] described these three options,
> and the advantages of nested EPT ("multidimensional paging").
>
> Nested EPT is enabled by default (if the hardware supports EPT), so users do
> not have to do anything special to enjoy the performance improvement that
> this patch gives to L2 guests.
>
> Just as a non-scientific, non-representative indication of the kind of
> dramatic performance improvement you may see in workloads that have a lot of
> context switches and page faults, here is a measurement of the time
> an example single-threaded "make" took in L2 (kvm over kvm):
>
>  shadow over shadow: 105 seconds
>  ("ept=0" forces this)
>
>  shadow over EPT: 87 seconds
>  (the previous default; Can be forced now with "nested_ept=0")
>
>  EPT over EPT: 29 seconds
>  (the default after this patch)
>
> Note that the same test on L1 (with EPT) took 25 seconds, so for this example
> workload, performance of nested virtualization is now very close to that of
> single-level virtualization.
>
>

This patchset is missing a fairly hairy patch that makes reading L2
virtual addresses work.  The standard example is L1 passing a bit of
hardware (emulated in L0) to a L2; when L2 accesses it, the instruction
will fault and need to be handled in L0, transparently to L1.  The
emulation can cause a fault to be injected to L2, or and EPT violation
or misconfiguration injected to L1.

-- 
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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to