On 08/05/13 18:12, Borislav Petkov wrote: > On Mon, Aug 05, 2013 at 05:15:38PM +0200, Laszlo Ersek wrote: >> The current implementation (how pointers are converted) probably doesn't >> accommodate a second call. >> >> Of course you want to know why SetVirtualAddressMap() was designed like >> that... I didn't participate in the design so I don't know :) >> >> But, as I said, a kernel directly executing another kernel is an >> unexpected idea. IMHO the second kernel in question doesn't fit the UEFI >> phases at all. The OS booted like that (ie. the OS whose kernel is the >> 2nd (=kexec) kernel) never goes through SEC, PEI, DXE, BDS. > > Yes, the thing is, imposing unnecessary restrictions is very > counterproductive. And kexec is just an example here - if > SetVirtualAddressMap was callable an arbitrary number of times, this > whole work I'm doing is unnecessary. So I'm jumping through hoops just > to accomodate a braindead design. I doubt it was a deliberate restriction. More like, there was no incentive (... that the designers were aware of) *not* to design something easy (or easier) to implement. Your use case has come later. > This is what I cannot fathom in the face of people praising UEFI as the > solution to all problems. I agree that such people exist. I'm not one of them. >> BTW there's another point I'd like to ask about -- you're saying you >> see the region corruption during the same boot, from the first (early) >> memmap dump to the second one (when just about to enter virtual mode). >> But, is this one boot the very first boot, or the kexec one? > > No, kexec is not even involved yet. If you look at the timestamps, > there's 0.005 seconds between the two dumps during the *same* kernel > booting on the machine, baremetal, straight from grub. I didn't realize the timestamps survive kexec. (As far as I remember the kernels I played with kexec on didn't have the automatic timestamps yet in dmesg, but I might have messed up just as well...) Laszlo -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
