From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZmY2T-00080d-50 for mharc-grub-devel@gnu.org; Wed, 14 Oct 2015 22:13:05 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmY1I-0007w2-Fo for grub-devel@gnu.org; Wed, 14 Oct 2015 22:11:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmY1E-0001r6-F5 for grub-devel@gnu.org; Wed, 14 Oct 2015 22:11:52 -0400 Received: from mga14.intel.com ([192.55.52.115]:30077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmY1E-0001pr-4u for grub-devel@gnu.org; Wed, 14 Oct 2015 22:11:48 -0400 Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga103.fm.intel.com with ESMTP; 14 Oct 2015 19:11:46 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,683,1437462000"; d="scan'208";a="664615160" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga003.jf.intel.com with ESMTP; 14 Oct 2015 19:11:46 -0700 Received: from fmsmsx120.amr.corp.intel.com (10.18.124.208) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 14 Oct 2015 19:11:46 -0700 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by fmsmsx120.amr.corp.intel.com (10.18.124.208) with Microsoft SMTP Server (TLS) id 14.3.248.2; Wed, 14 Oct 2015 19:11:45 -0700 Received: from shsmsx104.ccr.corp.intel.com ([169.254.5.194]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.47]) with mapi id 14.03.0248.002; Thu, 15 Oct 2015 10:11:43 +0800 From: "Ye, Ting" To: Seth Goldberg , The development of GNU GRUB Subject: RE: [edk2] [grub PATCH] efinet: disable MNP background polling Thread-Topic: [edk2] [grub PATCH] efinet: disable MNP background polling Thread-Index: AQHQ/D9pgKrqD+2amEej31vtjlTQ7Z5qEpjXgABXpdD///iMgIAAS44AgAEr45A= Date: Thu, 15 Oct 2015 02:11:42 +0000 Message-ID: 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> In-Reply-To: <1BAD7DA9-D60E-4743-9143-3327989DF6B6@oracle.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 192.55.52.115 Cc: "arvidjaar@gmail.com" , Laszlo Ersek , edk2-devel-01 , "glin@suse.com" , 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 02:11:54 -0000 So the current problem is: GRUB wants to EXCLUSIVE open SNP, though if other application/driver alrea= dy opens SNP with EXCLUSIVE attribute, the GRUB would fail. According to UE= FI 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 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?=20 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 ne= eds to EXCLUSIVE open SNP, one alternative is the GRUG uses OpenProtocolInf= ormation() to retrieve the list of agents that currently EXCLUSIVE opened S= NP, then calls CloseProtocol() to close the opened protocol. If it is the c= ase that GRUB and 'other stuff' both need the network operation and would l= ike to keep EXCLUSIVE open SNP by intention, a MNP solution should be invol= ved 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 Salte= r; Laszlo Ersek Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling > On Oct 14, 2015, at 4:08 AM, Daniel Kiper wrote= : >=20 >> On Wed, Oct 14, 2015 at 05:19:32AM +0000, Ye, Ting wrote: >> Hi all, >>=20 >> 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.OpenProt= ocol(). >>=20 >> EXCLUSIVE Used by applications to gain exclusive access to a prot= ocol interface. >> If any drivers have the protocol interface opened with an att= ribute of BY_DRIVER, >> then an attempt will be made to remove them by calling the dr= iver's Stop() function. >>=20 >> 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 EXCLUSIV= E >> to disconnect the other drivers. This is the typical usage for all UEFI >> protocol, not particular constraints to SNP protocol. >=20 > Looks good! Great! However, it looks that we still have a problem if some= body > opens SNP in EXCLUSIVE mode. Then GRUB2 SNP open will fail according to U= EFI spec. > Sadly we do not have a control on other stuff and one day our approach ma= y 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 sh= ip 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 >=20 > Daniel >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel