On Tue, Jul 16, 2013 at 12:40 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Tue, Jul 16, 2013 at 12:36 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> On 07/16/2013 12:31 PM, Kees Cook wrote: >>> >>> Could the first step be documenting the limitation? I've found this >>> patch extremely useful for my case already, and I imagine there might >>> be other people that need the early mmio stuff to. Generally the >>> compressed boot serial console stuff is going to be used in the more >>> common non-kexec situations at least for a while. >>> >>> Does this patch create any _problems_? Right now, neither low nor >4G >>> kernel can use an mmio serial port. :) This this, we'd at least gain >>> it for the low case. >>> >> >> Even documenting the limitation is likely to end up with a bunch of >> emails asking why their kernel crashed. >> >> I think setting up a dynamic #PF handler is the right thing for the >> decompressor, we already did for the kernel proper. > > I'm not sure how to accomplish this yet. I'm still trying to > understand how the page tables are arranged. :) Other way could be: Detect if it get into misc.c directly from arch/x86/boot/compressed/head_64.S::startup_64. that is from 64bit bootloader. others go through startup_32 should be 32bit bootloader. If it with 64bit boot loader path, You can skip parsing mmio in misc.c::console_init() calling. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
