[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [edk2] [grub PATCH] efinet: disable MNP background polling

From: Andrew Fish
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling
Date: Thu, 15 Oct 2015 15:33:45 -0700

> On Oct 15, 2015, at 11:14 AM, Laszlo Ersek <address@hidden> wrote:
> On 10/15/15 04:11, Ye, Ting wrote:
>> 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 
>> 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?
> Right; when an app is done using the SNP instance and intends to pass
> control to another app for good, it should close the protocol first --
> same as it is expected to release memory.
> ... I wonder if these problems are rooted in an "outdated" pre-OS view
> of system resources. I assume that before UEFI, pre-OS applications used
> to think to own all of those resources, and no real life-cycle
> management was done. I don't know if that's the case, but if it is, it's
> not compatible with UEFI. With UEFI in the picture, there are resources
> that need to be tracked and handled cooperatively between unrelated /
> independent applications. Each single app needs to be prudent about
> resource management.

From an EFI history point of view EXCLUSIVE was not intended for “every day” 
use.  EXCLUSIVE exists to solve the problem of how do you format a hard drive, 
or run diagnostics on a hard drive that could break the file system driver etc. 

The EFI Driver Model, lets you connect and disconnect, drivers as needed. The 
EFI networking stack supports the EFI Manged Network Protocol to help manage 
the network stack configuration. This is what was intended for normal 

I’m just guessing but the iPXE developers have to deal with multiple 
environments (Legacy BIOS, EFI, …) and probably picked a path that allowed all 
these “worlds” to have a similar code flow. So the EFI OpenProtocol  EXCLUSIVE 
probably mapped into the other flows where iPXE just takes over. If you are 
maintaining a complex networking stack (iPXE) trying to make it as common as 
possible in all its various ports does not seem like an unreasonable goal, but 
you might not end up with the ideal implementation for each environment. 


Andrew Fish

> Laszlo
>>       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:address@hidden 
>> Sent: Wednesday, October 14, 2015 11:39 PM
>> To: The development of GNU GRUB
>> Cc: Ye, Ting; address@hidden; edk2-devel-01; address@hidden; Mark Salter; 
>> Laszlo Ersek
>> Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling
>>> On Oct 14, 2015, at 4:08 AM, Daniel Kiper <address@hidden> 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
>>> address@hidden
> _______________________________________________
> edk2-devel mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]