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

[Ye, Ting]

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