Re: [edk2] [grub PATCH] efinet: disable MNP background polling
14.10.2015 09:15, Ye, Ting пишет: May I know the details what problems it causes in some cases? One is being discussed in this thread: http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00013.html http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00068.html Another was reported recently: http://lists.gnu.org/archive/html/help-grub/2015-09/msg00033.html http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00071.html Thanks, Ye Ting -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Wednesday, October 14, 2015 1:58 PM To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-devel@gnu.org Cc: konrad.w...@oracle.com; edk2-devel-01; g...@suse.com; seth.goldb...@oracle.com; Mark Salter Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling 14.10.2015 08:19, Ye, Ting пишет: Hi all, If I understand the issue correctly, I don't quite agree that UEFI spec is imprecise about SNP constraints described as following. The "constraint" described here is that the grub should use attribute "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage is clearly described in page 184, chapter 6.3 EFI_BOOT_SERVICES.OpenProtocol(). EXCLUSIVE Used by applications to gain exclusive access to a protocol interface. If any drivers have the protocol interface opened with an attribute of BY_DRIVER, then an attempt will be made to remove them by calling the driver's Stop() function. The grub code should not assume that the SNP is not occupied by other drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to be more precise, use OpenProtocolInformation() to check whether SNP is already opened by other driver, then decide whether need to use EXCLUSIVE to disconnect the other drivers. This is the typical usage for all UEFI protocol, not particular constraints to SNP protocol. That is exactly what grub currently does - it opens SNP exclusively. Apparently it is causing problems in some cases. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [grub PATCH] efinet: disable MNP background polling
14.10.2015 04:01, Yinghai Lu пишет: On Tue, Oct 13, 2015 at 3:11 PM, Daniel Kiper wrote: On Thu, Oct 01, 2015 at 08:53:44PM +0300, Andrei Borzenkov wrote: Hatayama-san, would you consider implementing MNP-based driver for GRUB? Having at least proof of concept available for testing would be good. Are we sure that we want to migrate to MNP? As I saw others (e.g. PXELINUX, iPXE) use SNP and it work for them. If yes then I can post my unfinished rebase work for Solaris GRUB2 MNP patches. I did that for our internal needs, however, I did not finish it because usptream GRUB2 solved our problems. Well, patches are very raw, based on very old GRUB2 (Apr 2012) and do not build. However, maybe they could be a good starting point for further work. I ported that on top of grub2 upstream this January. It is based on upstream of 2015-01-28. so need to revert 4fe8e6d f348aee c52ae40 49426e9 cf2b4a3 from current upstream. Do you also observe problems with current upstream? We (x86 system group) have used it internally for a while. It solved all the uefi pxe booting problems that we met with grub2, like 1g intel supper slow, or 10g intel does not even start. Thanks Yinghai ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
RE: [edk2] [grub PATCH] efinet: disable MNP background polling
Hi all, If I understand the issue correctly, I don't quite agree that UEFI spec is imprecise about SNP constraints described as following. The "constraint" described here is that the grub should use attribute "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage is clearly described in page 184, chapter 6.3 EFI_BOOT_SERVICES.OpenProtocol(). EXCLUSIVE Used by applications to gain exclusive access to a protocol interface. If any drivers have the protocol interface opened with an attribute of BY_DRIVER, then an attempt will be made to remove them by calling the driver's Stop() function. The grub code should not assume that the SNP is not occupied by other drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to be more precise, use OpenProtocolInformation() to check whether SNP is already opened by other driver, then decide whether need to use EXCLUSIVE to disconnect the other drivers. This is the typical usage for all UEFI protocol, not particular constraints to SNP protocol. > 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 :) Best Regards, Ye Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek Sent: Wednesday, October 14, 2015 6:21 AM To: daniel.ki...@oracle.com; grub-devel@gnu.org Cc: konrad.w...@oracle.com; arvidj...@gmail.com; edk2-devel-01; g...@suse.com; seth.goldb...@oracle.com; Mark Salter Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling On 10/13/15 23:49, Daniel Kiper wrote: > Hi Laszlo, > > First of all, thanks a lot for very nice explanation! > > On Thu, Oct 01, 2015 at 01:50:31PM +0200, Laszlo Ersek wrote: >> CC'ing Mark Salter, and edk2-devel, also updating the subject slightly >> for better context. >> >> On 10/01/15 11:26, HATAYAMA Daisuke wrote: >>> Currently, as of the commit f348aee7b33dd85e7da62b497a96a7319a0bf9dd, >>> SNP is exclusively reopened to avoid slowdown or complete failure to >>> load files due to races between MNP background polling and grub's >>> receiving and transmitting packets. >>> >>> This exclusive SNP reopen affects some EFI applications/drivers that >>> use SNP and causes PXE boot on such systems to fail. Hardware filter >>> issue fixed by the commit 49426e9fd2e562c73a4f1206f32eff9e424a1a73 is >>> one example. >> >> I think the above two commit references are in inverse order. That is, >> commit 49426e9f is the one responsible for the (needed) exclusive open, >> and commit f348aee7 fixes up the former by reconfiguring the receive >> filters. >> >> In other words, the first two paragraphs here seem accurate, just please >> reorder the commit hashes. >> >>> The difficulty here is that effects of the exclusive SNP reopen >>> differs from system to system depending their UEFI firmware >>> implementations. One system works well with the commit >>> f348aee7b33dd85e7da62b497a96a7319a0bf9dd only, another system still >>> needs the commit 49426e9fd2e562c73a4f1206f32eff9e424a1a73, and there >>> could be other systems where PXE boot still fails. >> >> Here too I think the commit hashes should be switched around. >> >>> >>> Actually, PXE boot fails on Fujitsu PRIMEQUEST 2000 series now. >>> >>> Thus, it seems to me that the exclusive SNP reopen makes grub >>> maintenance difficult by affecting a variety of systems differently. >> >> (Admittedly, this is going to be a bit of speculation:) I think the >> difference in behavior is not due to SNP implementations, but due to >> differences in higher level protocol implementations -- i.e., the >> behavior depends on what those drivers do to the underlying SNP that are >> *closed*. >> >> According to the spec of OpenProtocol(), in case of a successful >> exclusive open, the other BY_DRIVER reference is kicked off with >> DisconnectController(), which in turn calls the other driver's >> EFI_DRIVER_BINDING_PROTOCOL.Stop() function. >> >> So, the question is what that *other* (higher level) driver does in its >> Stop() function, when it unbinds the handle with the underlying SNP >> interface. Does it mess with SNP's receive filters? And so on. >> >>> >>> Instead, the idea of this patch is
RE: [edk2] [grub PATCH] efinet: disable MNP background polling
May I know the details what problems it causes in some cases? Thanks, Ye Ting -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Wednesday, October 14, 2015 1:58 PM To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-devel@gnu.org Cc: konrad.w...@oracle.com; edk2-devel-01; g...@suse.com; seth.goldb...@oracle.com; Mark Salter Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling 14.10.2015 08:19, Ye, Ting пишет: > Hi all, > > If I understand the issue correctly, I don't quite agree that UEFI spec is > imprecise about SNP constraints described as following. > The "constraint" described here is that the grub should use attribute > "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage is > clearly described in page 184, chapter 6.3 EFI_BOOT_SERVICES.OpenProtocol(). > > EXCLUSIVE Used by applications to gain exclusive access to a > protocol interface. > If any drivers have the protocol interface opened with > an attribute of BY_DRIVER, > then an attempt will be made to remove them by calling > the driver's Stop() function. > > The grub code should not assume that the SNP is not occupied by other > drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to be more > precise, use OpenProtocolInformation() to check whether SNP is already opened > by other driver, then decide whether need to use EXCLUSIVE to disconnect the > other drivers. This is the typical usage for all UEFI protocol, not > particular constraints to SNP protocol. > That is exactly what grub currently does - it opens SNP exclusively. Apparently it is causing problems in some cases. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
RE: [edk2] [grub PATCH] efinet: disable MNP background polling
Could you please describe the details how does GRUB use UEFI network protocols? I see the thread says that EXCLUSIVE open SNP causes PXE boot fail. If you read below description about 'EXCLUSIVE' in UEFI specification, you will find when GRUB exclusive opens SNP protocol, the UEFI will remove any drivers that opened SNP with BY_DRIVER by calling the driver's Stop() function. In UEFI network stack, MNP driver will open SNP 'BY_DRIVER'. So if GRUB/iPXE exclusive opens SNP, MNP will uninstall itself and the whole UEFI network stack is disconnected except SNP and UNDI. Hence, the UEFI PXE no longer work. >> EXCLUSIVEUsed by applications to gain exclusive access to a >> protocol interface. >> If any drivers have the protocol interface opened with >> an attribute of BY_DRIVER, >> then an attempt will be made to remove them by calling >> the driver's Stop() function. If GRUB would like to call SNP protocol only, it should use EXCLUSIVE open to gain the exclusive access and disconnect UEFI network stack since MNP. Then the MNP background polling is also disabled. If GRUB still needs UEFI PXE capability, it should utilize PXE base code protocol to continue the process, rather than calling SNP, as SNP is already consumed by UEFI network stack. Thanks, Ye Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrei Borzenkov Sent: Wednesday, October 14, 2015 2:58 PM To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-devel@gnu.org Cc: edk2-devel-01; Mark Salter; g...@suse.com; seth.goldb...@oracle.com; konrad.w...@oracle.com Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling 14.10.2015 09:15, Ye, Ting пишет: > May I know the details what problems it causes in some cases? > One is being discussed in this thread: http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00013.html http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00068.html Another was reported recently: http://lists.gnu.org/archive/html/help-grub/2015-09/msg00033.html http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00071.html > Thanks, > Ye Ting > > -Original Message- > From: Andrei Borzenkov [mailto:arvidj...@gmail.com] > Sent: Wednesday, October 14, 2015 1:58 PM > To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-devel@gnu.org > Cc: konrad.w...@oracle.com; edk2-devel-01; g...@suse.com; > seth.goldb...@oracle.com; Mark Salter > Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling > > 14.10.2015 08:19, Ye, Ting пишет: >> Hi all, >> >> If I understand the issue correctly, I don't quite agree that UEFI spec is >> imprecise about SNP constraints described as following. >> The "constraint" described here is that the grub should use attribute >> "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage is >> clearly described in page 184, chapter 6.3 EFI_BOOT_SERVICES.OpenProtocol(). >> >> EXCLUSIVEUsed by applications to gain exclusive access to a >> protocol interface. >> If any drivers have the protocol interface opened with >> an attribute of BY_DRIVER, >> then an attempt will be made to remove them by calling >> the driver's Stop() function. >> >> The grub code should not assume that the SNP is not occupied by other >> drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to be >> more precise, use OpenProtocolInformation() to check whether SNP is already >> opened by other driver, then decide whether need to use EXCLUSIVE to >> disconnect the other drivers. This is the typical usage for all UEFI >> protocol, not particular constraints to SNP protocol. >> > > That is exactly what grub currently does - it opens SNP exclusively. > Apparently it is causing problems in some cases. > ___ edk2-devel mailing list edk2-de...@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [edk2] [grub PATCH] efinet: disable MNP background polling
On Wed, Oct 14, 2015 at 05:19:32AM +, Ye, Ting wrote: > Hi all, > > If I understand the issue correctly, I don't quite agree that UEFI > spec is imprecise about SNP constraints described as following. > The "constraint" described here is that the grub should use attribute > "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage > is clearly described in page 184, chapter 6.3 > EFI_BOOT_SERVICES.OpenProtocol(). > > EXCLUSIVE Used by applications to gain exclusive access to a > protocol interface. > If any drivers have the protocol interface opened with > an attribute of BY_DRIVER, > then an attempt will be made to remove them by calling > the driver's Stop() function. > > The grub code should not assume that the SNP is not occupied by other > drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to > be more precise, use OpenProtocolInformation() to check whether SNP is > already opened by other driver, then decide whether need to use EXCLUSIVE > to disconnect the other drivers. This is the typical usage for all UEFI > protocol, not particular constraints to SNP protocol. Looks good! Great! However, it looks that we still have a problem if somebody opens SNP in EXCLUSIVE mode. Then GRUB2 SNP open will fail according to UEFI spec. Sadly we do not have a control on other stuff and one day our approach may fail because somebody decided to open SNP in EXCLUSIVE mode in e.g. a driver. Does it mean that migration to MNP is one sensible solution for our problems? As I know this is huge overhaul, so, we should think twice before choosing that way. Daniel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Ensure that MIPS target code is compiled for the O32 ABI.
Le 14 oct. 2015 6:50 AM, "Andrei Borzenkov" a écrit : > > 10.10.2015 03:28, Vladimir 'φ-coder/phcoder' Serbinenko пишет: > >> On 09.10.2015 23:14, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >>> >>> On 13.09.2015 08:32, Andrei Borzenkov wrote: 08.09.2015 20:11, Vladimir 'φ-coder/phcoder' Serbinenko пишет: > > On 23.08.2015 23:50, Mark H Weaver wrote: >> >> Include -mabi=32 in CFLAGS_PLATFORM and CCASFLAGS_PLATFORM to compile >> code for the O32 ABI when targetting MIPS, since the MIPS assembly code >> in GRUB assumes this. > > Could you be more precise where we assume this? Why not fix the assembly > instead? If I understand it correctly, this is not only about assembly - ABIs differ in sizes of types as well, >>> >>> Only in obscure types long double and uint128_t. We use neither. >> >> Correction: I was comparing o32 to n32. We still need to ensure that >> either o32 or n32 is used. It's easier to just ensure that o32 is used, >> so that we have less variability in the code but can be relaxed later if >> need be. > > > I see that you committed my suggested patch but I find comments (and commit message) a bit misleading. While grub main code is fixed, the configure asm test not, and that was the first thing that failed. > Can you please elaborate on how am test fails? The only failure I have seen was due to usage of $t4 and I replaced it with $t0 >>>f) int grub_setjmp (grub_jmp_buf env) // grub_jmp_buf is an array, so >>> pointer >>>g) int grub_longjmp (grub_jmp_buf env, int val) >> >> Correction: setjmp/longjmp are not adapted to n32 but we don't use them >> anyway. Probably it's time to delete the dead code after double checking >> that extras don't use it either. >> >> >> >> >> ___ >> Grub-devel mailing list >> Grub-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/grub-devel >> > > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [edk2] [grub PATCH] efinet: disable MNP background polling
> On Oct 14, 2015, at 4:08 AM, Daniel Kiper wrote: > >> On Wed, Oct 14, 2015 at 05:19:32AM +, Ye, Ting wrote: >> Hi all, >> >> If I understand the issue correctly, I don't quite agree that UEFI >> spec is imprecise about SNP constraints described as following. >> The "constraint" described here is that the grub should use attribute >> "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage >> is clearly described in page 184, chapter 6.3 >> EFI_BOOT_SERVICES.OpenProtocol(). >> >> EXCLUSIVEUsed by applications to gain exclusive access to a protocol >> interface. >>If any drivers have the protocol interface opened with an >> attribute of BY_DRIVER, >>then an attempt will be made to remove them by calling the >> driver's Stop() function. >> >> The grub code should not assume that the SNP is not occupied by other >> drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to >> be more precise, use OpenProtocolInformation() to check whether SNP is >> already opened by other driver, then decide whether need to use EXCLUSIVE >> to disconnect the other drivers. This is the typical usage for all UEFI >> protocol, not particular constraints to SNP protocol. > > Looks good! Great! However, it looks that we still have a problem if somebody > opens SNP in EXCLUSIVE mode. Then GRUB2 SNP open will fail according to UEFI > spec. > Sadly we do not have a control on other stuff and one day our approach may > fail > because somebody decided to open SNP in EXCLUSIVE mode in e.g. a driver. Does > it mean that migration to MNP is one sensible solution for our problems? As I > know > this is huge overhaul, so, we should think twice before choosing that way. Then it is fortunate that when I wrote the MNP implementation that we ship with Oracle Solaris 11.2, that I tested it on many thousands of systems as well as on new UEFI implementations at the UEFI Plugfest ;). --S > > Daniel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [edk2] [grub PATCH] efinet: disable MNP background polling
14.10.2015 11:00, Ye, Ting пишет: Could you please describe the details how does GRUB use UEFI network protocols? When efinet driver is loaded it enumerates handles with SNP; these handles represent network cards for grub. If driver is part of initial core.img (default for network boot image) it additionally queries loaded image handle for PXE for DhcpAck using EFI_PXE_BASE_CODE_PROTOCOL and is using it for autoconfiguration. Before the first send/receive request on network card SNP on associated handle is opened exclusively and SNP Transmit/Receive are used. I see the thread says that EXCLUSIVE open SNP causes PXE boot fail. If you read below description about 'EXCLUSIVE' in UEFI specification, you will find when GRUB exclusive opens SNP protocol, the UEFI will remove any drivers that opened SNP with BY_DRIVER by calling the driver's Stop() function. In UEFI network stack, MNP driver will open SNP 'BY_DRIVER'. So if GRUB/iPXE exclusive opens SNP, MNP will uninstall itself and the whole UEFI network stack is disconnected except SNP and UNDI. Hence, the UEFI PXE no longer work. EXCLUSIVE Used by applications to gain exclusive access to a protocol interface. If any drivers have the protocol interface opened with an attribute of BY_DRIVER, then an attempt will be made to remove them by calling the driver's Stop() function. If GRUB would like to call SNP protocol only, it should use EXCLUSIVE open to gain the exclusive access and disconnect UEFI network stack since MNP. Then the MNP background polling is also disabled. It does it already. If GRUB still needs UEFI PXE capability, it should utilize PXE base code protocol to continue the process, rather than calling SNP, as SNP is already consumed by UEFI network stack. It does not use PXE after initial autoconfiguration as described above nor does it need it. All data transmission is performed using SNP only. Thanks, Ye Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrei Borzenkov Sent: Wednesday, October 14, 2015 2:58 PM To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-devel@gnu.org Cc: edk2-devel-01; Mark Salter; g...@suse.com; seth.goldb...@oracle.com; konrad.w...@oracle.com Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling 14.10.2015 09:15, Ye, Ting пишет: May I know the details what problems it causes in some cases? One is being discussed in this thread: http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00013.html http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00068.html Another was reported recently: http://lists.gnu.org/archive/html/help-grub/2015-09/msg00033.html http://lists.gnu.org/archive/html/grub-devel/2015-10/msg00071.html Thanks, Ye Ting -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Wednesday, October 14, 2015 1:58 PM To: Ye, Ting; Laszlo Ersek; daniel.ki...@oracle.com; grub-devel@gnu.org Cc: konrad.w...@oracle.com; edk2-devel-01; g...@suse.com; seth.goldb...@oracle.com; Mark Salter Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling 14.10.2015 08:19, Ye, Ting пишет: Hi all, If I understand the issue correctly, I don't quite agree that UEFI spec is imprecise about SNP constraints described as following. The "constraint" described here is that the grub should use attribute "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage is clearly described in page 184, chapter 6.3 EFI_BOOT_SERVICES.OpenProtocol(). EXCLUSIVE Used by applications to gain exclusive access to a protocol interface. If any drivers have the protocol interface opened with an attribute of BY_DRIVER, then an attempt will be made to remove them by calling the driver's Stop() function. The grub code should not assume that the SNP is not occupied by other drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to be more precise, use OpenProtocolInformation() to check whether SNP is already opened by other driver, then decide whether need to use EXCLUSIVE to disconnect the other drivers. This is the typical usage for all UEFI protocol, not particular constraints to SNP protocol. That is exactly what grub currently does - it opens SNP exclusively. Apparently it is causing problems in some cases. ___ edk2-devel mailing list edk2-de...@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH v2] Ensure that MIPS target code is compiled for the O32 ABI.
14.10.2015 15:16, Vladimir 'phcoder' Serbinenko пишет: Le 14 oct. 2015 6:50 AM, "Andrei Borzenkov" a écrit : 10.10.2015 03:28, Vladimir 'φ-coder/phcoder' Serbinenko пишет: On 09.10.2015 23:14, Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 13.09.2015 08:32, Andrei Borzenkov wrote: 08.09.2015 20:11, Vladimir 'φ-coder/phcoder' Serbinenko пишет: On 23.08.2015 23:50, Mark H Weaver wrote: Include -mabi=32 in CFLAGS_PLATFORM and CCASFLAGS_PLATFORM to compile code for the O32 ABI when targetting MIPS, since the MIPS assembly code in GRUB assumes this. Could you be more precise where we assume this? Why not fix the assembly instead? If I understand it correctly, this is not only about assembly - ABIs differ in sizes of types as well, Only in obscure types long double and uint128_t. We use neither. Correction: I was comparing o32 to n32. We still need to ensure that either o32 or n32 is used. It's easier to just ensure that o32 is used, so that we have less variability in the code but can be relaxed later if need be. I see that you committed my suggested patch but I find comments (and commit message) a bit misleading. While grub main code is fixed, the configure asm test not, and that was the first thing that failed. Can you please elaborate on how am test fails? The only failure I have seen was due to usage of $t4 and I replaced it with $t0 Sorry, missed patch for asm-tests/mips.S f) int grub_setjmp (grub_jmp_buf env) // grub_jmp_buf is an array, so pointer g) int grub_longjmp (grub_jmp_buf env, int val) Correction: setjmp/longjmp are not adapted to n32 but we don't use them anyway. Probably it's time to delete the dead code after double checking that extras don't use it either. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: iPXE efi chainloading grub2 pxe efi file
14.10.2015 19:56, Rivard, Matthew T пишет: Sorry, I thought I had replied back to this. I found a work around by calling net_bootp on the adapters (I wrote a manual block of 64 potential devices given that that's not an unrealistic number of adapter ports to be found in a server in our lab), and setting a bootp range on our DHCP server for that purpose. Since there's no command in grub to simply tell it to do a standard DHCP on the adapters, Huh? net_bootp does standard DHCP on adapters (do not be confused by name). What do you mean by this? this has been the only feasible workaround to make them play together nicely. Ironically, executing the chainload from iPXE via embedded script vs their shell has solved the issue with it hanging if multiple adapters have IP addresses in grub when loading off to a Linux Kernel. -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Tuesday, October 13, 2015 11:14 PM To: Rivard, Matthew T; The development of GNU GRUB; ipxe-de...@lists.ipxe.org; edk2-devel-01 Subject: Re: iPXE efi chainloading grub2 pxe efi file [Redirecting to grub-devel where similar problem is being discussed right now and trying iPXE/EDK2 as well] 18.09.2015 22:59, Rivard, Matthew T пишет: Thanks, its loading the menu now, however, I appear to be hitting the same problem I was going from grub to ipxe. The adapters are there, but won't autoconfigure, Exclusive SNP open used by iPXE quite likely tears down PXE information, so GRUB has nothing to autoconfigure card from. and if I try to manually set an IP address, I see the debugging data start spewing from ipxe (which appears to be still running underneath grub) before the system eventually halts. Well, now we have two *applications* each holding exclusive open on adapter. I do not know details about iPXE but if there is any remote chance it does background polling we are back at square one. Unfortunately I do not really see what we can do in this case (iPXE => GRUB) from GRUB side. Switching GRUB to MNP may fix GRUB => iPXE case though. OTOH I do not know what happens long term. GRUB calls other image (let's say iPXE) passes control to it. Now firmware continues to queue packets for GRUB MNP instance, which GRUB never consumes. Does not really look good either. In principle the same is true for GRUB pure if it is left sitting in menu/CLI for a long time. And for every other active MNP instance. I'll try your rollback, but was it mean to come out in the email as a long hash string? Did you have chance to test it? -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Thursday, September 17, 2015 8:52 PM To: Rivard, Matthew T; help-g...@gnu.org Subject: Re: iPXE efi chainloading grub2 pxe efi file 18.09.2015 03:05, Rivard, Matthew T пишет: I've got a good working EFI Grub2 efi Bootloader that works fine when its directly handed off to by the DHCP for PXE, however, if I attempt to chainload it from iPXE snponly.efi, it goes straight to the grub command prompt. I've tried embedding the grub.cfg file via -c on the grub-mkimage command, but it spews out the grub file as a stream of "command not found prompts" and then still goes to the grub command line. Embedded config is processed very early, before normal.mod is loaded, so only commands available at rescue prompts are present. If I try embedding all of the modules directly into grub.efi during mkimage, along with the config file, it then throws a grub_divmod64_full not found error. Embedding all modules in grub.efi is usually wrong (not all modules can be loaded concurrently) either. Try creating standalone image with grub-mkstandalone. This image contains all grub modules in memory disk (as cpio archive) and grub is configured with $prefix pointing to this disk. You can also add own files, in particular put grub.cfg in memory disk. What is the ideal way to chain load my grub.efi file from iPXE so that it works the same as if it was the direct handoff from the DHCP/TFTP server? Unfortunately, in order to allow for selecting either our EFI WDS Server or our EFI Linux Server, I have to use iPXE first, as chainloading snponly.efi from grub2 ends up with iPXE snp not being able to enumerate anything from the PCI Bus. Hmm ... this actually sounds like exclusive SNP open (used by both iPXE and GRUB) messes something up. For testing you could try to revert 49426e9fd2e562c73a4f1206f32eff9e424a1a73 (and f348aee7b33dd85e7da62b497a96a7319a0bf9dd which depends on it) to see if it makes any difference. Using git pulls for both that were from yesterday. Matt R. ___ Help-grub mailing list help-g...@gnu.org https://lists.gnu.org/mailman/listinfo/help-grub ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
RE: iPXE efi chainloading grub2 pxe efi file
Just going by these definitions of bootp and dhcp here: https://technet.microsoft.com/en-us/library/cc781243%28v=ws.10%29.aspx The net_bootp only works with a bootp enabled scope on the dhcp server after chaining from iPXE to grub2. Without a "bootp" scope setup on the dhcp, calling net_bootp on the adapter fails to get an IP address. So, I guess I could more clearly word that the bootp protocol works when calling net_bootp, but standard dhcp isn't. -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Wednesday, October 14, 2015 11:04 AM To: Rivard, Matthew T; The development of GNU GRUB Subject: Re: iPXE efi chainloading grub2 pxe efi file 14.10.2015 19:56, Rivard, Matthew T пишет: > Sorry, I thought I had replied back to this. > > I found a work around by calling net_bootp on the adapters (I wrote a manual > block of 64 potential devices given that that's not an unrealistic number of > adapter ports to be found in a server in our lab), and setting a bootp range > on our DHCP server for that purpose. Since there's no command in grub to > simply tell it to do a standard DHCP on the adapters, Huh? net_bootp does standard DHCP on adapters (do not be confused by name). What do you mean by this? > this has been the only feasible workaround to make them play together nicely. > > Ironically, executing the chainload from iPXE via embedded script vs their > shell has solved the issue with it hanging if multiple adapters have IP > addresses in grub when loading off to a Linux Kernel. > > > > -Original Message- > From: Andrei Borzenkov [mailto:arvidj...@gmail.com] > Sent: Tuesday, October 13, 2015 11:14 PM > To: Rivard, Matthew T; The development of GNU GRUB; > ipxe-de...@lists.ipxe.org; edk2-devel-01 > Subject: Re: iPXE efi chainloading grub2 pxe efi file > > [Redirecting to grub-devel where similar problem is being discussed > right now and trying iPXE/EDK2 as well] > > 18.09.2015 22:59, Rivard, Matthew T пишет: >> Thanks, its loading the menu now, however, I appear to be hitting the >> same problem I was going from grub to ipxe. The adapters are there, >> but won't autoconfigure, > > Exclusive SNP open used by iPXE quite likely tears down PXE information, so > GRUB has nothing to autoconfigure card from. > >> and if I try to manually set an IP address, I see the debugging data start >> spewing from ipxe (which appears to be still running underneath grub) before >> the system eventually halts. >> > > Well, now we have two *applications* each holding exclusive open on adapter. > I do not know details about iPXE but if there is any remote chance it does > background polling we are back at square one. > > Unfortunately I do not really see what we can do in this case (iPXE => > GRUB) from GRUB side. Switching GRUB to MNP may fix GRUB => iPXE case though. > OTOH I do not know what happens long term. GRUB calls other image (let's say > iPXE) passes control to it. Now firmware continues to queue packets for GRUB > MNP instance, which GRUB never consumes. Does not really look good either. > > In principle the same is true for GRUB pure if it is left sitting in menu/CLI > for a long time. And for every other active MNP instance. > >> I'll try your rollback, but was it mean to come out in the email as a long >> hash string? >> > > Did you have chance to test it? > >> >> -Original Message- >> From: Andrei Borzenkov [mailto:arvidj...@gmail.com] >> Sent: Thursday, September 17, 2015 8:52 PM >> To: Rivard, Matthew T; help-g...@gnu.org >> Subject: Re: iPXE efi chainloading grub2 pxe efi file >> >> 18.09.2015 03:05, Rivard, Matthew T пишет: >>> I've got a good working EFI Grub2 efi Bootloader that works fine when its >>> directly handed off to by the DHCP for PXE, however, if I attempt to >>> chainload it from iPXE snponly.efi, it goes straight to the grub command >>> prompt. >>> >>> I've tried embedding the grub.cfg file via -c on the grub-mkimage command, >>> but it spews out the grub file as a stream of "command not found prompts" >>> and then still goes to the grub command line. >>> >> >> Embedded config is processed very early, before normal.mod is loaded, so >> only commands available at rescue prompts are present. >> >>> If I try embedding all of the modules directly into grub.efi during >>> mkimage, along with the config file, it then throws a grub_divmod64_full >>> not found error. >>> >> >> Embedding all modules in grub.efi is usually wrong (not all modules can be >> loaded concurrently) either. >> >> Try creating standalone image with grub-mkstandalone. This image contains >> all grub modules in memory disk (as cpio archive) and grub is configured >> with $prefix pointing to this disk. You can also add own files, in >> particular put grub.cfg in memory disk. >> >>> What is the ideal way to chain load my grub.efi file from iPXE so that it >>> works the same as if it was the direct handoff from the DHCP/TFTP server? >>> >
RE: iPXE efi chainloading grub2 pxe efi file
Sorry, I thought I had replied back to this. I found a work around by calling net_bootp on the adapters (I wrote a manual block of 64 potential devices given that that's not an unrealistic number of adapter ports to be found in a server in our lab), and setting a bootp range on our DHCP server for that purpose. Since there's no command in grub to simply tell it to do a standard DHCP on the adapters, this has been the only feasible workaround to make them play together nicely. Ironically, executing the chainload from iPXE via embedded script vs their shell has solved the issue with it hanging if multiple adapters have IP addresses in grub when loading off to a Linux Kernel. -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Tuesday, October 13, 2015 11:14 PM To: Rivard, Matthew T; The development of GNU GRUB; ipxe-de...@lists.ipxe.org; edk2-devel-01 Subject: Re: iPXE efi chainloading grub2 pxe efi file [Redirecting to grub-devel where similar problem is being discussed right now and trying iPXE/EDK2 as well] 18.09.2015 22:59, Rivard, Matthew T пишет: > Thanks, its loading the menu now, however, I appear to be hitting the > same problem I was going from grub to ipxe. The adapters are there, > but won't autoconfigure, Exclusive SNP open used by iPXE quite likely tears down PXE information, so GRUB has nothing to autoconfigure card from. > and if I try to manually set an IP address, I see the debugging data start > spewing from ipxe (which appears to be still running underneath grub) before > the system eventually halts. > Well, now we have two *applications* each holding exclusive open on adapter. I do not know details about iPXE but if there is any remote chance it does background polling we are back at square one. Unfortunately I do not really see what we can do in this case (iPXE => GRUB) from GRUB side. Switching GRUB to MNP may fix GRUB => iPXE case though. OTOH I do not know what happens long term. GRUB calls other image (let's say iPXE) passes control to it. Now firmware continues to queue packets for GRUB MNP instance, which GRUB never consumes. Does not really look good either. In principle the same is true for GRUB pure if it is left sitting in menu/CLI for a long time. And for every other active MNP instance. > I'll try your rollback, but was it mean to come out in the email as a long > hash string? > Did you have chance to test it? > > -Original Message- > From: Andrei Borzenkov [mailto:arvidj...@gmail.com] > Sent: Thursday, September 17, 2015 8:52 PM > To: Rivard, Matthew T; help-g...@gnu.org > Subject: Re: iPXE efi chainloading grub2 pxe efi file > > 18.09.2015 03:05, Rivard, Matthew T пишет: >> I've got a good working EFI Grub2 efi Bootloader that works fine when its >> directly handed off to by the DHCP for PXE, however, if I attempt to >> chainload it from iPXE snponly.efi, it goes straight to the grub command >> prompt. >> >> I've tried embedding the grub.cfg file via -c on the grub-mkimage command, >> but it spews out the grub file as a stream of "command not found prompts" >> and then still goes to the grub command line. >> > > Embedded config is processed very early, before normal.mod is loaded, so only > commands available at rescue prompts are present. > >> If I try embedding all of the modules directly into grub.efi during mkimage, >> along with the config file, it then throws a grub_divmod64_full not found >> error. >> > > Embedding all modules in grub.efi is usually wrong (not all modules can be > loaded concurrently) either. > > Try creating standalone image with grub-mkstandalone. This image contains all > grub modules in memory disk (as cpio archive) and grub is configured with > $prefix pointing to this disk. You can also add own files, in particular put > grub.cfg in memory disk. > >> What is the ideal way to chain load my grub.efi file from iPXE so that it >> works the same as if it was the direct handoff from the DHCP/TFTP server? >> >> Unfortunately, in order to allow for selecting either our EFI WDS Server or >> our EFI Linux Server, I have to use iPXE first, as chainloading snponly.efi >> from grub2 ends up with iPXE snp not being able to enumerate anything from >> the PCI Bus. >> > > Hmm ... this actually sounds like exclusive SNP open (used by both > iPXE and GRUB) messes something up. For testing you could try to > revert > 49426e9fd2e562c73a4f1206f32eff9e424a1a73 (and > f348aee7b33dd85e7da62b497a96a7319a0bf9dd which depends on it) to see if it > makes any difference. > >> Using git pulls for both that were from yesterday. >> >> Matt R. >> >> >> >> >> ___ >> Help-grub mailing list >> help-g...@gnu.org >> https://lists.gnu.org/mailman/listinfo/help-grub >> > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: iPXE efi chainloading grub2 pxe efi file
14.10.2015 21:09, Rivard, Matthew T пишет: Just going by these definitions of bootp and dhcp here: https://technet.microsoft.com/en-us/library/cc781243%28v=ws.10%29.aspx The net_bootp only works with a bootp enabled scope on the dhcp server after chaining from iPXE to grub2. Without a "bootp" scope setup on the dhcp, calling net_bootp on the adapter fails to get an IP address. What is "bootp enabled scope"? Do you refer to Windows DHCP server? Could you give link to manual that describes this setting? So, I guess I could more clearly word that the bootp protocol works when calling net_bootp, but standard dhcp isn't. Could you make available network traces from both working and non-workign attempts? -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Wednesday, October 14, 2015 11:04 AM To: Rivard, Matthew T; The development of GNU GRUB Subject: Re: iPXE efi chainloading grub2 pxe efi file 14.10.2015 19:56, Rivard, Matthew T пишет: Sorry, I thought I had replied back to this. I found a work around by calling net_bootp on the adapters (I wrote a manual block of 64 potential devices given that that's not an unrealistic number of adapter ports to be found in a server in our lab), and setting a bootp range on our DHCP server for that purpose. Since there's no command in grub to simply tell it to do a standard DHCP on the adapters, Huh? net_bootp does standard DHCP on adapters (do not be confused by name). What do you mean by this? this has been the only feasible workaround to make them play together nicely. Ironically, executing the chainload from iPXE via embedded script vs their shell has solved the issue with it hanging if multiple adapters have IP addresses in grub when loading off to a Linux Kernel. -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Tuesday, October 13, 2015 11:14 PM To: Rivard, Matthew T; The development of GNU GRUB; ipxe-de...@lists.ipxe.org; edk2-devel-01 Subject: Re: iPXE efi chainloading grub2 pxe efi file [Redirecting to grub-devel where similar problem is being discussed right now and trying iPXE/EDK2 as well] 18.09.2015 22:59, Rivard, Matthew T пишет: Thanks, its loading the menu now, however, I appear to be hitting the same problem I was going from grub to ipxe. The adapters are there, but won't autoconfigure, Exclusive SNP open used by iPXE quite likely tears down PXE information, so GRUB has nothing to autoconfigure card from. and if I try to manually set an IP address, I see the debugging data start spewing from ipxe (which appears to be still running underneath grub) before the system eventually halts. Well, now we have two *applications* each holding exclusive open on adapter. I do not know details about iPXE but if there is any remote chance it does background polling we are back at square one. Unfortunately I do not really see what we can do in this case (iPXE => GRUB) from GRUB side. Switching GRUB to MNP may fix GRUB => iPXE case though. OTOH I do not know what happens long term. GRUB calls other image (let's say iPXE) passes control to it. Now firmware continues to queue packets for GRUB MNP instance, which GRUB never consumes. Does not really look good either. In principle the same is true for GRUB pure if it is left sitting in menu/CLI for a long time. And for every other active MNP instance. I'll try your rollback, but was it mean to come out in the email as a long hash string? Did you have chance to test it? -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Thursday, September 17, 2015 8:52 PM To: Rivard, Matthew T; help-g...@gnu.org Subject: Re: iPXE efi chainloading grub2 pxe efi file 18.09.2015 03:05, Rivard, Matthew T пишет: I've got a good working EFI Grub2 efi Bootloader that works fine when its directly handed off to by the DHCP for PXE, however, if I attempt to chainload it from iPXE snponly.efi, it goes straight to the grub command prompt. I've tried embedding the grub.cfg file via -c on the grub-mkimage command, but it spews out the grub file as a stream of "command not found prompts" and then still goes to the grub command line. Embedded config is processed very early, before normal.mod is loaded, so only commands available at rescue prompts are present. If I try embedding all of the modules directly into grub.efi during mkimage, along with the config file, it then throws a grub_divmod64_full not found error. Embedding all modules in grub.efi is usually wrong (not all modules can be loaded concurrently) either. Try creating standalone image with grub-mkstandalone. This image contains all grub modules in memory disk (as cpio archive) and grub is configured with $prefix pointing to this disk. You can also add own files, in particular put grub.cfg in memory disk. What is the ideal way to chain load my grub.efi file from iPXE so that it works the same as if it wa
Re: iPXE efi chainloading grub2 pxe efi file
14.10.2015 21:09, Rivard, Matthew T пишет: Just going by these definitions of bootp and dhcp here: https://technet.microsoft.com/en-us/library/cc781243%28v=ws.10%29.aspx The net_bootp only works with a bootp enabled scope on the dhcp server after chaining from iPXE to grub2. Without a "bootp" scope setup on the dhcp, calling net_bootp on the adapter fails to get an IP address. So, I guess I could more clearly word that the bootp protocol works when calling net_bootp, but standard dhcp isn't. Hmm ... you are right; we are actually doing BOOTP here, not DHCP. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
RE: iPXE efi chainloading grub2 pxe efi file
ISC DHCPD, specifically, v4.1.1 running on RHEL6.6x64 The code block needed is adding to the top of the config file: "allow bootp;" Then in the subnet (I call them scopes since I have a wide variety of different dhcps setup in our lab and there's more windows units than linux), A bootp specific range needed to be added: range dynamic-bootp 10.0.100.1 10.0.100.254; Without these two lines, grub won't get a DHCP address after being chainloaded by ipxe when you perform net_bootp efinetX (X represents the adapter number, e.g efinet0, efinet1, etc). -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Wednesday, October 14, 2015 11:24 AM To: Rivard, Matthew T; The development of GNU GRUB Subject: Re: iPXE efi chainloading grub2 pxe efi file 14.10.2015 21:09, Rivard, Matthew T пишет: > Just going by these definitions of bootp and dhcp here: > https://technet.microsoft.com/en-us/library/cc781243%28v=ws.10%29.aspx > > The net_bootp only works with a bootp enabled scope on the dhcp server after > chaining from iPXE to grub2. Without a "bootp" scope setup on the dhcp, > calling net_bootp on the adapter fails to get an IP address. > What is "bootp enabled scope"? Do you refer to Windows DHCP server? Could you give link to manual that describes this setting? > So, I guess I could more clearly word that the bootp protocol works when > calling net_bootp, but standard dhcp isn't. > Could you make available network traces from both working and non-workign attempts? > > -Original Message- > From: Andrei Borzenkov [mailto:arvidj...@gmail.com] > Sent: Wednesday, October 14, 2015 11:04 AM > To: Rivard, Matthew T; The development of GNU GRUB > Subject: Re: iPXE efi chainloading grub2 pxe efi file > > 14.10.2015 19:56, Rivard, Matthew T пишет: >> Sorry, I thought I had replied back to this. >> >> I found a work around by calling net_bootp on the adapters (I wrote a manual >> block of 64 potential devices given that that's not an unrealistic number of >> adapter ports to be found in a server in our lab), and setting a bootp range >> on our DHCP server for that purpose. Since there's no command in grub to >> simply tell it to do a standard DHCP on the adapters, > > Huh? net_bootp does standard DHCP on adapters (do not be confused by name). > What do you mean by this? > >> this has been the only feasible workaround to make them play together nicely. >> >> Ironically, executing the chainload from iPXE via embedded script vs their >> shell has solved the issue with it hanging if multiple adapters have IP >> addresses in grub when loading off to a Linux Kernel. >> >> >> >> -Original Message- >> From: Andrei Borzenkov [mailto:arvidj...@gmail.com] >> Sent: Tuesday, October 13, 2015 11:14 PM >> To: Rivard, Matthew T; The development of GNU GRUB; >> ipxe-de...@lists.ipxe.org; edk2-devel-01 >> Subject: Re: iPXE efi chainloading grub2 pxe efi file >> >> [Redirecting to grub-devel where similar problem is being discussed >> right now and trying iPXE/EDK2 as well] >> >> 18.09.2015 22:59, Rivard, Matthew T пишет: >>> Thanks, its loading the menu now, however, I appear to be hitting >>> the same problem I was going from grub to ipxe. The adapters are >>> there, but won't autoconfigure, >> >> Exclusive SNP open used by iPXE quite likely tears down PXE information, so >> GRUB has nothing to autoconfigure card from. >> >>> and if I try to manually set an IP address, I see the debugging data start >>> spewing from ipxe (which appears to be still running underneath grub) >>> before the system eventually halts. >>> >> >> Well, now we have two *applications* each holding exclusive open on adapter. >> I do not know details about iPXE but if there is any remote chance it does >> background polling we are back at square one. >> >> Unfortunately I do not really see what we can do in this case (iPXE >> => >> GRUB) from GRUB side. Switching GRUB to MNP may fix GRUB => iPXE case >> though. OTOH I do not know what happens long term. GRUB calls other image >> (let's say iPXE) passes control to it. Now firmware continues to queue >> packets for GRUB MNP instance, which GRUB never consumes. Does not really >> look good either. >> >> In principle the same is true for GRUB pure if it is left sitting in >> menu/CLI for a long time. And for every other active MNP instance. >> >>> I'll try your rollback, but was it mean to come out in the email as a long >>> hash string? >>> >> >> Did you have chance to test it? >> >>> >>> -Original Message- >>> From: Andrei Borzenkov [mailto:arvidj...@gmail.com] >>> Sent: Thursday, September 17, 2015 8:52 PM >>> To: Rivard, Matthew T; help-g...@gnu.org >>> Subject: Re: iPXE efi chainloading grub2 pxe efi file >>> >>> 18.09.2015 03:05, Rivard, Matthew T пишет: I've got a good working EFI Grub2 efi Bootloader that works fine when its directly handed off to by the DHCP for PXE, however, if I attempt to chai
RE: [edk2] [grub PATCH] efinet: disable MNP background polling
So the current problem is: GRUB wants to EXCLUSIVE open SNP, though if other application/driver already opens SNP with EXCLUSIVE attribute, the GRUB would fail. According to UEFI spec V2.5 page 182, If Attributes is BY_DRIVER , BY_DRIVER|EXCLUSIVE, or EXCLUSIVE, and there are any items on the open list of the protocol interface with an attribute of EXCLUSIVE or BY_DRIVER|EXCLUSIVE, then EFI_ACCESS_DENIED is returned. My question is: who will EXCLUSIVE open SNP before GRUB? Why it EXCLUSIVE opens SNP and NOT close SNP protocol before handover to GRUB? For information, the MNP driver in UEFI network stack will open SNP with attribute 'BY_DRIVER', without EXCLUSIVE. In my opinion, if it is a bug in other stuff GRUB can't handle, and GRUB needs to EXCLUSIVE open SNP, one alternative is the GRUG uses OpenProtocolInformation() to retrieve the list of agents that currently EXCLUSIVE opened SNP, then calls CloseProtocol() to close the opened protocol. If it is the case that GRUB and 'other stuff' both need the network operation and would like to keep EXCLUSIVE open SNP by intention, a MNP solution should be involved since SNP can't support multiple access to use the network interface at the same time. Best Regards, Ye Ting -Original Message- From: Seth Goldberg [mailto:seth.goldb...@oracle.com] Sent: Wednesday, October 14, 2015 11:39 PM To: The development of GNU GRUB Cc: Ye, Ting; arvidj...@gmail.com; edk2-devel-01; g...@suse.com; Mark Salter; Laszlo Ersek Subject: Re: [edk2] [grub PATCH] efinet: disable MNP background polling > On Oct 14, 2015, at 4:08 AM, Daniel Kiper wrote: > >> On Wed, Oct 14, 2015 at 05:19:32AM +, Ye, Ting wrote: >> Hi all, >> >> If I understand the issue correctly, I don't quite agree that UEFI >> spec is imprecise about SNP constraints described as following. >> The "constraint" described here is that the grub should use attribute >> "EXCLUSIVE" to open SNP protocol to gain exclusive access. This usage >> is clearly described in page 184, chapter 6.3 >> EFI_BOOT_SERVICES.OpenProtocol(). >> >> EXCLUSIVEUsed by applications to gain exclusive access to a protocol >> interface. >>If any drivers have the protocol interface opened with an >> attribute of BY_DRIVER, >>then an attempt will be made to remove them by calling the >> driver's Stop() function. >> >> The grub code should not assume that the SNP is not occupied by other >> drivers, instead, it should use EXCLUSIVE to open SNP protocol, or to >> be more precise, use OpenProtocolInformation() to check whether SNP is >> already opened by other driver, then decide whether need to use EXCLUSIVE >> to disconnect the other drivers. This is the typical usage for all UEFI >> protocol, not particular constraints to SNP protocol. > > Looks good! Great! However, it looks that we still have a problem if somebody > opens SNP in EXCLUSIVE mode. Then GRUB2 SNP open will fail according to UEFI > spec. > Sadly we do not have a control on other stuff and one day our approach may > fail > because somebody decided to open SNP in EXCLUSIVE mode in e.g. a driver. Does > it mean that migration to MNP is one sensible solution for our problems? As I > know > this is huge overhaul, so, we should think twice before choosing that way. Then it is fortunate that when I wrote the MNP implementation that we ship with Oracle Solaris 11.2, that I tested it on many thousands of systems as well as on new UEFI implementations at the UEFI Plugfest ;). --S > > Daniel > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
