Re: SNP_INIT while in TPL_NOTIFY

["Ye, Ting" <ting.ye@intel.com>]

May I ask which SNP module are we discussing here?  Is it the common SnpDxe driver under MdeModulePkg/Universal/Network, or a specific driver implemented for your network device?

Best Regards,
Ye Ting

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Saturday, January 28, 2017 2:12 AM
To: Tomas Pilar (tpilar) <tpilar@solarflare.com>; 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,
> 
> 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

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel