From patchwork Mon Oct 11 18:59:17 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Luck, Tony" X-Patchwork-Id: 12550889 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8EDFCC433F5 for ; Mon, 11 Oct 2021 18:59:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 293EC61054 for ; Mon, 11 Oct 2021 18:59:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 293EC61054 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 9CF876B0071; Mon, 11 Oct 2021 14:59:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 97F936B0072; Mon, 11 Oct 2021 14:59:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86E2F6B0073; Mon, 11 Oct 2021 14:59:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0006.hostedemail.com [216.40.44.6]) by kanga.kvack.org (Postfix) with ESMTP id 7923E6B0071 for ; Mon, 11 Oct 2021 14:59:34 -0400 (EDT) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 2C41C181AC212 for ; Mon, 11 Oct 2021 18:59:34 +0000 (UTC) X-FDA: 78685070268.07.4BF93C6 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by imf02.hostedemail.com (Postfix) with ESMTP id 4BF6070021F7 for ; Mon, 11 Oct 2021 18:59:33 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10134"; a="226845150" X-IronPort-AV: E=Sophos;i="5.85,365,1624345200"; d="scan'208";a="226845150" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2021 11:59:31 -0700 X-IronPort-AV: E=Sophos;i="5.85,365,1624345200"; d="scan'208";a="562329859" Received: from agluck-desk2.sc.intel.com ([10.3.52.146]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2021 11:59:31 -0700 From: Tony Luck To: "Rafael J. Wysocki" , naoya.horiguchi@nec.com Cc: Andrew Morton , Sean Christopherson , Jarkko Sakkinen , Dave Hansen , Cathy Zhang , linux-sgx@vger.kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org, Tony Luck Subject: [PATCH v9 0/7] Basic recovery for machine checks inside SGX Date: Mon, 11 Oct 2021 11:59:17 -0700 Message-Id: <20211011185924.374213-1-tony.luck@intel.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: <20211001164724.220532-1-tony.luck@intel.com> References: <20211001164724.220532-1-tony.luck@intel.com> MIME-Version: 1.0 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4BF6070021F7 X-Stat-Signature: oyh3s9z4gzi87goi58yszjmhb3rjxnma Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf02.hostedemail.com: domain of tony.luck@intel.com has no SPF policy when checking 134.134.136.24) smtp.mailfrom=tony.luck@intel.com X-HE-Tag: 1633978773-335996 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Posting latest version to a slightly wider audience. The big picture is that SGX uses some memory pages that are walled off from access by the OS. This means they: 1) Don't have "struct page" describing them 2) Don't appear in the kernel 1:1 map But they are still backed by normal DDR memory, so errors can occur. Parts 1-4 of this series handle the internal SGX bits to keep track of these pages in an error context. They've had a fair amount of review on the linux-sgx list (but if any of the 37 subscribers to that list not named Jarkko or Reinette want to chime in with extra comments and {Acked,Reviewed,Tested}-by that would be great). Linux-mm reviewers can (if they like) skip to part 5 where two changes are made: 1) Hook into memory_failure() in the same spot as device mapping 2) Skip trying to change 1:1 map (since SGX pages aren't there). The hooks have generic looking names rather than specifically saying "sgx" at the suggestion of Dave Hansen. I'm not wedded to the names, so better suggestions welcome. I could also change to using some "ARCH_HAS_PLATFORM_PAGES" config bits if that's the current fashion. Rafael (and other ACPI list readers) can skip to parts 6 & 7 where there are hooks into error injection and reporting to simply say "these odd looking physical addresses are actually ok to use). I added some extra notes to the einj.rst documentation on how to inject into SGX memory. Tony Luck (7): x86/sgx: Add new sgx_epc_page flag bit to mark in-use pages x86/sgx: Add infrastructure to identify SGX EPC pages x86/sgx: Initial poison handling for dirty and free pages x86/sgx: Add SGX infrastructure to recover from poison x86/sgx: Hook arch_memory_failure() into mainline code x86/sgx: Add hook to error injection address validation x86/sgx: Add check for SGX pages to ghes_do_memory_failure() .../firmware-guide/acpi/apei/einj.rst | 19 ++++ arch/x86/include/asm/processor.h | 8 ++ arch/x86/include/asm/set_memory.h | 4 + arch/x86/kernel/cpu/sgx/main.c | 104 +++++++++++++++++- arch/x86/kernel/cpu/sgx/sgx.h | 6 +- drivers/acpi/apei/einj.c | 3 +- drivers/acpi/apei/ghes.c | 2 +- include/linux/mm.h | 14 +++ mm/memory-failure.c | 19 +++- 9 files changed, 168 insertions(+), 11 deletions(-) base-commit: 64570fbc14f8d7cb3fe3995f20e26bc25ce4b2cc