Re: issue with dom0_pvh on Xen 4.20

[Jan Beulich <jbeulich@xxxxxxxx>]

On 02.09.2025 16:06, Manuel Bouyer wrote:
> 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 ?

For the symbol table to be loaded, it needs to live in some loadable section.
You should be able to mark that section's end (or the end of the symbol
table in the section, in case there's more stuff there) with a symbol in the
linker script (which I assume you use). If you used the GNU toolchain, you
could also consider using the assembler's .startof. / .sizeof. operators
(producing symbols that the linker then recognizes and resolves accordingly).

Or wait - are you perhaps using the thing we call "bsd_symtab" in our libelf?
Then, as per the scheme in elf_load_bsdsyms(), can't you find the start of
the ELF header from the end of your kernel? At least that's how I understand
it's supposed to work.

Jan