richlowe: I'd like to see it added, but I personally have not had the time or priority for it yet.

richlowe: that would be nice... i'll hopefully know more next week, but there's a pretty decent chance that I'll _will_ need PCI segment support, and quickly... even if I have to do a 'quick and dirty' and not something upstreamed, but it'd be nice if I could at least advance the state of things towards where we want to go, even if not everything goes upstream (because quick and dirty)

jbk: In terms of where we want to go, I started drafting something a while back on that, but still needs some work: github.com/illumos/ipd/blob/master/ipd/0060/README.adoc

Basically short form is add a new pci-segment property on root ports using a prd method to figure it out. Then nexus drives like npe need to look at that property on children when it's doing a bus map and translate appropriately.

While I'm not goign to have a ton of spare time over the coming weeks, let me know how I can help here jbk. I think something simple won't be too bad as long as you don't care about userland tooling like pcieadm or some of the other stuff working 100%.

I'll see if I can get some stuff firmed up there and get the doc into broader discussion.

i actually have some bits from trying to get the HP Gen12's working (since i was still trying to figure out what was needed) that actually sets a property (I guess a good sign I also picked 'pci-segment' for it :P) on all the NPE devices... I'm guessing/hoping where we're accessing cfgspace with a dip for the dev in question, it shouldn't be too bad to just lookup the property (letting it inherit from the

ultimate parent npe)

the ugly part is all the alternate ways we seem to have in x86 to access cfg space (even when it seems like we should have a good dip to use)

there's the pci_{get,put}{b,w,l}_func() pointers, then there's pci_cfgacc_acc_p (which does use the former, but also at least includes a dip)

then there's pci_config_{rd,wr}{8,16,32} (and the rep variants) which only sometimes have a dip

not to be confused with DDI pci_config_{get,put}{8,16,32,64} functions

and as far as I can tell are specific to x86

They call eachother

you can get rid of one layer (I did)

I think richlowe/arm64/pci-hacking may still exist

richlowe/arm64/pci* even, there's other cfgspace-y things in there

have any of you messed with id32?

and/or know why " * For amd64 the 32 bit id is the offset of the entry in the arena"

jbk: and github.com/richlowe/illumos-gate/bl…te/doc/pci-express/pci-express.adoc

wow, I am nonplussed by id32