From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Ni, Ray" <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>,
"Wu, Jiaxin" <jiaxin.wu@intel.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Dong, Eric" <eric.dong@intel.com>,
"Zeng, Star" <star.zeng@intel.com>,
"Kumar, Rahul R" <rahul.r.kumar@intel.com>
Subject: Re: [PATCH v3 5/5] OvmfPkg/SmmCpuFeaturesLib: Skip SMBASE configuration
Date: Fri, 3 Feb 2023 08:31:44 +0100 [thread overview]
Message-ID: <20230203073144.pdrwf7logbgbow3c@sirius.home.kraxel.org> (raw)
In-Reply-To: <MN6PR11MB8244299569BE5F2EDAE3C9208CD79@MN6PR11MB8244.namprd11.prod.outlook.com>
Hi,
> > > Ok. So new Intel processors apparently got new MSR(s) to set SMBASE
> > > directly. Any specific reason why you don't add support for that to
> > > PiSmmCpuDxeSmm? That would avoid needing the new HOB (and the related
> > > problems with the 8190 cpu limit) in the first place.
>
> The reason is the hardware interface to set SMBASE is in thread scope meaning
> such firmware-hardware communication needs to be done for each CPU thread.
>
> 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.
> 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.
> 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.
take care,
Gerd
next prev parent reply other threads:[~2023-02-03 7:31 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-18 9:56 [PATCH v3 0/5] Simplify SMM Relocation Process Wu, Jiaxin
2023-01-18 9:56 ` [PATCH v3 1/5] UefiCpuPkg/SmmBaseHob.h: Add SMM Base HOB Data Wu, Jiaxin
2023-01-18 11:19 ` Gerd Hoffmann
2023-01-18 15:06 ` Ni, Ray
2023-01-19 7:13 ` Gerd Hoffmann
2023-01-29 5:08 ` Wu, Jiaxin
2023-02-01 13:02 ` Gerd Hoffmann
2023-01-20 8:21 ` Laszlo Ersek
2023-01-29 5:24 ` Wu, Jiaxin
2023-02-01 13:14 ` Gerd Hoffmann
2023-02-02 0:44 ` Wu, Jiaxin
2023-02-02 3:54 ` [edk2-devel] " Ni, Ray
2023-02-02 3:52 ` Ni, Ray
2023-02-02 12:51 ` Gerd Hoffmann
2023-02-02 22:29 ` [edk2-devel] " Brian J. Johnson
2023-02-03 3:14 ` Ni, Ray
2023-02-03 7:54 ` Gerd Hoffmann
2023-02-03 13:22 ` Wu, Jiaxin
2023-02-03 13:31 ` Ni, Ray
2023-02-03 15:00 ` Gerd Hoffmann
2023-01-18 9:56 ` [PATCH v3 2/5] UefiCpuPkg/PiSmmCpuDxeSmm: Fix invalid InitializeMpSyncData call Wu, Jiaxin
2023-01-18 9:56 ` [PATCH v3 3/5] UefiCpuPkg/PiSmmCpuDxeSmm: Consume SMM Base Hob for SmBase info Wu, Jiaxin
2023-01-18 12:02 ` Gerd Hoffmann
2023-01-29 6:14 ` [edk2-devel] " Wu, Jiaxin
2023-01-18 9:56 ` [PATCH v3 4/5] UefiCpuPkg/SmmCpuFeaturesLib: Skip SMBASE configuration Wu, Jiaxin
2023-01-18 9:56 ` [PATCH v3 5/5] OvmfPkg/SmmCpuFeaturesLib: " Wu, Jiaxin
2023-01-18 12:19 ` Gerd Hoffmann
2023-01-18 14:37 ` Ni, Ray
2023-01-19 7:53 ` Gerd Hoffmann
2023-01-29 5:47 ` Wu, Jiaxin
2023-02-01 13:40 ` Gerd Hoffmann
2023-02-02 1:41 ` Wu, Jiaxin
2023-02-02 9:00 ` Gerd Hoffmann
2023-02-02 11:47 ` Laszlo Ersek
2023-02-02 12:24 ` Gerd Hoffmann
2023-02-03 3:05 ` Wu, Jiaxin
2023-02-03 2:47 ` Wu, Jiaxin
2023-02-03 3:45 ` Ni, Ray
2023-02-03 7:31 ` Gerd Hoffmann [this message]
2023-02-03 7:43 ` Ni, Ray
2023-02-03 8:49 ` Gerd Hoffmann
2023-02-03 11:18 ` Wu, Jiaxin
[not found] ` <173B5EAF72B992BD.14781@groups.io>
2023-02-03 8:59 ` [edk2-devel] " Wu, Jiaxin
2023-02-03 9:04 ` Gerd Hoffmann
2023-02-03 11:15 ` Wu, Jiaxin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230203073144.pdrwf7logbgbow3c@sirius.home.kraxel.org \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox