x86/HVM: don't cause #NM to be raised in Xen
authorJan Beulich <jbeulich@suse.com>
Thu, 28 Jun 2018 07:39:09 +0000 (09:39 +0200)
committerJan Beulich <jbeulich@suse.com>
Thu, 28 Jun 2018 07:39:09 +0000 (09:39 +0200)
commit959353ad4aebb8c26c71c7650a449d2618d3a720
treeb8e5bc2b1445d51d304bbf5436e3c48d82f4d558
parentb33b61105c1ab1facf01ab7f46d2aae3a71fcd11
x86/HVM: don't cause #NM to be raised in Xen

The changes for XSA-267 did not touch management of CR0.TS for HVM
guests. In fully eager mode this bit should never be set when
respective vCPU-s are active, or else hvmemul_get_fpu() might leave it
wrongly set, leading to #NM in hypervisor context.

{svm,vmx}_enter() and {svm,vmx}_fpu_dirty_intercept() become unreachable
this way. Explicit {svm,vmx}_fpu_leave() invocations need to be guarded
now.

With no CR0.TS management necessary in fully eager mode, there's also no
need anymore to intercept #NM.

Reported-by: Charles Arnold <carnold@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
master commit: 488efc29e4e996bb3805c982200f65061390cdce
master date: 2018-06-28 09:07:06 +0200
xen/arch/x86/hvm/svm/svm.c
xen/arch/x86/hvm/svm/vmcb.c
xen/arch/x86/hvm/vmx/vmcs.c
xen/arch/x86/hvm/vmx/vmx.c