[edk2-devel] [PATCH v3 5/5] OvmfPkg/SmmCpuFeaturesLib: Skip SMBASE configuration

[Ni, Ray]

> >
> > 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.


> 
> > 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.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#99541): https://edk2.groups.io/g/devel/message/99541
Mute This Topic: https://groups.io/mt/96350764/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3943202/1813853/130120423/xyzzy [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-