public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Wu, Jiaxin" <jiaxin.wu@intel.com>
Cc: "Ni, Ray" <ray.ni@intel.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Dong, Eric" <eric.dong@intel.com>,
	"Zeng, Star" <star.zeng@intel.com>,
	Laszlo Ersek <lersek@redhat.com>,
	"Kumar, Rahul R" <rahul.r.kumar@intel.com>
Subject: Re: [PATCH v3 5/5] OvmfPkg/SmmCpuFeaturesLib: Skip SMBASE configuration
Date: Thu, 2 Feb 2023 10:00:03 +0100	[thread overview]
Message-ID: <20230202090003.5vmmeyhsv4zn7wn4@sirius.home.kraxel.org> (raw)
In-Reply-To: <MN0PR11MB61588FF985E6CC74808ECC90FED69@MN0PR11MB6158.namprd11.prod.outlook.com>

  Hi,

> > But the serialized SMBASE programming still happens, now in the PEI
> > module, and I don't see a good reason why the runtime the new PEI module
> > and the runtime of PiSmmCpuDxeSmm combined is faster than before.
> 
> As I said, PEI module can also programs SMBASE in parallel, for
> example program the some register directly instead of depending the
> existing RSM instruction to reload the SMBASE register with the new
> allocated SMBASE each time when it exits SMM.

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.

> Different vender might
> has different implementation.

Yes.

We can have different implementations in PiSmmCpuDxeSmm and/or
SmmCpuFeaturesLib to handle that.

> Another benefit with this series will make the smbase relocation more
> independent & more simple compared with existing process in smm cpu
> driver. 

Maybe it is.  Hard to justify from outside if you are not willing to
show the code of the PEI module.

> > Do you intent submitting code for OVMF producing such a HOB?
> > There isn't any in this series.
> 
> No, we won't do that. 

Then there is no point in changing the OVMF code,
other than maybe adding an ASSERT that there is no such HOB.

> > How is the SMM initialization of hotplugged CPUs
> > supposed to work with the new mode of operation?
> 
> Yes, that's already considered. For hot plugged CPU supported, the max
> number of CPUs should be defined in the
> PcdCpuMaxLogicalProcessorNumber, and all CPU Hot Plug Data is recorded
> in the PcdCpuHotPlugDataAddress, which contains the smbase info
> pre-allocated in the hob (filling the value in pi smm cpu driver),
> then CPU Hotplug MMI handler will relocate the SMBASE for new CPUs.

So that keeps the old workflow.

take care,
  Gerd


  reply	other threads:[~2023-02-02  9:00 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 [this message]
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
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=20230202090003.5vmmeyhsv4zn7wn4@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