[haiku-development] 64 bit physical addresses
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 22 Jun 2010 16:03:31 +0200
Howdy,
I've finished crawling through the kernel add-ons, trying to fix all issues
with 64 bit physical addresses. The physical addresses of allocated memory
are irrelevant for most software, save for drivers for hardware that e.g.
supports DMA. Some -- mostly older -- hardware can only deal with 32 bit
addresses, which poses a problem when there is physical memory beyond the 4
GB limit. I've recently implemented PAE support (not compiled in by
default), which allows to use this memory on x86, but the situation is the
same for actual 64 bit architectures like x86_64.
There are a few drivers for hardware that supports 64 bit addresses (like
HDA, AHCI, some network drivers), but in most cases I had to force memory
allocations made by drivers to use only physical memory below 4 GB. This
can be done via the kernel private create_area_etc() call with the
respective physical address restrictions or with create_area() and the
newly introduced lock parameter constant B_32_BIT_MEMORY, which implies
B_CONTIGUOUS with physical address < 4 GB. (*)
I wouldn't rule out that I have missed occurrences, so it would be great,
if driver developers could have a look at their drivers for problems with
64 bit physical addresses.
I wasn't quite sure what to do what to do with several drivers for USB
devices (usb_serial, usb_audio, etc.). They allocate memory with
B_CONTIGUOUS -- usually a sign for memory for DMA -- but the physical
addresses are never retrieved as far as I have seen. I might have
overlooked something, though.
Finally I want to ask what everyone thinks about enabling PAE support. IMO
it would be nice, but it's not really a must-have feature, as the
additional memory beyond the 3.x GB that should always be accessible
(mostly depending on the gfx memory) probably won't be used for anything
but caching, anyway. An advantage would be that our drivers would already
get a bit of 64 bit exposure.
Building PAE support in costs a bit of memory (since all structures
containing physical addresses will be a bit larger, initially additionally
about 0.1% of the total memory). Building it in alone causes only binary
compatibility issues with the get_memory_map() and map_physical_memory()
functions, which can be easily solved, though.
Whether PAE paging is used is decided at boot (only when it is needed at
all). When it is used, drivers could be faced with physical addresses they
can't deal with. The drivers in the repository should be fine now (save
where I missed something). For older drivers I would simply force all
create_area() calls to use B_32_BIT_MEMORY via a compatibility wrapper
function. That will probably satisfy most drivers. Some could get memory
from other sources (I believe graphic card drivers can support DMA from/to
user-provided memory), but since the compatibility get_memory_map() would
panic when encountering addresses > 4 GB, that would at least not slip by
unnoticed (and corrupt memory).
I intend to add a boot loader safemode setting and a kernel settings file
option to enable/disable PAE. So there are essentially the following
options:
1. Don't build PAE support in.
2. Build PAE support in, but make it opt-in via kernel settings.
3. Build PAE support in, but make it opt-out via kernel settings.
Opinions?
CU, Ingo
(*) Some machines have a dedicated MMU for DMA address translation, which
would allow for a nicer solution (simply mapping addresses > 4 GB to
addresses < 4 GB for hardware that needs it), but not all do and ATM we
don't support that anyway.
Other related posts:
