Page MenuHomeFreeBSD

amd64: several preparational patches for changing the KVA layout
ClosedPublic

Authored by kib on Jun 25 2025, 9:48 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Oct 10, 12:08 AM
Unknown Object (File)
Sat, Oct 4, 7:03 AM
Unknown Object (File)
Sun, Sep 28, 2:21 AM
Unknown Object (File)
Fri, Sep 26, 9:22 PM
Unknown Object (File)
Thu, Sep 25, 4:04 PM
Unknown Object (File)
Wed, Sep 24, 3:32 AM
Unknown Object (File)
Fri, Sep 19, 6:08 AM
Unknown Object (File)
Wed, Sep 17, 3:33 PM
Subscribers

Details

Summary
amd64 locore: fix typo in comment


amd64: express KV4ADDR() using KV5ADDR()


amd64: remove dmapbase, dmapend symbols


amd64: eliminate asm symbols DMAP_MIN/MAX_ADDRESS


amd64: switch to la57 mode before creating kernel page tables

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kib requested review of this revision.Jun 25 2025, 9:48 PM
sys/amd64/amd64/locore.S
112

Can these steps be removed?

sys/amd64/amd64/locore.S
112

No, since otherwise machine is not properly configured for long mode.
Now it is done in pmap_bootstrap() when we reload system machine state after the final pcpu area for bsp is created. And this is the (minor) advantage of the move.

Real goal is much bigger, but it is too early.

Add a sentence about LA57 and the new gdt.

sys/amd64/amd64/pmap.c
1964 ↗(On Diff #157689)

Should we still be populating the PML4PML4Ith slot of KPML4phys when LA57 is enabled?

1971 ↗(On Diff #157689)

allocpages() zeroes the page, so this looks like a convoluted way of writing

KPML5phys = allocpages(firstaddr, 1);
p5_p = (pml5_entry_t *)KPML5phys;
p5_p[PML5PML5I] = ...
p5_p[pmap_pml5e_index(UPT_MAX_ADDRESS)] = ...
sys/amd64/amd64/pmap.c
1964 ↗(On Diff #157689)

Isn't this done in lines 1914,1915 above?

1971 ↗(On Diff #157689)

Right now, yes. Later I would need to populate much more pm5 entries. If you prefer to have the two lines instead of the loop in the patch, I will change it.

markj added inline comments.
sys/amd64/amd64/pmap.c
1964 ↗(On Diff #157689)

I mean, should those lines be conditional on !la57? I am not sure offhand if those PML4 entries are used when the recursive map is defined here.

This revision is now accepted and ready to land.Jun 27 2025, 2:08 AM
sys/amd64/amd64/pmap.c
1964 ↗(On Diff #157689)

They are not used, I believe. Lets look at the real page tables walk info from the la57 machine:

(gdb) p/x vtoptem
$1 = 0xfffffffffff8
(gdb) p &rootvnode 
$2 = (struct vnode **) 0xffffffff80bda9c8 <rootvnode>
(gdb) p/x PTmap + ((((uint64_t)&rootvnode) >> 9) & vtoptem) <= this is vtopte(&rootvnode)
$3 = 0xff00ffffffc05ed0 <= pte mapping location for rootvnode
db> show pte 0xff00ffffffc05ed0
VA 0xff00ffffffc05ed0 pml5e@0xfffff80075200800 0x8000000075200063 pml4e@0xfffff80075200ff8 0x000000007518e063 pdpe@0xfffff8007518eff8 0x0000000075192023 pde@0xfffff80075192ff0 0x00000000751be023 pte@0xfffff800751be028 0x80000000748000e3

Note that pml5e and pml4e entries are located at the same virtual page 0xxfffff800752000
00 (DMAP). Or to look at it differently, PTmap for la57 is KV5ADDR(PML5PML5I, 0, 0, 0, 0) which is 0xff00000000000000 ATM.

(The 'show pte' ddb command was modified to also print the addresses of ptes on walk. I will commit this in a minute).

But why removing it? For now the structure of the pd4p level is completely identical for la57 and la48, and this is kind of feature of the current la57 setup.