[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: Laszlo Ersek
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling
Date: Fri, 16 Oct 2015 01:38:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 10/16/15 00:33, Andrew Fish wrote:
>> 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 operation.
> 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.

This exactly has been my thinking about GRUB, and to an extent, iPXE.
They have their internal networking abstractions.


> Thanks,
> 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]