From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Zms6a-0000I0-O0 for mharc-grub-devel@gnu.org; Thu, 15 Oct 2015 19:38:40 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50646) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zms6X-0000HO-Nz for grub-devel@gnu.org; Thu, 15 Oct 2015 19:38:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zms6U-0006uL-F3 for grub-devel@gnu.org; Thu, 15 Oct 2015 19:38:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zms6U-0006uG-5A for grub-devel@gnu.org; Thu, 15 Oct 2015 19:38:34 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id AFE59C0BFD3D; Thu, 15 Oct 2015 23:38:33 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-188.phx2.redhat.com [10.3.113.188]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9FNcUSs005317; Thu, 15 Oct 2015 19:38:31 -0400 Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling To: Andrew Fish References: <20151001.182655.371384337.d.hatayama@jp.fujitsu.com> <560D1E07.3090902@redhat.com> <20151013214919.GA6140@router-fw-old.local.net-space.pl> <561D83E9.6050703@redhat.com> <20151014110847.GQ6226@olila.local.net-space.pl> <1BAD7DA9-D60E-4743-9143-3327989DF6B6@oracle.com> <561FED1C.7050801@redhat.com> From: Laszlo Ersek Message-ID: <562038F6.5020009@redhat.com> Date: Fri, 16 Oct 2015 01:38:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 209.132.183.28 Cc: The development of GNU GRUB , "Ye, Ting" , edk2-devel-01 , "arvidjaar@gmail.com" , "glin@suse.com" , Seth Goldberg , Mark Salter X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 23:38:39 -0000 On 10/16/15 00:33, Andrew Fish wrote: >=20 >> On Oct 15, 2015, at 11:14 AM, Laszlo Ersek 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. Accordin= g to UEFI spec V2.5 page 182,=20 >>> 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 at= tribute of EXCLUSIVE or BY_DRIVER|EXCLUSIVE, then EFI_ACCESS_DENIED is re= turned. >>> >>> My question is: who will EXCLUSIVE open SNP before GRUB? Why it EXCLU= SIVE 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 us= ed >> 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 resource= s >> that need to be tracked and handled cooperatively between unrelated / >> independent applications. Each single app needs to be prudent about >> resource management. >> >=20 > From an EFI history point of view EXCLUSIVE was not intended for > =E2=80=9Cevery day=E2=80=9D 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. >=20 > 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. >=20 > I=E2=80=99m just guessing but the iPXE developers have to deal with mul= tiple > environments (Legacy BIOS, EFI, =E2=80=A6) and probably picked a path t= hat > allowed all these =E2=80=9Cworlds=E2=80=9D 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 >=20 > Thanks, >=20 > Andrew Fish >=20 >> 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.goldberg@oracle.com]=20 >>> Sent: Wednesday, October 14, 2015 11:39 PM >>> To: The development of GNU GRUB >>> Cc: Ye, Ting; arvidjaar@gmail.com; edk2-devel-01; glin@suse.com; Mark= Salter; Laszlo Ersek >>> Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polli= ng >>> >>> >>> >>>> On Oct 14, 2015, at 4:08 AM, Daniel Kiper = 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 attribu= te >>>>> "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usa= ge >>>>> is clearly described in page 184, chapter 6.3 EFI_BOOT_SERVICES.Ope= nProtocol(). >>>>> >>>>> 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 th= e driver's Stop() function. >>>>> >>>>> The grub code should not assume that the SNP is not occupied by oth= er >>>>> 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 EXC= LUSIVE >>>>> 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 approa= ch may fail >>>> because somebody decided to open SNP in EXCLUSIVE mode in e.g. a dri= ver. Does >>>> it mean that migration to MNP is one sensible solution for our probl= ems? As I know >>>> this is huge overhaul, so, we should think twice before choosing tha= t 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 s= ystems 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-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel >=20