From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.groups.io with SMTP id smtpd.web10.1151.1630652673221105240 for ; Fri, 03 Sep 2021 00:04:33 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=K6HxRozk; spf=pass (domain: redhat.com, ip: 216.205.24.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1630652672; 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=I0n2kQGfx7/EA3tqjFLh3gY9FtBe0TE04JnaEhm9ryQ=; b=K6HxRozkeXW+mSqBQE19CYSWR19OYAKOBC5+ShzxITLdwPbqZui+Z2sF6285zMZ37OqDM7 hDmi6BVg46hG6xFhquGHE8jxjE96CzzWSl/AVJHl6I0IptEf6lXbrp2Krh/ok8iEApAN2Q v1btRFfrTHTfddn14ghMWnOvdA4nedQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-579-4O8TA8HaOKaa6EHtjNPQWA-1; Fri, 03 Sep 2021 03:04:29 -0400 X-MC-Unique: 4O8TA8HaOKaa6EHtjNPQWA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 020C0802C80; Fri, 3 Sep 2021 07:04:27 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 508691B42C; Fri, 3 Sep 2021 07:04:26 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 1C91B1800931; Fri, 3 Sep 2021 09:04:24 +0200 (CEST) Date: Fri, 3 Sep 2021 09:04:24 +0200 From: "Gerd Hoffmann" To: Brijesh Singh Cc: devel@edk2.groups.io, James Bottomley , Min Xu , Jiewen Yao , Tom Lendacky , Jordan Justen , Ard Biesheuvel , Erdem Aktas , Michael Roth Subject: Re: [PATCH v6 15/29] OvmfPkg/MemEncryptSevLib: add support to validate system RAM Message-ID: <20210903070424.huj2hrkj3jejq3lx@sirius.home.kraxel.org> References: <20210901161646.24763-1-brijesh.singh@amd.com> <20210901161646.24763-16-brijesh.singh@amd.com> <20210902095001.butpnnnyvmi3tbnc@sirius.home.kraxel.org> <19ba1918-7c3b-04d7-f415-8c5b1a9e64c8@amd.com> MIME-Version: 1.0 In-Reply-To: <19ba1918-7c3b-04d7-f415-8c5b1a9e64c8@amd.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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, > IIRC, in the TDX proposal, I got the impression that TDX implementation > will skip the PEI phase, and it jumps from SEC->DXE. The SEC phase > somehow will know the guest memory range and validate it. Well, their design review document lists two configurations, one (named "config-a" in the slides) following the existing boot flow and another ("config-b") which skips PEI. The motivation for config-b is not clear from the design review document. The slides describe what they are doing but there isn't much information on _why_ things are done that way. Asked a few days ago, answer is still outstanding. I'd prefer to not have two completely different initialization code paths in ovmf. Easier for TDX/SNP code sharing, also easier for long-term maintenance. > Approach #1 > > The main advantage is that EDK2 core and guest OS can accept the memory > without any validation step. [ ... ] > Approach #2 > > The main advantage of this approach is that it can support lazy > validation, and it can undoubtedly help reduce boot time. [ ... ] > This patch series implements #1. And we will be looking at approach #2 > after the base is enabled. Approach #2 builds upon #1. As you > highlighted below that we have not seen the patches for the Lazy > validation here so its hard to comment but I am hopeful that it will > integrated just fine with the SNP. Good, that plan makes sense to me. take care, Gerd