On 10/16/15 00:33, Andrew Fish wrote: > >> On Oct 15, 2015, at 11:14 AM, Laszlo Ersek <ler...@redhat.com> 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 >>> 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. >> > > 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 Laszlo > > 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:seth.goldb...@oracle.com] >>> Sent: Wednesday, October 14, 2015 11:39 PM >>> To: The development of GNU GRUB >>> Cc: Ye, Ting; arvidj...@gmail.com; edk2-devel-01; g...@suse.com; Mark >>> Salter; Laszlo Ersek >>> Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling >>> >>> >>> >>>> On Oct 14, 2015, at 4:08 AM, Daniel Kiper <daniel.ki...@oracle.com> 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 >>>> Grub-devel@gnu.org >>>> https://lists.gnu.org/mailman/listinfo/grub-devel >> >> _______________________________________________ >> edk2-devel mailing list >> edk2-de...@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
