[prev in list] [next in list] [prev in thread] [next in thread]
List: grub-devel
Subject: Re: Grub2: add UEFI support for accessing memory address above 4GB.
From: Michel Hermier <michel.hermier () gmail ! com>
Date: 2017-03-07 18:13:08
Message-ID: CAAZ5spC+emFQuR9G860_EpOyjz1ZzXe0yMe3-nqTdCuVBSopFQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Le 7 mars 2017 18:22, "Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com> a
=C3=A9crit :
On Tue, Mar 7, 2017, 09:09 Michel Hermier <michel.hermier@gmail.com> wrote:
>
>
> Le 7 mars 2017 17:24, "Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>
> a =C3=A9crit :
>
>
>
> On Tue, Mar 7, 2017, 08:15 Leif Lindholm <leif.lindholm@linaro.org> wrote=
:
>
> On Tue, Mar 07, 2017 at 01:55:01AM +0000, Yufuping wrote:
> > Who can add the new feature for grub2:
> > Add UEFI support for accessing memory address above 4GB.
>
> Presumably you mean for x86_64?
> Since GRUB supports all 5 architectures currently supported by the
> UEFI specification, 3 of which are 64-bit, it is useful to be a bit
> more precise.
>
> > When using grub2 as PXE downloading engine, grub2 can get initrd
> > file from network and put it to memory above 4GB.
>
> I'd like to know more about the usecase. Generally you should avoid
> downloading or loading too large files in bootloader. I.a. TFTP protocol
> has problems with files over about 100MIB. Generally you should download
> only kernel + initrd and rest of the system should be on iSCSI or NFS.
>
>
> I can think of nothing particularly related to PXE here.
> The x86_64 port currently sets GRUB_EFI_MAX_USABLE_ADDRESS to
> 0xffffffff or 0x7fffffff, depending on toolchain configuration.
>
> ARM64 sets it to 0xffffffffffffULL, and that works fine.
>
> I seem to recall that the x86_64 port was being restricted due to
> known bad firmware encountered in the past. It could be that it would
> be worth adding an option to configure for enabling access to higher
> addresses, alternatively for retaining compatibility with the broken
> systems.
>
> I'm opposed to a config option for this. We don't want to have several
> variants of grub binaries for the same platform. If we want to support
> >4GiB memory we should detect the buggy firmware on runtime. It's pretty
> easy: buggy firmware didn't map memory above 4GiB. We can then either avo=
id
> memory above 4GiB or map it ourselves.
>
>
> What about a dynamic variable instead or at least accessible from script?
> So a user could redefine a value of any kind.
>
What if advantage compared to automatic detection. And still, I want to
know about usecase
Because I don't trust automatic detection. Even if one say it is 200% safe,
there is allways that machine that nobody heard of that will fail. So
having user being able to force some values is usually a good idea.
>
> > The feature should support UEFI BIOS boot mode.
>
> I do not understand this statement.
>
> /
> Leif
>
> _______________________________________________
> 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
[Attachment #5 (text/html)]
<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">Le 7 \
mars 2017 18:22, "Vladimir 'phcoder' Serbinenko" <<a \
href="mailto:phcoder@gmail.com">phcoder@gmail.com</a>> a écrit :<br \
type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"><div class="quoted-text"><br><br><div \
class="gmail_quote"><div dir="ltr">On Tue, Mar 7, 2017, 09:09 Michel Hermier <<a \
href="mailto:michel.hermier@gmail.com" \
target="_blank">michel.hermier@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="auto" class="m_3484573264226180382gmail_msg"><div \
class="m_3484573264226180382gmail_msg"><br \
class="m_3484573264226180382gmail_msg"><div class="gmail_extra \
m_3484573264226180382gmail_msg"><br class="m_3484573264226180382gmail_msg"><div \
class="gmail_quote m_3484573264226180382gmail_msg">Le 7 mars 2017 17:24, \
"Vladimir 'phcoder' Serbinenko" <<a \
href="mailto:phcoder@gmail.com" class="m_3484573264226180382gmail_msg" \
target="_blank">phcoder@gmail.com</a>> a écrit :<br type="attribution" \
class="m_3484573264226180382gmail_msg"><blockquote \
class="m_3484573264226180382m_-4417564263042796321quote \
m_3484573264226180382gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div \
class="m_3484573264226180382m_-4417564263042796321quoted-text \
m_3484573264226180382gmail_msg"><br class="m_3484573264226180382gmail_msg"><br \
class="m_3484573264226180382gmail_msg"><div class="gmail_quote \
m_3484573264226180382gmail_msg"><div dir="ltr" \
class="m_3484573264226180382gmail_msg">On Tue, Mar 7, 2017, 08:15 Leif Lindholm \
<<a href="mailto:leif.lindholm@linaro.org" class="m_3484573264226180382gmail_msg" \
target="_blank">leif.lindholm@linaro.org</a>> wrote:<br \
class="m_3484573264226180382gmail_msg"></div><blockquote class="gmail_quote \
m_3484573264226180382gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Tue, Mar 07, 2017 at 01:55:01AM +0000, Yufuping wrote:<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> > Who can add the new feature for grub2:<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> > Add UEFI support for accessing memory address \
above 4GB.<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> <br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> Presumably you mean for x86_64?<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> Since GRUB supports all 5 architectures currently \
supported by the<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> UEFI specification, 3 of which are 64-bit, it is \
useful to be a bit<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> more precise.<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> <br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> > When using grub2 as PXE downloading engine, \
grub2 can get initrd<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> > file from network and put it to memory above \
4GB.<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"></blockquote></div></div><div \
class="m_3484573264226180382gmail_msg">I'd like to know more about the usecase. \
Generally you should avoid downloading or loading too large files in bootloader. I.a. \
TFTP protocol has problems with files over about 100MIB. Generally you should \
download only kernel + initrd and rest of the system should be on iSCSI or \
NFS.</div><div class="m_3484573264226180382m_-4417564263042796321quoted-text \
m_3484573264226180382gmail_msg"><div class="gmail_quote \
m_3484573264226180382gmail_msg"><blockquote class="gmail_quote \
m_3484573264226180382gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> I can think of nothing particularly related to PXE \
here.<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> The x86_64 port currently sets \
GRUB_EFI_MAX_USABLE_ADDRESS to<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> 0xffffffff or 0x7fffffff, depending on toolchain \
configuration.<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> <br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> ARM64 sets it to 0xffffffffffffULL, and that works \
fine.<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> <br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> I seem to recall that the x86_64 port was being \
restricted due to<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> known bad firmware encountered in the past. It could \
be that it would<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> be worth adding an option to configure for enabling \
access to higher<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> addresses, alternatively for retaining compatibility \
with the broken<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> systems.<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"></blockquote></div></div><div \
class="m_3484573264226180382gmail_msg">I'm opposed to a config option for this. \
We don't want to have several variants of grub binaries for the same platform. If \
we want to support >4GiB memory we should detect the buggy firmware on runtime. \
It's pretty easy: buggy firmware didn't map memory above 4GiB. We can then \
either avoid memory above 4GiB or map it \
ourselves.</div></blockquote></div></div></div><div dir="auto" \
class="m_3484573264226180382gmail_msg"><br \
class="m_3484573264226180382gmail_msg"></div></div><div dir="auto" \
class="m_3484573264226180382gmail_msg"><div dir="auto" \
class="m_3484573264226180382gmail_msg">What about a dynamic variable instead or at \
least accessible from script? So a user could redefine a value of any \
kind.</div></div></blockquote></div></div><div>What if advantage compared to \
automatic detection. And still, I want to know about \
usecase</div></blockquote></div></div></div><div dir="auto"><br></div><div \
dir="auto">Because I don't trust automatic detection. Even if one say it is 200% \
safe, there is allways that machine that nobody heard of that will fail. So having \
user being able to force some values is usually a good idea.</div><div \
dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div \
class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" \
class="m_3484573264226180382gmail_msg"><div dir="auto" \
class="m_3484573264226180382gmail_msg"><br \
class="m_3484573264226180382gmail_msg"></div><div dir="auto" \
class="m_3484573264226180382gmail_msg"><div class="gmail_extra \
m_3484573264226180382gmail_msg"><div class="gmail_quote \
m_3484573264226180382gmail_msg"><blockquote \
class="m_3484573264226180382m_-4417564263042796321quote \
m_3484573264226180382gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div \
class="m_3484573264226180382m_-4417564263042796321elided-text \
m_3484573264226180382gmail_msg"><div class="gmail_quote \
m_3484573264226180382gmail_msg"><blockquote class="gmail_quote \
m_3484573264226180382gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> <br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> > The feature should support UEFI BIOS boot \
mode.<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> <br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> I do not understand this statement.<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> <br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> /<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg">
Leif<br class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> <br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> \
______________________________<wbr>_________________<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> Grub-devel mailing list<br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> <a href="mailto:Grub-devel@gnu.org" \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg" target="_blank">Grub-devel@gnu.org</a><br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> <a \
href="https://lists.gnu.org/mailman/listinfo/grub-devel" rel="noreferrer" \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg" \
target="_blank">https://lists.gnu.org/mailman/<wbr>listinfo/grub-devel</a><br \
class="m_3484573264226180382m_-4417564263042796321m_3116463110773228278gmail_msg \
m_3484573264226180382gmail_msg"> </blockquote></div>
</div><br class="m_3484573264226180382gmail_msg">______________________________<wbr>_________________<br \
class="m_3484573264226180382gmail_msg"> Grub-devel mailing list<br \
class="m_3484573264226180382gmail_msg"> <a href="mailto:Grub-devel@gnu.org" \
class="m_3484573264226180382gmail_msg" target="_blank">Grub-devel@gnu.org</a><br \
class="m_3484573264226180382gmail_msg"> <a \
href="https://lists.gnu.org/mailman/listinfo/grub-devel" rel="noreferrer" \
class="m_3484573264226180382gmail_msg" \
target="_blank">https://lists.gnu.org/mailman/<wbr>listinfo/grub-devel</a><br \
class="m_3484573264226180382gmail_msg"> <br \
class="m_3484573264226180382gmail_msg"></blockquote></div><br \
class="m_3484573264226180382gmail_msg"></div></div></div> \
______________________________<wbr>_________________<br \
class="m_3484573264226180382gmail_msg"> Grub-devel mailing list<br \
class="m_3484573264226180382gmail_msg"> <a href="mailto:Grub-devel@gnu.org" \
class="m_3484573264226180382gmail_msg" target="_blank">Grub-devel@gnu.org</a><br \
class="m_3484573264226180382gmail_msg"> <a \
href="https://lists.gnu.org/mailman/listinfo/grub-devel" rel="noreferrer" \
class="m_3484573264226180382gmail_msg" \
target="_blank">https://lists.gnu.org/mailman/<wbr>listinfo/grub-devel</a><br \
class="m_3484573264226180382gmail_msg"> </blockquote></div>
</div><br>______________________________<wbr>_________________<br>
Grub-devel mailing list<br>
<a href="mailto:Grub-devel@gnu.org">Grub-devel@gnu.org</a><br>
<a href="https://lists.gnu.org/mailman/listinfo/grub-devel" rel="noreferrer" \
target="_blank">https://lists.gnu.org/mailman/<wbr>listinfo/grub-devel</a><br> \
<br></blockquote></div><br></div></div></div>
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic