public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Marvin H?user <Marvin.Haeuser@outlook.com>
To: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
	Abhishek Singh <abh@cs.unc.edu>
Cc: "star.zeng@intel.com" <star.zeng@intel.com>,
	"eric.dong@intel.com" <eric.dong@intel.com>,
	"ruiyu.ni@intel.com" <ruiyu.ni@intel.com>,
	"Laszlo Ersek" <lersek@redhat.com>
Subject: Re: smm lock query
Date: Sun, 27 May 2018 16:47:57 +0000	[thread overview]
Message-ID: <VI1PR0801MB1790F1633F0C8AFFEC20703E806F0@VI1PR0801MB1790.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <CAGB8-zrEfuVx98ku=0hrQnEztjRRJmON0zTbWcDaDsLZC+UyDQ@mail.gmail.com>

Good day Abhishek,

I CC'd the MdeModulePkg maintainers, Ruiyu for the Platform BDS aspect (exposes the ReadyToLock protocol) and Laszlo for his high-quality answers.

Strictly speaking you are, right, because of the description for the MM protocol:
"Indicates that MM resources and services that should not be used by the third party code are about[Marvin: (!)] to be locked."
Practically however, I don't see any issue with the current implementation. Code inside MMRAM is not affected directly by the lock, it is just notified.
However, either the code or the specification should be slightly updated to be in sync. A code update might require review of the caller assumptions, just to be sure.

I have a different concern though and hope I'm actually overlooking something.
If I understand the code correctly, it is the Platform BDS that exposes the (S)MmReadyToLock protocol. PiSmmIpl seems to consume that event and lock SMM resources based on the event.
Because of latter being an event however, I don't think it is, or can be, guaranteed to be the last event group member executing.
When it is not the last, the "about to be locked" part is not true for any subsequent callbacks, that could actually be a risky break of the specification - if it is.
If it is a break of the specification, I can only think of letting Platform BDS expose an "internal" event group, which is only caught by PiSmmIpl, which then drives the actual SmmReadyToLock flow.
This would require updates to all platform trees and hence I would propose a temporary backwards-compatibility.

Any comments? Did I overlook something (I hope)?

Thanks and regards,
Marvin

> -----Original Message-----
> From: edk2-devel <edk2-devel-bounces@lists.01.org> On Behalf Of
> Abhishek Singh
> Sent: Saturday, May 26, 2018 5:05 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] smm lock query
> 
> Hi,
> 
> This is the first time I am mailing to this list. If this is not the right place for the
> kind of questions I am asking please let me know where to direct my queries.
> 
> I have been looking at the SMM IPL code and a portion of the code is a little
> confusing to me. In the function SmmIplReadyToLockEventNotify, smram is
> locked (mSmmAccess->Lock) before the ready to lock notifications are sent
> through SmmIplGuidedEventNotify. Shouldn't the lock be placed after the
> ready to lock notifications?
> 
> Best regards,
> Abhishek
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel


  reply	other threads:[~2018-05-27 16:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-26 15:04 smm lock query Abhishek Singh
2018-05-27 16:47 ` Marvin H?user [this message]
2018-05-27 20:44   ` Andrew Fish
2018-05-27 20:45     ` Andrew Fish
2018-05-28 10:57     ` Laszlo Ersek
2018-05-28 14:03       ` Marvin Häuser
2018-05-28 18:02         ` Abhishek Singh
2018-05-29  1:15           ` Zeng, Star
2018-05-29  2:21             ` Yao, Jiewen
2018-05-29  5:17               ` Abhishek Singh
2018-05-29 14:54                 ` Andrew Fish
2018-05-29 14:56                 ` Yao, Jiewen

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=VI1PR0801MB1790F1633F0C8AFFEC20703E806F0@VI1PR0801MB1790.eurprd08.prod.outlook.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