Re: PCI I/O Space Consumption Limitation

["Monish Shah" <monish@mcsy2.fc.hp.com>]

On Aug 22, 12:00pm, David O'Shea wrote:
> Subject: Re: PCI I/O Space Consumption Limitation
>
> The issue of using I/O mapped BAR is not as clear cut as the spec.
> might suggest.   Certainly the advice of avoiding I/O BAR is bad
> advice.   Please see my sermon on the subject below.

This definitely deserves my sermon against I/O space. :-)

David O'Shea's main point, as quoted below, was that I/O space is required
if your device is used for booting (in a PC compatible system).

> If your device is to used for booting
> the system then you MUST supply an I/O space BAR for status/control/data
> path to your PCI device.   This is NOT a requirement of the PCI specification
> but rather an IMPLICIT REQUIREMENT of the PC-legacy expansion ROM definition
> and the fact that system BIOS will NOT assign memory mapped BAR's below 1MB.

I don't disagree with this.  In fact, I had acknowledged this in passing in
my previous message in this thread.

However, here's my problem:  I/O port space is a precious commodity because
there is only 64 KB of it.  Yes, in theory it could be extended.  But, card
BIOSes, working with their early 80s programming model, wouldn't be able to
talk to that either.  So, we have to work with the 64K limit.

Now, if you look at the PCI to PCI bridge (PPB) spec, you'll find that they
only deal with I/O space in increments of 4KB.  So, if you put a couple of
devices behind a PPB, and at least one device requires even a single byte
of I/O space, you've burned 4KB of that space.  If you have 16 such cards,
you've lost the entire space!  Presumably, you needed atleast the first 256
bytes of I/O space for motherboard I/O.  So, you're already in trouble.
You can't assign all the space required.

Does 16 cards sound outlandish?  If so, may I point out that the DEC 8400
currently supports 144 PCI slots.  That is Alpha based and presumably
doesn't have to deal with BIOS, but certainly it is reasonable for somebody
to want to build a PC compatible system with 16 slots.  While PPBs on every
card is a rarity, note that in a system with 100+ slots, only a small
percentage of the cards would have to have PPBs before one gets into
trouble.

To make matters worse, even if a card has both an I/O BAR and a memory BAR,
you can't be sure that the driver will only talk to it with the memory BAR.
Indeed, the memory BAR may be mapping something completely different from
what the I/O BAR is mapping and both may be required for proper operation.
So, you don't even know which I/O BARs can safely be left uninitialized.

The conclusion:

- Avoid I/O BARs if you can.  If you must have one, request as little space
  as you possibly can.

- In the longer term, one might explore mechanisms by which I/O BARs can be
  declared as non-essential to the driver.  That way, if the system BIOS
  runs out of I/O space, it would have some clue about which BARs can be
  left uninitialized.

> Further, as described by others on this thread already, the devices I/O
> function must be broken up into 256 byte chunks in order allow the system
> BIOS to place all such functions into the aliases of the 0-FFh range of
> a 4K chunk.    This later restriction is based on the fact that some 16-bit
> ISA devices were specifically designed to avoid conflicts with 10-bit I/O
> devices and yet have more I/O function registers....
> .... (Very few devices had this 16-bit alias quality.  The PCI spec
> writers did us a diservice by requiring the 256 byte limit to maintain
> compatiblity with these dying devices...)

Unfortunately, VGA cards do this routinely.  Since improved graphics
performance was the single biggest motivation for PCI, the spec writers
really didn't have a choice.  I suppose if VGA was the only concern, they
could have made the limit 512 byte, but that would have only made the
problem of limited I/O port space worse.

...

> -David O'Shea
> daveo@corollary.com

Monish Shah
Hewlett Packard
v
D2