[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
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
> .
>
signature.asc
Description: OpenPGP digital signature
- Re: [edk2] [grub PATCH] efinet: disable MNP background polling, (continued)
- Re: [edk2] [grub PATCH] efinet: disable MNP background polling, Daniel Kiper, 2015/10/14
- Re: [edk2] [grub PATCH] efinet: disable MNP background polling, Seth Goldberg, 2015/10/14
- RE: [edk2] [grub PATCH] efinet: disable MNP background polling, Ye, Ting, 2015/10/14
- Re: [edk2] [grub PATCH] efinet: disable MNP background polling, Laszlo Ersek, 2015/10/15
- Re: [edk2] [grub PATCH] efinet: disable MNP background polling, Andrew Fish, 2015/10/16
- Re: [edk2] [grub PATCH] efinet: disable MNP background polling, Michael Brown, 2015/10/15
- Re: [edk2] [grub PATCH] efinet: disable MNP background polling, Laszlo Ersek, 2015/10/15
- Re: [edk2] [grub PATCH] efinet: disable MNP background polling,
Vladimir 'φ-coder/phcoder' Serbinenko <=
Re: [PATCH] efinet: disable MNP background polling, Andrei Borzenkov, 2015/10/08