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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81106): https://edk2.groups.io/g/devel/message/81106
Mute This Topic: https://groups.io/mt/85761661/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to