[+cc Martin] On Thu, Oct 08, 2015 at 09:33:10PM +0000, Keith Busch wrote: > 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. Yes, this could be a real can of worms. > 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. If you make the kernel start using domain numbers that don't fit in 16 bits, what happens if you run the old lspci on a new kernel? Bjorn -- 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
