Re: 64 bit BARs

[Devendra K Tripathi <tripathi@Synopsys.COM>]

Hi Matt,

Just a comments:
 A device may request memory 4 or more GBytes. In such cases the BAR type must be
   "locate anywhere in 64 bit space". Actually if memory is more than 2 GB, it must be
 locatable in 64 bit space because as you pointed out, the 2 GB can not be assigned
 to lower space.

Thanks,
Tripathi.  


> 
>     Can a PCI device request more than 32 bits of memory space? It can
>     certainly be allocated memory anywhere in 64-bit space (assuming it
>     implemented its BARs properly) but should config software have to
>     worry about a device wanting more than 32 bits worth of data? I
>     thought that given the low 4 bits of memory BARs were predefined
>     the limit was something like 2GB.
> 
> I see no reason why we should not allow devices to grab big chunks of
> the 64 bit address space.
> 
> Granted, a "make me in the lower 4GB" BAR is limited to 2GB (you
> probably need at least one settable bit in a 32 bit BAR but I don't see
> where the letter of that law is laid down).
> 
> Devices that want more than 0.5 GByte are antisocial in 32 bit
> addressable systems.  You won't get more than 2 or 3 of them in a
> system.
> 
> Note that it is not possible for a single BAR to describe memory that
> CROSSES the 4GB boundary.  Regions must be a power of 2 in size
> starting on the same power of 2 boundary, so you can't have anything
> cross the 4GB boundary unless it is something like an 8GByet device
> assigned to location 0.  Zero is a reserved value for the BAR contents
> (per earlier discussions on this list, check the archive for details).
> 
>     Reason I'm asking, reading the spec it states that when trying to
>     determine the size of a memory range you write 'all bits one' into
>     'the register' and reading the value back. By my literalist
>     reading, even if the memory can be mapped anywhere in 64 bit space,
>     config software need only write all bits one to the lower of the 2
>     BARs that comprise a 64 bit address.  It needs to read both BARs if
>     the device can be mapped anywhere, however.
> 
> My reading is that a 64 bit BAR is logically "one register", even
> though the config space it's built from could also be one or two 32 bit
> BARs in other devices.
> 
> Note that Figure 6-5 on page 196 does not indicate an upper bit.  Also
> note that the last paragraph on page 196 talks about base registers
> being either 32 or 64 bits wide.  It does not talk about a Pair of
> registers" being concatenated, but rather about a single 64 bit
> register.
> 
> If you're on a tiny system (4GB physical addressing so you'll never get
> to place anything above 4GB) and you depend on the BAR contents being 0
> at reset, you could get away with ignoring the upper 32 bits of a 64
> bit BAR since they would already be 0 and the only reasonable value you
> could use would also be zero.
> 
>     Speaking of which, if a device can be mapped anywhere in 64 bit
>     space, is it correct to assume that to find where the device has
>     been mapped you must read 2 BARs, even though its likely the
>     'higher' BAR (the one after the one whose lower order bits specify
>     'anywhere in 64 bit space') in most systems will be all zeros? That
>     is, the address is constructed by 'stringing together' the higher
>     bar if its non-zero and the lower one?
> 
>     Hope this makes sense. Comments?
> 
>     Matt
> 
> ------------
> Steve Glaser				Digital Equipment Corporation
> glaser@lkg.dec.com (or NACTO::GLASER)	550 King Street	LKG1-2/W6
> +1.508.486.7212  FAX: +1.508.486.5279	Littleton, MA 01460-1289
> 
dp	^