Hi Everyone, This RFC has been sitting for a while and it seems like we have reached a conclusion. I would like to make a request to the TianoCore stewards to create 2 new git repositories in the

In order to support Intel Trust Domain Extensions (TDX) (https://software.intel.com/content/www/us/en/develop/articles/intel-trust-domain-extensions.html), we need a new Trust Domain Virtual Firmware

Could you explain more about the gap that needs to be bridged here? I suppose the desire is to be able to reuse existing DXE_SMM_DRIVER modules, and deploy them unmodified in a standalone MM

Hi, Sami I know the traditional MM is planned to be deprecated but the reality is that there are many existing traditional MM platforms/drivers and the migration has to happen step-by-step. It may

Hi Siyuan, I can see the following points: - current code organisation is such that the traditional MM and standalone MM are clearly separated. - traditional MM is planned to be deprecated. - some

Hi, Jiewen/Laszlo Thanks for your comments on this. Hi, Ard/Sami/Supreeth Since ARM based platforms are currently the major user of the MM Core in StandaloneMmPkg, I would like to hear you idea

IMHO, StandaloneMm (in StandaloneMmPkg) should be the long term direction to replace the traditional MM (in MdeModulePkg). If we want to do some enhancement, I prefer #2 to update the one in

This is a good idea -- when we think we are ready to retire PiSmmCore in MdeModulePkg, because we think that StandaloneMmPkg can fully replace it, platforms can evaluate the latter (hopefully with

Which method is the least risky with regard to regressions, in your opinion? I tend to prefer #2. Either option is neutral for ArmVirtPkg at the moment, and option#2 is safer for OvmfPkg (no risk of

Hi, All This email is to collect feedback about making one common EDK2 MM Core driver to support both MM Traditional drivers and MM Standalone drivers. We know that PI Spec defines two types of

Hey Leif, It is actually seeing a pretty large amount of external consumption right now. To my knowledge, every IBV and most OEMs depend on MinPlatformPkg for Tiger Lake UEFI firmware

Hey Bret, I'm not opposed to that idea, but it sounds like a totally different RFC 😊. We also need to be cognizant that there are many people downstream from TianoCore that don't use any repo

I think that to support anything larger that proofs of concept – in other words, to support the actual platforms that we WANT to consume this trusted, common code – we already have to support

If it is being used by any external consumers, then yes edk2 makes perfect sense. It might still make sense to start prototyping that usage in a vendor-neutral section of edk2-platforms. / Leif

Hey Sean, IMHO I'm starting to get annoyed at the number of submodules in edk2 at this point. It's getting to the point that we are in danger of needing recursive submodule clones, which are a huge

Hey Hot, Edk2 would be a good place as well. Thanks, Nate

Nate, I would actually propose you go further. In Project Mu we consume MinPlatform as its own repo. This is because it has its own lifetime and spans multiple product generations and hopefully

Why not move to edk2 repo? Thanks, Hot

Hey Laszlo, With regard to the tool refactoring, Leif had the same feedback and I completely agree with both of you. I have filed a BZ to track the tool refactoring as a separate item: