public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Jordan Justen <jordan.l.justen@intel.com>,
	edk2-devel-01 <edk2-devel@lists.01.org>
Subject: Re: [PATCH 0/5] OvmfPkg: recognize an extended TSEG when QEMU offers it
Date: Tue, 20 Jun 2017 00:39:18 +0200	[thread overview]
Message-ID: <652be3ef-03fe-2aa5-71ac-1917b6902510@redhat.com> (raw)
In-Reply-To: <149789577753.584.556612464247357262@jljusten-skl>

On 06/19/17 20:09, Jordan Justen wrote:
> On 2017-06-08 10:13:28, Laszlo Ersek wrote:
>> In <https://bugzilla.redhat.com/show_bug.cgi?id=1447027> we found that
>> the SMM_REQUIRE build of OVMF cannot boot with as many VCPUs as we'd
>> like, due to SMRAM exhaustion (even with the largest TSEG, 8MB).
>>
>> Related thread on edk2-devel:
>> <https://lists.01.org/pipermail/edk2-devel/2017-May/010371.html>.
>>
>> The QEMU patch at
>> <http://mid.mail-archive.com/20170608161013.17920-1-lersek@redhat.com>
> 
> This patch hasn't been merged to qemu yet, right? Would you propose
> that we wait until this is merged to qemu master, or present in a qemu
> release before merging the OVMF support? At what point does qemu
> consider it an unchangable supported feature?

The QEMU patch is now part of a pending PULL request:

http://lists.nongnu.org/archive/html/qemu-devel/2017-06/msg03901.html

Given that the QEMU patch (intentionally) preserves compatibility /
behavior for earlier machine types, we can safely commit the OVMF series
once upstream QEMU merges the patch. Using pc-q35-2.9 or earlier machine
types, the feature won't be (or won't appear) available; with
pc-q35-2.10 or later, the feature will be turned on.

I agree we should wait until Michael's qemu PULL req is actually merged.
There's no reason (specific to QEMU) to wait with the OVMF patches
longer than that. (SeaBIOS follows the same method.)

Thanks
Laszlo


>> adds a new device property / PCI config register to the Q35 board's DRAM
>> controller. The property allows the user (and new Q35 machine types by
>> default) to specify an arbitrary TSEG size (expressed as a number of
>> megabytes). The register enables the firmware to query the size /
>> availability of the feature. The extended size, when available, can be
>> selected by writing the "11" bitmask to the ESMRAMC.TSEG_SZ register
>> bit-field. This bitmask (similarly to the invented register's location
>> in PCI config space) is defined as reserved in the original Q35/MCH
>> spec.
>>
>> This series adds support for the feature to OVMF. When an extended TSEG
>> is offered, OVMF will choose it.
>>
>> The first four patches extract Q35TsegSizeLib, centralizing the
>> interpretation of ESMRAMC.TSEG_SZ between PlatformPei, SmmAccessPei and
>> SmmAccess2Dxe. This subset of patches incurs no observable change in
>> behavior.
>>
>> The last patch implements the feature in Q35TsegSizeLib.
>>
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: extended_tseg_bz1447027
>>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>
>> Thanks
>> Laszlo
>>
>> Laszlo Ersek (5):
>>   OvmfPkg: introduce Q35TsegSizeLib (class header and sole lib instance)
>>   OvmfPkg/PlatformPei: rebase to Q35TsegSizeLib
>>   OvmfPkg/SmmAccess: rebase code unique to SmmAccessPei to
>>     Q35TsegSizeLib
>>   OvmfPkg/SmmAccess: rebase shared PEIM/DXE code to Q35TsegSizeLib
>>   OvmfPkg/Q35TsegSizeLib: recognize an extended TSEG when QEMU offers it
>>
>>  OvmfPkg/Include/IndustryStandard/Q35MchIch9.h     |   4 +
>>  OvmfPkg/Include/Library/Q35TsegSizeLib.h          |  74 +++++++
>>  OvmfPkg/Library/Q35TsegSizeLib/Q35TsegSizeLib.c   | 230 ++++++++++++++++++++
>>  OvmfPkg/Library/Q35TsegSizeLib/Q35TsegSizeLib.inf |  47 ++++
>>  OvmfPkg/OvmfPkg.dec                               |  13 +-
>>  OvmfPkg/OvmfPkgIa32.dsc                           |   1 +
>>  OvmfPkg/OvmfPkgIa32X64.dsc                        |   1 +
>>  OvmfPkg/OvmfPkgX64.dsc                            |   1 +
>>  OvmfPkg/PlatformPei/MemDetect.c                   |   7 +-
>>  OvmfPkg/PlatformPei/PlatformPei.inf               |   2 +-
>>  OvmfPkg/SmmAccess/SmmAccess2Dxe.inf               |   1 +
>>  OvmfPkg/SmmAccess/SmmAccessPei.c                  |   7 +-
>>  OvmfPkg/SmmAccess/SmmAccessPei.inf                |   4 +-
>>  OvmfPkg/SmmAccess/SmramInternal.c                 |  13 +-
>>  14 files changed, 384 insertions(+), 21 deletions(-)
>>  create mode 100644 OvmfPkg/Include/Library/Q35TsegSizeLib.h
>>  create mode 100644 OvmfPkg/Library/Q35TsegSizeLib/Q35TsegSizeLib.c
>>  create mode 100644 OvmfPkg/Library/Q35TsegSizeLib/Q35TsegSizeLib.inf
>>
>> -- 
>> 2.9.3
>>



  reply	other threads:[~2017-06-19 22:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-08 17:13 [PATCH 0/5] OvmfPkg: recognize an extended TSEG when QEMU offers it Laszlo Ersek
2017-06-08 17:13 ` [PATCH 1/5] OvmfPkg: introduce Q35TsegSizeLib (class header and sole lib instance) Laszlo Ersek
2017-06-19 17:30   ` Jordan Justen
2017-06-19 19:39     ` Laszlo Ersek
2017-06-26 17:59       ` Jordan Justen
2017-06-26 19:12         ` Laszlo Ersek
2017-06-26 22:36           ` Jordan Justen
2017-06-26 23:04             ` Laszlo Ersek
2017-06-29 19:14               ` Jordan Justen
2017-07-01 20:42                 ` Laszlo Ersek
2017-07-02  5:50                   ` Jordan Justen
2017-06-21  0:52     ` Yao, Jiewen
2017-06-22 16:22       ` Laszlo Ersek
2017-06-08 17:13 ` [PATCH 2/5] OvmfPkg/PlatformPei: rebase to Q35TsegSizeLib Laszlo Ersek
2017-06-08 17:13 ` [PATCH 3/5] OvmfPkg/SmmAccess: rebase code unique to SmmAccessPei " Laszlo Ersek
2017-06-08 17:13 ` [PATCH 4/5] OvmfPkg/SmmAccess: rebase shared PEIM/DXE code " Laszlo Ersek
2017-06-08 17:13 ` [PATCH 5/5] OvmfPkg/Q35TsegSizeLib: recognize an extended TSEG when QEMU offers it Laszlo Ersek
2017-06-16  8:15 ` [PATCH 0/5] OvmfPkg: " Laszlo Ersek
2017-06-19 18:09 ` Jordan Justen
2017-06-19 22:39   ` Laszlo Ersek [this message]
2017-06-20 22:29     ` 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=652be3ef-03fe-2aa5-71ac-1917b6902510@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