On Thu, 8 Oct 2015, Bjorn Helgaas wrote:
On Wed, Oct 07, 2015 at 12:21:02AM +0000, Keith Busch wrote:
Thank you for bringing this up as I hadn't thought much about it and may
have misunderstood the meaning of _SEG. AIUI, it is used to identify a
logical grouping. The OS does not need to use the same identifier for
the domain, so we there's no need to collide if we can assign the domain
of a a new _SEG to the next available domain_nr.
Yes, I guess it would be possible to decouple _SEG and Linux PCI
domain numbers. It's *convenient* to have them the same, so dmesg and
lspci output matches _SEG directly, but I guess you could argue that's
not essential.
I think we'd have to maintain a mapping from domain back to _SEG to
deal with firmware interfaces that expect _SEG, e.g., ia64 PAL calls.
It looks like there are lots of assumptions in the kernel that segment
and domain are the same thing. I don't have the necessary h/w to test
any changes here to verify the mappings are handled correctly, so I'm
apprehensive to start changing this much code that I can't test.
Given that domain_nr is a 32-bit integer, APCI's _SEG is only 16 bits,
and the pci domain is purely a software construct, do you see any problem
if we start these 'special' domains at 0x10000? I've tested this in
the driver and lspci + setpci with the single line update in pciutils'
lib/pci.h, and it all seems to work just fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
