mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Sakkinen, Jarkko" <jarkko.sakkinen@intel.com>
To: "Luck, Tony" <tony.luck@intel.com>,
	"seanjc@google.com" <seanjc@google.com>
Cc: "Hansen, Dave" <dave.hansen@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [RFC PATCH 1/4] x86/sgx: Track phase and type of SGX EPC pages
Date: Tue, 27 Jul 2021 01:48:40 +0000	[thread overview]
Message-ID: <98df594dccc9fb5ac857a00308118e6a48bc24a4.camel@intel.com> (raw)
In-Reply-To: <YO3FuBupQTKYaKBf@google.com>

On Tue, 2021-07-13 at 16:56 +0000, Sean Christopherson wrote:
> On Tue, Jun 08, 2021, Tony Luck wrote:
> > Add a type field to struct epc_page for how an in-use page has been
> > allocated. Re-use "enum sgx_page_type" for this type, with a couple
> > of additions for s/w types.
> 
> IMO, taking different actions based on the page type is flawed.  Ditto for adding
> a flag to track so called "dirty" pages.

I agree with this. Let's keep microarchitecture related
structures/enums separate from "software defined" things.

If such things add up (i.e. similar additions to something
else in future), it will be both hard to maintain, and also
the subsystem will be harder to understand for potential future
contributers.

/Jarkko

  reply	other threads:[~2021-07-27  1:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-08 21:40 [RFC PATCH 0/4] Machine check recovery for SGX Tony Luck
2021-06-08 21:40 ` [RFC PATCH 1/4] x86/sgx: Track phase and type of SGX EPC pages Tony Luck
2021-07-13 16:56   ` Sean Christopherson
2021-07-27  1:48     ` Sakkinen, Jarkko [this message]
2021-06-08 21:40 ` [RFC PATCH 2/4] x86/sgx: Add basic infrastructure to recover from errors in SGX memory Tony Luck
2021-07-13 17:14   ` Sean Christopherson
2021-06-08 21:40 ` [RFC PATCH 3/4] x86/sgx: Hook sgx_memory_failure() into mainline code Tony Luck
2021-06-08 21:40 ` [RFC PATCH 4/4] x86/sgx: Add hook to error injection address validation Tony Luck

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=98df594dccc9fb5ac857a00308118e6a48bc24a4.camel@intel.com \
    --to=jarkko.sakkinen@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=seanjc@google.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /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

Powered by JetHome