I agree with Bret. Adding EmbeddedPkg dependency is not a good idea. Another option: Is there any possibility to move the function to EmbeddedPkg and just add a simple function call in StanaloneMmPkg

Hi Sean That is excellent topic. I agree with you that, one of most frequent asked question in the design meeting is: Should I use protocol or library? Sigh... I added my personal thought below. I wou

Thanks. Code talks better. I prefer option 2, which is a generic way for abstraction. And you may enable option 1 under the cover of option 2, just create a lib instance to get config from Hob. Thank

Hi Sorry, I am not able to follow the discussion. Is there any sample or POC code to show the concept?

Indeed. Too many emails. Glad that we can reach consensus finally. :-) Thanks, Min and Brijesh.

Hey I am not sure why Min did not response to my latest email. I did give suggestion in my previous comment. ===== CcWorkArea.Type = 0; InitCcWorkAreaSev(); // set Type=1 if SEV InitCcWorkAreaTdx(); /

I think I have given R-B. If no, then Reviewed-by: Jiewen Yao <Jiewen.yao@...>

comment below thank you! Yao, Jiewen [jiewen] I am not sure how SEV works. For TDX, this memory is private memory. VMM or QEMU cannot modify it *after* launch. VMM or QEMU may modify it *before* launc

Hi Brijesh Thanks for the patient. Most of my comment focus on the *common* part, and *interface* between SEV and common code. I will leave you to decide the detailed SEV specific implementation. Patc

Pushed. https://github.com/tianocore/edk2/pull/1842 githash: dc485c556d5f5db21debe8de3a45a7564aacbe24..b461d67639f2deced77e9bb967d014b7cfcd75f8

Comment below:

For OvmfPkg, reviewed-by: Jiewen Yao <Jiewen.yao@...> For ArmVirtPkg, acked-by: Jiewen Yao <Jiewen.yao@...>

Sounds good. Thank you to confirm that. I will send my feedback.

I would say it is NOT the best software practice to define 2 enable fields to indicate one type. What if some software error, set both TdxEnable and SevEnable at same time? How do you detect such erro

Hi Brijesh Thanks! I think if we want to reuse this, we need rename the data structure. First, we should use a generic name. Second, I don’t think it is good idea to define two *enable* fields. Since

Hi Brijesh I reviewed the patch set. I have some basic questions. Please help me understand before I post my comment If a platform supports SEV-SNP, can we assume SEV-ES is supported? Or is it a valid

Yes. I am thinking the same thing. [CC Flag memory location] 1) A general purpose register, such as EBP. 2) A global variable, such as .data TeeFlags: DD 0 3) A fixed region in stack, such as dword[ST

It does not necessary to be a working area. We just need a common TEE flag to indicate if the system run in legacy, SEV, or TDX, right? thank you! Yao, Jiewen

Oops. Sorry for late response. The code is NOT in EDKII, but EDKII-platform as example. https://github.com/tianocore/edk2-platforms/tree/master/Platform/Intel/MinPlatformPkg/Tcg We allow a platform ha

HI Min I agree with Brijesh. The basic rule is: SEV file shall never refer to TDX data structure. TDX file shall never refer to SEV data structure. These code should be isolated clearly. Do we still n