02:04:09 <jbk> anyone know of a reason why pcf_cfgacc_x86.c appears to map and unmap the PCI config space on every access?
02:04:38 <jbk> (just curious.. seems like we could map it once w/ appropriate attributes and leave it)
02:06:02 <jbk> (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
08:30:31 <tsoome> too bad there is no commit log.
14:52:36 <jbk> 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...
15:07:54 <rmustacc> Being able to reliably access config space without the device tree is fairly unique to x86.
15:08:50 <rmustacc> 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.
19:49:32 <richlowe> doesn't ecam on x86 map the physical through a window?
19:50:23 <richlowe> jbk: I rewrote how our pci config access works for ARM, you should look at arm64-gate 
19:50:47 <richlowe> (though not fully, in the x86 side, in deference to rmustacc and a thoughtful mergee)
19:51:11 <richlowe> 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 
19:51:44 <richlowe> (we also enumerate via a bus op, rather than a magic call at configure time)
19:52:02 <richlowe> it seems like if we're all redesigning that we should all pull together
20:08:14 <rmustacc> ECAM is generally a contiguous region noawadays, but that's an AMD focus.
20:08:49 <rmustacc> 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.
20:08:57 <rmustacc> I agree though that any changes should be coordinated and planned.
20:40:51 <richlowe> 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
20:40:54 <richlowe> maybe that was only for pcitool
20:41:30 <richlowe> rmustacc: so on x86 making sure there's a root complex dip isn't hard, it's just shitty
20:41:45 <richlowe> by which I mean, if we decided it was a good shape for the future, it could be done gently to x86
20:42:30 <richlowe> 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
20:42:43 <richlowe> it just makes the implementation even kookier
20:42:44 <richlowe> :(
20:43:31 <richlowe> 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
21:05:49 <gitomat> [illumos-gate] 17879 Update Intel microcode to 20260210 -- Dan McDonald <danmcd⊙ei>
21:09:58 <richlowe> oh, also, I fully rewrote pci_boot like, 4 times, and fucked it up each and every one
21:10:19 <richlowe> 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
22:13:07 <richlowe> rzezeski: did you ever decide whether to add "%#x" to the kernel?
22:42:45 <szilard> PF solaris port : https://hachyderm.io/@alanc/116110929827583992