[PATCH 5/5] kexec: X86: Pass memory ranges via e820 table instead of memmap= boot parameter

[Zhang Yanfei]

于 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