? 2013?04?16? 15:52, Thomas Renninger ??:
> On Monday, April 15, 2013 12:54:47 PM H. Peter Anvin wrote:
>> On 04/15/2013 12:48 PM, Thomas Renninger wrote:
>>> On Monday, April 15, 2013 05:20:24 AM H. Peter Anvin wrote:
>>>> Except that is wrong. The kernel can receive more than 128 e820 entries,
>>>> they just have to be passed via a different mechanism.
>
> But you do not name/describe it.
> Is it the "efi map mechanism" you are talking about or is there
> something else?
Hi Thomas
I think hpa meant the mechanism related to the field setup_data in
setup_header.
Field name: setup_data
Type: write (special)
Offset/size: 0x250/8
Protocol: 2.09+
The 64-bit physical pointer to NULL terminated single linked list of
struct setup_data. This is used to define a more extensible boot
parameters passing mechanism. The definition of struct setup_data is
as follow:
struct setup_data {
u64 next;
u32 type;
u32 len;
u8 data[0];
};
Where, the next is a 64-bit physical pointer to the next node of
linked list, the next field of the last node is 0; the type is used
to identify the contents of data; the len is the length of data
field; the data holds the real payload.
This list may be modified at a number of points during the bootup
process. Therefore, when modifying this list one should always make
sure to consider the case where the linked list already contains
entries.
And Linux has the setup_data type SETUP_E820_EXT which means extended
e820 entries.
Also see kernel functions:
setup_arch
--> parse_setup_data
--> parse_e820_ext
Thanks
Zhang
>
> Thomas
>
>>> Would it make sense to pass the tables via efi_map by moving up
>>> efi_map parsing to the beginning of efi init in
>>> arch/x86/platform/efi/efi.c?
>>>
>>> And in kexec pass the efi signature, efi map pointers, add add_efi_memmap
>>> param (and possibly some more?)?
>>> Then there would be no limit at all anymore.
>>
>> There is no limit... that's what I'm telling you.
>
>> kexec should certainly pass the EFI information, otherwise the second
>> kernel can't invoke EFI runtime calls at all. Therein lies a whole bit
>> of pain.
>>
>> -hpa
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
