>
> I checked the code again and find the comment of
> nested_vmx_check_permission().
>
> "/*
> * Intel's VMX Instruction Reference specifies a common set of
> prerequisites
> * for running VMX instructions (except VMXON, whose prerequisites are
> * slightly different). It also specifies what exception to inject
> otherwise.
> * Note that many of these exceptions have priority over VM exits, so they
> * don't have to be checked again here.
> */"
>
> I think the Note part in the comment has tried to callout why the check
> for compatibility mode is unnecessary.
>
> But I have a question here, nested_vmx_check_permission() checks that
> the vcpu is vmxon,
> otherwise it will inject a #UD. Why this #UD is handled in the VMExit
> handler specifically?
> Not all #UDs have higher priority than VM exits?
>
> According to SDM Section "Relative Priority of Faults and VM Exits":
> "Certain exceptions have priority over VM exits. These include
> invalid-opcode exceptions, ..."
> Seems not further classifications of #UDs.
This is clarified in the pseudo code of VMX instructions in the SDM. If you
look at the pseudo code, all VMX instructions except VMXON (obviously) have
something like below:
IF (not in VMX operation) ...
THEN #UD;
ELSIF in VMX non-root operation
THEN VMexit;
So to me "this particular" #UD has higher priority over VM exits (while other
#UDs may not).
But IIUC above #UD won't happen when running VMX instruction in the guest,
because if there's any live guest, the CPU must already have been in VMX
operation. So below check in nested_vmx_check_permission():
if (!to_vmx(vcpu)->nested.vmxon) {
kvm_queue_exception(vcpu, UD_VECTOR);
return 0;
}
is needed to emulate the case that guest runs any other VMX instructions before
VMXON.
>
> Anyway, I will seperate this patch from the LAM KVM enabling patch. And
> send a patch seperately if
> needed later.
>
I think your change for SGX is still needed based on the pseudo code of ENCLS.
