From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: "Gao, Liming" <liming.gao@intel.com>
Cc: Jagadeesh Ujja <jagadeesh.ujja@arm.com>,
"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
"Zhang, Chao B" <chao.b.zhang@intel.com>
Subject: Re: [PATCH 10/13] MdeModulePkg/VarCheckLib: allow MM_STANDALONE drivers to use this library
Date: Wed, 2 Jan 2019 17:54:51 +0100 [thread overview]
Message-ID: <CAKv+Gu_Qret5gs=UuGmaUVwcKeyiG-=1Puw9O8Ts=sRDwW1gOw@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu9RNdeLvgKfwvyJN2-NRS6Xu+GycKaw10k9TnHi_nhOBA@mail.gmail.com>
On Wed, 2 Jan 2019 at 15:23, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
> On Wed, 2 Jan 2019 at 14:23, Gao, Liming <liming.gao@intel.com> wrote:
> >
> > Ard:
> > Why need to change module type? The non-base type library can support more than one module types, such as MdeModulePkg\Library\PeiDxeDebugLibReportStatusCode\PeiDxeDebugLibReportStatusCode.inf. Only if this library has constructor and needs to support cross module type, it must be set to BASE. For other case, its module type can be kept as-is. I clarify this rule in https://lists.01.org/pipermail/edk2-devel/2018-December/033523.html.
> >
>
> Currently, standalone MM on AArch64 requires strict alignment, and we
> only build SEC, PEI_CORE, PEIM and BASE modules with strict alignment.
>
> In general, I think it makes sense to default to BASE type for all
> libraries unless there is a need to using something else, i.e, when
> the library has a constructor that needs to ImageHandle and/or
> SystemTable arguments.
Actually, regardless of whether BASE is more appropriate in general, I
think there is no reason to keep the strict alignment checking in
standalone MM, since the MM core will be invoked with MMU and caches
enabled, and so there is no reason to disallow unaligned accesses
(this is different from SEC and PEI modules on ARM, since they may
execute in place with the caches and MMU off, in which case unaligned
accesses are never permitted)
I will raise this internally. In the mean time, please disregard this
aspect of my feedback. Simply adding MM_STANDALONE to the list of
permitted module types should be sufficient.
next prev parent reply other threads:[~2019-01-02 16:55 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-14 12:13 [PATCH 00/13] Extend secure variable service to be usable from Standalone MM Jagadeesh Ujja
2018-12-14 12:13 ` [PATCH 01/13] StandaloneMmPkg: Pull in additonal libraries from staging branch Jagadeesh Ujja
2018-12-21 8:58 ` Ard Biesheuvel
2018-12-14 12:13 ` [PATCH 02/13] MdePkg: Add a PCD that indicates presence of Standalone MM mode Jagadeesh Ujja
2018-12-21 9:13 ` Ard Biesheuvel
2018-12-14 12:13 ` [PATCH 03/13] MdeModulePkg: Add a PCD to indicate Standalone MM supports secure variable Jagadeesh Ujja
2018-12-21 9:13 ` Ard Biesheuvel
2018-12-14 12:13 ` [PATCH 04/13] MdePkg/Include: add StandaloneMmServicesTableLib header file Jagadeesh Ujja
2018-12-14 12:13 ` [PATCH 05/13] MdePkg/Library/BaseLib/AArch64: Add AsmLfence function Jagadeesh Ujja
2018-12-14 13:53 ` Ard Biesheuvel
2018-12-17 2:04 ` Gao, Liming
2018-12-17 3:29 ` Yao, Jiewen
2018-12-17 7:45 ` Ard Biesheuvel
2018-12-17 8:10 ` Ard Biesheuvel
2018-12-17 8:24 ` Yao, Jiewen
2018-12-17 8:30 ` Yao, Jiewen
2018-12-17 8:35 ` Ard Biesheuvel
2018-12-17 8:44 ` Yao, Jiewen
2018-12-17 9:27 ` Ard Biesheuvel
2018-12-18 2:08 ` Yao, Jiewen
2018-12-18 2:12 ` Gao, Liming
2018-12-18 2:19 ` Yao, Jiewen
2018-12-20 9:00 ` Jagadeesh Ujja
2018-12-20 9:10 ` Ard Biesheuvel
2018-12-14 12:13 ` [PATCH 06/13] MdePkg/Library: Add StandaloneMmRuntimeDxe library Jagadeesh Ujja
2018-12-14 12:13 ` [PATCH 07/13] MdeModulePkg/FaultTolerantWriteDxe: allow reusability as a MM driver Jagadeesh Ujja
2018-12-14 12:13 ` [PATCH 08/13] MdeModulePkg/Variable/RuntimeDxe: adapt for usability with MM Standalone Jagadeesh Ujja
2018-12-14 12:13 ` [PATCH 09/13] MdeModulePkg/Variable/RuntimeDxe: adapt as a MM Standalone driver Jagadeesh Ujja
2018-12-14 12:13 ` [PATCH 10/13] MdeModulePkg/VarCheckLib: allow MM_STANDALONE drivers to use this library Jagadeesh Ujja
2019-01-02 13:05 ` Ard Biesheuvel
2019-01-02 13:23 ` Gao, Liming
2019-01-02 14:23 ` Ard Biesheuvel
2019-01-02 16:54 ` Ard Biesheuvel [this message]
2019-01-02 13:27 ` Jagadeesh Ujja
2018-12-14 12:13 ` [PATCH 11/13] ArmPlatformPkg/NorFlashDxe: allow reusability as a MM driver Jagadeesh Ujja
2018-12-21 11:07 ` Ard Biesheuvel
2018-12-14 12:13 ` [PATCH 12/13] SecurityPkg/AuthVariableLib: allow MM_STANDALONE drivers to use this library Jagadeesh Ujja
2019-01-02 13:05 ` Ard Biesheuvel
2018-12-14 12:13 ` [PATCH 13/13] CryptoPkg/BaseCryptLib: " Jagadeesh Ujja
2018-12-21 10:13 ` Ard Biesheuvel
2018-12-17 1:45 ` [PATCH 00/13] Extend secure variable service to be usable from Standalone MM Gao, Liming
2018-12-17 11:46 ` Jagadeesh Ujja
2018-12-18 4:37 ` Gao, Liming
2018-12-18 11:19 ` Jagadeesh Ujja
2018-12-20 14:23 ` Gao, Liming
2019-01-02 17:15 ` Ard Biesheuvel
2019-01-03 7:43 ` Jagadeesh Ujja
2019-01-03 9:52 ` Ard Biesheuvel
2019-01-03 10:35 ` Ard Biesheuvel
2018-12-21 2:57 ` Wang, Jian J
2019-01-02 13:19 ` Jagadeesh Ujja
2019-01-03 2:37 ` Wang, Jian J
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='CAKv+Gu_Qret5gs=UuGmaUVwcKeyiG-=1Puw9O8Ts=sRDwW1gOw@mail.gmail.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