Re: SNP_INIT while in TPL_NOTIFY

[Laszlo Ersek <lersek@redhat.com>]

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