On Mon, Mar 16, 2020 at 03:53:22PM -0700, Sean Christopherson wrote: > Yes and no. If we wanted to minimize the amount of wrapping around the > vDSO's ENCLU then we wouldn't have the exit handler shenanigans in the > first place. The whole process has been about balancing the wants of each > use case against the overall quality of the API and code. Minimizing is not something that happens in a void. Given the user base for the SDK having the handler was a necessity. Otherwise, we would not have that handler in the first place. > Up until Nathaniel joined the party, the only stakeholder in terms of the > exit handler was the Intel SDK. There was a general consensus to pass > registers as-is when there isn't a strong reason to do otherwise. Note > that Nathaniel has also expressed approval of that approach. OK, great. > The major benefits being that the vDSO would be callable from C and that > the kernel could define a legitimate prototype instead of a frankenstein > prototype that's half assembly and half C. For me, those are significant I was not aware that there was a plot to make it callable by C. OK, so right now A. @leaf = %eax B. @tcs = 8(%rsp) C. @e = 0x10(%rsp) D. @handler = 0x18(%rsp) On x86-64 Linux C calling convention means DI/SI/DX/CX type of thing. So what is the thing that we are referring to C calling convetion in this email discussion? > benefits and well worth the extra MOV, PUSH and POP. For some use cases > it would eliminate the need for an assembly wrapper. For runtimes that > need an assembly wrapper for whatever reason, it's probably still a win as > a well designed runtime can avoid register shuffling in the wrapper. And > if there is a runtime that isn't covered by the above, it's at worst an > extra MOV. Is it cool if I rip of the documentation from vsgx_enter_enclave.S and move it to Documentation/ ? It is nasty to keep and update it where it is right now. How it is right now, it is destined to rotten. /Jarkko
