kboot: Update amd64 to use enumerate_memory_arch()
ClosedPublic
Actions

Authored by imp on Jan 29 2023, 3:14 PM.

Details

Reviewers

kevans
tsoome
manu

Commits

rGa967cd4db2af: kboot: Update amd64 to use enumerate_memory_arch()

Summary

Move memory enumeration to the enumerate_memory_arch(), tweak the code a
bit to make that fit into that framework.

Also fix a bug in the name of the end location. The old code never found
memory (though amd64 doesn't yet work, this lead to using fallback
addresses that were good enough for QEMU...).

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

imp created this revision.Jan 29 2023, 3:14 PM

Herald added a reviewer: manu. · View Herald TranscriptJan 29 2023, 3:14 PM

Herald added a subscriber: dab. · View Herald Transcript

imp requested review of this revision.Jan 29 2023, 3:14 PM

imp added a parent revision: D38249: kboot: aarch64 memory enumeration enumerate_memory_arch().

Harbormaster completed remote builds in B49292: Diff 116008.Jan 29 2023, 3:15 PM

imp added a child revision: D38251: kboot: Call enumerate_memory_arch().Jan 29 2023, 3:15 PM

rebase / refactor / redo

Harbormaster completed remote builds in B49445: Diff 116251.Feb 1 2023, 11:24 PM

kevans accepted this revision.Feb 2 2023, 3:25 AM

kevans added inline comments.

stand/kboot/arch/amd64/load_addr.c
102–104	Now that it's a static `16` upper bound, this should probably be converted to a `for` loop for readability.
119	A DPRINTF or something might be nice, but this is still early enough stage that I don't think we really care; presumably this won't live too much longer.

This revision is now accepted and ready to land.Feb 2 2023, 3:25 AM

imp added inline comments.Feb 2 2023, 3:49 AM

stand/kboot/arch/amd64/load_addr.c
102–104	fair point. This is a static array, but we need to do something akin to what I've done in the aarch64 case with the code that's now living in seg.c. I should just use the 'avail' interface I think here. The limits are arbitrary, though this is the only way to snag the table, so I may need to have aux data the table that avail builds won't need... So I need to think about this feedback... But maybe the real answer is I need a dynamic array of what will become the UEFI table we need to ship into the kernel... I don't plan on supporting kboot from anything other than a UEFI booted kernel...
119	Yea, perhaps you are right... Though I think the 'avail' interface might largely obsolete this code.