All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ye, Ting" <ting.ye@intel.com>
To: Andrei Borzenkov <arvidjaar@gmail.com>,
	Laszlo Ersek <lersek@redhat.com>,
	 "daniel.kiper@oracle.com" <daniel.kiper@oracle.com>,
	"grub-devel@gnu.org" <grub-devel@gnu.org>
Cc: edk2-devel-01 <edk2-devel@ml01.01.org>,
	"glin@suse.com" <glin@suse.com>,
	"seth.goldberg@oracle.com" <seth.goldberg@oracle.com>,
	Mark Salter <msalter@redhat.com>
Subject: RE: [edk2] [grub PATCH] efinet: disable MNP background polling
Date: Wed, 14 Oct 2015 08:00:39 +0000	[thread overview]
Message-ID: <BC0C045B0E2A584CA4575E779FA2C12A0A9588A4@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <561DFCFE.9080408@gmail.com>

Could you please describe the details how does GRUB use UEFI network protocols?

I see the thread says that EXCLUSIVE open SNP causes PXE boot fail. 

If you read below description about 'EXCLUSIVE' in UEFI specification, you will find when GRUB exclusive opens SNP protocol, the UEFI will remove any drivers that opened SNP with BY_DRIVER by calling the driver's Stop() function. In UEFI network stack, MNP driver will open SNP 'BY_DRIVER'. So if GRUB/iPXE exclusive opens SNP, MNP will uninstall itself and the whole UEFI network stack is disconnected except SNP and UNDI. Hence, the UEFI PXE no longer work.


>> 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.


If GRUB would like to call SNP protocol only, it should use EXCLUSIVE open to gain the exclusive access and disconnect UEFI network stack since MNP. Then the MNP background polling is also disabled.
If GRUB still needs UEFI PXE capability, it should utilize PXE base code protocol to continue the process, rather than calling SNP, as SNP is already consumed by UEFI network stack.

Thanks,
Ye Ting


-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andrei Borzenkov
Sent: Wednesday, October 14, 2015 2:58 PM
To: Ye, Ting; Laszlo Ersek; daniel.kiper@oracle.com; grub-devel@gnu.org
Cc: edk2-devel-01; Mark Salter; glin@suse.com; seth.goldberg@oracle.com; konrad.wilk@oracle.com
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling

14.10.2015 09:15, Ye, Ting пишет:
> May I know the details what problems it causes in some cases?
>

One is being discussed in this thread:

http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00013.html
http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00068.html

Another was reported recently:

http://lists.gnu.org/archive/html/help-grub/2015-09/msg00033.html
http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00071.html


> Thanks,
> Ye Ting
>
> -----Original Message-----
> From: Andrei Borzenkov [mailto:arvidjaar@gmail.com]
> Sent: Wednesday, October 14, 2015 1:58 PM
> To: Ye, Ting; Laszlo Ersek; daniel.kiper@oracle.com; grub-devel@gnu.org
> Cc: konrad.wilk@oracle.com; edk2-devel-01; glin@suse.com; seth.goldberg@oracle.com; Mark Salter
> Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling
>
> 14.10.2015 08:19, Ye, Ting пишет:
>> 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.
>>
>
> That is exactly what grub currently does - it opens SNP exclusively.
> Apparently it is causing problems in some cases.
>

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

  reply	other threads:[~2015-10-14  8:01 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 [this message]
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
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=BC0C045B0E2A584CA4575E779FA2C12A0A9588A4@SHSMSX104.ccr.corp.intel.com \
    --to=ting.ye@intel.com \
    --cc=arvidjaar@gmail.com \
    --cc=daniel.kiper@oracle.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.