Re: issue with dom0_pvh on Xen 4.20

[Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>]

On Tue, Sep 02, 2025 at 03:55:14PM +0200, Jan Beulich wrote:
> 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?

yes, sorry

> 
> > 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.

But I don't have access to the ELF headers from the kernel binary (nor do I
know which kernel was booted).

Hum, maybe a I can hardcode this info in some const of the binary with a
ld trick ?

-- 
Manuel Bouyer <bouyer@xxxxxxxxxxxxxxx>
     NetBSD: 26 ans d'experience feront toujours la difference
--