On 11/11/18 10:19 PM, Ingo Molnar wrote:
>
>> In part as a result of this exchange I have spent some time thinking
>> about the boot protocol and its dependencies, and there is, in fact, a
>> much more serious problem that needs to be addressed: it is not
>> currently possible in a forward-comp
On 11/11/18 10:19 PM, Ingo Molnar wrote:
>
> I might be a bit dense early in the morning, but could you elaborate?
> What do you mean by mapping all data areas?
>
Heh. I need to pack for LPC and get some sleep before my flight lest I'll be
denser than depleted uranium; I'll write an explanation
* H. Peter Anvin wrote:
> > Such an extended header could use a more modern (self-extending) ABI as
> > well.
>
> Yes, although I don't really think it is as much of an issue as it seems at
> this point.
>
> The limit comes from having used a one-byte jump instruction at the beginning;
> how
On 11/11/18 8:56 PM, Ingo Molnar wrote:
>
>> Also note that the ext_ramdisk_image and ext_ramdisk_size are part of
>> struct boot_params as opposed to struct setup_header, which means that
>> they are not supported when entering via the 16-bit BIOS entry point,
>> and I am willing to bet that ther
* H. Peter Anvin wrote:
> On 11/9/18 5:40 AM, Li Zhijian wrote:
> > Just noticed that there is a field xloadflags at recent protocol
> > 60 Protocol 2.12: (Kernel 3.8) Added the xloadflags field and
> > extension fields
> > 61 to struct boot_params for loading bzImage and r
On 11/9/18 5:40 AM, Li Zhijian wrote:
> Just noticed that there is a field xloadflags at recent protocol
> 60 Protocol 2.12: (Kernel 3.8) Added the xloadflags field and
> extension fields
> 61 to struct boot_params for loading bzImage and ramdisk
> 62 above 4G
On 11/9/2018 3:20 PM, Ingo Molnar wrote:
* Li Zhijian wrote:
If the kernel initrd creation process creates an initrd which
is larger than 2GB and also claims that it can't be placed
with any part of it above 2GB, then that sounds like a bug
in the initrd creation process...
Exactly, it's a re
Just noticed that there is a field xloadflags at recent protocol
60 Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension
fields
61 to struct boot_params for loading bzImage and ramdisk
62 above 4G in 64bit.
[snip]
617 Field name: xloadfl
Just noticed that there is a field xloadflags at recent protocol
60 Protocol 2.12: (Kernel 3.8) Added the xloadflags field and extension
fields
61 to struct boot_params for loading bzImage and ramdisk
62 above 4G in 64bit.
[snip]
617 Field name: xloadfl
* Li Zhijian wrote:
> > If the kernel initrd creation process creates an initrd which
> > is larger than 2GB and also claims that it can't be placed
> > with any part of it above 2GB, then that sounds like a bug
> > in the initrd creation process...
>
> Exactly, it's a real problem.
>
> Add x
On 09/11/2018 10:57, Li Zhijian wrote:
> On 11/9/2018 3:20 PM, Ingo Molnar wrote:
>> * Li Zhijian wrote:
>>
If the kernel initrd creation process creates an initrd which
is larger than 2GB and also claims that it can't be placed
with any part of it above 2GB, then that sounds like a
On 11/08/2018 07:06 PM, Peter Maydell wrote:
On 8 November 2018 at 10:59, Li Zhijian wrote:
x86/x86_64 has alredy supported 4G initrd.
linux/arch/x86/boot/header.S:
# (Header version 0x0203 or later) the highest safe address for the contents
# of an initrd. The current kernel allows up t
On 8 November 2018 at 10:59, Li Zhijian wrote:
> x86/x86_64 has alredy supported 4G initrd.
>
> linux/arch/x86/boot/header.S:
> # (Header version 0x0203 or later) the highest safe address for the contents
> # of an initrd. The current kernel allows up to 4 GB, but leave it at 2 GB to
> # avoid
x86/x86_64 has alredy supported 4G initrd.
linux/arch/x86/boot/header.S:
# (Header version 0x0203 or later) the highest safe address for the contents
# of an initrd. The current kernel allows up to 4 GB, but leave it at 2 GB to
# avoid possible bootloader bugs.
CC: Philip Li
Signed-off-by: Li
14 matches
Mail list logo
