Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net writes:
On 13.04.2010 09:28, Arne Georg Gleditsch wrote:
Stefan Reinauer stepan@coresystems.de writes:
Nice... !
I've been wondering before... why this odd approach with read8x and gs:... instead of just doing normal read8/16/32 ?
Primarily to enable mapping in 64-bit space, I suppose. I guess we could map AMD fam10 mmio config space into 32 bit-space as well, the main reason not to is that it consumes quite a lot of space.
Mh. This also means that any OS using MMCONFIG (either directly or through ACPI) has to be 64 bit. Among others, this will break some Linux Live CDs (which are 32bit, although there are 64bit variants out there for some of them). Oh, and Windows might be affected, too.
This is true. We could map the MMCONFIG area into 32-bit address space, if we wanted. That would remote quite a bit of complexity. Addressing all 256 PCI buses requires 256M, and I see there are vendors who are using 0xe0000000 - 0xf0000000 for this. We can configure the window to be smaller according to the actual number of buses present, but I'm not sure it's worth it.
I'm not exacly sure where to hook into the resource allocation framework to register such a range, but the actual changes ought to be fairly small.
As far as I know, we're not communicating any information about the the MMCONFIG area we've set up to the OS at present, so it's not really a pressing issue. (I suppose we do want to do so, however.)