Gentle ping on this series.
Most patches of series haven't got any reply yet (submitted 3 weeks ago).
On 23/06/18 02:35, Liran Alon wrote:
Hi,
This patch series aims to expose VMCS Shadowing feature to L1 guest.
This is done in order to accelerate the use-case of
Triple-Virtualization: When L2 is running a hypervisor which runs a L3
guest.
The patch series was originally developed by Jim Mattson and then was
further modified by myself. I consulted Jim and he suggested
that I will submit the patches with myself as the Author and first
Signed-off-by and him as the second Signed-off-by on all patches.
Jim has also reviewed all the final patches submitted in this series.
The patch series is logically divided into 2 sub-series:
1) Patches 1-11 implement VMCS Shadowing emulation. When L1 enables VMCS
Shadowing in vmcs12, L0 will not enable VMCS Shadowing in vmcs02 and
thus will still intercept all VMREAD/VMWRITE executed by L2. However,
L0 will consult with vmcs12->{vmread,vmwrite}_bitmap to determine if
it should forward VMExit to L1 or simulate L2 VMREAD/VMWRITE itself by
writing to shadow vmcs12.
2) Patches 12-21 implement VMCS Shadowing virtualization. When L1
enables VMCS Shadowing in vmcs12, L0 will now enable VMCS Shadowing
in vmcs02 and define relevant vmcs02->{vmread,vmwrite}_bitmap based on
vmcs12->{vmread,vmwrite}_bitmap and supported physical CPU VMCS
fields. Therefore, CPU will now be able to handle L2 VMREAD/VMWRITE by
using shadow vmcs02. Special care is also made to sync shadow vmcs02
to shadow vmcs12 on L1<->L2 VMEntry/VMExit.
Patch 22 mimics undocumented VMCS Shadowing CPU behavior of making
sure to mask guest access rights VMCS fields to only relevant bits
when they are written using VMWRITE into shadow vmcs.
Note that the solution implemented by this patch series have many
optimization opportunities that we decided to delay to further patch
series. Optimizations such as:
1) Get rid of cached_shadow_vmcs12 and instead use
vmcs12->vmcs_link_pointer directly. This should be simple but
gets complicated when considering nVMX Live-Migration.
2) Avoid building vmcs02->{vmread,vmwrite}_bitmap when
vmcs12->{vmread,vmwrite}_bitmaps have not changed.
3) Avoid using cpu_has_vmcs_field() on every build of
vmcs02->{vmread,vmwrite}_bitmap. We could build this information at
KVM module startup and use this information when building bitmap.
Thus, avoiding additional VMREADs during L1->L2 VMEntry.
Regards,
-Liran Alon
