[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: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling
Date: Thu, 29 Oct 2015 15:47:50 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.3.0

On 14.10.2015 17:39, Seth Goldberg wrote:
>> 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 ;).
Can you please point to the patch you used?
I think the only sane solution judging from what I have read so far is
to use MNP as far as possible and fallback to current code if MNP fails
>   --S
>> Daniel
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> .

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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