Re: [patch] PCI Express Enhanced Config Patch - 2.6.0-test11

[ebiederm@xmission.com (Eric W. Biederman)]

Matthew Wilcox <willy@debian.org> writes:

> On Sat, Jan 31, 2004 at 02:57:29PM -0700, Eric W. Biederman wrote:
> > Is it really safe to treat the base address as a u32?  I know
> > if I was doing the BIOS and that address was tied to a 32bit BAR I
> > would be extremely tempted to put those 256M of address space above
> > 4G.  Putting something like that below 4G leads to 1/2 Gig of memory
> > missing. 
> 
> This is actually a Linux limitation -- we're pretty bad at dealing with
> 64-bit BARs on 32-bit architectures.  There's two interfaces to get
> at it -- ioremap() and set_fixmap().  Both of these interfaces take an
> unsigned long to describe a physical address.

Which is another issue besides PCI express.  This 32bit VM on a 64bit
box I find quite annoying.  Now that there are 64bit x86 alternatives
I won't be shy about using 64bit addresses in BARs, if I need them.  
On a box with 4G or more you need PAE anyway...

I'm wondering if ioremap or set_fixmap could be modified to take
a page frame number or possibly a token like the dma mapping functions
so we don't need all of the low bits and can actually solve these
problems on a 32bit architecture.

> > Point being I don't think it is safe to assume the BIOS always puts
> > the extended PCI configuration space below 4G.
> 
> MCFG isn't described in any released version of the ACPI spec, so I
> don't know whether it's even possible for it to be a 64-bit address.
> There's a reserved field that might be used for the upper 32 bits.

The first draft of the patch had a u64 there.  So I think we should
at least check to ensure the high half is zero.  If it the high half
is not zero we can print an annoying error message.  All of the normal
pci capabilities are still limited to being in the first 256 bytes of
the configuration space.  So not a lot is lost if we can't enable the
entire 4K. 

There is also one piece I did not see the PCI Express configuration
space for the root complex.  This is a configuration space with no pci
bus/dev/fn numbers, if my memory serves me correctly.

On the interface side I also have the question how it will be
described when there are multiple memory configuration spaces
corresponding to disjoint pci configuration spaces.  I don't think
we can easily support that in Linux at the moment but there is no
reason why there can't be a table entry for it.

Eric