From: Jordan Justen <jordan.l.justen@intel.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>,
edk2-devel-01 <edk2-devel@lists.01.org>,
Jiewen Yao <jiewen.yao@intel.com>, Jeff Fan <jeff.fan@intel.com>
Subject: Re: [PATCH 1/5] OvmfPkg: introduce Q35TsegSizeLib (class header and sole lib instance)
Date: Thu, 29 Jun 2017 12:14:06 -0700 [thread overview]
Message-ID: <149876364614.17954.18085820933912290198@jljusten-skl.jf.intel.com> (raw)
In-Reply-To: <ba6fbe72-2639-2cfb-87c3-b30da7f3dc89@redhat.com>
On 2017-06-26 16:04:41, Laszlo Ersek wrote:
> On 06/27/17 00:36, Jordan Justen wrote:
> >
> > Why can't SmramInternal.c read the size from the PCD directly?
>
> If I remember correctly, I wanted to base SmramAccessGetCapabilities()
> directly on hardware configuration. At that point (regardless of whether
> the function would be called via PEI_SMM_ACCESS_PPI or
> EFI_SMM_ACCESS2_PROTOCOL), the ESMRAMC.TSEG_SZ bits used as source for
> the calculation would already be locked, by the SmmAccessPei entry point
> function.
I guess it does look slightly more appropriate to read to reg, even if
the end result will always match the PCD. The 'internal' file is used
by PEI as well, so if you want to add a function or variable in the
'internal' give the mask, it sounds good.
-Jordan
next prev parent reply other threads:[~2017-06-29 19:12 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 [this message]
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
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=149876364614.17954.18085820933912290198@jljusten-skl.jf.intel.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