aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/syscall-counts-by-pid.py
diff options
context:
space:
mode:
authorJim Mattson <[email protected]>2018-09-13 11:54:48 -0700
committerPaolo Bonzini <[email protected]>2018-10-17 00:29:47 +0200
commit3c6e099fa15fdb6fb1892199ed8709012e1294f2 (patch)
treea3a547070c1e17b08a4b08b46b5219d33472f412 /tools/perf/scripts/python/syscall-counts-by-pid.py
parent214ff83d4473a7757fa18a64dc7efe3b0e158486 (diff)
KVM: nVMX: Always reflect #NM VM-exits to L1
When bit 3 (corresponding to CR0.TS) of the VMCS12 cr0_guest_host_mask field is clear, the VMCS12 guest_cr0 field does not necessarily hold the current value of the L2 CR0.TS bit, so the code that checked for L2's CR0.TS bit being set was incorrect. Moreover, I'm not sure that the CR0.TS check was adequate. (What if L2's CR0.EM was set, for instance?) Fortunately, lazy FPU has gone away, so L0 has lost all interest in intercepting #NM exceptions. See commit bd7e5b0899a4 ("KVM: x86: remove code for lazy FPU handling"). Therefore, there is no longer any question of which hypervisor gets first dibs. The #NM VM-exit should always be reflected to L1. (Note that the corresponding bit must be set in the VMCS12 exception_bitmap field for there to be an #NM VM-exit at all.) Fixes: ccf9844e5d99c ("kvm, vmx: Really fix lazy FPU on nested guest") Reported-by: Abhiroop Dabral <[email protected]> Signed-off-by: Jim Mattson <[email protected]> Reviewed-by: Peter Shier <[email protected]> Tested-by: Abhiroop Dabral <[email protected]> Reviewed-by: Liran Alon <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/syscall-counts-by-pid.py')
0 files changed, 0 insertions, 0 deletions