Khalid Aziz <khalid.aziz at hp.com> writes: > On 09/13/2012 07:38 AM, Vivek Goyal wrote: >> So what does this mean? Second kernel assumes the regular BIOS and tries >> to initialize that way? That sounds broken or is it just fine given >> the fact we are anyway not planning to call into any of the efi services. >> But what about memory maps, ACPI tables etc. > > Hi Vivek, > > My understanding on x86 side is not as clear as on ia64 side of kexec. From my > reading of the code, second kernel seems to assume a regular BIOS. It searches > through EBDA or upper memory region E0000h-FFFFFh to find RSDP, if an RSDP > pointer was not passed to the second kernel. This works on my EFI machine which > also implements a BIOS compatibility layer. I wonder how it works on pure EFI > machines. Do pure EFI machines not implement, say EBDA? If yes, > acpi_find_root_pointer() should fail tofind RSDP.As for memory map, all I can > find are reference to e820 memory map which again assumes a BIOS but most EFI > implementations I have come across implement a BIOS compatibility layer, so this > will work still. I will look some more into this. Kexec in general enters the kernel past the point where BIOS calls have been made. So basically the kexec path assumes no runtime services from any firmware. As I recall the e820 memory map can report the ACPI location. Last I checked we still had that useless set_virtual_memory map call in the kernel when efi is detected and until that goes away I don't know that we can or should depend on any efi bits in the kernel on the kdump path. Honestly I don't think we should make any EFI calls later than we make BIOS calls, certainly the kdump case proves it works. Eric
