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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 D2C8BC4320A for ; Thu, 2 Sep 2021 09:27:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AFE406108B for ; Thu, 2 Sep 2021 09:27:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245426AbhIBJ2d (ORCPT ); Thu, 2 Sep 2021 05:28:33 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:50358 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245139AbhIBJ2c (ORCPT ); Thu, 2 Sep 2021 05:28:32 -0400 Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id D91A0225DE; Thu, 2 Sep 2021 09:27:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1630574852; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bjaQEerT4+CdbjFrLgaMt67gvVqUKw1V0kBH85jwObA=; b=Iyn0nfUSi9DyIsyI1gBQuzUE1Uz2REQy193mUGHVbITVS3Qo6JvXCBHz7sBNiwKScDqSAW SfOfvkNmdDZRikzvvW5NAPY3hFooiKddfQQKC+dYW1pMoSN4yFqRisT/DjTYBLiavrx2gN W3SFXMHwTxK2FMS+LtA8ihgfSWIjtVM= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1630574852; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bjaQEerT4+CdbjFrLgaMt67gvVqUKw1V0kBH85jwObA=; b=prIjHJhKs6+qfeR9s7/JeP4Iw+aXOzwEYrtkuB1R/a2P+97wxWrsQXysD4IvI7RoLDRSFr kwl/mXUICTSwWxBw== Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id D9FE813887; Thu, 2 Sep 2021 09:27:31 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id xHPQMgOZMGEnWAAAGKfGzw (envelope-from ); Thu, 02 Sep 2021 09:27:31 +0000 Date: Thu, 2 Sep 2021 11:27:30 +0200 From: Joerg Roedel To: Andy Lutomirski Cc: Yu Zhang , David Hildenbrand , Sean Christopherson , 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: kvm@vger.kernel.org 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 :) Regards, Joerg