On Tue, 2013-01-08 at 14:50 -0800, Jordan Justen wrote: > On Tue, Jan 8, 2013 at 9:55 AM, David Woodhouse <dw...@infradead.org> wrote: > > On Tue, 2013-01-08 at 09:41 +0000, David Woodhouse wrote: > >> Note that OVMF is already broken for the case of booting a 32-bit kernel > >> from 64-bit firmware, even for the legacy handover case which *ought* to > >> work. We need to switch back into 32-bit mode before jumping to the > >> 32-bit entry point. Rather than just jumping to the non-existent 64-bit > >> entry point in a 32-bit kernel. I haven't addressed that here. > > > > It turns out that it's fairly much impossible for the bootloader to tell > > whether the 64-bit entry point at 0x200 actually exists. In theory I've > > been told that you can look at the ELF payload of the bzImage payload > > and its ELF class and the entry point in its headers. But that would > > involve decompressing it first. With the compression method du jour of > > the kernel. As far as I can tell, the 64-bit entry point (at the > > undocumented offset 0x200) is completely unusable when booting a > > bzImage. Vivek? > > Like I mentioned in the other message, I think EFI_STUB + PE/COFF > -kernel booting might be a solution. We can easily see if it is a > 32-bit or 64-bit PE/COFF image. Can this work for what you need?
Not really. This is to handle the case when the answer is "No. It is not a 32-bit or 64-bit PE/COFF image". That's why I kept it in a separate patch. It's needed *regardless* of my other patch. You might be asked to boot a 32-bit bzImage which doesn't have an EFI entry point. You *have* to jump to the start of it, in 32-bit mode. There is no option here. You might also be asked to boot a 64-bit bzImage which doesn't have an EFI entry point. You can jump to that at the undocumented but about-to-be-documented-because-some-people-need-whipping offset 0x200, in 64-bit mode. If you *know* it's a 64-bit kernel. Which you don't. So it's easier just to use the 32-bit entry point for *all* kernels, for the case where you aren't using the EFI entry point. Thus the thunk code. > > So let's *unconditionally* switch back to 32-bit mode and jump to the > > 32-bit entry point which *is* guaranteed to work, like grub does... > > > > Does this look sane? It would need translating for JumpToKernel.asm. > > And it's assuming that both kernel and bootparams are below 4GiB. > > I hope your answer is yes above, because this is not very desirable. Sorry :) -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512
_______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
