[coreboot] PCI IO Address space over 0xffff

[Peter Stuge]

Joe Korty wrote:
> I've solved this one, kind of.  It is PCI IO Space
> overflow, we are going over 0xffff which apparently is
> a hard limit.

On x86 it is very much a hard limit. Not so on other architectures.


> I image this is there so that inb, outw,
> etc instructions can be used to reference these devices.
> 
> But if one doesn't use such instructions (instead using
> memory mapped PCI IO space),

The feasibility of that is totally device dependent. PCI devices can
expose all combinations of I/O and memory, and only the device driver
knows which one to use how.


> I see no reason why Linux and coreboot couldn't work with PCI IO
> Space addresses > 0xffff.

The I/O opcodes on x86 are limited to 16 bit addresses. Since this
is part of the architecture, both Linux and coreboot make this
assumption on x86 systems.


Joe Korty wrote:
> Heck, even my failing large IO configuration is not really
> very large.  I am putting only one expansion chassis on
> the system.

Either you are just totally out of luck with the I/O space situation,
or there is room for improvement in coreboot. Not at all impossible.

What cards did you have in this expansion chassis? Would it be
possible for you to provide lspci -vv output on that system?
Does the system boot if the chassis is completely empty?


> I expect that we will eventually get customers that will want two
> or even three expansion chassis (each chassis holds 20 PCI-e
> cards).

How do the chassis connect upstream, on PCI level? How does that
upstream-facing component divide address space? Does it reserve
a chunk for everything that can connect downstream? How big a chunk?


> In one sense this is kinda exciting.  Mainframes have
> always been about large IO. That's what distinguishes them
> from PCs.  With these tweaks, PC-like machines can start
> to eat away at the bottom of that market.

Only if 16 bits is enough for all I/O BARs that the plugged-in cards
need.

Maybe the allocation algorithm in coreboot can be optimized to
pack things better into those 16 bits, but worst case you've simply
hit an architecture limitation with x86. :\


//Peter