Re: efinet SNP issue affects iscsi boot

[Michael Chang]

On Thu, Sep 20, 2018 at 02:01:08PM +0200, Daniel Kiper wrote:
> On Thu, Sep 20, 2018 at 06:38:07PM +0800, Michael Chang wrote:
> > On Thu, Sep 13, 2018 at 06:06:15PM -0600, Micah Parrish wrote:
> > > Hi, new subscriber here.? We have a problem with Grub 2 and its use of SNP
> > > instead of MNP.? Our UEFI driver for a network card parses the relevant 
> > > DHCP
> > > options for iSCSI boot, generates an iBFT table, then gets closed by Grub
> > > when it opens the SNP interface. The driver removes the iBFT table as part
> > > of normal unload cleanup.? I think this should happen with the Tianocore
> > > UEFI reference driver as well.? The problem is often masked or does not
> > > occur when there are multiple network ports enabled.? It occurs with 
> > > several
> > > different vendors NICs.
> > >
> > > Possible solutions I see:
> > >
> > > 1. Grub parses the DHCP options and creates its own iBFT.
> > >
> > > 2. Grub copies the already generated iBFT before destroying the interface.
> > >
> > > 3. Grub opens the network interface MNP instead of SNP.
> > >
> > > Although I am a neophyte at grub and UEFI development, I would like to 
> > > start
> > > a discussion on possible solutions.? Has anyone else seen this?
> >
> > For possible solution 3, I managed to work out patch to use MNP but is not
> > polished, although it survived my testing. If you don't mind and willing to
> > give it go I will post it here as RFC patch for review.
> 
> That would be perfect. However, there are a few things worth mentioning here.
> 
> The issue is never ending story. So, please look for relevant discussions
> in grub-devel archives and take them into account if it is possible/make 
> sense.
> If you have any difficulties with finding them drop me a line.

Thanks. I'm able to find those discussions in my mailbox. They are indeed very
helpful for me in catching up the problems.

Moreover I found that Laszlo Ersek <address@hidden> already proposed an
approach which is very close to what I was working on,

- identify NIC handles the same way you do now (I guess by enumerating
  SNP interfaces)
- for each handle found, look for MNPSB *first*.
- If there is no MNPSB, then stick with the current strategy -- open
  the SNP with exclusive access
- However, if there *is* an MNPSB, call the CreateChild() function to
  extract a new MNP instance
- Use this MNP instance to send and receive packets. This MNP instance
  will peacefully coexist with other (sibling) MNP clients.

> Please do not drop SNP driver. I think that we should make MNP driver a new
> default and SNP should stay as a backup. Just in case.

Yes. The patch has been worked the way you asked.

> Additionally, a few days ago I have started looking for people interested
> in the project. There are some. Hence, if you are going to take a stab at
> it I will ask them to do some reviews of your work. I will drop you their
> emails if they are happy to do so.

Please feel free to CC them to the discussion.

Thanks,
Michael

> 
> Daniel