On Tue, Sep 02, 2025 at 02:45:04PM +0200, Jan Beulich wrote:
> >> What puzzles me is that:
> >>
> >> - %cr2 is 0, so probably the first fault wasn't a page fault
> >
> > AFAIK it can't be as we're still in real mode
>
> It's protected mode, but with paging still off.
>
> >> - 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?
> >
> > No. RIP shouldn't end up there in any way. the assembly code is quite
> > simple,
> > it's just a loop and I'm quite confident that we did enter the loop with
> > sane values
>
> Yet Jürgen has a point - entry point and what is being modified are on the
> same page (and despite paging still being off, you writing page tables here
> makes pages a relevant unit). Considering
> - entry point @ 0x20e4d0
> - %ecx = 0xdfeb7
> - %ebx = 0x20e260
> the loop continuing a little further will overwrite the entry point code.
> And with the entry point not at an even (e.g page-aligned) address, other
> code (like the one here) could conceivably live immediately ahead of it.
> (Of course this overwriting may be intentional, but it looks suspicious in
> this context.)
Indeed. Now the exact same kernel is booting fine with Xen 4.18 (and also
the same bootstrap is used for domU PVH which works with Xen 4.20).
I guess something changed in the way Xen sets up the dom0 kernel.
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
