Re: [PATCH v3 5/5] OvmfPkg/SmmCpuFeaturesLib: Skip SMBASE configuration

["Wu, Jiaxin" <jiaxin.wu@intel.com>]

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