linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	Nathaniel McCallum <npmccallum@redhat.com>,
	Cedric Xing <cedric.xing@intel.com>,
	Jethro Beekman <jethro@fortanix.com>,
	linux-sgx@vger.kernel.org
Subject: Re: [RFC PATCH 4/4] x86/vdso: x86/sgx: Allow the user to exit the vDSO loop on interrupts
Date: Tue, 18 Aug 2020 10:15:49 -0700	[thread overview]
Message-ID: <CALCETrVRAdzFcJOJN6oU1F7hC57zYSmFZi6y2DwhU0sd27FJjQ@mail.gmail.com> (raw)
In-Reply-To: <20200818042405.12871-5-sean.j.christopherson@intel.com>

On Mon, Aug 17, 2020 at 9:24 PM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
>
> Allow userspace to exit the vDSO on interrupts that are acknowledged
> while the enclave is active.  This allows the user's runtime to switch
> contexts at opportune times without additional overhead, e.g. when using
> an M:N threading model (where M user threads run N TCSs, with N > M).

This is IMO rather odd.  We don't support this type of notification on
interrupts for normal user code.  The fact user code can detect
interrupts during enclave execution is IMO an oddity of SGX, and I
have asked Intel to consider replacing the AEX mechanism with
something more transparent to user mode.  If this ever happens, this
mechanism is toast.

Even without architecture changes, building a *reliable* M:N threading
mechanism on top of this will be difficult or impossible, as there is
no particular guarantee that a thread will get timing interrupts at
all or that these interrupts will get lucky and hit enclave code, thus
triggering an AEX.  We certainly don't, and probably never will,
support any corresponding feature for non-enclave code.

So this seems like an odd, and possibly unsupportable, feature to add.

--Andy

  parent reply	other threads:[~2020-08-18 17:16 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18  4:24 [RFC PATCH 0/4] x86/vdso: x86/sgx: Rework SGX vDSO API Sean Christopherson
2020-08-18  4:24 ` [RFC PATCH 1/4] x86/vdso: x86/sgx: Explicitly force 8-byte CMP for detecting user handler Sean Christopherson
2020-08-18 16:46   ` Jarkko Sakkinen
2020-08-20 11:13   ` Jethro Beekman
2020-08-18  4:24 ` [RFC PATCH 2/4] x86/vdso: x86/sgx: Rework __vdso_sgx_enter_enclave() API Sean Christopherson
2020-08-18 16:57   ` Jarkko Sakkinen
2020-08-20 11:23   ` Jethro Beekman
2020-08-24 13:36   ` Jethro Beekman
2020-08-24 19:49     ` Jarkko Sakkinen
2020-09-04 10:25       ` Sean Christopherson
2020-09-04 13:36         ` Jarkko Sakkinen
2020-09-04 16:01           ` Sean Christopherson
2020-08-24 23:54     ` Sean Christopherson
2020-08-25  7:36       ` Jethro Beekman
2020-08-25  7:38         ` Sean Christopherson
2020-08-25  7:41           ` Jethro Beekman
2020-08-26 20:16             ` Sean Christopherson
2020-08-26 19:27   ` Xing, Cedric
2020-08-26 20:15     ` Sean Christopherson
2020-08-26 23:26       ` Xing, Cedric
2020-09-04  9:52         ` Sean Christopherson
2020-08-27  8:58       ` Jethro Beekman
2020-08-26 20:20   ` Sean Christopherson
2020-08-26 20:55     ` Andy Lutomirski
2020-08-27 13:35     ` Jarkko Sakkinen
2020-08-18  4:24 ` [RFC PATCH 3/4] x86/vdso: x86/sgx: Introduce dedicated SGX exit reasons for vDSO Sean Christopherson
2020-08-18 16:58   ` Jarkko Sakkinen
2020-08-20 11:13   ` Jethro Beekman
2020-08-18  4:24 ` [RFC PATCH 4/4] x86/vdso: x86/sgx: Allow the user to exit the vDSO loop on interrupts Sean Christopherson
2020-08-18 17:00   ` Jarkko Sakkinen
2020-08-18 17:15   ` Andy Lutomirski [this message]
2020-08-18 17:31     ` Sean Christopherson
2020-08-18 19:05       ` Andy Lutomirski
2020-08-19 14:21     ` Jethro Beekman
2020-08-19 15:02       ` Andy Lutomirski
2020-08-20 11:20         ` Jethro Beekman
2020-08-20 17:44           ` Andy Lutomirski
2020-08-20 17:53             ` Jethro Beekman
2020-08-22 21:55               ` Andy Lutomirski
2020-08-24 13:36                 ` Jethro Beekman
2020-08-26 18:32                   ` Sean Christopherson
2020-08-26 19:09                     ` Xing, Cedric
2020-08-27  8:57                     ` Jethro Beekman
2020-08-20 11:13   ` Jethro Beekman

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=CALCETrVRAdzFcJOJN6oU1F7hC57zYSmFZi6y2DwhU0sd27FJjQ@mail.gmail.com \
    --to=luto@kernel.org \
    --cc=cedric.xing@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jethro@fortanix.com \
    --cc=linux-sgx@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).