Re: [Xen-devel] [ipxe-devel] Tips on how to debug EFI code (iPXE) from within KVM after ipxe.efi has crashed with #GP?

[Michael Brown]

On 28/09/17 18:37, Konrad Rzeszutek Wilk wrote:

!!! X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID -
 
ExceptionData - 
RIP  - BEC2949C, CS  - 0038, RFLAGS - 00210216

> 

 Find image 808610ed.efidrv (ImageBase=BEC27000,
EntryPoint=BEC2E089) 

And now I am trying to figure out how to troubleshoot this.
(and yes I am thinking it was related to the Tivoli work-around, but
disabling that didn't help).


The Tivoli workaround is for legacy BIOS only; it doesn't apply to the 
UEFI build of iPXE.


You have the RIP and ImageBase, so you know that the exception happens 
at offset +0x249c within your iPXE binary.  You can use this in 
conjunction with the corresponding map file from the iPXE build (which 
will probably be named bin-x86_64-efi/808610d3.efidrv.tmp.map, but see 
below) to figure out exactly where the crash is occurring.



#crash ipxe/src/bin/ipxe.lkrn.tmp ./guest-memory


That's a completely different iPXE binary from the one you are using.


- The 80810ed.efidrv is built using:

(cd ipxe/src;make bin-x86_64-efi/808610d3.efi  CONFIG=qemu
DEBUG=iscsi:4,scsi:4 EMBED=/ipxe.config -j8)
if [ $? -ne 0 ]; then exit 1; fi
(cd ipxe/src;EfiRom -f 0x8086 -i 0x1528 --pci23 -ec
bin-x86_64-efi/808610d3.efidrv -o ../../808610d3.rom)
if [ $? -ne 0 ]; then exit 1; fi


You can build this much more simply in a single command:

  make bin-x86_64-efi/808610d3.efirom EMBED=/ipxe.config

Also note that:

- debug levels in iPXE are bitmasks, so DEBUG=:4 generally doesn't 
make much sense.  You probably want DEBUG=iscsi,scsi for minimal debug 
(i.e. detailed error messages for any problems), or DEBUG=iscsi:3,scsi:3 
for much more verbose logging.  That said, you don't seem to be using 
iSCSI anyway, so .?


- In your build chain (using EfiRom) I think you have a typo: you build 
the EFI _application_ bin-x86_64-efi/808610d3.efi but then use the EFI 
_driver_ bin-x86_64-efi/808610d3.efidrv, which you have not explicitly 
built.  Your final binary may therefore not match what you think you 
have just built.  You should probably not worry about any of this, and 
just use the single-command build given above instead.


Michael

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v1 0/8] x86/init: Linux linker tables

[Michael Brown]

On 21/01/16 21:37, Konrad Rzeszutek Wilk wrote:

On Thu, Jan 21, 2016 at 12:33:43PM -0800, Luis R. Rodriguez wrote:

Sure, do we know if that ICC compatible? Do we care? There are a
series of ICC hacks put in place on ipxe's original solution which
I've folded in, it seems that works but if we care about ICC those
folks should perhaps help review as well.


I didn't know the kernel could even be compiled with ICC? Thought
only GCC worked?

Anyhow - it may be that those fixes were for quite old ICC versions.
Does the latest one manifest these oddities?


I haven't tested building iPXE with icc for some time.  (The support for 
icc was originally added with the plan to be able to compile to EFI Byte 
Code; this plan was swiftly abandoned.)


The most recent version of icc that I have personally used with that 
code was 10.1.018.


Michael

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC v1 2/8] tables.h: add linker table support

[Michael Brown]

+ * To solve this problem linker tables can be used on Linux, it enables you to
+ * always force compiling of select features that one wishes to avoid bit-rot
+ * while still enabling you to disable linking feature code into the final
+ * kernel image or building certain modules if the features have been disabled
+ * via Kconfig. The code is derivative of gPXE linker table's solution.


I missed the start of this thread.  However, asking as the author of the 
original Etherboot/gPXE/iPXE linker table solution: please change all 
references from "gPXE" to "iPXE".


Thanks,

Michael

___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel