From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id AD4FA82039 for ; Sun, 5 Feb 2017 22:11:03 -0800 (PST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga104.fm.intel.com with ESMTP; 05 Feb 2017 22:11:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,340,1477983600"; d="scan'208";a="61237273" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga005.jf.intel.com with ESMTP; 05 Feb 2017 22:11:03 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Sun, 5 Feb 2017 22:11:02 -0800 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.20]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.177]) with mapi id 14.03.0248.002; Mon, 6 Feb 2017 14:11:01 +0800 From: "Ye, Ting" To: Laszlo Ersek , "Tomas Pilar (tpilar)" , "edk2-devel@lists.01.org" Thread-Topic: [edk2] SNP_INIT while in TPL_NOTIFY Thread-Index: AQHSeL2oj+Po9OMOrk2Ihcf8D2oR/qFMGjkAgA9zJLA= Date: Mon, 6 Feb 2017 06:10:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Subject: Re: SNP_INIT while in TPL_NOTIFY X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 06:11:03 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable May I ask which SNP module are we discussing here? Is it the common SnpDxe= driver under MdeModulePkg/Universal/Network, or a specific driver implemen= ted for your network device? Best Regards, Ye Ting -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Lasz= lo Ersek Sent: Saturday, January 28, 2017 2:12 AM To: Tomas Pilar (tpilar) ; edk2-devel@lists.01.org <= edk2-devel@ml01.01.org> Subject: Re: [edk2] SNP_INIT while in TPL_NOTIFY On 01/27/17 17:51, Tomas Pilar (tpilar) wrote: > Hi, >=20 > I am currently maintaining our network driver written using the EDKII=20 > framework. Our network device implements a MCDI (mc-driver interface)=20 > which is (in theory) asynchronous (DMA doorbell-messagebox=20 > communication), although the majority of the calls take less than a=20 > jiffy. So for example, the setting up of TX and RX queues on the NIC=20 > requires some MCDI calls which the driver then has to wait for. I've=20 > implemented this using the gSB->SetTimer event system. >=20 > My problem is that the SimpleNetworkInitialize() method is called by=20 > the UEFI platform network core (network core finds a new NIC with SNP=20 > -> tries to open -> not initialised, so it tries to INIT) using a=20 > TPL_NOTIFY context, This looks like a bug, in the code that calls SimpleNetworkInitialize(). According to "Table 24. TPL Restrictions", for Simple Network Protocol meth= ods, the TPL must be <=3D TPL_CALLBACK. Meaning, an SNP implementation must= n't raise the TPL above TPL_CALLBACK, but also that any client can't call S= NP methods while executing on a TPL > TPL_CALLBACK. Worse, even staying at TPL_CALLBACK wouldn't be good enough for calling gBS->SetTimer(). SetTimer is < TPL_HIGH_LEVEL, so that'd be fine, but gBS->WaitForEvent() is strictly =3D TPL_APPLICATION. So WaitForEvent() can't be called when running on TPL_CALLBACK level. > where the code is not allowed to sleep (I assume that this is the MNP=20 > generic one second network poll timer). I could in theory initialise=20 > the NIC earlier, during probe, but the SNP allows for specification of=20 > extra buffer space for TX and RX during init. The network core might=20 > conceivable use that. Or the MNP might want to change station address=20 > using SNP or call for a reset which again requires asynchronous NIC=20 > operation. >=20 > Has anyone encountered something similar? Is there a canonical=20 > solution to this issue? I think you can poll the NIC in a busy loop, or if that's excessive, use gBS->Stall() between polls. Stall() is <=3D TPL_HIGH_LEVEL, so it should be safe. OTOH, "Execution of the processor is not yielded for the duration = of the stall". Thanks Laszlo >=20 > Cheers, > Tomas Pilar >=20 >=20 > The information contained in this message is confidential and is=20 > intended for the addressee(s) only. If you have received this message=20 > in error, please notify the sender immediately and delete the message. > Unless you are an addressee (or authorized to receive for an=20 > addressee), you may not use, copy or disclose to anyone this message=20 > or any information contained in this message. The unauthorized use,=20 > disclosure, copying or alteration of this message is strictly prohibited. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel