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 3BF63C63797 for ; Tue, 17 Jan 2023 13:27:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AE38A6B0071; Tue, 17 Jan 2023 08:27:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A95016B0073; Tue, 17 Jan 2023 08:27:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 935776B0074; Tue, 17 Jan 2023 08:27:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 807616B0071 for ; Tue, 17 Jan 2023 08:27:41 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 431EA40579 for ; Tue, 17 Jan 2023 13:27:41 +0000 (UTC) X-FDA: 80364368322.03.DD3E73A Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by imf23.hostedemail.com (Postfix) with ESMTP id 21FC8140010 for ; Tue, 17 Jan 2023 13:27:37 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=A39mvJj8; spf=none (imf23.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1673962058; h=from:from:sender:reply-to: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=uO6Hl9Q1M/Q348P8FnxA7jBYA0T+TYYW0ZM59Q1/+sI=; b=kU4PviwqzdjxS4BTPckg7/gyTSu6fpaAWmEx9adDyKqZovlIcu8bJrRZWjl54MYlXpO0aQ DlQd3l2bHx/PbE6IBCvBn5uSAdSvWqCCXp2b3ndBrLBsAYJW5OmhGyaoHZkPetSotnGGGd SCp5W5kafzhVslu/YQ+z/xDz8kXgUh4= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=A39mvJj8; spf=none (imf23.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 192.55.52.43) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1673962058; a=rsa-sha256; cv=none; b=HIyVwxpLfPl6D2CrfIq+GELOlBzek3RZ7+94yG/KkvZSrlHXtM7b4dez2ywBw02ego3dxo xwJ+cFioTd3srsYXk8SZIIPWvpyY5CJ670PX3e1XLCNM5RLLFO1XG5R/rFW4fPJ0/EXIBX 4TKlXmM2QF5JTEgkzkM20ymX9Eygefs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673962058; x=1705498058; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=OkxN9qHIfugzlGcYWrmJzkTgsJkFyQ0089rnB9xhbso=; b=A39mvJj8Oh1fQHMjbJnMBB32OqntK7snve+bCGwark7PZk6lcGJ7sAPF awlpjwC+p/2q2Wfz7YIOmyy4JDBx8sumEhcos2wf4xh0h/pK6udKsCsDB ue7shD3crPDqcVWVaJgMfnQcDfUvdM8AyWNaYhgI2V77pVzAoQ7FQay/W oQC1EWz+epbSE4G2TMWRj5ThQZSlvy13/0A91ao2f6qeKPw5Dh3xKWyPu ALv2EA98+XxjW6mVaJg6ggJbmPvTlZH5nd0bZlNhLL8tR7gzNgdsqq/zH iyLiEwnqzIdFtSgotTCkSgYTnh566p/84UaZm2Tt7YsPauNskUofOV5jl g==; X-IronPort-AV: E=McAfee;i="6500,9779,10592"; a="410930557" X-IronPort-AV: E=Sophos;i="5.97,224,1669104000"; d="scan'208";a="410930557" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jan 2023 05:27:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10592"; a="722655367" X-IronPort-AV: E=Sophos;i="5.97,224,1669104000"; d="scan'208";a="722655367" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.192.105]) by fmsmga008.fm.intel.com with ESMTP; 17 Jan 2023 05:27:25 -0800 Date: Tue, 17 Jan 2023 21:19:37 +0800 From: Chao Peng To: Sean Christopherson Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Arnd Bergmann , Naoya Horiguchi , Miaohe Lin , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, david@redhat.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , tabba@google.com, Michael Roth , mhocko@suse.com, wei.w.wang@intel.com Subject: Re: [PATCH v10 0/9] KVM: mm: fd-based approach for supporting KVM Message-ID: <20230117131937.GD273037@chaop.bj.intel.com> Reply-To: Chao Peng References: <20221202061347.1070246-1-chao.p.peng@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 21FC8140010 X-Stat-Signature: 1rfabcskm9xbttae9ra4rge6d8nes7z3 X-HE-Tag: 1673962057-108718 X-HE-Meta: U2FsdGVkX18NQW52k+wU4+KkXSo0h+3Wuf1VSX2jrMie8Tbtp/Cew0baWj1BroicjHBXMo+urSAPIv5YdgEzgfbn4/a+RPTmztQ+tckvHBHDRv4/HTDwwcno0OjViRS5RGdOxfAtegEX1JdJib7bTUvmcSeHsNVxtuG1tnhOO5ZkgB185ZJZ5R44JEh+L2kScj2RpATlxeMJCDB4ngV2ZjfoZsvwMrY5Kgf7DFPGqDbIbRASowDnhllzlSIETxqviDyX4vbhN82EEVrsX+KGeTMJAWciYQbpp4bKKQyLCYS+ktJyDBaZbm6DubVHMOm7jiQPn6sQv2K5r3MVaHwFuyJhleAUnjlxy+YaN77dBl8qFHk5SG3RLY7zj7HYhEeOwc9qqdXOZTIx7syVUCTMehK25qaRnO7V3r6T7AOJigzqz7UBqk+X5z0vUU8rG+FxUT0oLClsm//Fe6+ov1EumMUVhjYcbBaIiXojNHtTk10+1Of2UbnidYLyvMQzW6ZOTePCHVOfNrt5GUngD/YkJNgDG/hUQX1dJUOx/zD5Q5oKK4RubSTuUnMZGHLAtKdgZ9jS0bZVJfJIttAdSplPNTo+iMzYixvrPGmo5704Q1hm4Ss/dZjRgURDjUyQwAPegmma4H+g/Gykvg6SINTDqnJ+XwQdXAnT+0EsZOOq6I4kS4rO9+EDB1gPaJIrWz7ZGx9j9/19JshzcVVU1QH/0Yovmuh2Rmhs8OD0jiul0WMjdNW5GnL1mk21Ol6Rm3dZNk0aRMEHcxTl5fgGAMB3U/UMn7So7UIsxQRd9Mc9R93Z+rmfQn1k0MgUeXyE6jaRgv/tRQDYcMlDTw/ACObbWhgF1cnYDaJ1OosAGL7poQZbD56xOKulmb08KxGKGOorWLBMU2LizgTwiZbu7Cf61zCgPKNM46uper03Yo/Y9n3uIrdAUwIqIsPffZFGgs7ORYgOPxcmXbM= 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 Sat, Jan 14, 2023 at 12:37:59AM +0000, Sean Christopherson wrote: > On Fri, Dec 02, 2022, Chao Peng wrote: > > This patch series implements KVM guest private memory for confidential > > computing scenarios like Intel TDX[1]. If a TDX host accesses > > TDX-protected guest memory, machine check can happen which can further > > crash the running host system, this is terrible for multi-tenant > > configurations. The host accesses include those from KVM userspace like > > QEMU. This series addresses KVM userspace induced crash by introducing > > new mm and KVM interfaces so KVM userspace can still manage guest memory > > via a fd-based approach, but it can never access the guest memory > > content. > > > > The patch series touches both core mm and KVM code. I appreciate > > Andrew/Hugh and Paolo/Sean can review and pick these patches. Any other > > reviews are always welcome. > > - 01: mm change, target for mm tree > > - 02-09: KVM change, target for KVM tree > > A version with all of my feedback, plus reworked versions of Vishal's selftest, > is available here: > > git@github.com:sean-jc/linux.git x86/upm_base_support > > It compiles and passes the selftest, but it's otherwise barely tested. There are > a few todos (2 I think?) and many of the commits need changelogs, i.e. it's still > a WIP. Thanks very much for doing this. Almost all of your comments are well received, except for two cases that need more discussions which have replied individually. > > As for next steps, can you (handwaving all of the TDX folks) take a look at what > I pushed and see if there's anything horrifically broken, and that it still works > for TDX? I have integrated this into my local TDX repo, with some changes (as I replied individually), the new code basically still works with TDX. I have also asked other TDX folks to take a look. > > Fuad (and pKVM folks) same ask for you with respect to pKVM. Absolutely no rush > (and I mean that). > > On my side, the two things on my mind are (a) tests and (b) downstream dependencies > (SEV and TDX). For tests, I want to build a lists of tests that are required for > merging so that the criteria for merging are clear, and so that if the list is large > (haven't thought much yet), the work of writing and running tests can be distributed. > > Regarding downstream dependencies, before this lands, I want to pull in all the > TDX and SNP series and see how everything fits together. Specifically, I want to > make sure that we don't end up with a uAPI that necessitates ugly code, and that we > don't miss an opportunity to make things simpler. The patches in the SNP series to > add "legacy" SEV support for UPM in particular made me slightly rethink some minor > details. Nothing remotely major, but something that needs attention since it'll > be uAPI. > > I'm off Monday, so it'll be at least Tuesday before I make any more progress on > my side. Appreciate your effort. As for the next steps, if you see something we can do parallel, feel free to let me know. Thanks, Chao