x86/HVM: don't cause #NM to be raised in Xen
authorJan Beulich <jbeulich@suse.com>
Thu, 28 Jun 2018 07:07:06 +0000 (09:07 +0200)
committerJan Beulich <jbeulich@suse.com>
Thu, 28 Jun 2018 07:07:06 +0000 (09:07 +0200)
commit488efc29e4e996bb3805c982200f65061390cdce
tree3a96ebd65ec809bd4cb779dabd0bbeab27da0063
parentdd64d3c41a2d15139c3a35d22d4cb6b78f4c5c59
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>
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