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=-10.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 10797C433FE for ; Thu, 2 Sep 2021 18:41:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AB559610E5 for ; Thu, 2 Sep 2021 18:41:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org AB559610E5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 140A66B0071; Thu, 2 Sep 2021 14:41:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F0B88D0001; Thu, 2 Sep 2021 14:41:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F20F86B0073; Thu, 2 Sep 2021 14:41:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0196.hostedemail.com [216.40.44.196]) by kanga.kvack.org (Postfix) with ESMTP id DFAA16B0071 for ; Thu, 2 Sep 2021 14:41:10 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 72BBB235DE for ; Thu, 2 Sep 2021 18:41:10 +0000 (UTC) X-FDA: 78543500700.28.B8C2877 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf11.hostedemail.com (Postfix) with ESMTP id E9CACF0000B9 for ; Thu, 2 Sep 2021 18:41:09 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 18B7561054; Thu, 2 Sep 2021 18:41:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1630608069; bh=Rz27QrMv3CmEHDYgF/fVueCgLU4vpnJjqWFkkAFYWTo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=aAeGYLAqgzAU48atK8jAIAITEdS1UEjxwuAflbmidzx0ALrOBEwzA2ev56kjz/umQ uZqY+/B5VCOzIeDcO0/SMFwQ2ZrHxn0rHI7R+SiZcZc+bvPu5hA33bnpI2x354TeNw gNoh7kx6MyBDHccHT4gwSqhwqTFQKPoupyUd4BPiSU+6E21EV8dOBm+ed43cUnVrOu wMjhh8vcM98olY5RkwTuRnZhw++6zXDWQZU27zpjTszKctI2/N4PZwaexQ7hFguDoG DQdBdHB5zbJpPmFiCHNChobr1WkwQDIpG7aQ/V2CfxmMvI4oOhOhTHQsER188NlSvP Wju2ZUSj2VOXA== Subject: Re: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory To: Yu Zhang Cc: David Hildenbrand , Sean Christopherson , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm list , Linux Kernel Mailing List , Borislav Petkov , Andrew Morton , Joerg Roedel , Andi Kleen , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , "Peter Zijlstra (Intel)" , Ingo Molnar , Varad Gautam , Dario Faggioli , the arch/x86 maintainers , linux-mm@kvack.org, linux-coco@lists.linux.dev, "Kirill A. Shutemov" , "Kirill A . Shutemov" , Sathyanarayanan Kuppuswamy , Dave Hansen References: <20210824005248.200037-1-seanjc@google.com> <307d385a-a263-276f-28eb-4bc8dd287e32@redhat.com> <20210827023150.jotwvom7mlsawjh4@linux.intel.com> <8f3630ff-bd6d-4d57-8c67-6637ea2c9560@www.fastmail.com> <20210901102437.g5wrgezmrjqn3mvy@linux.intel.com> <20210902081923.lertnjsgnskegkmn@linux.intel.com> From: Andy Lutomirski Message-ID: Date: Thu, 2 Sep 2021 11:41:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210902081923.lertnjsgnskegkmn@linux.intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aAeGYLAq; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf11.hostedemail.com: domain of luto@kernel.org designates 198.145.29.99 as permitted sender) smtp.mailfrom=luto@kernel.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: E9CACF0000B9 X-Stat-Signature: rnbcgzrkziezdfj8xwqcqrao7owfbh3w X-HE-Tag: 1630608069-563803 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: >> >> In principle, you could actually initialize a TDX guest with all of its >> memory shared and all of it mapped in the host IOMMU. When a guest >> turns some pages private, user code could punch a hole in the memslot, >> allocate private memory at that address, but leave the shared backing >> store in place and still mapped in the host IOMMU. The result would be >> that guest-initiated DMA to the previously shared address would actually >> work but would hit pages that are invisible to the guest. And a whole >> bunch of memory would be waste, but the whole system should stll work. > > Do you mean to let VFIO & IOMMU to treat all guest memory as shared first, > and then just allocate the private pages in another backing store? I guess > that could work, but with the cost of allocating roughly 2x physical pages > of the guest RAM size. After all, the shared pages shall be only a small > part of guest memory. Yes. My point is that I don't think there should be any particular danger in leaving the VFIO code alone as part of TDX enablement. The code ought to *work* even if it will be wildly inefficient. If someone cares to make it work better, they're welcome to do so. --Andy