All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ye, Ting" <ting.ye@intel.com>
To: Seth Goldberg <seth.goldberg@oracle.com>,
	The development of GNU GRUB <grub-devel@gnu.org>
Cc: "arvidjaar@gmail.com" <arvidjaar@gmail.com>,
	Laszlo Ersek <lersek@redhat.com>,
	edk2-devel-01 <edk2-devel@ml01.01.org>,
	"glin@suse.com" <glin@suse.com>, Mark Salter <msalter@redhat.com>
Subject: RE: [edk2] [grub PATCH] efinet: disable MNP background polling
Date: Thu, 15 Oct 2015 02:11:42 +0000	[thread overview]
Message-ID: <BC0C045B0E2A584CA4575E779FA2C12A0A958E2F@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <1BAD7DA9-D60E-4743-9143-3327989DF6B6@oracle.com>

So the current problem is:
 GRUB wants to EXCLUSIVE open SNP, though if other application/driver already opens SNP with EXCLUSIVE attribute, the GRUB would fail. According to UEFI spec V2.5 page 182, 
	If Attributes is BY_DRIVER , BY_DRIVER|EXCLUSIVE, or EXCLUSIVE, and there are any items on the open list of the protocol interface with an attribute of EXCLUSIVE or BY_DRIVER|EXCLUSIVE, then EFI_ACCESS_DENIED is returned.

 My question is: who will EXCLUSIVE open SNP before GRUB? Why it EXCLUSIVE opens SNP and NOT close SNP protocol before handover to GRUB? 
	 For information, the MNP driver in UEFI network stack will open SNP with attribute 'BY_DRIVER', without EXCLUSIVE.

In my opinion, if it is a bug in other stuff GRUB can't handle, and GRUB needs to EXCLUSIVE open SNP, one alternative is the GRUG uses OpenProtocolInformation() to retrieve the list of agents that currently EXCLUSIVE opened SNP, then calls CloseProtocol() to close the opened protocol. If it is the case that GRUB and 'other stuff' both need the network operation and would like to keep EXCLUSIVE open SNP by intention, a MNP solution should be involved since SNP can't support multiple access to use the network interface at the same time.


Best Regards,
Ye Ting


-----Original Message-----
From: Seth Goldberg [mailto:seth.goldberg@oracle.com] 
Sent: Wednesday, October 14, 2015 11:39 PM
To: The development of GNU GRUB
Cc: Ye, Ting; arvidjaar@gmail.com; edk2-devel-01; glin@suse.com; Mark Salter; Laszlo Ersek
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling



> On Oct 14, 2015, at 4:08 AM, Daniel Kiper <daniel.kiper@oracle.com> wrote:
> 
>> On Wed, Oct 14, 2015 at 05:19:32AM +0000, Ye, Ting wrote:
>> Hi all,
>> 
>> If I understand the issue correctly, I don't quite agree that UEFI
>> spec is imprecise about SNP constraints described as following.
>> The "constraint" described here is that the grub should use attribute
>> "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage
>> is clearly described in page 184, chapter 6.3 EFI_BOOT_SERVICES.OpenProtocol().
>> 
>> EXCLUSIVE        Used by applications to gain exclusive access to a protocol interface.
>>            If any drivers have the protocol interface opened with an attribute of BY_DRIVER,
>>            then an attempt will be made to remove them by calling the driver's Stop() function.
>> 
>> The grub code should not assume that the SNP is not occupied by other
>> drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to
>> be more precise, use OpenProtocolInformation() to check whether SNP is
>> already opened by other driver, then decide whether need to use EXCLUSIVE
>> to disconnect the other drivers. This is the typical usage for all UEFI
>> protocol, not particular constraints to SNP protocol.
> 
> Looks good! Great! However, it looks that we still have a problem if somebody
> opens SNP in EXCLUSIVE mode. Then GRUB2 SNP open will fail according to UEFI spec.
> Sadly we do not have a control on other stuff and one day our approach may fail
> because somebody decided to open SNP in EXCLUSIVE mode in e.g. a driver. Does
> it mean that migration to MNP is one sensible solution for our problems? As I know
> this is huge overhaul, so, we should think twice before choosing that way.


   Then it is fortunate that when I wrote the MNP implementation that we ship with Oracle Solaris 11.2, that I tested it on many thousands of systems as well as on new UEFI implementations at the UEFI Plugfest ;).

  --S



> 
> Daniel
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel


  reply	other threads:[~2015-10-15  2:13 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-01  9:26 [PATCH] efinet: disable MNP background polling HATAYAMA Daisuke
2015-10-01 11:50 ` [grub PATCH] " Laszlo Ersek
2015-10-01 17:53   ` Andrei Borzenkov
2015-10-01 22:04     ` Yinghai Lu
2015-10-02  3:48       ` Andrei Borzenkov
2015-10-09 10:15     ` HATAYAMA Daisuke
2015-10-13 22:11     ` Daniel Kiper
2015-10-13 22:23       ` Laszlo Ersek
2015-10-14  1:01       ` Yinghai Lu
2015-10-14  7:00         ` Andrei Borzenkov
2015-10-09 10:10   ` HATAYAMA Daisuke
2015-10-09 11:19     ` Laszlo Ersek
2015-10-13 21:49   ` Daniel Kiper
2015-10-13 22:21     ` Laszlo Ersek
2015-10-13 22:56       ` Daniel Kiper
2015-10-14  0:43       ` Seth Goldberg
2015-10-14  5:19       ` [edk2] " Ye, Ting
2015-10-14  5:57         ` Andrei Borzenkov
2015-10-14  6:15           ` Ye, Ting
2015-10-14  6:58             ` Andrei Borzenkov
2015-10-14  8:00               ` Ye, Ting
2015-10-14 17:52                 ` Andrei Borzenkov
2015-10-14 11:08         ` Daniel Kiper
2015-10-14 15:39           ` Seth Goldberg
2015-10-15  2:11             ` Ye, Ting [this message]
2015-10-15 18:14               ` Laszlo Ersek
2015-10-15 22:33                 ` Andrew Fish
2015-10-15 22:57                   ` Michael Brown
2015-10-15 23:38                   ` Laszlo Ersek
2015-10-29 14:47             ` Vladimir 'φ-coder/phcoder' Serbinenko
2015-10-01 17:40 ` [PATCH] " Andrei Borzenkov
2015-10-09 10:30   ` HATAYAMA Daisuke

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-all 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=BC0C045B0E2A584CA4575E779FA2C12A0A958E2F@SHSMSX104.ccr.corp.intel.com \
    --to=ting.ye@intel.com \
    --cc=arvidjaar@gmail.com \
    --cc=edk2-devel@ml01.01.org \
    --cc=glin@suse.com \
    --cc=grub-devel@gnu.org \
    --cc=lersek@redhat.com \
    --cc=msalter@redhat.com \
    --cc=seth.goldberg@oracle.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.