Why kernel load address changed?

[yushang]

Hi guys,
In the loader command line, I loaded the kernel as follow
load /boot/kernel/kernel
then lsmod show the following line

OK lsmod
0x200000: /boot/kernel/kernel (elf kernel , 0x1f3e2d0)
...

which means that kernel is loaded at address 0x200000, but later after the kernel has up, the sysctl debug.dump_modinfo shows a different address as follow

root@freebsd132:~ # sysctl debug.dump_modinfo
debug.dump_modinfo:
0xffffffff82906168:
type: (0x01) MODINFO_NAME
len: 20
value: /boot/kernel/kernel
0xffffffff82906188:
type: (0x02) MODINFO_TYPE
len: 11
value: elf kernel
0xffffffff829061a0:
type: (0x03) MODINFO_ADDR
len: 8
value: 0xffffffff80200000
...

what confused me is MODINFO_ADDR. Its value is 0xffffffff80200000 , which does not match the previous load address 0x200000. Is there any chance that the load address is changed when it is copied ? Or what I've missed ? Many thanks. (BTW I'm running amd64 GENERIC kernel)

 

[George]

What address is shown in kldstat?

 

[yushang]

What address is shown in kldstat?

0xffffffff80200000

 

[VladiBG]

freebsd-src/stand/kboot/arch/amd64/elf64_freebsd.c at 51e7276365bad2871257ef121cead2c19bcd7434 · freebsd/freebsd-src

The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - freebsd/freebsd-src

github.com

Kernel/Boot: Cope with a Relocation by a Bootloader in 32-bit x86 Assembly Code – PHIPS BLOG

A kernel should be relocatable by bootloaders as this is the only guarantee that it doesn’t interfere with addresses already in use by the firmware. This is especially true for the legacy boot flow on Read more…

phip1611.de

 

[yushang]

freebsd-src/stand/kboot/arch/amd64/elf64_freebsd.c at 51e7276365bad2871257ef121cead2c19bcd7434 · freebsd/freebsd-src

The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - freebsd/freebsd-src

github.com

Kernel/Boot: Cope with a Relocation by a Bootloader in 32-bit x86 Assembly Code – PHIPS BLOG

A kernel should be relocatable by bootloaders as this is the only guarantee that it doesn’t interfere with addresses already in use by the firmware. This is especially true for the legacy boot flow on Read more…

phip1611.de

I believe I'm not using kboot. I'm running amd64 GENERIC kernel on a virtual machine.

 

[VladiBG]

Check the comments of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c6

 

[yushang]

Check the comments of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c6

Yes, I'm using Hyper-V. But I'm not using UEFI. I'm using BIOS.

 

[VladiBG]

It get relocated depending of the arch. Check the common/load_elf.c

 

[yushang]

It get relocated depending of the arch. Check the common/load_elf.c

Yes. I've checked that.
1. loadimage will load kernel at 0x200000.
2. this address is recorded in the f_addr field of preloaded_file
3. and f_addr is copied to MODINFO_ADDR by md_copymodules(common/modinfo.c).
So in my understanding, the value of MODINFO_ADDR should be 0x200000 but it is not. This is what confused me.

 

[yuripv79]

Could be related:

/sys/amd64/include/vmparam.h: * 0xffffffff80000000                        KERNBASE

The address is not really different, it looks to be added to the value above.

 

[yushang]

The address is not really different

Yes. I know , per the setup of page table , 0xffffffff80200000 and 0x200000 all map to the same page frame.

it looks to be added to the value above

where in the code? that's what I'm trying to find out.

 

[VladiBG]

Before the BSD Kernel starts: Part One on AMD64

System initialization is one of the niche areas that few people look into. The exact details vary considerably between different platforms, firmwares, CPU architectures and operating systems, making it difficult to learn it all. Usually, if something is not working correctly during the early...

www.moritz.systems

 

[T-Aoki]

Would be insufficient but related #define's in stable/14.
Searhed under /usr/src/sys/amd64/ only.

/usr/src/sys/amd64/include/vmparam.h:218:#define KERNBASE KV4ADDR(KPML4I, KPDPI, 0, 0) /usr/src/sys/amd64/include/vmparam.h:219:#define KERNSTART (KERNBASE + NBPDR) /usr/src/sys/amd64/include/param.h:97:#define PAGE_SHIFT 12 /* LOG2(PAGE_SIZE) */ /usr/src/sys/amd64/include/param.h:98:#define PAGE_SIZE (1<<PAGE_SHIFT) /* bytes/page */ /usr/src/sys/amd64/include/param.h:103:#define PDRSHIFT 21 /* LOG2(NBPDR) */ /usr/src/sys/amd64/include/param.h:104:#define NBPDR (1<<PDRSHIFT) /* bytes/page dir */ /usr/src/sys/amd64/include/param.h:107:#define NPDPEPG (PAGE_SIZE/(sizeof (pdp_entry_t))) /usr/src/sys/amd64/include/param.h:109:#define PDPSHIFT 30 /* LOG2(NBPDP) */ /usr/src/sys/amd64/include/param.h:113:#define NPML4EPG (PAGE_SIZE/(sizeof (pml4_entry_t))) /usr/src/sys/amd64/include/param.h:115:#define PML4SHIFT 39 /* LOG2(NBPML4) */ /usr/src/sys/amd64/include/pmap.h-168-/* /usr/src/sys/amd64/include/pmap.h-169- * Pte related macros. This is complicated by having to deal with /usr/src/sys/amd64/include/pmap.h-170- * the sign extension of the 48th bit. /usr/src/sys/amd64/include/pmap.h-171- */ /usr/src/sys/amd64/include/pmap.h:172:#define KV4ADDR(l4, l3, l2, l1) ( \ /usr/src/sys/amd64/include/pmap.h-173- ((unsigned long)-1 << 47) | \ /usr/src/sys/amd64/include/pmap.h-174- ((unsigned long)(l4) << PML4SHIFT) | \ /usr/src/sys/amd64/include/pmap.h-175- ((unsigned long)(l3) << PDPSHIFT) | \ /usr/src/sys/amd64/include/pmap.h-176- ((unsigned long)(l2) << PDRSHIFT) | \ /usr/src/sys/amd64/include/pmap.h-177- ((unsigned long)(l1) << PAGE_SHIFT))