Message ID | 20240212104448.2589568-9-kirill.shutemov@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-61358-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:50ea:b0:106:860b:bbdd with SMTP id r10csp2381636dyd; Mon, 12 Feb 2024 04:04:27 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCV6uE2NpVFmTZBr+ScwK/4gElp2HFOcEfddgH3R0JJeD3W5ZZzRwHVkmOvV9fdu57K3tY6U+8eEMh9FktGtsjmsXYtXNg== X-Google-Smtp-Source: AGHT+IEDXVD06GEVuLKd0oAlB000nNw1Ww7Ctokhu64wKMqwtO5W8Hg3ihSSFsCcC8hGWk5Pf1xt X-Received: by 2002:a62:aa18:0:b0:6de:12ae:68d6 with SMTP id e24-20020a62aa18000000b006de12ae68d6mr4876524pff.17.1707739466688; Mon, 12 Feb 2024 04:04:26 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1707739466; cv=pass; d=google.com; s=arc-20160816; b=DMN2Sp5SC8drgJnWHLPSlWHHIS96+TWAxl5zZIICnyXp/vIHVKdBfk2mnDGlFYwFjk LEYHXWLLnsdjbqfkqd3nQ0J3MX/jFbtGXdNjZ4whrDe40peJY6aYY+F7FbsbRks0zBoI 7nWkBRIZwksT3WaTnbN3y7+vLA1mcgHdZdoBGrzb61rU3Qi7PnSs+o0cvGog0/uprPzn LC2vyg/iuK+hQABWC2a7B/+/n/MWb6qAKBpYT64qt4eaEN5SxMUASDY+ObFLM0kLxS8a bKa/sB2t5mVLnfP5d1eTF1Sac1+UsJBYdUqgn9EdBuawSUsNa+eVpMBL8KxCb88nK7+L f07A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=QbNVvvHkrGHh7BR7Qwt2J0OgUR8dAXMlMSzqos0/4mY=; fh=9pjAm4BxNj5nm9kUGUruITVWZNW2VNpBpmUYyogX64s=; b=o4cDy9BznONV83I3DU1Sdr33rA59jAxZm9q5BkoBPz0vMDAD+ftEA4l1Jw8hLu2skB OCRPmiKv5POSzanrEff/bzbCUNS++oKHR45bmjT6l9lSoHcYHNL6fkSis0v6LVdUjlYU 9mZzPLMrMzA+BHSPg8vMbpE9SK5z6FmbCxgXGG91qg3Ql1Spp175W+676HQoDjsVv53b fda+eY8edjQiTp+uBn6aPw+IxGjHJjE/LXpi794ql9RFj1S8A3No2i/HPt+vMe0/vVN+ YIF3gVqns3O8cxJFKdZW4D7xxwVJF8DgUA5cIe6M0jaDIszE10xOEmsqzFbHNG1DNZ3k jLuw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jY57t3qY; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-61358-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61358-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com X-Forwarded-Encrypted: i=2; AJvYcCXdZGUww6Xc2w62+dqAZ2RC3efoNw6l9CcT3AsU0tsyfT+U8ZiQ3uhCYGDJ2V97r/enVofT8H0TyOWSA0hcKDF9uwHDGQ== Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id x32-20020a056a0018a000b006dbe30aeb1dsi4927185pfh.112.2024.02.12.04.04.26 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 04:04:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-61358-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=jY57t3qY; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-61358-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-61358-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 73FF828600B for <ouuuleilei@gmail.com>; Mon, 12 Feb 2024 10:49:04 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BDD3824B2F; Mon, 12 Feb 2024 10:45:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="jY57t3qY" Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5566A3B191 for <linux-kernel@vger.kernel.org>; Mon, 12 Feb 2024 10:45:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707734710; cv=none; b=rs6Wg0bhYdn7lrVgyW4GgJxTuffhwBtMg6RNeemgDha/G0jFt4NP7e2u/0+8kzB/DK22hyntpS1XrSNPYHWioddT69IMdNEhwDYdVGjm4guNPfMH/oxjwe1eRhDYm3kYEqLdh+KGrLozTCSqlImqMI6U5No1miM1SwLJRQUIMxk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1707734710; c=relaxed/simple; bh=ttorKfrAsCfwHjNDg0dNsgpEDrTBddN8JkJtVUzul2k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Yw+uVtD+wZuIlUamYAMWXEoQ7IpjJQ3NRnQ93429jU6XN1XPHyvDWJD7SYeeXGIS4hull4sWlEzEl3K9qHCbQiO3flvRR1mrfTfxZn+uwpIz8T/ITZ6DPaZc1Vp09ZQMcpUAjBBSZFnaHo823cc0HnAdiDXkofOXrxMRYUkPEDU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.helo=mgamail.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=jY57t3qY; arc=none smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.helo=mgamail.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1707734707; x=1739270707; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=ttorKfrAsCfwHjNDg0dNsgpEDrTBddN8JkJtVUzul2k=; b=jY57t3qYL1YgZPvA3KmwHJC8ugSV5cqWXYdxz5wXsGvJVUbq8RLyZV+z K1zPqp9ye+QdowjxCsbVlvJK97g50II/pZKIAuOu4jv+3634NmK4SwLYM I3aBcJv8660NLOFh1OgTf5YagMTGsv7vvkeOJoYJ0Qw4LmReUwmaeBC4q MGTVsqrwSkQUvMxiwi66EDnf3CJMjnfComelVHZ+ioLlWWS0brEWvgSVy qI9g3D/sH9E9EALLrMcWCO0I44wiaMJ2F+0YAtPAbT1urIqr+Y0QPULby EXJN5ddd9tnGBRR1cMupBbbEBtKUu5M3xqrwlJvBt5Jt6DQhsn2GpStJy Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10981"; a="1585068" X-IronPort-AV: E=Sophos;i="6.05,263,1701158400"; d="scan'208";a="1585068" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Feb 2024 02:45:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10981"; a="935035601" X-IronPort-AV: E=Sophos;i="6.05,262,1701158400"; d="scan'208";a="935035601" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga001.fm.intel.com with ESMTP; 12 Feb 2024 02:45:00 -0800 Received: by black.fi.intel.com (Postfix, from userid 1000) id 54901541; Mon, 12 Feb 2024 12:44:53 +0200 (EET) From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> To: Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org Cc: "Rafael J. Wysocki" <rafael@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Adrian Hunter <adrian.hunter@intel.com>, Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>, Elena Reshetova <elena.reshetova@intel.com>, Jun Nakajima <jun.nakajima@intel.com>, Rick Edgecombe <rick.p.edgecombe@intel.com>, Tom Lendacky <thomas.lendacky@amd.com>, "Kalra, Ashish" <ashish.kalra@amd.com>, Sean Christopherson <seanjc@google.com>, "Huang, Kai" <kai.huang@intel.com>, Baoquan He <bhe@redhat.com>, kexec@lists.infradead.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Subject: [PATCHv7 08/16] x86/tdx: Account shared memory Date: Mon, 12 Feb 2024 12:44:40 +0200 Message-ID: <20240212104448.2589568-9-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240212104448.2589568-1-kirill.shutemov@linux.intel.com> References: <20240212104448.2589568-1-kirill.shutemov@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1790694619046331734 X-GMAIL-MSGID: 1790694619046331734 |
Series |
x86/tdx: Add kexec support
|
|
Commit Message
Kirill A. Shutemov
Feb. 12, 2024, 10:44 a.m. UTC
The kernel will convert all shared memory back to private during kexec.
The direct mapping page tables will provide information on which memory
is shared.
It is extremely important to convert all shared memory. If a page is
missed, it will cause the second kernel to crash when it accesses it.
Keep track of the number of shared pages. This will allow for
cross-checking against the shared information in the direct mapping and
reporting if the shared bit is lost.
Include a debugfs interface that allows for the check to be performed at
any point.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
arch/x86/coco/tdx/tdx.c | 69 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 69 insertions(+)
Comments
On 2/12/24 02:44, Kirill A. Shutemov wrote: > The kernel will convert all shared memory back to private during kexec. > The direct mapping page tables will provide information on which memory > is shared. > > It is extremely important to convert all shared memory. If a page is > missed, it will cause the second kernel to crash when it accesses it. > > Keep track of the number of shared pages. This will allow for > cross-checking against the shared information in the direct mapping and > reporting if the shared bit is lost. > > Include a debugfs interface that allows for the check to be performed at > any point. When I read this, I thought you were going to do some automatic checking. Could you make it more clear here that it's 100% up to the user to figure out if the numbers in debugfs match and whether there's a problem? This would also be a great place to mention that the whole thing is racy. > +static atomic_long_t nr_shared; > + > +static inline bool pte_decrypted(pte_t pte) > +{ > + return cc_mkdec(pte_val(pte)) == pte_val(pte); > +} Name this pte_is_decrypted(), please. > /* Called from __tdx_hypercall() for unrecoverable failure */ > noinstr void __noreturn __tdx_hypercall_failed(void) > { > @@ -821,6 +829,11 @@ static int tdx_enc_status_change_finish(unsigned long vaddr, int numpages, > if (!enc && !tdx_enc_status_changed(vaddr, numpages, enc)) > return -EIO; > > + if (enc) > + atomic_long_sub(numpages, &nr_shared); > + else > + atomic_long_add(numpages, &nr_shared); > + > return 0; > } > > @@ -896,3 +909,59 @@ void __init tdx_early_init(void) > > pr_info("Guest detected\n"); > } > + > +#ifdef CONFIG_DEBUG_FS > +static int tdx_shared_memory_show(struct seq_file *m, void *p) > +{ > + unsigned long addr, end; > + unsigned long found = 0; > + > + addr = PAGE_OFFSET; > + end = PAGE_OFFSET + get_max_mapped(); > + > + while (addr < end) { > + unsigned long size; > + unsigned int level; > + pte_t *pte; > + > + pte = lookup_address(addr, &level); > + size = page_level_size(level); > + > + if (pte && pte_decrypted(*pte)) > + found += size / PAGE_SIZE; > + > + addr += size; > + > + cond_resched(); > + } This is totally racy, right? Nothing prevents the PTE from flip-flopping all over the place. > + seq_printf(m, "Number of shared pages in kernel page tables: %16lu\n", > + found); > + seq_printf(m, "Number of pages accounted as shared: %16ld\n", > + atomic_long_read(&nr_shared)); > + return 0; > +} Ditto with 'nr_shared'. There's nothing to say that the page table walk has anything to do with 'nr_shared' by the time we get down here. That's not _fatal_ for a debug interface, but the pitfalls need to at least be discussed. Better yet would be to make sure this and the cpa code don't stomp on each other.
On Fri, Feb 23, 2024 at 11:08:18AM -0800, Dave Hansen wrote: > On 2/12/24 02:44, Kirill A. Shutemov wrote: > > The kernel will convert all shared memory back to private during kexec. > > The direct mapping page tables will provide information on which memory > > is shared. > > > > It is extremely important to convert all shared memory. If a page is > > missed, it will cause the second kernel to crash when it accesses it. > > > > Keep track of the number of shared pages. This will allow for > > cross-checking against the shared information in the direct mapping and > > reporting if the shared bit is lost. > > > > Include a debugfs interface that allows for the check to be performed at > > any point. > > When I read this, I thought you were going to do some automatic > checking. Could you make it more clear here that it's 100% up to the > user to figure out if the numbers in debugfs match and whether there's a > problem? This would also be a great place to mention that the whole > thing is racy. What about this: Include a debugfs interface to dump the number of shared pages in the direct mapping and the expected number. There is no serialization against memory conversion. The numbers might not match if access to the debugfs interface races with the conversion. > > +static atomic_long_t nr_shared; > > + > > +static inline bool pte_decrypted(pte_t pte) > > +{ > > + return cc_mkdec(pte_val(pte)) == pte_val(pte); > > +} > > Name this pte_is_decrypted(), please. But why? pte_decrypted() is consistent with other pte helpers pte_none(), pte_present, pte_dirty(), ... > > /* Called from __tdx_hypercall() for unrecoverable failure */ > > noinstr void __noreturn __tdx_hypercall_failed(void) > > { > > @@ -821,6 +829,11 @@ static int tdx_enc_status_change_finish(unsigned long vaddr, int numpages, > > if (!enc && !tdx_enc_status_changed(vaddr, numpages, enc)) > > return -EIO; > > > > + if (enc) > > + atomic_long_sub(numpages, &nr_shared); > > + else > > + atomic_long_add(numpages, &nr_shared); > > + > > return 0; > > } > > > > @@ -896,3 +909,59 @@ void __init tdx_early_init(void) > > > > pr_info("Guest detected\n"); > > } > > + > > +#ifdef CONFIG_DEBUG_FS > > +static int tdx_shared_memory_show(struct seq_file *m, void *p) > > +{ > > + unsigned long addr, end; > > + unsigned long found = 0; > > + > > + addr = PAGE_OFFSET; > > + end = PAGE_OFFSET + get_max_mapped(); > > + > > + while (addr < end) { > > + unsigned long size; > > + unsigned int level; > > + pte_t *pte; > > + > > + pte = lookup_address(addr, &level); > > + size = page_level_size(level); > > + > > + if (pte && pte_decrypted(*pte)) > > + found += size / PAGE_SIZE; > > + > > + addr += size; > > + > > + cond_resched(); > > + } > > This is totally racy, right? Nothing prevents the PTE from > flip-flopping all over the place. Yes. > > + seq_printf(m, "Number of shared pages in kernel page tables: %16lu\n", > > + found); > > + seq_printf(m, "Number of pages accounted as shared: %16ld\n", > > + atomic_long_read(&nr_shared)); > > + return 0; > > +} > > Ditto with 'nr_shared'. There's nothing to say that the page table walk > has anything to do with 'nr_shared' by the time we get down here. > > That's not _fatal_ for a debug interface, but the pitfalls need to at > least be discussed. Better yet would be to make sure this and the cpa > code don't stomp on each other. Serializing is cumbersome here. I can also just drop the interface.
On 2/25/24 07:54, Kirill A. Shutemov wrote:
> Serializing is cumbersome here. I can also just drop the interface.
Just drop it for now. We can come back after the fact and debate how to
do the debugging.
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 26fa47db5782..fd212c9bad89 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -5,6 +5,7 @@ #define pr_fmt(fmt) "tdx: " fmt #include <linux/cpufeature.h> +#include <linux/debugfs.h> #include <linux/export.h> #include <linux/io.h> #include <asm/coco.h> @@ -38,6 +39,13 @@ #define TDREPORT_SUBTYPE_0 0 +static atomic_long_t nr_shared; + +static inline bool pte_decrypted(pte_t pte) +{ + return cc_mkdec(pte_val(pte)) == pte_val(pte); +} + /* Called from __tdx_hypercall() for unrecoverable failure */ noinstr void __noreturn __tdx_hypercall_failed(void) { @@ -821,6 +829,11 @@ static int tdx_enc_status_change_finish(unsigned long vaddr, int numpages, if (!enc && !tdx_enc_status_changed(vaddr, numpages, enc)) return -EIO; + if (enc) + atomic_long_sub(numpages, &nr_shared); + else + atomic_long_add(numpages, &nr_shared); + return 0; } @@ -896,3 +909,59 @@ void __init tdx_early_init(void) pr_info("Guest detected\n"); } + +#ifdef CONFIG_DEBUG_FS +static int tdx_shared_memory_show(struct seq_file *m, void *p) +{ + unsigned long addr, end; + unsigned long found = 0; + + addr = PAGE_OFFSET; + end = PAGE_OFFSET + get_max_mapped(); + + while (addr < end) { + unsigned long size; + unsigned int level; + pte_t *pte; + + pte = lookup_address(addr, &level); + size = page_level_size(level); + + if (pte && pte_decrypted(*pte)) + found += size / PAGE_SIZE; + + addr += size; + + cond_resched(); + } + + seq_printf(m, "Number of shared pages in kernel page tables: %16lu\n", + found); + seq_printf(m, "Number of pages accounted as shared: %16ld\n", + atomic_long_read(&nr_shared)); + return 0; +} + +static int tdx_shared_memory_open(struct inode *inode, struct file *file) +{ + return single_open(file, tdx_shared_memory_show, NULL); +} + +static const struct file_operations tdx_shared_memory_fops = { + .open = tdx_shared_memory_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + +static __init int debug_tdx_shared_memory(void) +{ + if (!cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) + return 0; + + debugfs_create_file("tdx_shared_memory", 0400, arch_debugfs_dir, + NULL, &tdx_shared_memory_fops); + return 0; +} +fs_initcall(debug_tdx_shared_memory); +#endif