From: "Luck, Tony" <tony.luck@intel.com>
To: Sean Christopherson <seanjc@google.com>,
"Chatre, Reinette" <reinette.chatre@intel.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/4] x86/sgx: Track phase and type of SGX EPC pages
Date: Wed, 14 Jul 2021 23:39:01 +0000 [thread overview]
Message-ID: <c0fa2e9e65da4f58893386279ce914c1@intel.com> (raw)
In-Reply-To: <YO9uZKLYCIBc1HsH@google.com>
> I've no objection to tracking the type for SGX2, my argument in the context of
> #MC support is that there should be no need to track the type. Either the #MC
> is recoverable or it isn't, and the enclave is toast regardless of what type of
> page hit the #MC.
I'll separate the "phase" from the "type".
Here phase is used for the life-cycle of EPC pages:
DIRTY -> FREE -> IN-USE -> DIRTY
Errors can be reported by memory controller page scrubbers
for pages that are not "IN-USE" ... and the recovery action is
just to make sure that they are never allocated.
When a page is IN-USE ... it has a "type". I currently
only have a way to inject errors into SGX_PAGE_TYPE_REG
pages. That means initial recovery code is going to focus on
those since that is all I can test. But I'll try not to special case
them as far as possible.
-Tony
next prev parent reply other threads:[~2021-07-14 23:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-08 18:14 [PATCH 0/4] Basic recovery for machine checks inside SGX Tony Luck
2021-07-08 18:14 ` [PATCH 1/4] x86/sgx: Track phase and type of SGX EPC pages Tony Luck
2021-07-09 18:08 ` Jarkko Sakkinen
2021-07-09 18:09 ` Jarkko Sakkinen
2021-07-14 20:42 ` Reinette Chatre
2021-07-14 20:59 ` Luck, Tony
2021-07-14 21:21 ` Reinette Chatre
2021-07-14 23:08 ` Sean Christopherson
2021-07-14 23:39 ` Luck, Tony [this message]
2021-07-15 15:33 ` Sean Christopherson
2021-07-08 18:14 ` [PATCH 2/4] x86/sgx: Add basic infrastructure to recover from errors in SGX memory Tony Luck
2021-07-08 18:14 ` [PATCH 3/4] x86/sgx: Hook sgx_memory_failure() into mainline code Tony Luck
2021-07-08 18:14 ` [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=c0fa2e9e65da4f58893386279ce914c1@intel.com \
--to=tony.luck@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=jarkko@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=reinette.chatre@intel.com \
--cc=seanjc@google.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