RFC: 64-bit resources and changes to pci, ioremap, ...

RFC: 64-bit resources and changes to pci, ioremap, ...

[Kumar Gala]

As I started to update the existing patches to make struct resource  
have 64-bit start and end values I started to see all the places that  
this effects and was hoping to get some discussion on what direction  
we want to take.

One of the main reasons to make this change is to handle processors  
that have larger physical address space than effective.  A number of  
higher-end embedded processors are starting to support larger  
physical address space while still having a 32-bit effective  
address.  I was wondering if any x86 variants support this type of  
feature?

The main issue that I'm starting to see is that the concept of a  
physical address from the processors point of view needs to be  
consistent throughout all subsystems of the kernel.  Currently the  
major usage of struct resource is with the PCI subsystem and PCI  
drivers.  The following are some questions that I was hoping to get  
answers to and discussion around:

* How many 32-bit systems support larger than 32-bit physical  
addresses (I know newer PPCs do)?
* How many 32-bit systems support a 64-bit PCI address space?
* Should ioremap and variants start taking 64-bit physical addresses?
* Do we make this an arch option and wrap start and end in a typedef  
similar to pte_t and provide accessor macros to ensure proper use?

Andrew has also asked me to post size comparisons of drivers/*/*.o  
building allmodconfig with 32-bit resources and 64-bit resources to  
see what the size growth is.  I'll post logs for people to take a  
look at in a followup email.

- Kumar

Re: RFC: 64-bit resources and changes to pci, ioremap, ...

[Deepak Saxena]

On Jul 29 2005, at 10:53, Kumar Gala was caught saying:
> The main issue that I'm starting to see is that the concept of a  
> physical address from the processors point of view needs to be  
> consistent throughout all subsystems of the kernel.  Currently the  
> major usage of struct resource is with the PCI subsystem and PCI  
> drivers.  The following are some questions that I was hoping to get  
> answers to and discussion around:
>
> * How many 32-bit systems support larger than 32-bit physical  
> addresses (I know newer PPCs do)?

Intel's new XSC3 ARM core supports up to 36-bit addressing and 
they have several CPUs based on this that are already out or will
be released in the next year. I can currently get around 64-bit
resources by playing ugly tricks with the memory map and trapping
ioremap() calls to a certain unused 32-bit physical range and fixing 
it up to 64-bit (like PPC440?? does) but that may not work on future
CPUs that don't have holes in the memmap.

> * How many 32-bit systems support a 64-bit PCI address space?

This is a fairly common thing on some of the Intel XScale I/O and
network processors. Some of the Intel CPUs provide a window in 
32-bit CPU that translates to 64-bit PCI space.

> * Should ioremap and variants start taking 64-bit physical addresses?

If we are to use 64 bit resources, then yes. Or pfns...

Do a google for my real opinion on this. I think ioremap() should take 
a device and resource describing the address of the resources in the
address space of the device (the bus it is one). The whole resource 
and I/O subwystem currently assumes that physical and PCI bus address 
spaces are one and the same, but I have HW that breaks this assumption 
by allowing up to 2 GB of RAM and 3GB of PCI devices. Whenever this
has been brought up though, Linus has shot it down. What we need is
a real concept of per-bus address spaces and resources. But that is
far more complicated change.

> * Do we make this an arch option and wrap start and end in a typedef  
> similar to pte_t and provide accessor macros to ensure proper use?

Probably the best thing to do b/c on really small systems that 
don't have 64-bit needs, we'll just be wasting memory with the
extra data structure size. We need to scale down to PCI systems
with just 8MB of RAM.

~Deepak

-- 
Deepak Saxena - dsaxena@plexity.net - http://www.plexity.net

Even a stopped clock gives the right time twice a day.

Re: RFC: 64-bit resources and changes to pci, ioremap, ...

[Doug Reiland]

current pentium4 have this problem as well. Shouldn't
need to use the emt64 (x86_64) mode. It takes i/o
bridges and MCH to support it, but the latest Intel
ones do. However, I am pretty sure BIOSes wouldn't
assign the pci/pci-e addresses > 4GIG so most are not
impacted.


--- Kumar Gala <kumar.gala@freescale.com> wrote:

> As I started to update the existing patches to make
> struct resource  
> have 64-bit start and end values I started to see
> all the places that  
> this effects and was hoping to get some discussion
> on what direction  
> we want to take.
> 
> One of the main reasons to make this change is to
> handle processors  
> that have larger physical address space than
> effective.  A number of  
> higher-end embedded processors are starting to
> support larger  
> physical address space while still having a 32-bit
> effective  
> address.  I was wondering if any x86 variants
> support this type of  
> feature?
> 
> The main issue that I'm starting to see is that the
> concept of a  
> physical address from the processors point of view
> needs to be  
> consistent throughout all subsystems of the kernel. 
> Currently the  
> major usage of struct resource is with the PCI
> subsystem and PCI  
> drivers.  The following are some questions that I
> was hoping to get  
> answers to and discussion around:
> 
> * How many 32-bit systems support larger than 32-bit
> physical  
> addresses (I know newer PPCs do)?
> * How many 32-bit systems support a 64-bit PCI
> address space?
> * Should ioremap and variants start taking 64-bit
> physical addresses?
> * Do we make this an arch option and wrap start and
> end in a typedef  
> similar to pte_t and provide accessor macros to
> ensure proper use?
> 
> Andrew has also asked me to post size comparisons of
> drivers/*/*.o  
> building allmodconfig with 32-bit resources and
> 64-bit resources to  
> see what the size growth is.  I'll post logs for
> people to take a  
> look at in a followup email.
> 
> - Kumar
> 



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs