Re: efinet SNP issue affects iscsi boot

[Daniel Kiper]

On Thu, Sep 27, 2018 at 06:15:45PM +0800, Michael Chang wrote:
> 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.

More or less LGTM.

> > 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.

I will try to take a look at it next week.

> > 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.

Will do.

Daniel