anyone know of a reason why pcf_cfgacc_x86.c appears to map and unmap the PCI config space on every access?

(just curious.. seems like we could map it once w/ appropriate attributes and leave it)

(also, having multiple ways for the rest of the kernel to access the PCI config space (pci_cfgacc_x86.c and pci_cfgspace.c) is making my head hurt

too bad there is no commit log.

it seems like we could have one (private) API for accesing cfgspace by bdf that gets setup early in boot (after VM is setup, after we've looked at the ACPI stuff, but before (perhaps immediately) we start enumerating the PCI buses... something like that...

Being able to reliably access config space without the device tree is fairly unique to x86.

I don't see the problem with the mapping being brought up and down as needed. Most stuff should go thorugh the device tree / ddi mappings.

doesn't ecam on x86 map the physical through a window?

jbk: I rewrote how our pci config access works for ARM, you should look at arm64-gate

(though not fully, in the x86 side, in deference to rmustacc and a thoughtful mergee)

but we always access config space via the same function (an improvement, as you're noticing) and always with the knowledge of the root complex dip

(we also enumerate via a bus op, rather than a magic call at configure time)

it seems like if we're all redesigning that we should all pull together

ECAM is generally a contiguous region noawadays, but that's an AMD focus.

And as much as I want to get to a point where there is always a dip for accesses that can go through the normal methods, I think that's a long path on x86.

I agree though that any changes should be coordinated and planned.

rmustacc: I just think I remember that Keith had rewritten that part so we stored an ecam physical, and mapped it through a window to use it

maybe that was only for pcitool

rmustacc: so on x86 making sure there's a root complex dip isn't hard, it's just shitty

by which I mean, if we decided it was a good shape for the future, it could be done gently to x86

you just have to create the RC dip either 1) a bit sooner than before, or 2) at exactly the same spot, but let autoconf look below it

it just makes the implementation even kookier

:(

but between x86, devicetree arm, and acpi (both), I think we have a startling mix of how differently you might have to do all this

[illumos-gate] 17879 Update Intel microcode to 20260210 -- Dan McDonald <danmcd⊙ei>

oh, also, I fully rewrote pci_boot like, 4 times, and fucked it up each and every one

if you don't have the PCI spec, the PCI firmware spec, the firmware bit of the PCIe spec, and a collection of hardware, you're going to get frustrated

rzezeski: did you ever decide whether to add "%#x" to the kernel?

PF solaris port : hachyderm.io/@alanc/116110929827583992