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

[Laszlo Ersek]

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

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.

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
>> https://lists.gnu.org/mailman/listinfo/grub-devel