On Thu, Apr 08, 2021, Kai Huang wrote: > + /* > + * sgx_virt_ecreate() returns: > + * 1) 0: ECREATE was successful > + * 2) -EFAULT: ECREATE was run but faulted, and trapnr was set to the > + * exception number. > + * 3) -EINVAL: access_ok() on @secs_hva fails. It's a kernel bug and > + * sgx_virt_ecreate() aleady gave a warning. Eh, I don't love "kernel bug", all we know is that access_ok() failed. It's also not all that helpful since it doesn't guide the debugger to any particular code that would prevent access_ok() from failing. What if this comment simply states the rules/expectations and lets the debugger figure out what's wrong? E.g. * 3) -EINVAL: access_ok() on @secs_hva failed. This should never * happen as KVM checks host addresses at memslot creation. * sgx_virt_create() has already warned in this case. Same goes for sgx_virt_einit() in the next patch. > + */ > + ret = sgx_virt_ecreate(pageinfo, (void __user *)secs_hva, &trapnr); > + if (!ret) > + return kvm_skip_emulated_instruction(vcpu); > + if (ret == -EFAULT) > + return sgx_inject_fault(vcpu, secs_gva, trapnr); > + > + return ret; > +}
