From mboxrd@z Thu Jan 1 00:00:00 1970 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 17372C88CB4 for ; Tue, 13 Jun 2023 11:05:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5528D6B0074; Tue, 13 Jun 2023 07:05:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 502F28E0003; Tue, 13 Jun 2023 07:05:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A42D8E0002; Tue, 13 Jun 2023 07:05:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2C8DC6B0074 for ; Tue, 13 Jun 2023 07:05:51 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 00A92C0487 for ; Tue, 13 Jun 2023 11:05:50 +0000 (UTC) X-FDA: 80897444460.08.CFA208F Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf26.hostedemail.com (Postfix) with ESMTP id 2B21F140028 for ; Tue, 13 Jun 2023 11:05:46 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=GI6opklR; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf26.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686654347; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=PFuYh0fvwQpbZ73XJqUtIXV8ZdXCt1+RByvARyUudUo=; b=x0WiJy6GoRhSHiuVMlwikiIHWAy/mbouiJwuAnVRLLIoBW9OCYqOvaXIGpq+c26s3PPPYQ p1Hqn8buMc/E0b2Z8D15BB44vd5YB//zCwlrlze4i1d870ByL/eiGr/kIT/DNpFQqFLt3E PZRyFwajg/Uwrw5mrkDEDD1PE0CmNlo= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=GI6opklR; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf26.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=kirill.shutemov@linux.intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686654347; a=rsa-sha256; cv=none; b=3WM7d40dCxT1R4rSQWGKBloP+rH3rfmEFL1uF0rxYNfyV8wDmIpydw2TVoUPY2Xb7arga3 GtWAbv9xANvIlsGF9G+JNnp/XQV7Sjqni8wWKYIJst9MDXR1nHdpZPAtWIuoW0XKwCd04R /PtdANJPU3kfDEq0zRmJxKPOzJv0PHw= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1686654347; x=1718190347; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=UmOXzsunhXdXp44lTelSL36XFYP6MdWvrrp3FDoTFjA=; b=GI6opklRWuTll0gtSzqgksbQyva4ISVRgFmSf9RzLc7WaGuFKkMjh7F7 80mUikw98HTs4jmcywhpy/oyhnMZ2oQnBRAooARRvoEt4ymTp15iK3uDo eQC4FB+qYMmi5TRw+FSHykaRVLQTaRD3FYWcwY+zlitkto6zF9fl2c3y6 BLXqiQIU+JxffwZ/wOhm7hLSNyDUUlYFtr9JksvO7SGzzIRSa0VwPJcqw UhnL0VgJPd1jRn4VO4MxaQe1yYtpIRSas1JgSFTJPzytsDuCTM4aHze8T hvve9skssT7+oKQJFYlf61+iDKq6wuRtBdbxIDnRfpG7X/yWrbeX+4KH0 g==; X-IronPort-AV: E=McAfee;i="6600,9927,10739"; a="355796316" X-IronPort-AV: E=Sophos;i="6.00,239,1681196400"; d="scan'208";a="355796316" Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jun 2023 04:05:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10739"; a="781617957" X-IronPort-AV: E=Sophos;i="6.00,239,1681196400"; d="scan'208";a="781617957" Received: from attilavx-mobl2.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.62.33]) by fmsmga004-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jun 2023 04:05:40 -0700 Received: by box.shutemov.name (Postfix, from userid 1000) id 0BBBB10BB72; Tue, 13 Jun 2023 14:05:38 +0300 (+03) Date: Tue, 13 Jun 2023 14:05:38 +0300 From: "kirill.shutemov@linux.intel.com" To: "Huang, Kai" Cc: "Hansen, Dave" , "kvm@vger.kernel.org" , "Luck, Tony" , "david@redhat.com" , "bagasdotme@gmail.com" , "ak@linux.intel.com" , "Wysocki, Rafael J" , "linux-kernel@vger.kernel.org" , "Chatre, Reinette" , "Christopherson,, Sean" , "pbonzini@redhat.com" , "tglx@linutronix.de" , "linux-mm@kvack.org" , "Yamahata, Isaku" , "peterz@infradead.org" , "Shahar, Sagi" , "imammedo@redhat.com" , "Gao, Chao" , "Brown, Len" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "Huang, Ying" , "Williams, Dan J" Subject: Re: [PATCH v11 18/20] x86: Handle TDX erratum to reset TDX private memory during kexec() and reboot Message-ID: <20230613110538.5pwhy26q6irrlqqx@box.shutemov.name> References: <5aa7506d4fedbf625e3fe8ceeb88af3be1ce97ea.1685887183.git.kai.huang@intel.com> <20230609132301.uvvp27yr5kpenl6f@box.shutemov.name> <58f34b4b81b6d6b37d3386dec0f073e6eb7a97ff.camel@intel.com> <20230612075830.jbrdd6ysz4qq7wdf@box.shutemov.name> <4c7effc3abe71aa1cbee41f3bd46b97aed40be26.camel@intel.com> <48d5a29a-878c-665d-6ac2-6f0563bf6f3c@intel.com> <3bbb6b384ba89dfaa13be01654ad27e41d779fba.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbb6b384ba89dfaa13be01654ad27e41d779fba.camel@intel.com> X-Rspamd-Queue-Id: 2B21F140028 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: rjc4twyfjoe1b7z5idn5uyp8scp9a37f X-HE-Tag: 1686654346-546417 X-HE-Meta: U2FsdGVkX1+Def3R+R6vOWRlnh/NOdRYasit/dp+eGd3kT3VJ7MNb+HGL0w1SXTF8OsVZwtGiAkaPcizLZV4xL9Stjd4Vl+UM5SWP7bCkfsT07pgvgcptLJalihnjF3+Yvu6Cs38kgVGl50dYuUUnmTbvhYMqQajIz/p4Y07TPige6k0AtYr+j5NpZQNDEJ/cirkut0OXRNxCoz+tZVOIl3EW23oZ9FID/C8UAUrNL7D5MBg02K3CyqlR8iL/bpxog/3wkluk1bbQugjXNpKzlhl5sKFOKjxpoTJ/QBTnKuJNs+IplOlZx7UuNVCcgAX977OHVW06FHT5Q0zzGqu0cGaXXzgPoafNLVRKR7mSlJHHFnULO7aTmWjy8D04R4Ujao/EQ8s/ZPL5RCMxZ3ikrYy6znXBQYo/2hXTVR1oPY8UodPIkBFmWEk5ElsGy8/tZctOqCUz8y7PXCgVsIZ8qjPYzY4zXLfSi9sO/c2M4YX0GjP8SqWNR+SDmvIGWQ/c/malu5Xs4z4vEpw4MailKZg4Y/ivaEd62xU2wZH8ZbjUSBK05WgAZs6tmeiGuCf6rRaYv6eMzsJ1mgyCFam/gYV5wPu6a7goKCo+kxdn1B5hCwD7ktbHCgVdlvCcqqq3+nX/orsJ8zttPMY/e3xwHsxOK2K+iYqE3nFKnzE+OZt47ECk5XJdY2NbvPFfKKDcYnbNn/WfT64L36wfXu5fZ0roL1YMiAQL/J6Kj3ISmJD8CGn6lHYcYIIEYtrLdDGRFozhVsJhF51lX/a76S7i2BN2SfCPRai0f5l4rlv+vD4MIlC+kjwYAVLKZc9EZIs13dDjKt57a8RY76Ov1dDSKO0h09msgDlrNj8Un0wN1gmSbR0oVwyXEZ6CIGsvJemJ9wNkANdK47l/J3FQUNyKyAuvzfibSgIJkBuiZghQoVdh4RjmkvQnxsOfEXbmFRfAFkhOdyRzTbKclMzjUW +OpRWEBw OjmvyX0Sj6bIB2mI3WA/OsRt7UhOtx32aQ0WqpI/HAARQw3TwNRvNO+fSOQYzeizx40KGPBR+85/f8N/3fOl22D0LB8/+QL/Q9J2c5BI4sPPWyUeyYH5p2BIQ8WMC+DCH0fC/dY3lFfO+maG6Nmeq+UmYX51ymBl14ECMH2kmcVuOWg50mAqNkX5pDQ== 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: On Tue, Jun 13, 2023 at 12:51:23AM +0000, Huang, Kai wrote: > On Mon, 2023-06-12 at 06:47 -0700, Dave Hansen wrote: > > On 6/12/23 03:27, Huang, Kai wrote: > > > So I think a __mb() after setting tdmr->pamt_4k_base should be good enough, as > > > it guarantees when setting to any pamt_*_size happens, the valid pamt_4k_base > > > will be seen by other cpus. > > > > > > Does it make sense? > > > > Just use a normal old atomic_t or set_bit()/test_bit(). They have > > built-in memory barriers are are less likely to get botched. > > Thanks for the suggestion. > > Hi Dave, Kirill, > > I'd like to check with you that whether we should introduce a mechanism to track > TDX private pages for both this patch and the next. > > As you can see this patch only deals PAMT pages due to couple of reasons that > mnentioned in the changelog. The next MCE patch handles all TDX private pages, > but it uses SEAMCALL in the #MC handler. Using SEAMCALL has two cons: 1) it is > slow (probably doesn't matter, though); 2) it brings additional risk of > triggering further #MC inside TDX module, although such risk should be a > theoretical thing. > > If we introduce a helper to mark a page as TDX private page, then both above > patches can utilize it. We don't need to consult TDMRs to get PAMT anymore in > this patch (we will need a way to loop all TDX-usable memory pages, but this > needs to be done anyway with TDX guests). I believe eventually we can end up > with less code. > > In terms of how to do, for PAMT pages, we can set page->private to a TDX magic > number because they come out of page allocator directly. Secure-EPT pages are > like PAMT pages too. For TDX guest private pages, Sean is moving to implement > KVM's own pseudo filesystem so they will have a unique mapping to identify. > > https://github.com/sean-jc/linux/commit/40d338c8629287dda60a9f7c800ede8549295a7c > > And my thinking is in this TDX host series, we can just handle PAMT pages. Both > secure-EPT and TDX guest private pages can be handled later in KVM TDX series. > I think eventually we can have a function like below to tell whether a page is > TDX private page: > > bool page_is_tdx_private(struct page *page) > { > if (page->private == TDX_PRIVATE_MAGIC) > return true; > > if (!page_mapping(page)) > return false; > > return page_mapping(page)->a_ops == &kvm_gmem_ops; > } > > How does this sound? Or any other comments? Thanks! If you going to take this path it has to be supported natively by kvm_gmem_: it has to provide API for that. You should not assume that page->private is free to use. It is owned by kvm_gmmem. -- Kiryl Shutsemau / Kirill A. Shutemov