Sean Christopherson <sean.j.christopherson@xxxxxxxxx> writes:
> On Tue, Mar 26, 2019 at 02:07:46PM +0100, Vitaly Kuznetsov wrote:
>> Commit 5bea5123cbf0 ("KVM: VMX: check nested state and CR4.VMXE against
>> SMM") introduced a check to vmx_set_cr4() forbidding to set VMXE from SMM.
>> The check is correct, however, there is a special case when RSM is called
>> to leave SMM: rsm_enter_protected_mode() is called with HF_SMM_MASK still
>> set and in case VMXE was set before entering SMM we're failing to return.
>>
>> Resolve the issue by temporary dropping HF_SMM_MASK around set_cr4() calls
>> when ops->set_cr() is called from RSM.
>>
>> Reported-by: Jon Doron <arilou@xxxxxxxxx>
>> Suggested-by: Liran Alon <liran.alon@xxxxxxxxxx>
>> Fixes: 5bea5123cbf0 ("KVM: VMX: check nested state and CR4.VMXE against SMM")
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
>
> Plumbing from_rsm all the way to set_cr() is pretty heinous. What about
> going with the idea Jim alluded to, i.e. manually save/restore VMXE during
> transitions to/from SMM? It's a little more tedious than it aught to be
> due to the placement and naming of the x86_ops hooks for SMM, but IMO the
> end result is cleaner even after adding the necessary callbacks.
>
> The following patches are compile tested only.
Thanks and welcome to the 'rsm fixing' party :-)
I like your/Jim's approach, however, with these patches as-is the issue
persists:
KVM: entry failed, hardware error 0x80000021
If you're running a guest on an Intel machine without unrestricted mode
support, the failure can be most likely due to the guest entering an invalid
state for Intel VT. For example, the guest maybe running in big real mode
which is not supported on less recent Intel processors.
RAX=000000007ffc7301 RBX=0000000000000000 RCX=0000000000000000 RDX=00007ff900000000
RSI=000000007dab4018 RDI=000000007ff9f000 RBP=0000000000000000 RSP=ffffe80000210fc0
R8 =0000000000000000 R9 =0000000000000000 R10=ffffbb8140cfd790 R11=ffffbb8140cfd7d0
R12=ffffbb8140cfd7d0 R13=ffffbb8140cfd790 R14=0000000000000008 R15=0000000000000000
RIP=fffff80007d44125 RFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=1 HLT=0
...
Let me take a look what's wrong.
P.S. We probably need a kvm-unit-tests or selftests test as
Hyper-V+secureboot is the only known way to test this atm.
--
Vitaly
