On Wed, Oct 07, 2020 at 08:08:32PM +0300, Jarkko Sakkinen wrote: > On Wed, Oct 07, 2020 at 08:25:45AM -0700, Sean Christopherson wrote: > > On Wed, Oct 07, 2020 at 10:39:23AM +0300, Jarkko Sakkinen wrote: > > > On Tue, Oct 06, 2020 at 09:34:19PM -0700, Sean Christopherson wrote: > > > > > Even if that was in place, you'd need to separate normal and interrupt. > > > > > Tristate is useless here. > > > > > > > > Huh? You mean like adding SGX_INTERRUPT_EXIT and SGX_EXCEPTION_EXIT? > > > > > > OK, so I'll throw something. > > > > > > 1. "normal" is either exception from either EENTER or ERESUME, > > > or just EEXIT. > > > 2. "interrupt" is something where you want to tailor AEP path. > > > > Manipulating the behavior of the vDSO, as in #2, would be done via an input > > flag. It may be related to the exit reason, e.g. the flag may also opt-in to > > a new exit reason, but that has no bearing on whether or not a dedicated exit > > reason is valuable. > > The fact is that AEP path is not actual right now. > > I'm not even interested to go further on discussing about feature that > does not exist. Perhaps if/when it exist it turns out that we want a > variable lets say 'exit_reason' to present something in that context. > > I'm neither against that or for it because it is all speculative. > > > > > I'm not arguing that any of the above is even remotely likely. I just don't > > > > understand why we'd want an API that at best requires heuristics in userspace > > > > to determine why the enclave stopped running, and at worst will saddle us with > > > > an ugly mess in the future. All to save 4 bytes that no one cares about (they > > > > literally cost nothing), and a single MOV in a flow that is hundreds, if not > > > > thousands, of cycles. > > > > > > I don't care as much as saving bytes as defining API, which has zero > > > ambiguous state variables. > > > > How is exit_reason ambiguous? > > I rather pick the word redundant: > > 1. 'leaf' exist anyway. > 2. It can represent all the state we need right now. > 3. It does not block anything., > > I care deeply about wasting 4 bytes in a fixed size struct for > absolutely nothing. And I do care about what to pick for the struct size. My remarks on that are lost somewhere in this thread. I absoutely do not have any interest whether 'exit_reason' in some future situation is useful or not. /Jarkko
