From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 88BD38204E for ; Mon, 6 Feb 2017 19:32:00 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga102.fm.intel.com with ESMTP; 06 Feb 2017 19:32:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,344,1477983600"; d="scan'208";a="40710682" Received: from fmsmsx104.amr.corp.intel.com ([10.18.124.202]) by orsmga002.jf.intel.com with ESMTP; 06 Feb 2017 19:31:59 -0800 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by fmsmsx104.amr.corp.intel.com (10.18.124.202) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 6 Feb 2017 19:31:59 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 6 Feb 2017 19:31:59 -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; Tue, 7 Feb 2017 11:31:58 +0800 From: "Ye, Ting" To: "Tomas Pilar (tpilar)" , Laszlo Ersek , "edk2-devel@lists.01.org" Thread-Topic: [edk2] SNP_INIT while in TPL_NOTIFY Thread-Index: AQHSeL2oj+Po9OMOrk2Ihcf8D2oR/qFMGjkAgA9zJLCAAA4FAIABWBFQ Date: Tue, 7 Feb 2017 03:31:58 +0000 Message-ID: References: <2775048a-f988-0e65-4ef7-7fea5c8cc255@solarflare.com> In-Reply-To: <2775048a-f988-0e65-4ef7-7fea5c8cc255@solarflare.com> 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: Tue, 07 Feb 2017 03:32:00 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks for the clarification. I just want to confirm that it is not a bug i= n the common SNP driver.=20 Best Regards, Ye Ting -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Toma= s Pilar (tpilar) Sent: Monday, February 06, 2017 10:59 PM To: Ye, Ting ; Laszlo Ersek ; edk2-de= vel@lists.01.org Subject: Re: [edk2] SNP_INIT while in TPL_NOTIFY This is the specific implementation of SNP for our driver. We expose this i= mplementation which is then consumed by MNP so that our NIC can be used as = a NIC. The specific problem is that some functionality that SNP needs to im= plement (initializing queues, changing MAC, resetting) are asynchronous, bu= t MNP can call our SNP implementation in raised TPL where one is not allowe= d to wait. So the only solution seems to be to use a busy poll and actually hang the e= xecution until the asynchronous call to the MC on the NIC is completed, eve= n though we've been called in TPL_CALLBACK or TPL_NOTIFY. Cheers, Tom On 06/02/17 06:10, Ye, Ting wrote: > May I ask which SNP module are we discussing here? Is it the common SnpD= xe driver under MdeModulePkg/Universal/Network, or a specific driver implem= ented for your network device? > > Best Regards, > Ye Ting > > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of=20 > Laszlo Ersek > Sent: Saturday, January 28, 2017 2:12 AM > To: Tomas Pilar (tpilar) ;=20 > edk2-devel@lists.01.org > Subject: Re: [edk2] SNP_INIT while in TPL_NOTIFY > > On 01/27/17 17:51, Tomas Pilar (tpilar) wrote: >> Hi, >> >> 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. >> >> My problem is that the SimpleNetworkInitialize() method is called by=20 >> the UEFI platform network core (network core finds a new NIC with SNP >> -> tries to open -> not initialised, so it tries to INIT) using a >> TPL_NOTIFY context, > This looks like a bug, in the code that calls SimpleNetworkInitialize(). > According to "Table 24. TPL Restrictions", for Simple Network Protocol me= thods, the TPL must be <=3D TPL_CALLBACK. Meaning, an SNP implementation mu= stn't raise the TPL above TPL_CALLBACK, but also that any client can't call= SNP methods while executing on a TPL > TPL_CALLBACK. > > Worse, even staying at TPL_CALLBACK wouldn't be good enough for=20 > 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=20 >> of extra buffer space for TX and RX during init. The network core=20 >> might conceivable use that. Or the MNP might want to change station=20 >> address using SNP or call for a reset which again requires=20 >> asynchronous NIC operation. >> >> 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,=20 > 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 duratio= n of the stall". > > Thanks > Laszlo > >> Cheers, >> Tomas Pilar >> >> >> 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 The information contained in this message is confidential and is intended f= or the addressee(s) only. If you have received this message in error, pleas= e notify the sender immediately and delete the message. Unless you are an a= ddressee (or authorized to receive for an addressee), you may not use, copy= or disclose to anyone this message or any information contained in this me= ssage. The unauthorized use, disclosure, copying or alteration of this mess= age is strictly prohibited. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel