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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A8793C43214 for ; Wed, 1 Sep 2021 03:34:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5986B61056 for ; Wed, 1 Sep 2021 03:34:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5986B61056 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C335C6B006C; Tue, 31 Aug 2021 23:34:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BBA188D0001; Tue, 31 Aug 2021 23:34:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5A256B0072; Tue, 31 Aug 2021 23:34:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0031.hostedemail.com [216.40.44.31]) by kanga.kvack.org (Postfix) with ESMTP id 907486B006C for ; Tue, 31 Aug 2021 23:34:44 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3B7791855E for ; Wed, 1 Sep 2021 03:34:44 +0000 (UTC) X-FDA: 78537587688.34.3686BF2 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf14.hostedemail.com (Postfix) with ESMTP id 6334B6001983 for ; Wed, 1 Sep 2021 03:34:43 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10093"; a="215482013" X-IronPort-AV: E=Sophos;i="5.84,368,1620716400"; d="scan'208";a="215482013" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Aug 2021 20:34:41 -0700 X-IronPort-AV: E=Sophos;i="5.84,368,1620716400"; d="scan'208";a="531657052" Received: from zhibosun-mobl2.ccr.corp.intel.com (HELO localhost) ([10.255.31.93]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Aug 2021 20:34:32 -0700 Date: Wed, 1 Sep 2021 11:34:29 +0800 From: Yu Zhang To: Andi Kleen Cc: David Hildenbrand , Sean Christopherson , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Borislav Petkov , Andy Lutomirski , Andrew Morton , Joerg Roedel , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Ingo Molnar , Varad Gautam , Dario Faggioli , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, "Kirill A . Shutemov" , "Kirill A . Shutemov" , Kuppuswamy Sathyanarayanan , Dave Hansen Subject: Re: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: <20210901033429.4c2dh5cwlppjvz2h@linux.intel.com> References: <20210824005248.200037-1-seanjc@google.com> <307d385a-a263-276f-28eb-4bc8dd287e32@redhat.com> <20210827023150.jotwvom7mlsawjh4@linux.intel.com> <243bc6a3-b43b-cd18-9cbb-1f42a5de802f@redhat.com> <765e9bbe-2df5-3dcc-9329-347770dc091d@linux.intel.com> <4677f310-5987-0c13-5caf-fd3b625b4344@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-Rspamd-Queue-Id: 6334B6001983 Authentication-Results: imf14.hostedemail.com; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=intel.com (policy=none); spf=none (imf14.hostedemail.com: domain of yu.c.zhang@linux.intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=yu.c.zhang@linux.intel.com X-Rspamd-Server: rspam01 X-Stat-Signature: 6dxrfc4zyuzsnz7sw63f91cwkhjysuwj X-HE-Tag: 1630467283-800356 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, Aug 31, 2021 at 01:39:31PM -0700, Andi Kleen wrote: > > On 8/31/2021 1:15 PM, David Hildenbrand wrote: > > On 31.08.21 22:01, Andi Kleen wrote: > > > > > > > > Thanks a lot for this summary. A question about the requirement: do > > > > > we or > > > > > do we not have plan to support assigned device to the protected VM? > > > > > > > > Good question, I assume that is stuff for the far far future. > > > > > > It is in principle possible with the current TDX, but not secure. But > > > someone might decide to do it. So it would be good to have basic support > > > at least. > > > > Can you elaborate the "not secure" part? Do you mean, making the device > > only access "shared" memory, not secure/encrypted/whatsoever? > > > Yes that's right. It can only access shared areas. Thanks, Andy & David. Actually, enabling of device assinment needs quite some effort, e.g., to guarantee only shared pages are mapped in IOMMU page table (using shared GFNs). And the buffer copying inside TD is still unavoidable, thus not much performance benefit. Maybe we should just *disable* VFIO device in TDX first. As to the fd-based private memory, enventually we will have to tolerate its impact on any place where GUP is needed in virtualization. :) B.R. Yu