On 02.09.2025 15:41, Manuel Bouyer wrote: > On Tue, Sep 02, 2025 at 02:28:27PM +0200, Juergen Gross wrote: >>> What puzzles me is that: >>> >>> - %cr2 is 0, so probably the first fault wasn't a page fault >>> - RIP is %ebx + 8, so maybe the code was just clobbered by the loop? >>> >>> Could it be the code has been moved to this location, or is about to >>> be moved away afterwards? >> >> And indeed: from the full boot log I can see: >> >> (XEN) virt_base = 0x0 >> (XEN) elf_paddr_offset = 0x0 >> (XEN) virt_offset = 0x0 >> (XEN) virt_kstart = 0x200000 >> (XEN) virt_kend = 0x17bab90 >> (XEN) virt_entry = 0x20e4d0 >> >> So virt_kentry is very near to the RIP. > > thanks to this, I think I found the issue: > with Xen 4.18, the kernel is started with ebx=17bb018; with 4.20 it's > 100018. > > The bootstrap code assumes that the kernel is after the kernel, and the
DYM "start info is after the kernel" or some such, seeing that that's what %ebx is about? > kernel symbol table. That seems to be no longer true with Xen 4.20 and a > PVH dom0 (but probably still true in all other cases). > > I can deal with that, but with the new layout how do I get the end of the > symbol table ? You'll need to handle that internally, I expect, perhaps from properties of your (ELF) binary. Jan
