From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nbfkord-smmo02.seg.att.com (nbfkord-smmo02.seg.att.com [209.65.160.78]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D2D7281FF8 for ; Mon, 30 Jan 2017 08:44:14 -0800 (PST) Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo02.seg.att.com(mxl_mta-7.2.4-7) with ESMTP id e5d6f885.2b126cc4d940.64819.00-2486.133712.nbfkord-smmo02.seg.att.com (envelope-from ); Mon, 30 Jan 2017 16:44:14 +0000 (UTC) X-MXL-Hash: 588f6d5e0f1bfff4-a2cc824a649b0a3cddea3f3db862844cb3de40bf Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo02.seg.att.com(mxl_mta-7.2.4-7) over TLS secured channel with ESMTP id f9a1f885.0.42715.00-2377.80375.nbfkord-smmo02.seg.att.com (envelope-from ); Mon, 30 Jan 2017 10:51:13 +0000 (UTC) X-MXL-Hash: 588f1aa1099b0a07-09ed3b3d06aae3c6caab26877bc7a080f7cc949d Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 30 Jan 2017 10:51:07 +0000 To: Laszlo Ersek , "edk2-devel@lists.01.org" References: From: "Tomas Pilar (tpilar)" Message-ID: Date: Mon, 30 Jan 2017 10:51:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.17.20.51] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-22854.003 X-TM-AS-Result: No--15.249000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=Sr+Wna60 c=1 sm=1 tr=0 a=8P+NB+fYZDP74ap4g4d9Kw==] X-AnalysisOut: [:17 a=uKoR9wHPcrcA:10 a=N659UExz7-8A:10 a=IgFoBzBjUZAA:10 ] X-AnalysisOut: [a=i3X5FwGiAAAA:8 a=I5JBZcOzRWn1JpGhRegA:9 a=d988UQZpejk-ab] X-AnalysisOut: [c6:21 a=tx0OIyfK-J6IA85O:21 a=pILNOxqGKmIA:10 a=mmqRlSCDY2] X-AnalysisOut: [ywfjPLJ4af:22] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [193.34.186.16] 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, 30 Jan 2017 16:44:15 -0000 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable Thanks Laszlo, I am glad I wasn't going insane there. I'll turn it into a simple busy poll= . Cheers, Tom On 27/01/17 18:12, Laszlo Ersek wrote: > On 01/27/17 17:51, Tomas Pilar (tpilar) wrote: >> Hi, >> >> I am currently maintaining our network driver written using the EDKII >> framework. Our network device implements a MCDI (mc-driver interface) >> which is (in theory) asynchronous (DMA doorbell-messagebox >> communication), although the majority of the calls take less than a >> jiffy. So for example, the setting up of TX and RX queues on the NIC >> requires some MCDI calls which the driver then has to wait for. I've >> implemented this using the gSB->SetTimer event system. >> >> My problem is that the SimpleNetworkInitialize() method is called by 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 > methods, the TPL must be <=3D TPL_CALLBACK. Meaning, an SNP implementatio= n > mustn'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 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 generic one second network poll timer). I could in >> theory initialise the NIC earlier, during probe, but the SNP allows for >> specification of extra buffer space for TX and RX during init. The >> network core might conceivable use that. Or the MNP might want to change >> station address using SNP or call for a reset which again requires >> asynchronous NIC operation. >> >> Has anyone encountered something similar? Is there a canonical 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 > >> Cheers, >> Tomas Pilar >> >> >> The information contained in this message is confidential and is >> intended for the addressee(s) only. If you have received this message in >> error, please notify the sender immediately and delete the message. >> Unless you are an addressee (or authorized to receive for an addressee), >> you may not use, copy or disclose to anyone this message or any >> information contained in this message. The unauthorized use, 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 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.