The kernel detects that it runs in a VM, where it doesn't know if it runs on a SMT "thread core" or a real, non-SMT shared core, you effectively can fake both for the VM by chaning the CPU setting (socket, core, thread) of the VM. The SMT part is only really relevant for the host.Is this ok?
The other part, i.e.,
is currently expected for VMs, the issue here is that the CPU would need the 'md_clear' flag to signal the Kernel that the recycled "VERW" instruction does what it should with the new microcode, clear the internal CPU buffers which made this exploit possible. Currently we cannot set the "md_clear" flag for the VM cpu, this will probably be possible in the future. But, AFAICT, that's for cosmetics only, as once "Clear CPU buffers attempted" is shown by the guest OS and the Host OS has new kernel + microcode updates the vmwerv instruction should go through and actually do the correct thing on the host. In other words, the guest OS always tries to call the mitigation instruction, if the host is mitigated then all is well, else it's a no-op, but the guest cannot really tell (yet) what of the two things are happening. I hope I could phrase this somewhat clear.Vulnerable: Clear CPU buffers attempted