On Tue, Aug 06, 2013 at 12:08:08AM +0200, Borislav Petkov wrote:
> Ok, thanks again for finding it, I'll go and try to figure out the whole
> mess tomorrow.
Ok, some more observations:
Decompressing Linux... Parsing ELF... done.
Booting the kernel.
[ 0.000000] memblock_reserve: [0x0000000009f000-0x00000000100000] reserve_ebda_region+0x56/0x58
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.11.0-rc4+ (boris@nazgul) (gcc version 4.7.3 (Debian 4.7.3-4) ) #4 SMP PREEMPT Tue Aug 6 15:15:07 CEST 2013
[ 0.000000] memblock_reserve: [0x00000002000000-0x000000036c0000] setup_arch+0x47/0xa63
[ 0.000000] Command line: root=/dev/sda1 debug ignore_loglevel log_buf_len=10M earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0 memblock=debug
[ 0.000000] efi: efi_memblock_x86_reserve_range: pmap: 0x7e0ad018
[ 0.000000] memblock_reserve: [0x0000007e0ad018-0x0000007e0ad588] efi_memblock_x86_reserve_range+0x70/0x75
And this is it:
efi_memblock_x86_reserve_range() reserves the region which overlaps with
the following region:
[ 0.000000] efi: mem11: type=4, attr=0xf, range=[0x000000007e0ad000-0x000000007e0cc000) (0MB)
Now, this address 0x7e0ad018 is boot_params.efi_info.efi_memmap which,
AFAICT, we write to in exit_boot() after calling GetMemoryMap(). IOW,
this the EFI memory map descriptor which we mark as reserved.
So, hmm, I'm not sure what we want to do here.
Off the top of my head, I'm thinking this: efi_reserve_boot_services()
which truncates this region to 0 should actually check that this special
region is reserved, and *enlarge* it instead of making it of size 0, no?
Right?
Or does anyone have a better idea?
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-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
