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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 92655C38142 for ; Wed, 18 Jan 2023 01:20:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229977AbjARBUW (ORCPT ); Tue, 17 Jan 2023 20:20:22 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229898AbjARBUC (ORCPT ); Tue, 17 Jan 2023 20:20:02 -0500 Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0D47915557 for ; Tue, 17 Jan 2023 17:16:53 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id z13so7544650plg.6 for ; Tue, 17 Jan 2023 17:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nR851gTQUNhuZ9nIqOBqdizsZwq4fVLd+DeaO/RL3js=; b=Hd6WMpGYSNQdq6x5bZEpXv1KX4X9pv/ZsFdwt6iPmRB17S3WL8F4pe+UYA/RvwFBR3 2andNh8JioNmt1w7ODtXwzK2SSABlFcpVJjGhA3lXo57Qdz4CO/NjcHzNEBUi/OnTKxW ox1NhKj4dnSoXAC58rF53eQK0b+9PC/0eSIQyJEZCsjeZGR2T/cvR7n12txhLtwqtQwU ywpJ44DNPB9j7b4VkcHo7QNEXTEVyn342SF26e8/RVcMW+tpnEjG/Dg4Z3EMbYlLQ84R g73nmIgc0JdPGhARJM+p1pjjuvK0ZNYZNQcI3JKkcHE5UAbz/ASX5xecyba7HkLKLbwt 4H0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=nR851gTQUNhuZ9nIqOBqdizsZwq4fVLd+DeaO/RL3js=; b=EPiqaxdBUhVl9ORr7TxyEu0xop9KEVicvWLuBzToBCWZMzIwyzBVDRdWAcludMtL3W yehH7S+GI5dExJAgd1rKdDx2JM5wGHv2drKdjeTPH5KLCXsGVUa0Vaa7HGBgfYLQzbj2 69Jp/c3UvCwDvqQngv2lXBRaTU4ify9qYO/yktXej4OfXBx9VVzdnJLVCdwo/BMTnxWa DGrI93JNH/iFJrwEn6zhLgCgAEwniY4X4xHuu2pygFx24dGSbfmqsaUtT7IPvYP9tcEK LgraFgqMFwxZzPrlG05hjEMPaIhX97/1haTT+uWmyPKAQw+4a5yqyU1stfbwkJOsUFil RBhA== X-Gm-Message-State: AFqh2ko2NnJXE91cX1nAxQpz6FS0fJlPUKnWXLnxFsqmdS8i2BqzXYnq rXTlbl6UzD1p193m36cPJuMVXg== X-Google-Smtp-Source: AMrXdXsY6+D7UtkQ8QiX1vkkhfrbiAxGDNZS2xOOMXN6r3s6A82c2NGSaWy3Rx6VWNBn2JQ5Ph2PHA== X-Received: by 2002:a05:6a21:33a1:b0:ac:af5c:2970 with SMTP id yy33-20020a056a2133a100b000acaf5c2970mr2962127pzb.3.1674004612406; Tue, 17 Jan 2023 17:16:52 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id t13-20020a170902b20d00b001926a76e8absm21827824plr.114.2023.01.17.17.16.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Jan 2023 17:16:51 -0800 (PST) Date: Wed, 18 Jan 2023 01:16:48 +0000 From: Sean Christopherson To: "Huang, Kai" Cc: "dmatlack@google.com" , "Shahar, Sagi" , "chao.p.peng@linux.intel.com" , "isaku.yamahata@gmail.com" , "Aktas, Erdem" , "kvm@vger.kernel.org" , "pbonzini@redhat.com" , "Yamahata, Isaku" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v11 025/113] KVM: TDX: Use private memory for TDX Message-ID: References: <4c3f5462852af9fd0957bb7db0b04a6f2d5639ee.1673539699.git.isaku.yamahata@intel.com> <9fa4473f76f20b94a8ba516defb3b33ac3e86e96.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9fa4473f76f20b94a8ba516defb3b33ac3e86e96.camel@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 17, 2023, Huang, Kai wrote: > On Tue, 2023-01-17 at 16:40 +0000, Sean Christopherson wrote: > > On Mon, Jan 16, 2023, Huang, Kai wrote: > > > AMD's series has a different solution: > > > > > > https://lore.kernel.org/lkml/20221214194056.161492-3-michael.roth@amd.com/ > > > > > > I think somehow this needs to get aligned. > > > > Ya. My thought is > > > > bool kvm_arch_has_private_mem(struct kvm *kvm) > > { > > return kvm->arch.vm_type != KVM_X86_DEFAULT_VM; > > } > > > > where the VM types end up being: > > > > #define KVM_X86_DEFAULT_VM 0 > > #define KVM_X86_PROTECTED_VM 1 > > #define KVM_X86_TDX_VM 2 > > #define KVM_X86_SNP_VM 3 > > What's the difference between PROTECTED_VM vs TDX_VM/SNP_VM, may I ask? Not sure :-) At this point, PROTECTED_VM is a handwavy "guest that can access restricted memory". I think/hope it can be used in combination with existing SEV/SEV-ES APIs to allow backing such guests with restrictedmem. As for TDX_VM and SNP_VM, I'm speculating that KVM will need to differentiate between SNP, TDX, and everything else. E.g. if KVM needs to uniquely identify TDX VMs at creation time, then adding dedicated VM types seems like the obvious choice. Ditto for SNP VMs. That's partly why I want to smush everything together, to see if we actually need multiple VM types.