From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web12.63996.1638861355530864568 for ; Mon, 06 Dec 2021 23:15:56 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=O6tes5zg; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1638861354; h=from:from:reply-to:subject:subject: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=mXJvY705Ob0nTYyfg7H8kJo+h8SjIxNVvCrEhCtSWqE=; b=O6tes5zge7j/JLA00Hv7O8byoDuWfUP3ja6Jw5Uc2AHC9hUfoUPlOdWq3v6F9jVr2XTbti sjYo8wSNBEAzLAM08snt3CWWno/s6pfGcxgYk/B0EVyum7fZ49TklCosDxCmL5MwTZL35C 4cix2D72YzuU2z/ixXze4hS3Cbt5QCU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-172-Q4ZjvbJ7NgOSd6Pyxtebew-1; Tue, 07 Dec 2021 02:15:51 -0500 X-MC-Unique: Q4ZjvbJ7NgOSd6Pyxtebew-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8089881CCB5; Tue, 7 Dec 2021 07:15:49 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A02435D9C0; Tue, 7 Dec 2021 07:15:48 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id A7C6C18003A1; Tue, 7 Dec 2021 08:15:46 +0100 (CET) Date: Tue, 7 Dec 2021 08:15:46 +0100 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "Ni, Ray" , "devel@edk2.groups.io" , Brijesh Singh , Erdem Aktas , James Bottomley , "Yao, Jiewen" , Tom Lendacky , "Dong, Eric" , "Kumar, Rahul1" Subject: Re: [edk2-devel] [PATCH V3 23/29] UefiCpuPkg: Update AddressEncMask in CpuPageTable Message-ID: <20211207071546.ne34dpqizaxaavzd@sirius.home.kraxel.org> References: <2885c5213149eadbc99bfc579a9a27cccf080109.1635769996.git.min.m.xu@intel.com> <20211103070008.ker73xikocbxtkfa@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > Looks like two PCDs for basically the same thing. > > Should we create a common CC PCD here? > > > 1. The current situation of PcdPteMemoryEncryptionAddressOrMask is: > 1.1 PcdPteMemoryEncryptionAddressOrMask is now set by AmdSev. > 1.2 In CreateIdentityMappingPageTables(), this value (AddressEncMask) is set to the page tables in SEV guest. > 1.3 This PCD is also used as an indicator in InternalMemEncryptSevStatus() if ReadSevMsr is TRUE or FALSE. > 1.4 This PCD is also used in BootScriptExecutorEntryPoint() Yes. Creating a common CC PCD may require some changes on the SEV side too. The code (1.3 for example) assumes sev is active when PcdPteMemoryEncryptionAddressOrMask is set, which will obviously not be the case any more when tdx uses it too. But there are other ways to check for sev which can be used instead ... > 2. The meaning and usage scenario of PcdTdxSharedBitMask are somehow different from PcdPteMemoryEncryptionAddressOrMask. > 2.1 Guest physical address (GPA) space of Td guest is divided into private and shared sub-spaces, determined by the shared bit of GPA.[1] Well, there are some differences in detail but the underlying concept is the same. The page table bit says whenever the page is private to the vm or not. With SEV the bit enables/disables encryption. With TDX the bit switches between private and shared encryption key. > 2.2 PcdTdxSharedBitMask indicates the above shared bit of GPA. And > only the shared GPA has the shared bit set. This breaks 1.2. Hmm, ok. So the logic is different. SEV enables the bit for private pages whereas TDX enables the bit for shared pages. Too bad. That indeed makes it impossible to share a single PCD. We could still define something generic, like a "set-this-bit-for-shared-pages" pcd and a "set-this-bit-for-private-pages" pcd. But at the end of the day that probably wouldn't be very different from having PcdPteMemoryEncryptionAddressOrMask + PcdTdxSharedBitMask ... take care, Gerd