All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: linux-sgx@vger.kernel.org,
	Nathaniel McCallum <npmccallum@redhat.com>,
	Haitao Huang <haitao.huang@linux.intel.com>,
	Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Cedric Xing <cedric.xing@intel.com>
Subject: Re: [PATCH] x86/vdso: Flatten and clean up struct sgx_enclave_run
Date: Fri, 2 Oct 2020 07:25:05 +0300	[thread overview]
Message-ID: <20201002042505.GA34513@linux.intel.com> (raw)
In-Reply-To: <20201001204027.GA18610@linux.intel.com>

On Fri, Oct 02, 2020 at 12:46:11AM +0300, Jarkko Sakkinen wrote:
> > > The documentation, selftest and the kernel source code use the terms "user
> > > handler" and "exit handler" in somewhat inconsistent manner. Start using
> > > "AEX handler" consistently as this is the term that Intel SDM volume D uses
> > > for these events.
> > 
> > No, AEX is specifically for "asynchronus" exits.  In this context, that is
> > limited to the exception path.  The vDSO invokes the user handler for EEXIT,
> > i.e. the synchrous path, which is not an AEX.
> 
> OK, I but this one.
> 
> I got gray hairs because:
> 
> - API called it user handler.
> - Documentation called it exit handler.
> - Selftest called it exit handler.
> 
> I think user_handler is too generic and abstract but I'm happy to hear
> other proposals than 'exit_' to which I will change given your feedback.

OK, so here I use my "too generic" argument pick user handler anyhow
because we don't know what the heck the handler is doing.

'exit_handler' implies that not only it would be called for enclave
exit resulting from an exception, but also for EEXIT path.

/Jarkko

  parent reply	other threads:[~2020-10-02  4:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-01 16:16 [PATCH] x86/vdso: Flatten and clean up struct sgx_enclave_run Jarkko Sakkinen
2020-10-01 16:51 ` Sean Christopherson
2020-10-01 21:46   ` Jarkko Sakkinen
2020-10-01 22:50     ` Sean Christopherson
2020-10-02  3:20       ` Jarkko Sakkinen
2020-10-02  4:25     ` Jarkko Sakkinen [this message]
2020-10-02 14:27       ` Jarkko Sakkinen
2020-10-02 15:49         ` Jarkko Sakkinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201002042505.GA34513@linux.intel.com \
    --to=jarkko.sakkinen@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=cedric.xing@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=haitao.huang@linux.intel.com \
    --cc=linux-sgx@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=npmccallum@redhat.com \
    --cc=sean.j.christopherson@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.