public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Jeff Fan <jeff.fan@intel.com>,
	Michael Kinney <michael.d.kinney@intel.com>,
	Jiewen Yao <jiewen.yao@intel.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>,
	Gerd Hoffmann <kraxel@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: SMRAM sizes on large hosts
Date: Tue, 2 May 2017 20:16:23 +0200	[thread overview]
Message-ID: <1382eb04-9646-133b-9ce5-8293cb54745f@redhat.com> (raw)

Hi All,

in your experience, how much SMRAM do "big hosts" provide? (Machines
that have, say, ~300 CPU cores.)

With QEMU's Q35 board, which provides 8MB of SMRAM (TSEG), we're hitting
various out-of-SMRAM conditions with OVMF at around 230-240 VCPUs. We'd
like to go to a higher VCPU count than that.

* So, in your experience, how much SMRAM do physical boards, that carry
such a high number of cores, provide?

* Perhaps we'll have to do something about the SMRAM size on QEMU in the
longer term, but until then, can you guys recommend various "cheap
tricks" to decrease per-VCPU SMRAM usage?

For example, in OVMF we have a 16KB SMM stack per VCPU, and we also
enable the SMM stack overflow guard page -- we had been hit by an SMM
stack overflow with the original 8KB stack size, and so we increased
both the stack size and enabled the guard page; see commits

  509f8425b75d UefiCpuPkg: change PcdCpuSmmStackGuard default to TRUE
  0d0c245dfb14 OvmfPkg: set SMM stack size to 16KB

I've now tried to decrease the stack size to the "middle point" 12KB.
That stack size does not reproduce the SMM stack overflow seen
originally, but it also doesn't help with the SMRAM exhaustion -- we
cannot go to any higher VCPU count with it.

Are there any other "tweakables" (PCDs) we could massage to see the
per-VCPU SMRAM usage go down?

Here's a (somewhat indiscriminate) list of PCDs, from the OVMF Ia32X64
build report file, where each PCD's name contains "smm":

    PcdCpuSmmBlockStartupThisAp                 :   FLAG  (BOOLEAN) = 0
    PcdCpuSmmDebug                              :   FLAG  (BOOLEAN) = 0
    PcdCpuSmmFeatureControlMsrLock              :   FLAG  (BOOLEAN) = 1
    PcdCpuSmmProfileEnable                      :   FLAG  (BOOLEAN) = 0
    PcdCpuSmmProfileRingBuffer                  :   FLAG  (BOOLEAN) = 0
    PcdCpuSmmStackGuard                         :   FLAG  (BOOLEAN) = 1
 *P PcdCpuSmmEnableBspElection                  :   FLAG  (BOOLEAN) = 0
 *P PcdSmmSmramRequire                          :   FLAG  (BOOLEAN) = 1

    PcdCpuSmmCodeAccessCheckEnable              :  FIXED  (BOOLEAN) = 1
    PcdCpuSmmProfileSize                        :  FIXED   (UINT32) = 0x200000
    PcdCpuSmmStaticPageTable                    :  FIXED  (BOOLEAN) = 1
 *P PcdCpuSmmStackSize                          :  FIXED   (UINT32) = 0x4000

    PcdLoadFixAddressSmmCodePageNumber          :  PATCH   (UINT32) = 0

    PcdS3BootScriptTablePrivateSmmDataPtr       :    DYN   (UINT64) = 0x0
 *P PcdCpuSmmApSyncTimeout                      :    DYN   (UINT64) = 100000
 *P PcdCpuSmmSyncMode                           :    DYN    (UINT8) = 0x01

(BTW, security features should not be disabled, even if they saved some
SMRAM.)

Thank you,
Laszlo


             reply	other threads:[~2017-05-02 18:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-02 18:16 Laszlo Ersek [this message]
2017-05-02 20:49 ` SMRAM sizes on large hosts Kinney, Michael D
2017-05-03  1:20   ` Yao, Jiewen
2017-05-03  6:57   ` Gerd Hoffmann
2017-05-03 12:56     ` Paolo Bonzini
2017-05-03 13:14       ` Laszlo Ersek
2017-05-03 13:26         ` Paolo Bonzini
2017-05-03 13:35           ` Laszlo Ersek
2017-05-03 13:55             ` Paolo Bonzini
2017-05-03 22:34               ` Laszlo Ersek
2017-05-03 12:58     ` Laszlo Ersek
2017-05-03 13:44       ` Gerd Hoffmann
2017-05-03 22:33         ` Laszlo Ersek
2017-05-03 23:36           ` Laszlo Ersek
2017-05-04  6:18             ` Gerd Hoffmann
2017-05-04 14:52             ` Gerd Hoffmann
2017-05-04 15:21               ` Laszlo Ersek
2017-05-04  8:23           ` Igor Mammedov
2017-05-04 11:34             ` Laszlo Ersek
2017-05-04 14:00               ` Igor Mammedov
2017-05-04 14:41                 ` Gerd Hoffmann
2017-05-04 14:50                   ` Igor Mammedov
2017-05-04 15:19                     ` Laszlo Ersek

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=1382eb04-9646-133b-9ce5-8293cb54745f@redhat.com \
    --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