| Message ID | 1554388929-20127-1-git-send-email-igor.druzhinin@citrix.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/vmx: Fixup removals from MSR load-lists | expand |
On 04/04/2019 15:42, Igor Druzhinin wrote: I'd add "entries" to the subject, which can be done on commit. > Commit fd32dcfe ("x86/vmx: Don't leak EFER.NXE into guest context") > introduced a regression on Harpertown and earlier cores (Gen 1 VT-x) > where as soon as guest EFER becomes equal to Xen EFER > (almost any 64-bit VM) stale version of EFER is incorrectly > loaded into a guest causing almost immediate guest failure. > > Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
>>> On 04.04.19 at 16:42, <igor.druzhinin@citrix.com> wrote: > Commit fd32dcfe ("x86/vmx: Don't leak EFER.NXE into guest context") > introduced a regression on Harpertown and earlier cores (Gen 1 VT-x) > where as soon as guest EFER becomes equal to Xen EFER > (almost any 64-bit VM) stale version of EFER is incorrectly > loaded into a guest causing almost immediate guest failure. I'm afraid this is not an overly helpful description, considering the actual fix. It's definitely not that commit which has introduced the bug - vmx_del_msr() has been there before. Hence the bug was only uncovered by the referenced commit. With a reference to the actual faulty commit added Reviewed-by: Jan Beulich <jbeulich@suse.com> Jan
> From: Igor Druzhinin [mailto:igor.druzhinin@citrix.com] > Sent: Thursday, April 4, 2019 10:42 PM > > Commit fd32dcfe ("x86/vmx: Don't leak EFER.NXE into guest context") > introduced a regression on Harpertown and earlier cores (Gen 1 VT-x) > where as soon as guest EFER becomes equal to Xen EFER > (almost any 64-bit VM) stale version of EFER is incorrectly > loaded into a guest causing almost immediate guest failure. > > Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> Acked-by: Kevin Tian <kevin.tian@intel.com>
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index 74f2a08..45d1849 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -1490,15 +1490,15 @@ int vmx_del_msr(struct vcpu *v, uint32_t msr, enum vmx_msr_list_type type) switch ( type ) { case VMX_MSR_HOST: - __vmwrite(VM_EXIT_MSR_LOAD_COUNT, vmx->host_msr_count--); + __vmwrite(VM_EXIT_MSR_LOAD_COUNT, --vmx->host_msr_count); break; case VMX_MSR_GUEST: - __vmwrite(VM_EXIT_MSR_STORE_COUNT, vmx->msr_save_count--); + __vmwrite(VM_EXIT_MSR_STORE_COUNT, --vmx->msr_save_count); /* Fallthrough */ case VMX_MSR_GUEST_LOADONLY: - __vmwrite(VM_ENTRY_MSR_LOAD_COUNT, vmx->msr_load_count--); + __vmwrite(VM_ENTRY_MSR_LOAD_COUNT, --vmx->msr_load_count); break; }
Commit fd32dcfe ("x86/vmx: Don't leak EFER.NXE into guest context") introduced a regression on Harpertown and earlier cores (Gen 1 VT-x) where as soon as guest EFER becomes equal to Xen EFER (almost any 64-bit VM) stale version of EFER is incorrectly loaded into a guest causing almost immediate guest failure. Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com> --- I assume this is a candidate for backporting to stable-4.12. --- xen/arch/x86/hvm/vmx/vmcs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)