On Mon, Feb 11, 2019 at 01:22:20AM +0100, Borislav Petkov wrote: >On Fri, Feb 08, 2019 at 10:53:22PM +0100, Borislav Petkov wrote: >> On Fri, Feb 08, 2019 at 12:44:51PM -0800, Guenter Roeck wrote: >> > Yes, the kernel boots if I comment out that function and have it return 0. >> >> Thanks, this localizes the issue significantly. > >Some observations: > > } else { > efi_config_table_32_t *tmp_table; > > tmp_table = config_tables; > guid = tmp_table->guid; <--- * > table = tmp_table->table; > } > >It blows up at that tmp_table->guid deref above. Singlestepping through >it with gdb shows: > ># arch/x86/boot/compressed/acpi.c:114: guid = tmp_table->guid; > movq (%rdi), %rax # MEM[(struct efi_config_table_32_t *)config_tables_37].guid, guid > movq 8(%rdi), %rsi # MEM[(struct efi_config_table_32_t *)config_tables_37].guid, guid ># arch/x86/boot/compressed/acpi.c:115: table = tmp_table->table; > movl 16(%rdi), %r10d # MEM[(struct efi_config_table_32_t *)config_tables_37].table, table > jmp .L30 # > >and %rdi has: > > rdi 0x630646870 > >which is an address above 4G but we're using a 32-bit EFI BIOS. > >Which begs the question whether EFI system tables can even be mapped at >something above 4G with a 32-bit EFI and whether that could work ok. >Hmm. Thanks for your help. As you said, I am not wure whether 32-bit EFI can map table address above 4G. If the map method has problem, I think adding a check here can work. Thanks, Chao Fan > >Lemme add Ard and mfleming for insight here. > >Thx. > >-- >Regards/Gruss, > Boris. > >Good mailing practices for 400: avoid top-posting and trim the reply. > >