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

[Daniel Kiper]

On Wed, Oct 14, 2015 at 12:21:29AM +0200, Laszlo Ersek wrote:
> On 10/13/15 23:49, Daniel Kiper wrote:

[...]

> > Taking into account above and sentences in UEFI spec (v2.5) like "Once the
> > remote image is successfully loaded, it may utilize the 
> > EFI_PXE_BASE_CODE_PROTOCOL
> > interfaces, or even the EFI_SIMPLE_NETWORK_PROTOCOL interfaces, to continue
> > the remote process." I have a feeling that UEFI spec is very imprecise how
> > to use SNP. I have not seen any single word saying that there are any 
> > constraints
> > on SNP usage (am I missing something?). I heard about that in our internal
> > discussions but I was not convinced that it is true until I have seen your
> > email with all details. So, now I think that UEFI spec should have special
> > paragraph saying how to play with SNP. What do you think about that?
>
> I think that a request for clarification should be filed with the USWG,
> or at least raised on edk2-devel :)

I will take care of it. Hmmm... If firmware do not conform to spec then
firmware should be fixed not spec. Anyway, I will take a look and we
will see what (if any) should be done.

> > By the way, I saw that other boot loaders like PXELINUX or iPXE use SNP.
> > Do you suggest that all of them should be rewritten to avoid issues with
> > this protocol?
>
> I don't know these projects overly well :), but I wouldn't suggest such
> an indiscriminate rewrite for each. The main incentive for thinking
> about MNP at all is that the exclusive open of SNP, which *should* work,
> hangs various proprietary UEFI implementations.
>
> When Mark Salter pinged me on IRC quite a few months back about the
> original grub problem, the first thing that I recommended (although
> clearly not immediately -- I had to research the spec) was the exclusive
> open. Mark went ahead and implemented that, and grub started working on
> the UEFI platform we had. (Then he contributed the patch(es) to upstream.)
>
> The exclusive open is a valid (and simple) thing to do, according to the
> UEFI spec. So the alternative to the elaborate MNP(SB) patch is to debug

I have the same feeling since I started work on this issue.

> and fix the UEFI implementations on which the current (otherwise

This is firmware guys work. I think that we can try to convince
some of them to fix what should be fixed.

> spec-conformant) grub code -- the exclusive open -- exposes a hang /
> crash etc.
>
> The people who are likely most interested in either fixing those
> problematic UEFI implementations, *or* in converting the various open
> source projects to MNP(SB), should be those that want to run the latter
> on the former. :) Hatayama-san is certainly at liberty to solve the
> issue either way.

I think that we should push people who write firmware which do not
conform UEFI spec. Otherwise they will not care more and more and we
will have more and more problems (not only related to network stack).

Daniel