Method for Partial Configuration (Was: Re[2]: BAR value of zero?)

[Richard Walter <rwalter@corp.auspex.com>]

Folks,

Originally, I was just going to send this back to Kim since I don't really
have a strong objection to using 0 as a special case (after all, restricting
some relatively small portion of memory space isn't going to be the end
of the world.) *IF* this were explicitly stated.

I do have a strong opinion that if people really want to use 0 as a special
case then it ought to be documented in a stronger posisition in the spec
than simply as a second "Note:" of an implementation note.  Especially
since page xvi of the 2.1 spec states "Implementation notes are enclosed
in a box.  They are not part of the PCI specification and are included for
clarification and illustration only."  This is the main reason why I continue
to state that the spec is vague on the zero BAR issue;  Technically, the
spec does not state that a zero BAR is invalid.

But the more I looked at it, the more I thought that this might be the germ
of a solution to the partial configuration problem.  My major issue with
partial configuration is that there is no way for a device to indicate which
BARs are required for operation and which are optional to allow partial
configuration.  Ideally, a device would have a small BAR which would be
required and a larger BAR which would allow better/faster/stronger opperation,
but wouldn't be absolutely necessary for correct operation.

Therefore, I'm sending this out to the entire mailing list for thought,
discussion and general perusal.

Warning: Wild speculation follows that has no real bearing on the current PCI
universe.  Enter at your own risk.

kolsen@avionics.itt.com (Kim Olson) wrote:
> I agree with your concept that BAR 0 could be a valid address with a bit
> that enables that function.  I would actually consider using the reserved
> bit(s) of the BAR.  If the BAR value where 0 and the type = 11b for memory
> space or reserved bit = 1b for I/O then the BAR would be valid at 0.

Now there's a real interesting thought.  I like this!

Suppose:

For an I/O BAR, bit 1 (which is now reserved) becomes an optional read/write
bit.  If this bit is a 1, then 0 is considered a valid I/O BAR and if this
bit is a 1, then 0 is considered an invalid I/O BAR.  Configuration software
would determine if this bit is implemented the same way as any other BAR bits,
but it would be able to set it to 1 if the configurator wanted to assign some
device to 0.  And this would be backware compatible with both old devices &
old configuration utilities.

For Memory BARs, things get a little murkier, since the type bits are
read-only as a way for the device to tell the configuration software what
it wants and I don't like the idea of changing read-only bits to read/write
ones. (I've been very vocal against the evil that was done for the IDE
programming interface byte.)

But, suppose a type of 11 meant that the BAR is 32-bits wide, mapping to
anywhere in 32-bit memory space, and 0 is considered valid.  (ie: It is
the same as type 00, with the added proviso that 0 is valid (and type 00
would be augmented to indicate that 0 is explicitly considered invalid.))
And, we also explicitly state that 64-bit BARs are never located at the
bottom of memory.  (This seems reasonable to me, since if a single 64-bit
BAR were ever located at the bottom of memory, it would instantly overlap
every 32-bit BAR in the system, which is obviously not good.)

So, if there was a non-Intel system that allowed PCI devices to be mapped
at physical address 0, it could determine for sure that some device could
be placed there.

Now, we have the ability for a device to specify which BARs are optional
and which are mandatory to aid partial configuration.  It would work like
this:

If a device wants a BAR to be mandatory, then it indicates that 0 will
be considered valid.  (Configuration software is under no requirement to
actually set a device there, but it could if it wanted to.)  This means
that this BAR will always be used, no matter what address is given to it.

If a device wants a BAR to be optional, then it indicates that 0 will
be considered invalid, and configuration software could set individual
BARs to 0 to disable those.

64-bit BARs would always be considered optional, and the upper 32-bits would
be used to determine it was enabled or not.  A 0 in the upper 32-bits would
indicate that the BAR was disabled.  A non-0 in the upper 32-bits would
mean that the BAR is valid.

And finally, to make it all work with both new & old hardware, we take one
of the reserved bits in the status register to indicate to configuration
software if this device supports this "optional BAR" encoding or not.

All in all, this might be a doable thing, but it might also just be an
interesting intellectual exercise.

I believe that the zero-BAR issue can be settled rather easily by putting
a statement one way or the other explicitly in the spec.  Which way doesn't
really matter to me, as long as one is clearly spelled out so that everyone
is clear.

I also think that partial configuration is an interesting issue that deserves
to be investigated.  How important this issue is remains to be seen.

> 
> On the side, the real mode interrupt vectors reside in memory space at
> 0000:0000 in Intel architecture.  There is nothing that prevents the use
> of I/O space beginning at 0.

True, I was thinking only of memory space before.  However, I/O space from
0-0xFF is used (in PC-compatables) for standard motherboard devices (DMA
controller, Interrupt controller, timers etc...) so 0 isn't really available
for I/O either.

> 
> Kim
> 

Sincerely,
-Richard Walter
rwalter@corp.auspex.com
Note: I speak for myself, not for Auspex.