On 02.09.2025 14:54, Manuel Bouyer wrote:
> 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.

Hence why Andrew asked for full logs of both boots, to put side by side.

Jan

Reply via email to