> > > > > > It's doable to program the hardware interface using DXE MP service > > protocol in > > > CpuSmm driver's entry point. > > > But, considering the standalone MM environment where the CpuMm > > driver runs > > > in a isolated environment and it cannot invoke any DXE or PEI MP service, > > you could > > > understand that why we choose to put the hardware interface > > programming in a separate > > > PEI module. This is the major reason. > > > > Ok, *that* finally makes sense to me. Can you please add a source code > > comment explaining this to the patch series? Patch #1 (which adds the > > interface) is the best place I think. > > Sure. Jiaxin, please. >
Ok, I will follow this suggestion. > > > > > > I admit that a minor benefit of this design is we can isolate the > > > private hardware interface programming in a close-source module. > > > Otherwise, the SmmCpuFeaturesLib might need to expose a new API for > > > the hardware interface programming. > > > > "benefit" and "closed-source" in one sentence while discussion patches > > for an open source project. > > > > And you are wondering (see parallel mail by Jiaxin) why outsiders get > > the impression you are trying to hide information. > > > > No further questions. > > Gerd, the benefit is to have a better modular design (separate PEIM instead of > extending existing SmmCpuFeaturesLib), NOT "close-source" module. > I don't have the power to argue with you why not open source the PEIM. Sorry:( > I like open source world and the open-discussions here. It's the > open-discussions > that help to produce better design/code. > Please don't imagine that "I" want to hide something. If I cannot tell you > something, > that's because the information cannot be public for now required by > the company policy. Maybe people like you working on all open-source code > cannot understand the difficulty of mixing open source and close source code. > > > > > > Though this new HOB is not in PI spec, you remind me that we might > > > need to add more fields to the HOB so a way to distinguish between > > > different versions of the HOB should be considered. The way could be > > > to introduce a new GUID for new version of HOB, or add a field > > > (version?) in the HOB. I prefer the second. > > > > Established practice is to use a new GUID. We should stick to that. > No concern from my side to have a new GUID once the HOB format changes. Agree, it's fine to have a new GUID. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#99563): https://edk2.groups.io/g/devel/message/99563 Mute This Topic: https://groups.io/mt/96350764/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
