Re: [grub PATCH] efinet: disable MNP background polling

[Laszlo Ersek <lersek@redhat.com>]

On 10/09/15 12:10, HATAYAMA Daisuke wrote:
> Sorry for delayed response.
> 
> From: Laszlo Ersek <lersek@redhat.com>
> Subject: Re: [grub PATCH] efinet: disable MNP background polling
> Date: Thu, 1 Oct 2015 13:50:31 +0200
> 

[snip]

>> Here's an example. Boot OVMF, with a virtio-net-pci device enabled in
>> QEMU, and make sure that the NICs ROM BAR does not contain the iPXE
>> driver (-device virtio-net-pci,rombar=0). This will allow OVMF's builtin
>> VirtioNetDxe to bind the device (which I want to use now for
>> illustrating the question). Then, enter the UEFI shell, and issue the
>> following command:
>>
>>> Shell> dh -d -v -p SimpleNetwork
>>> A0: UnknownDevice
>>>     LoadFile
>>>     PXEBaseCode
>>>     TCPv4ServiceBinding
>>>     MTFTPv4ServiceBinding
>>>     DHCPv4ServiceBinding
>>>     UDPv4ServiceBinding
>>>     IPv4Config2
>>>     IPv4ServiceBinding
>>>     ARPServiceBinding
>>>     UnknownDevice
>>>     ManagedNetworkServiceBinding
>>>     VlanConfig
>>>     DevicePath PciRoot(0x0)/Pci(0x3,0x0)/MAC(52540036A382,0x1)
>>>     SimpleNetwork
>>>
>>>    Controller Name    : Virtio Network Device
>>>    Device Path        : PciRoot(0x0)/Pci(0x3,0x0)/MAC(52540036A382,0x1)
>>>    Controller Type    : BUS
>>>    Configuration      : NO
>>>    Diagnostics        : NO
>>>    Managed by         :
>>>      Drv[6F]          : MNP Network Service Driver
>>>      Drv[70]          : VLAN Configuration Driver
>>>      Drv[73]          : IP4 Network Service Driver
>>>    Parent Controllers :
>>>      Parent[8C]       : Virtio Network Device
>>>    Child Controllers  :
>>>      Child[A2]        : MNP (MAC=52-54-00-36-A3-82, ProtocolType=0x806, VlanId=0)
>>>      Child[A3]        : MNP (MAC=52-54-00-36-A3-82, ProtocolType=0x800, VlanId=0)
>>>      Child[A1]        : PciRoot(0x0)/Pci(0x3,0x0)/MAC(52540036A382,0x1)/VenHw(D79DF6B0-EF44-43BD-9797-43E93BCF5FA8)
>>>      Child[A4]        : PciRoot(0x0)/Pci(0x3,0x0)/MAC(52540036A382,0x1)/VenHw(9FB1A1F3-3B71-4324-B39A-745CBB015FFF)
>>
>> There is only one handle with an SNP instance on it in the system
>> (because I configured only one virtio-net NIC for the VM). The
>> underlying hardware controller handle (marked as A0 above) has a bunch
>> of other protocol interfaces installed on it. Note the many
>> ___ServiceBinding protocols!
>>
>> (
>> For example, the UEFI spec says about UDPv4ServiceBinding:
>>
>>     The EFI UDPv4 Service Binding Protocol is used to locate
>>     communication devices that are supported by an EFI UDPv4 Protocol
>>     driver and to create and destroy instances of the EFI UDPv4 Protocol
>>     child protocol driver that can use the underlying communications
>>     device.
>>
>> Multiple consumers could call UDPv4ServiceBinding.CreateChild(), and
>> then use their private UDPv4 protocol interfaces to transmit and receive
>> in parallel.
>> )
>>
>> Also, note that there is *no* MNP instance directly installed on the
>> handle.
>>
>> Anyway, among other things, this handle is open by "MNP Network Service
>> Driver" (which directly provides MNPSB), marked as [6F]. And,
>> apparently, there have been two requests to MNPSB for children: see [A2]
>> and [A3] above.
>>
>> We can investigate those as well:
>>
>>> Shell> dh -d -v A2
>>> A2: 7EF49B58
>>> ManagedNetwork
>>>    Controller Name    : MNP (MAC=52-54-00-36-A3-82, ProtocolType=0x806, VlanId=0)
>>>    Device Path        : <None>
>>>    Controller Type    : BUS
>>>    Configuration      : NO
>>>    Diagnostics        : NO
>>>    Managed by         :
>>>      Drv[71]          : ARP Network Service Driver
>>>    Parent Controllers :
>>>      Parent[A0]       : Virtio Network Device
>>>    Child Controllers  :
>>>      Child[AB]        : PXE Controller
>>
>> The first MNP child has been extracted / requested, from MNPSB, by the
>> ARP (SB) driver.
>>
>>> Shell> dh -d -v A3
>>> A3: 7EF56AD8
>>> ManagedNetwork
>>>    Controller Name    : MNP (MAC=52-54-00-36-A3-82, ProtocolType=0x800, VlanId=0)
>>>    Device Path        : <None>
>>>    Controller Type    : BUS
>>>    Configuration      : NO
>>>    Diagnostics        : NO
>>>    Managed by         :
>>>      Drv[73]          : IP4 Network Service Driver
>>>    Parent Controllers :
>>>      Parent[A0]       : Virtio Network Device
>>>    Child Controllers  :
>>>      Child[A5]        : IPv4 (SrcIP=0.0.0.0)
>>>      Child[A6]        : IPv4 (SrcIP=0.0.0.0)
>>>      Child[A8]        : IPv4 (Not started)
>>>      Child[AA]        : IPv4 (SrcIP=0.0.0.0)
>>>      Child[AD]        : PXE Controller
>>>      Child[AE]        : IPv4 (Not started)
>>>      Child[B1]        : IPv4 (Not started)
>>>      Child[B3]        : IPv4 (Not started)
>>>      Child[B7]        : IPv4 (Not started)
>>
>> The other MNP child has been extracted / requested, from MNPSB, by the
>> IPv4 (SB) driver.
>>
>> Now, assuming GRUB wants Ethernet packet level access, this is exactly
>> what GRUB should do too: locate MNPSB, and ask it for another MNP
>> instance. That MNP instance will be dedicated to GRUB, and the MNP
>> Network Service Driver will multiplex it with other users (ARP Network
>> Service Driver, IP4 Network Service Driver).
>>
>> Alternatively, GRUB could look for higher level service binding
>> protocols as well, on EFI systems (see the list near A0 above), but I
>> doubt that would fit well into GRUB's net framework (which is supposed
>> to run on "legacy" BIOS systems too).
>>
>> To summarize:
>> - identify the level / abstraction of the network protocol that GRUB
>>   needs,
>> - assuming it is "ethernet packet", look for MNPSB first, and if it's
>>   there, call it to get a private-use MNP instance, in order to transmit
>>   and receive,
>> - if MNPSB is not there, open SNP in exclusive mode, same as now.
>>
>> Or else,
>> - stick with the current exclusive SNP reopen, but make sure that all
>>   aspects are reconfigured from the ground up.
>>
>> ... I'm not a GRUB contributor, and ideas are cheap :), so I'll leave it
>> to you how much importance you give to the above. But, since you CC'd me
>> on the patch, I thought I'd offer an opinion.
>>
>> Thanks
>> Laszlo
>>
> 
> Thanks for detailed explanation. I'm beginner for UEFI field so this
> is very helpful to understand the details around this issue.
> 
> Now I think I need to do this work and I want sample codes that uses
> NMP and MNPSB protocols if exists. Could you tell me such ones if you
> know? In EDK2 source code?

Sure. As I mentioned in the above example, you can look at "ARP Network
Service Driver" and "IP4 Network Service Driver" for examples. The
relevant source files in edk2 are:

- MdeModulePkg/Universal/Network/ArpDxe/ArpDriver.c

  See function ArpCreateService():

  //
  // Create a MNP child instance.
  //
  Status = NetLibCreateServiceChild (
             ControllerHandle,
             ImageHandle,
             &gEfiManagedNetworkServiceBindingProtocolGuid,
             &ArpService->MnpChildHandle
             );
  if (EFI_ERROR (Status)) {
    return Status;
  }


- MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c

  See function Ip4CreateService():

  Status = NetLibCreateServiceChild (
             Controller,
             ImageHandle,
             &gEfiManagedNetworkServiceBindingProtocolGuid,
             &IpSb->MnpChildHandle
             );

  if (EFI_ERROR (Status)) {
    goto ON_ERROR;
  }

- In both cases, the private MNP instance is extracted from MNPSB with
  the NetLibCreateServiceChild() utility function. It is implemented in
  "MdeModulePkg/Library/DxeNetLib/DxeNetLib.c".

  NetLibCreateServiceChild() is a simple function that looks up the
  requested service binding protocol first, then calls its
  CreateChild() member function to extract a private handle for the
  caller.

  See also the parallel function NetLibDestroyServiceChild().

Once you have an MNP instance that is private to GRUB, please consult
the UEFI spec (chapter 24.1, in UEFI v2.5) for the right member
functions, for configuration / transmitting / receiving. Before the
member function reference sections start, the chapter gives a good
guide-level description.

Thanks
Laszlo