Re: [PATCH 00/11] EFI runtime services virtual mapping
From: Borislav Petkov
Date: Fri Sep 20 2013 - 05:05:55 EST
On Fri, Sep 20, 2013 at 03:29:04PM +0800, Dave Young wrote:
> Just tested this series, for 1st kernel It boots ok in qemu+ovmf. But
> it immediately reboot on my Thinkpad T420. Unfortunately there's no
> way to debug this very early problem because there's no serial port
> also earlyprintk does not work for efi boot. No usb debug as well on
> this machine. I will test it when I go back to work after the china
> holiday.
Hmm, I'm booting with the efi boot stub, how do you do it?
> OTOH, for 2nd kernel testing because kexec tools does not fill
> efi_info[] in bootparam so kernel will disable efi, also it pass
> acpi_rsdp pointer automaticlly to make 2nd kernel boot ok.
Right, the way this could be done is to pass in efi_info.efi_memmap,
i.e. the physical map and then iterate over it and compute the virtual
addresses *without* calling phys_efi_set_virtual_address_map() - they
are stable now.
> I tested with a user space patch which copy efi_info from 1st kernel
> to bootparams, as I said previously this is not enough because several
> fields in systab, fw_vendor, runtime and tables are converted to
> virtual address but in kernel efi init function they are assumed
> physical addresses. Thus we need save these physical address. I have a
> patch to save them and pass them to 2nd kernel in bootparams.
Yep.
> Since the mapping are same, I wonder if we can calculate the physical
> address from virtual address. Idea?
Just look at the loop where we're iterating over regions in
efi_enter_virtual_mode(): we basically can do the same __map_region
calls without calling phys_efi_set_virtual_address_map.
> Another concern is that is it safe for i386 efi boot?
That's why I didn't put a git tree on k.org - I wanted to run tests
myself before Fengguang's robot :)
But no, 32-bit is not addressed here. Which just dawned on me: Matt, I
probably should keep the ioremapping code for 32-bit, doh. I completely
went 64-bit only here :-)
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/