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.129.124]) by mx.groups.io with SMTP id smtpd.web12.8279.1639377789969473356 for ; Sun, 12 Dec 2021 22:43:10 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=D2RJKtRd; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639377789; 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=2k/z4qFIWgYWtEX/he3bsRcZHAEm37xKIWeCifTm0aQ=; b=D2RJKtRdaBdz90E8gWu8xl9gu0WO8YaRJr49GG32UBZpDVhq6KdwaTLNR7QVrTK5qcTq8I H7oP1cVcwbO7k3I7ujtcrEGdozaPhx3Lmdj7/OIx6jWBtNPC8Xs4qnAxxBoSvfB855Zb+C WR2pdolAstqdLm4LmvA5Je6cw9fvfZU= 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-423-4XHbC_xYOIS_P90AfTMcmQ-1; Mon, 13 Dec 2021 01:43:03 -0500 X-MC-Unique: 4XHbC_xYOIS_P90AfTMcmQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DCAAA344AF; Mon, 13 Dec 2021 06:43:01 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5BDD318035; Mon, 13 Dec 2021 06:43:01 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id A439C180009C; Mon, 13 Dec 2021 07:42:59 +0100 (CET) Date: Mon, 13 Dec 2021 07:42:59 +0100 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V3 29/29] OvmfPkg: Update IoMmuDxe to support TDX Message-ID: <20211213064259.zrru4bz2khxof532@sirius.home.kraxel.org> References: <20211103071714.23p72ezydujhwfvy@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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 On Mon, Dec 13, 2021 at 02:39:53AM +0000, Xu, Min M wrote: > Hi > > > > > + if (CC_GUEST_IS_SEV (PcdGet64 (PcdConfidentialComputingGuestAttr))) { > > > + // > > > + // Clear the memory encryption mask on the plaintext buffer. > > > + // > > > + Status = MemEncryptSevClearPageEncMask ( > > > + 0, > > > + MapInfo->PlainTextAddress, > > > + MapInfo->NumberOfPages > > > + ); > > > + } else if (CC_GUEST_IS_TDX (PcdGet64 > > (PcdConfidentialComputingGuestAttr))) { > > > + // > > > + // Set the memory shared bit. > > > + // > > > + Status = MemEncryptTdxSetPageSharedBit ( > > > + 0, > > > + MapInfo->PlainTextAddress, > > > + MapInfo->NumberOfPages > > > + ); > > > > Again, this looks very simliar and like a great opportunity to share code. > > > MemEncryptSevClearPageEncMask () is implemented in MemEncryptSevLib. > MemEncryptTdxSetPageSharedBit () is implemented in MemEncryptTdxlib. > > Yes, we have considered to merge these 2 EncryptLib into one lib (for > example: MemoryEncryptCcLib). But after investigation and some PoC, we > find it will make the code complicated and hard to maintain. (many > if-else checking in the code) > 1. From the naming perspective (in SEV/TDX documentation), SEV's bit is Enc bit, but TDX's bit is shared bit. > 2. In SEV's SetMemoryEncDec () it handles differently for the different version of SEV (for example, Sev-Snp). I am not sure if there will be more specific process will be added in the future. > 3. In TDX's SetMemorySharedOrPrivate, currently it is simple and clean. But there maybe some new features added in the future. > I am thinking if it is a better choice that every vendor takes their responsibility to maintain their own lib/code? Well, I still think there is opportunity to share code, specifically the page table handling. Have a generic page table walker which is able to set and clear bits for a given memory range. Then the sev/tdx specific code can just call that instead of both having their own, duplicated page table walking logic. Maybe the page table walking should even be a MdeModulePkg Library, i.e. move the code for page table walking (and huge page splitting) in MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c to a library so it can be reused elsewhere without duplicating the code, take care, Gerd