(it would also mean if we can delay exiting boot services you could use it to read things from a dataset during boot... though it'd also mean that everything is still unity mapped (va == pa) until we exit boot services

you don't want to stay identity mapped that long, I don't think

or at least, the (in this design) formerly early allocator would want to be much smarter

(this brings me back to my earlier question for toomas about MISC_VA)

since that slice is where the VA for those early allocations comes from

I guess wire up the hat so that it keeps identity mapping until you tell it to stop

and... panic? if you get a `hat_memload` that contradicts?

using boot services for bop* seems reasonable, I mean, that's what bop* is meant to be, but the sparc prom

what the fake in fakebop is faking

yeah

though I haven't looked at what assumptions are there about the env -- which i'm guessing probably inherits from sparc (just don't know what those are)

on x86 the assumption is what I was asking toomas about, I'm pretty sure what they used to be, but I can't find the mechanism it works through now

(that we allocate between valloc_base:valloc_sz to support the VM system, and MISC_VA_BASE:MISC_VA_SIZE to support the system until the hat is running)

those, at least, are the regions we then walk and import our knowledge of into the VM

(valloc* is actually backed by memory, misc_va is just virtual address space)

i do need to dig into that stuff more -- tangentially related, it would be _very_ helpful to be able to be able to use runtime services for a few things...

I think tsoome has mentioned it, but the big thing is that when loader gets the memory map from boot services, the pages marked as runtime pages (there's code and data types) need virtual address mappings (doesn't matter where) after we exit boot services and have to pass the pa<->va mappings for those pages back before we can make other calls

and obviously need to not be otherwise touched by the OS (I'm guessing we exclude those PAs already)

I _think_ we already meet the other requirements for making runtime calls

Whenever someone does rig that up, please reach out so we can make sure to get all the proper spectre mitigations around that.

i'm very tempted.. though I guess the question is what VA address range we'd want to stick the runtime pages..

the runtime pages are mapped to SMAP_TYPE_RESERVED - we do not use efi memory map directly, and do rely on smap table.

does anyone have any experience running illumos (/smartos) on HP DL325 G11 or similar genoa/DDR5 boxes?

wikky: While I can't speak for hp specifically, we run a lot of AMD on DDR5 / Turin.

rmustacc: with success, I presume :)

I know at least some HP G11s (though can't remember the specific model) should be fine -- though the biggest issue is both Dell and HP seem to love to use Broadcom NICs on their motherboards for some reason..

the dual socket G12s however is a bit of a different story... there's some work needed there (unfortuantely I only had access to those for a short period of time, though I'm hoping to get some longer term access maybe later this year)

tsoome: are we just excluding those physical addresses from use, or are we actually giving them virtual addesses in the kernel?

we are excluding those. We do pass efi memory map to kernel, so the information is all there.

I did that bit over 10 years ago and my knowledge about kernel memory management is still rather weak - its not a place you end up too often:D

wikky: Yeah, at least on the AMD side it's no problem. The company I work for (Oxide) is all AMD.

jbk: The 2P G12 was Intel though and not AMD, IIRC.

But if there are issues particularly with AMD stuff we should be in a reasonable place to help debug and make it work.

yeah, the G12s were a 2 socket Intel... not sure offhand what HPs AMD options are (or if they put them all on the same names)

dell's AMD systems though also have some issues.. though I'm hoping are simpler ones..

we have a fix for the USB system that doesn't appear to have been upstreamed (so I'm hoping to maybe do that next week) to deal with quirks with some BMC's virtual USB behavior (I'm hoping that's maybe the issue)

FWIW I just did a Genoa build: 9354P, AsRock GENOAD8X-2T. Two problems I've hit: 1) my U.2 drives do not show up over MCIO (not an illumos issue, they don't show up in BIOS either), 2) AsRock has no BIOS update for getting the latest Genoa PI, so that means I'm stuck with older microcode due to the fallout from CVE-2024-36347.

jbk: yeah we are getting the intels

rmustacc: of course you are :) older docs suggest better support for intel but oxide picking amd and putting in the serious work convinced us to go with amd (and of course the price)

rzezeski: good to know, this confirms my findings that if there are going to be issues, it's unlikely they're due to cpu or ddr5 support

the kit arrives in a few days, I'll report back

initially we ordered a g10 but our provider upgraded it to a g11 for free, nice of them but finding out days before delivery ...

we're also getting a bunch of DL385 G10