[illumos-gate] 18165 Want checker for test runner files -- Gordon Ross <gordon.w.ross⊙gc>

[illumos-gate] 14556 TSC calibration from HPET includes too much error -- Bill Sommerfeld <sommerfeld⊙ho>

[illumos-gate] 18137 loader: add userboot -- Toomas Soome <tsoome⊙mc>

heh.. i do wish we had been a bit more consistent in our naming..

while it's diag-device

jbk: clearly it's a battlefield between fortran_identifier_style and lisp-identifier-style (going back to I think the earliest language to use each style. I may be wrong..)

tsoome: despite the description saying 'BIOS' on UEFI systems, is 'smap' showing all of the UEFI mappings that get passed to the kernel?

it does translate efi memory map to smap

so yes, you will get all conventional memory entries and reserved memory entries.

is there an easy way to see the unmapped values? (not sure if I need it yet)

for some reason, on windows server 2025, we're hanging in clear_boot_mappings()

memmap command will show efi memory map

hyperv?

so i'm adding a bit of verbosity to see if it's a specific mapping (also: I got tired of doing :c)

yeah

omni and our stuff has hyperv gen2 support (still not upstreamed)

though none of that really comes into play at that point of the boot process

memmap can differ a bit from final map, as in loader, we do not own the memory map and even switching off boot services can change memory map.

well.. we have to explicitly add the ISA bus and the framebuffer in the device tree off the root nexus, but we're not to the point of attaching or otherwise messing with device mapping

tsoome: I saw the EFI variables change, I'm not sure if you're involved?

something apparently well known on ARM is EFI firmware that doesn't work unless you set the virtual address mapping (_even if_ you set it to identity mapped)

that firmware (erroneously) doesn't relocate until that call

you mean code.illumos.org/c/illumos-gate/+/4800? yes, I have been keeping my eye on it. Yes, I'm aware the need of virtual mapping on ARM. Unfortunately gate has no arm bits, therefore amd64 is basically best we can do for now.

→ CODE REVIEW 4800: 15017 efibootmgr for illumos (NEW) | illumos.org/issues/15017

i looked a bit, but have been on this boot hang all day

the big thing I wanted to confirm was the callign convention (it's the MS callign convention, gcc allows you to annotate a function) and re-checking the UEFI specs on XMM register usage

since those seem to be the big things that could be problematic

(at some point, it'd probably be nicer to move some of the bits into the kernel so you can also issue runtime services calls from the kernel w/o going through the driver)

but that can be left for the future

it is concentrating on variables (specifically on boot manager variables) atm. There are some traps too, linux once did let one to wipe UEFI variables and bricking the system...

jbk yea, I'd imagine time and shutdown/reboot callbacks...

actually one I'd like is if the UEFI implementation advertises support for it, you can mark a block of physical memory as 'don't clear on reset'

on Sparc, there's an I think 8k buffer they do that for dmesg

tsoome: no, I mean, the bug as described to me did not seem like an ARM bug, but a generic bug in some UEFI implementations

so the contents is preserved across reboots

so you should probably set the virtual map explicitly to an identity mapping

which can be _very_ helpful if the system panics without being able to save a crash dump

tsoome: but for some reason I thought it was your change

richlowe hm. reviews.freebsd.org/D14677 right.

tsoome: yeah

also 8.4.1 page 236 in UEFI Spec Final 2.11

tsoome: yeah, it says it's going to re-apply relocations etc, but apparently in broken implementations they haven't been applied in the first place :\

the annoying bit is the offending firmware is probably a copy of edk-ii and they just managed to screw things up

does cmn_err(CE_CONT, "?....\n") buffer output before outputting on the console on a verbose boot?

it might depend on whether /dev/log is up

but I don't know

i wonder if i use a different value if that'll work...

my suspicion is that the htable_t is somehow getting messed up, and clear_boot_mappings() is getting into an infinite loop or going off into the weeds, or it's tripping over invalidating one of the entries

You should be able to get a breakpoint prior to that

and the x86 mdb manages its own paging window, so perhaps even survive it

I don't remember what the x86 boot cleanup does, I was having big problems understanding some stuff

mainly, the page tables get P_BOOTPAGES set, but _don't_ get cleared

and it's not obvious by inspection how that all works out for the best

(for the record, if they _did_ get cleared, that would screw you over exactly as you just hypothesized)

i can set a breakpoint a clear_boot_mappings() (and when I was stepping prior, it hangs after callign it and not after it returns)... which is why i'm focused on it..

i tried to do `::bp -c '<rdi=E; :c' x86pte_inval` just to see if I could get it to spit out the first argument until it hangs

but then mdb gets rather unhappy

after a while

and seems to trip an internal mdb assert

that might mean the tables are screwed and mdb can't operate its window

yeah, which seems like fun to figure out

see hat_kdi

for mdb's window

the mdb support for the x86 is visibly broken, unfortunately

so be careful about trusting things in i86mmu.c

(it also seems to be specific to at least windows server 2025 -- older versions boot just fine)

and while you can i guess issue hypercalls (kinda like xen) to do mapping stuff, we don't and just treat it like a regular MMU

at perhaps the cost of a bit of performance...

it's ::report_maps that's visibly busted, so perhaps the bits you need are ok

jbk: it is useful to write down your page table addresses while things aren't yet broken (::htables, print the ht_pfn)

when they become broken, is cr3 still right? are the page tables still where we think they'll be? are the page tables smashed?

you might be able to set write watchpoints on all the page tables, too, but it's not obvious to me if that'd necessarily work on x86 or how badly mdb would take it