diff options
| author | Maxim Levitsky <[email protected]> | 2021-04-01 17:18:10 +0300 |
|---|---|---|
| committer | Paolo Bonzini <[email protected]> | 2021-04-17 08:31:01 -0400 |
| commit | 232f75d3b4b5456de6f0b671aa86345d62de1473 (patch) | |
| tree | 3ad310fc0a7ead96bfcfc0f229dd145c7285fd6a /tools/perf/scripts/python | |
| parent | 8486039a6c9f8f56ae8ad06394043b61fcbb7211 (diff) | |
KVM: nSVM: call nested_svm_load_cr3 on nested state load
While KVM's MMU should be fully reset by loading of nested CR0/CR3/CR4
by KVM_SET_SREGS, we are not in nested mode yet when we do it and therefore
only root_mmu is reset.
On regular nested entries we call nested_svm_load_cr3 which both updates
the guest's CR3 in the MMU when it is needed, and it also initializes
the mmu again which makes it initialize the walk_mmu as well when nested
paging is enabled in both host and guest.
Since we don't call nested_svm_load_cr3 on nested state load,
the walk_mmu can be left uninitialized, which can lead to a NULL pointer
dereference while accessing it if we happen to get a nested page fault
right after entering the nested guest first time after the migration and
we decide to emulate it, which leads to the emulator trying to access
walk_mmu->gva_to_gpa which is NULL.
Therefore we should call this function on nested state load as well.
Suggested-by: Paolo Bonzini <[email protected]>
Signed-off-by: Maxim Levitsky <[email protected]>
Message-Id: <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions