I boot with these kernel options for CPU security: "mitigations=auto,nosmt
mds=full,nosmt", on a laptop with Skylake i5-6200U. However, in the BIOS/UEFI
options I enabled all virtualization features of this CPU. This means VT-x/VMX
should be available, since Skylake supports this according to product pages.
The kernel's iTLB multihit mitigation documentation does NOT suggest that any
mitigation option will ever disable VT-x/VMX fully. Therefore, I would strongly
expect it to be enabled on this system with this configuration.

Now here comes the problem:

$ lscpu | grep VMX
Vulnerability Itlb multihit:     KVM: Mitigation: VMX disabled
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional
cache flushes, SMT disabled
$ cat /sys/devices/system/cpu/vulnerabilities/itlb_multihit
KVM: Mitigation: VMX disabled

Something seems to be wrong here. As a semi naive uninformed user, I am
guessing the following possible options for what happened:

Option A: VMX is actually disabled by the kernel through some mitigation
option. In this case this is a documentation issue, since the kernel help
explaining this "KVM: Mitigation: VMX disabled" text (
https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/multihit.html ) is
written like no mitigation would actively disable it, suggesting "VMX disabled"
is only meant to show when the BIOS/UEFI turned it off. So the help page should
then say what may mess with VMX on a kernel level beyond BIOS/UEFI.

Option B: VMX is actually enabled, and the iTLB mitigation is set to "Split
huge pages" (this would as far as I can tell be the "correct" option for this
system). In this case, there seems to be some mostly benign iTLB info output
bug.

Option C: VMS is actually enabled, and the iTLB mitigation is NOT active and
the device is vulnerable. This potential outcome is why I marked this as
SECURITY ISSUE until it can be ruled out, since if that is true then lscpu
clearly tells me I'm safe while I'm actually not. So this outcome could trick
admins into making expensive hardening missteps.

Option D: Maybe I'm just not smart enough to use my BIOS/UEFI, lol, or I
misunderstand VMX/VT-x fundamentally. I'm not a kernel developer, after all.

Vaguely related, this server fault post suggests this may also happen on many
distributions:
https://serverfault.com/questions/1073247/if-kvm-is-working-why-does-vmx-show-as-disabled
(Not entirely sure though if it's the same cause)

First seen with Fedora's 5.13.15-200.fc34.x86_64, still present with OpenSUSE
slowroll's 6.5.9-1-default.

Steps to reproduce:

1. Boot an Intel Skylake computer with Fedora installed. Ensure all
virtualization features are enabled in the UEFI/BIOS options.

2. Once Linux has booted, change /etc/default/grub to add in
"mitigations=auto,nosmt mds=full,nosmt" and update your generated grub2 files,
and reboot.

3. Once inside Linux again, check "lscpu" output and
/sys/devices/system/cpu/vulnerabilities/itlb_multihit output. Expected output
would be something else than "VMX disabled".