diff options
author | Maxim Levitsky <mlevitsk@redhat.com> | 2020-08-27 18:27:18 +0200 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2020-09-12 18:19:06 +0200 |
commit | 9883764ad0ce037c554ac0ef302dcf671f8d1ccb (patch) | |
tree | aad00e3ee71a25ecf6febe8658a1947e4715767e /arch/powerpc/kvm | |
parent | x86/kvm: don't forget to ACK async PF IRQ (diff) | |
download | linux-9883764ad0ce037c554ac0ef302dcf671f8d1ccb.tar.xz linux-9883764ad0ce037c554ac0ef302dcf671f8d1ccb.zip |
SVM: nSVM: correctly restore GIF on vmexit from nesting after migration
Currently code in svm_set_nested_state copies the current vmcb control
area to L1 control area (hsave->control), under assumption that
it mostly reflects the defaults that kvm choose, and later qemu
overrides these defaults with L2 state using standard KVM interfaces,
like KVM_SET_REGS.
However nested GIF (which is AMD specific thing) is by default is true,
and it is copied to hsave area as such.
This alone is not a big deal since on VMexit, GIF is always set to false,
regardless of what it was on VM entry. However in nested_svm_vmexit we
were first were setting GIF to false, but then we overwrite the control
fields with value from the hsave area. (including the nested GIF field
itself if GIF virtualization is enabled).
Now on normal vm entry this is not a problem, since GIF is usually false
prior to normal vm entry, and this is the value that copied to hsave,
and then restored, but this is not always the case when the nested state
is loaded as explained above.
To fix this issue, move svm_set_gif after we restore the L1 control
state in nested_svm_vmexit, so that even with wrong GIF in the
saved L1 control area, we still clear GIF as the spec says.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20200827162720.278690-2-mlevitsk@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'arch/powerpc/kvm')
0 files changed, 0 insertions, 0 deletions