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.web08.8756.1632492147429315662 for ; Fri, 24 Sep 2021 07:02:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WfiUQrmc; 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=1632492146; 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=kfoprncMXTcoB/lv9VL7f5lp4EFoKApnzxmclY2DQlg=; b=WfiUQrmcj+alZMbA2bz2ewdPRM0omjUR0rYBi7IxBVT5IvPPpcTnbp16qdMXHEk9UBSMk/ bcah3u6WBvmz6xpoCsp2zmSdUrZGu7xlqa5imPzAFk38riTE7CivOt+naXoYIUjxB6L7+4 9wzlfojJMJ3a1iQKf2Ur7l64noEcpLY= 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-360-raNNxLkZNvK7EqNv8x5LHg-1; Fri, 24 Sep 2021 10:02:24 -0400 X-MC-Unique: raNNxLkZNvK7EqNv8x5LHg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 212C5100CC89; Fri, 24 Sep 2021 14:02:23 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.193.134]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AB2D017010; Fri, 24 Sep 2021 14:02:22 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 34AE9180063A; Fri, 24 Sep 2021 16:02:21 +0200 (CEST) Date: Fri, 24 Sep 2021 16:02:21 +0200 From: "Gerd Hoffmann" To: "Yao, Jiewen" Cc: "devel@edk2.groups.io" , "Xu, Min M" , Brijesh Singh , Ard Biesheuvel , "Justen, Jordan L" , Erdem Aktas , James Bottomley , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector Message-ID: <20210924140221.6b3nk32eofwbwpgb@sirius.home.kraxel.org> References: <7c9aeb95-5c33-bd8d-4f0c-40133f4c7c3d@amd.com> <20210924052825.2qljhtvweonbov5q@sirius.home.kraxel.org> <20210924100726.m33otbjod4fo3vur@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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 Fri, Sep 24, 2021 at 10:33:35AM +0000, Yao, Jiewen wrote: > Again. Two topics. We need discuss them separately. > > Topic 1: TD metadata table is an architecture way to communicate with > VMM. We took the design from PE/COFF image section, which is flexible > to support different binary format. > EDKII TDVF is just one possible producer. There could be other > producer in the future. We don't want to define something only meet > current TDVF need. Hmm. efi has a kind-of binary format (EFI_FIRMWARE_VOLUME_HEADER). It's not fully self-contained though, you need to know where the architecture places the firmware (i.e. just below 4G for x86) because the load address isn't there. So I do see the point of adding other headers adding that. Possible alternative approach: Define an extension (EFI_FIRMWARE_VOLUME_EXT_HEADER) for the load address and use that instead of defining something new. Still not clear why the size is in there twice. I think you could instead use a flag telling whenever a section must be loaded from the image or not. This is what COFF and ELF are doing too. Also not clear why you want stick to 64bit base address. Loading the firmware above 4G isn't going to work without also changing a bunch of other things and it will break backward compatibility anyway. I think the entry size can be cut in half with something like this: struct { uint32_t file_offset; uint32_t load_address; uint32_t section_size; uint16_t section_type; uint16_t section_flags; }; > Topic 2: In config-B we remove PEI. > I think we should say it in different way: We add PEI back in config-A. > In our original design we totally eliminated PEI, because it is unnecessary. IMHO, it is totally an overdesign in OVMF to include PEI. Granted. PEI basically allows OEMs to plug their binary PEIMs into early hardware initialization. For a full open source firmware there is little reason to support that, other than maybe using PEIMs from other edk2 Pkgs unmodified. But, again, I don't want have two completely different initialization code paths in OVMF. We can certainly investigate and discuss dropping PEI, but that clearly shouldn't be a TDX-only thing. When we eliminate PEI, we should do it for all OVMF builds. take care, Gerd