summaryrefslogtreecommitdiff
path: root/drivers/infiniband/hw/ionic/ionic_datapath.c
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2025-09-19 15:32:36 -0700
committerSean Christopherson <seanjc@google.com>2025-09-23 09:23:10 -0700
commitf7336d47be53d0da1e74143b8befea8c0176f3cc (patch)
tree311844ea1f711e66d4002843dd94fabdacb23357 /drivers/infiniband/hw/ionic/ionic_datapath.c
parente140467bbdafff84f1f346a7c59f404cd9782b82 (diff)
KVM: VMX: Configure nested capabilities after CPU capabilities
Swap the order between configuring nested VMX capabilities and base CPU capabilities, so that nested VMX support can be conditioned on core KVM support, e.g. to allow conditioning support for LOAD_CET_STATE on the presence of IBT or SHSTK. Because the sanity checks on nested VMX config performed by vmx_check_processor_compat() run _after_ vmx_hardware_setup(), any use of kvm_cpu_cap_has() when configuring nested VMX support will lead to failures in vmx_check_processor_compat(). While swapping the order of two (or more) configuration flows can lead to a game of whack-a-mole, in this case nested support inarguably should be done after base support. KVM should never condition base support on nested support, because nested support is fully optional, while obviously it's desirable to condition nested support on base support. And there's zero evidence the current ordering was intentional, e.g. commit 66a6950f9995 ("KVM: x86: Introduce kvm_cpu_caps to replace runtime CPUID masking") likely placed the call to kvm_set_cpu_caps() after nested setup because it looked pretty. Reviewed-by: Chao Gao <chao.gao@intel.com> Link: https://lore.kernel.org/r/20250919223258.1604852-30-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'drivers/infiniband/hw/ionic/ionic_datapath.c')
0 files changed, 0 insertions, 0 deletions