public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Yao, Jiewen" <jiewen.yao@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Xu, Min M" <min.m.xu@intel.com>,
	Brijesh Singh <brijesh.singh@amd.com>,
	Ard Biesheuvel <ardb+tianocore@kernel.org>,
	"Justen, Jordan L" <jordan.l.justen@intel.com>,
	Erdem Aktas <erdemaktas@google.com>,
	James Bottomley <jejb@linux.ibm.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector
Date: Fri, 24 Sep 2021 16:02:21 +0200	[thread overview]
Message-ID: <20210924140221.6b3nk32eofwbwpgb@sirius.home.kraxel.org> (raw)
In-Reply-To: <PH0PR11MB48852EC79C25B1A23C9219BF8CA49@PH0PR11MB4885.namprd11.prod.outlook.com>

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


  reply	other threads:[~2021-09-24 14:02 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-21  9:05 [PATCH V7 0/1] Add Intel TDX support in OvmfPkg/ResetVector Min Xu
2021-09-21  9:05 ` [PATCH V7 1/1] OvmfPkg: Enable TDX in ResetVector Min Xu
2021-09-22  7:49   ` Gerd Hoffmann
2021-09-23  0:38     ` Min Xu
2021-09-23  8:48       ` Gerd Hoffmann
2021-09-23 11:39         ` Yao, Jiewen
2021-09-23 12:54           ` Brijesh Singh
2021-09-23 13:18             ` Yao, Jiewen
2021-09-23 13:19             ` [edk2-devel] " Min Xu
2021-09-23 13:38               ` Yao, Jiewen
2021-09-23 14:03                 ` Brijesh Singh
2021-09-23 14:15                   ` Min Xu
2021-09-23 14:19                     ` Yao, Jiewen
2021-09-24  5:37                       ` Gerd Hoffmann
2021-09-24  7:36                         ` Yao, Jiewen
2021-09-24  9:24                           ` Gerd Hoffmann
2021-09-24  9:55                             ` Yao, Jiewen
2021-09-24  5:28                     ` Gerd Hoffmann
2021-09-24  6:55                       ` Min Xu
2021-09-24 10:07                         ` Gerd Hoffmann
2021-09-24 10:33                           ` Yao, Jiewen
2021-09-24 14:02                             ` Gerd Hoffmann [this message]
2021-09-24 16:40                               ` Yao, Jiewen
2021-09-27  8:05                                 ` Gerd Hoffmann
2021-09-27 10:05                                   ` Yao, Jiewen
2021-09-27 14:59                                     ` Gerd Hoffmann
2021-09-28  0:21                                       ` Yao, Jiewen
2021-09-24  7:32                       ` Yao, Jiewen
2021-09-24  9:15                         ` Gerd Hoffmann
2021-09-24  4:54                 ` Gerd Hoffmann
2021-09-24  7:39                   ` Yao, Jiewen
2021-09-24  9:34                     ` Gerd Hoffmann
2021-09-24 10:11                       ` Yao, Jiewen
2021-09-24 10:38                         ` Brijesh Singh
2021-09-24 11:17                           ` Gerd Hoffmann
2021-09-24 11:29                             ` Brijesh Singh
2021-09-24 10:14                     ` Brijesh Singh
2021-09-24 10:58   ` Brijesh Singh
2021-09-25  0:03     ` Min Xu
2021-09-25  3:21       ` Brijesh Singh
2021-09-25 23:17         ` [edk2-devel] " Min Xu
2021-09-25 23:30           ` Yao, Jiewen
2021-09-27  8:44           ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210924140221.6b3nk32eofwbwpgb@sirius.home.kraxel.org \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox