public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Laszlo Ersek" <lersek@redhat.com>
To: devel@edk2.groups.io, michael.a.kubacki@intel.com
Subject: Re: [edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction
Date: Mon, 9 Sep 2019 17:31:33 +0200	[thread overview]
Message-ID: <5cb08fa7-b4c4-d8a6-155f-986eaa207f90@redhat.com> (raw)
In-Reply-To: <49AB4ACB9627B8468F29D589A27B745588AA4398@ORSMSX121.amr.corp.intel.com>

On 09/05/19 21:54, Kubacki, Michael A wrote:

> Proof-of-Concept Implementation
> ----------------------------------------------
> The implementation is available in the following commit - check the commit message for some more details. 
> https://github.com/makubacki/edk2/commit/d812d43412a26e44581d283382596a863c1ae825
> 
> Please note this is "POC" level code quality and there will be cleanup of lock interfaces used and some other minor changes. Please feel free to leave any comments on the changes.

First some meta thoughts:

- If this code is meant for edk2 ultimately, please keep the discussion
on the mailing list, and/or in a TianoCore bugzilla.

- The size of this feature is significant. According to the github
webui, "19 changed files with 2,083 additions and 1,072 deletions".

A feature of this size must absolutely be broken up into a fine-grained
patch series (assuming the feature targets the edk2 master branch). It's
not only that such a huge patch is basically unreviewable: if someone
runs into an issue after the feature is committed, they will need the
ability to bisect the regression to a well isolated, self contained
modification. Then the experts around the feature have a much better
chance at root causing the issue from the patch that the bug reporter
has identified. An all-or-nothing patch is not bisectable.

- Combining the above two points into one, I'd suggest splitting the
feature into small patches, and posting it as an RFC series to the list.
(Assuming the initial reaction to the feature is interest -- I think it
is.) Admittedly, this is a lot of work.

Some more on-topic comments:

> Why Keep SMM on Variable Writes
> ------------------------------------------------
>  * SMM provides a fairly ubiquitous isolated execution environment in x86 for authenticated UEFI variables.
>  * BIOS region SPI flash write restrictions to SMM in platforms today can be retained.

Can you confirm that the runtime DXE code would not read flash, only the
cache in EfiRuntimeServicesData memory?

> Today's UEFI Variable Cache
> --------------------------------------
>  * Maintained in SMRAM via VariableSmm.
>  * A "write-through" cache of variable data in the form of a UEFI variable store.
>  * Non-volatile and volatile variables are maintained in separate buffers (variable stores).

I'm unclear on how the items on this list should be interpreted. Are
these items from today that we keep, or items that we change?

For example, it's quite beneficial that NV and V variables are
maintained in separate buffers -- the sizing can be different, and
that's good. I believe we shouldn't change that.

Thanks!
Laszlo

  parent reply	other threads:[~2019-09-09 15:31 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-05 19:54 [edk2-rfc] [edk2-devel] UEFI Variable SMI Reduction Kubacki, Michael A
2019-09-05 20:59 ` [edk2-devel] " Johnson, Michael
2019-09-06 21:47   ` Kubacki, Michael A
2019-09-06 21:52     ` Johnson, Michael
2019-09-08 22:36       ` Yao, Jiewen
2019-09-11  2:42         ` Nate DeSimone
2019-09-11  3:31           ` Yao, Jiewen
2019-09-11 20:48             ` Kubacki, Michael A
2019-09-12 15:02             ` Nate DeSimone
2019-09-09 15:31 ` Laszlo Ersek [this message]
2019-09-09 18:03   ` Kubacki, Michael A
2019-09-11 13:16     ` 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=5cb08fa7-b4c4-d8a6-155f-986eaa207f90@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