Bug 53861 - nVMX: inaccuracy in emulation of entry failure
Summary: nVMX: inaccuracy in emulation of entry failure
Status: NEW
Alias: None
Product: Virtualization
Classification: Unclassified
Component: kvm (show other bugs)
Hardware: All Linux
: P1 enhancement
Assignee: virtualization_kvm
URL:
Keywords:
Depends on:
Blocks: 94971 53601
  Show dependency tree
 
Reported: 2013-02-14 15:13 UTC by Nadav Har'El
Modified: 2015-03-17 03:53 UTC (History)
0 users

See Also:
Kernel Version:
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Nadav Har'El 2013-02-14 15:13:28 UTC
Emulation of nested entry (L1->L2) failure is rather involved, and there are two kinds of entry failures - some recognized before the vmcs02 was touched (and nested_vmx_failValid/Invalid() is used), and some after we started to touch vmcs02 (and nested_vmx_entry_failure() is used). This whole business is explained in the Intel SDM, section "VM-entry failures during or after loading guest state".

But where's a corner cases related to *buggy L0* that we probably do not emulate sensibly:

Imagine that L0 runs L2 for L1, and succeeds, but then exits to L0 for some reason and L0 handles this event (without L1's involvement) and wants to resume L2. What if this entry fails, e.g., because we (L0) filled some vmcs02 field incorrectly? Neither nested_vmx_failValid() or nested_vmx_entry_failure() are appropriate because L2 did run for a while and most likely changed vmcs02 (so we need to update vmcs12 with prepare_vmcs12()).

This can only happen due to L0 bug (which sets something wrong in the vmcs) so perhaps the best solution is just to kill L1 in this case? Is there a better solution?

Note You need to log in before you can comment on or make changes to this bug.