From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 8750981FD2 for ; Fri, 27 Jan 2017 10:12:34 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1C517FAF2D; Fri, 27 Jan 2017 18:12:35 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-41.ams2.redhat.com [10.36.116.41]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0RICUmD026691; Fri, 27 Jan 2017 13:12:32 -0500 To: "Tomas Pilar (tpilar)" , "edk2-devel@lists.01.org" References: From: Laszlo Ersek Message-ID: Date: Fri, 27 Jan 2017 19:12:24 +0100 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-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 27 Jan 2017 18:12:35 +0000 (UTC) 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: Fri, 27 Jan 2017 18:12:34 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 <= TPL_CALLBACK. Meaning, an SNP implementation 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 = 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 <= 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