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=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 8AEFFC433FE for ; Thu, 2 Sep 2021 18:57:23 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 64AFE610E5 for ; Thu, 2 Sep 2021 18:57:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347214AbhIBS6U (ORCPT ); Thu, 2 Sep 2021 14:58:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347156AbhIBS6T (ORCPT ); Thu, 2 Sep 2021 14:58:19 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E2955C061757 for ; Thu, 2 Sep 2021 11:57:20 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id bg1so1779285plb.13 for ; Thu, 02 Sep 2021 11:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=AkmWZUegUhZEVUOACKSTOdlhb7SyRMPHYAHvTBr+eB4=; b=TnMNc8uOhY/OYYSg2N6xNC1fGTSR8kviK5K5YEINI0m2O8Z89Wzzv4DeGq+ml4O59E u83UPU0GGnBufLgYxSkuLGTn3UTtmtPT9K0vIwbunw3Tc8gAM0PKAX2ULUTDINl0qlJy NZDpV7k62Jvgq2wD02XKQRzQvv1P5Am+ACZFpcNxPyA3/KAbxPfgWlzxpUUQAlxNstAj uE4c1fjB7NGrzdIdCxfjd9wC/etG/JJxsfLgC8HtDSJ52ZTGSsCL3l6prPfcaSvO4cmd le0FM7CWdX2LcaUGSnom+tHFWyq2gValn0fvbZ+Qzl+rjvDJDCVv7dDaJw71C/kiRwYh 7dNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=AkmWZUegUhZEVUOACKSTOdlhb7SyRMPHYAHvTBr+eB4=; b=CtURd4FscCrV4LItTgp/T9csTuXgps7xuHTFOn19aGrTDtJS49frVLkdkPGqRDe1du LFaroSYbYbM/pY9LwbLnPCcyGhD1qQ86gdEqKX+3TqnmnR0Fw6rTg8kETRB+WoK6XL05 ozPADw1J4Ls8MSya4JQgoSN8qli/hC8WzQx7KUUe0HSZ+3ml7lSnJ6ux79cHeQvcSpgh GsV5vl6kDXI94UJ0sJyjr/DQRavKzUDXJwRtytKF0pEIvX8n6KUmUklAnm+kmtLl53nu 976Qn5DokKUC4gNdB6RmvfF4nD9S8YG5djrvf0yhO6eyiA6In+EtbBCTSzbnnA4ta84K sO0Q== X-Gm-Message-State: AOAM532kgUX9iNOQhJr5P/s1l8Pr5dRi8a/qX5NZL6QaaygSKQNGlkBV 9gNkpwNzs0gFY9/fVcsD0Episg== X-Google-Smtp-Source: ABdhPJzXIt7ZCXNKLguQN7iCvVvLI+EDT/Q0Dj1HLvNPmMNjO2x3c5nxy/MGerUjagXqZcuhjRVKDQ== X-Received: by 2002:a17:903:1207:b0:138:e2f9:6c98 with SMTP id l7-20020a170903120700b00138e2f96c98mr4153452plh.11.1630609040137; Thu, 02 Sep 2021 11:57:20 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id y14sm3063120pfp.84.2021.09.02.11.57.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Sep 2021 11:57:19 -0700 (PDT) Date: Thu, 2 Sep 2021 18:57:15 +0000 From: Sean Christopherson To: Andy Lutomirski Cc: Joerg Roedel , Yu Zhang , David Hildenbrand , Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm list , Linux Kernel Mailing List , Borislav Petkov , Andrew Morton , 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 Subject: Re: [RFC] KVM: mm: fd-based approach for supporting KVM guest private memory Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 02, 2021, Andy Lutomirski wrote: > On 9/2/21 2:27 AM, Joerg Roedel wrote: > > On Wed, Sep 01, 2021 at 09:07:59AM -0700, Andy Lutomirski wrote: > >> In principle, you could actually initialize a TDX guest with all of its > >> memory shared and all of it mapped in the host IOMMU. > > > > Not sure how this works in TDX, but in SEV code fetches are always > > treated as encrypted. So this approach would not work with SEV, not to > > speak about attestation, which will not work with this approach either > > :) > > > > Oof. TDX is kinda similar. _All_ accesses are private if paging is disabled because the shared bit is either bit 48 or bit 51 in the GPA, i.e. can't be reached if paging is disabled. The vCPU is hardcoded to start in unpaged protected mode, so at least some amount of guest memory needs to be private. I also could've sworn code fetches from shared memory would #VE, but I can't find anything in the specs that confirm that. I may be conflating TDX with SGX's #GP on a code fetch outside of ELRANGE...