Hmm. But at least it was lyingFor anything VMXE related, yes.
similarly on AMD and Intel CPUs. :)
So I was able to reproduce the problems
myself.
Do you mean, any AMD tests are now useless, and we need to proceed with Intel
tests only?
Then additional question.I'm struggling to even come up with a theory as to how setting VMXE from
On old Intel CPUs we needed to set VMXE in guest to make it to work in
nested-guest mode.
Is it still needed even with your patches?
Or the nested-guest mode will work now even on older Intel CPUs and KVM will
set VMXE for us itself, when needed?
userspace would have impacted KVM with unrestricted_guest=n, let alone fixed
anything.
CR4.VMXE must always be 1 in _hardware_ when VMX is on, including when running
the guest. But KVM forces vmcs.GUEST_CR4.VMXE=1 at all times, regardless of
the guest's actual value (the guest sees a shadow value when it reads CR4).
And unless I grossly misunderstand dosemu2, it's not doing anything related to
nested virtualization, i.e. the stuffing VMXE=1 for the guest's shadow value
should have absolutely zero impact.
More than likely, VMXE was a red herring.
Given that the reporter is also
seeing the same bug on bare metal after moving to kernel 5.4, odds are good
the issue is related to unrestricted_guest=n and has nothing to do with nVMX.