Le 7 mars 2017 18:22, "Vladimir 'phcoder' Serbinenko" <address@hidden> a
écrit :
Le 7 mars 2017 17:24, "Vladimir 'phcoder' Serbinenko" <address@hidden> a
écrit :
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.
You are right, I means for x86_64 system.
> 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.
For manufacture testing purpose, we use grub2 as PXE engine to download OS from network.
Because there are many different initrd files to be used, we did not use NFS or iSCSI.
Grub2 can support HTTP protocol, so we use HTTP protocol to get kernel and initrd files.
Normally we can use grub2 to download OS and put it to memory below 4GB and boot successfully.
But on some environment, there is not enough memory below 4GB to put initrd file, so we want to access high memory above 4GB.
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 have tried to redefine GRUB_EFI_MAX_USABLE_ADDRESS as 0xffffffffffffULL, but it still can not access memory above 4GB on x86_64 system.
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 avoid 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.
This bug is well understood. There is no guesswork involved in detecting unmapped ranges. And generally allowing overrides results in that everybody uses overrides rather than reporting and fixing problems. Also exposing
this kind of details in higher levels is a whole different can of worms. Allocatable ranges are determined before you reach any parser.
|