Sure, that is not an issue at all. As a matter of fact I had only one section in my original SNP_BOOT_BLOCK GUID to cover the MEMFD region ;) I think we can live with just 2 to 3 sections common to

We could add just a single range for stack + heap + pagetables (+more?) and comments saying which MEMFD areas are covered by that range, to keep the table small. take care, Gerd

Hi Min, Why you are removing the above block ? The workarea hdr must be initialized to zero, its not safe to assume that the guest memory is zero'ed in the non-encrypted case. thanks

Yes, this is just an interim problem. Once we move to lazy validation then this will be removed.

Let me see where I can use the new Pcd. We need to check the Sev status in SEC and before the dynamic PCD is set so in those case its still required but once PCD is set then we can switch to using

In the SEV patches you are seeing more sections because I tried to keep it in sync with the MEMFD [1] so that its much more readable. In TDX patches, Min decided to breakdown things a bit

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

FYI, SEV also measures code or data put by the VMM in the guest memory space. In SEV, qemu calls a routine to encrypt the pflash unit0 -- while handling the callback you can convert the GPA to HVA and

You are right. My statement for page table is wrong. Both TDX and SEV need them. That is NOT our original design. But I can understand why it is changed today. I compare

Hi, TDX_BFV_RAW_DATA_SIZE + TDX_BFV_MEMORY_SIZE are identical. Why do you need both? Yes, I know, some entries have RAW_DATA_SIZE=0 because nothing is loaded for them. You can also figure that by

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3642 when the module is not building in IA32 mode which will lead to building error. when a module built-in X64 function pointer will be the size of

I think we are discussing two topics. Please allow me to separate them. 1) Topic one: A unified build for config-A and config-B I think we have discussed that before in EDKII, when Laszlo

Hi, I think you are wrong here, the patch has this ... +_OvmfPageTable: + DD 0 + DD 0 + DQ OVMF_PAGE_TABLE_BASE + DQ OVMF_PAGE_TABLE_SIZE + DD TDX_METADATA_SECTION_TYPE_TEMP_MEM + DD 0 ...

Isn't that the plan anyway? At least for "config-a" with a basic feature set? See other mail just sent for comments on "config-b". Not sure what you are trying to tell me. take care, Gerd

There isn't that much of a difference between the normal and amd sev build. It has additional drivers and the grub boot loader added, smm support turned off, network stack removed. The differences

Hi, This looks good to me! [...] This should just be Token, not GTBlockTimerFrameToken. [...] [...] The SubObjParser doesn't actually seem to be used by any of the objects? (Unless I misread

Apologies, I have already shared the patch. I will take this input for future patches. Regards, JP

Comment below:

That is my question. AMD has its own extension. TDX has its own extension. Why we have to unify the firmware binary, and to make both us unconfirmable? Or do we want to unify ARM/AARch64/RISC-V ? I

Hi Rebecca, I also reviewed/tested the patch: Reviewed-by: Pierre Gondois <Pierre.Gondois@...> Regards, Pierre