Opened 15 years ago

Last modified 6 years ago

#11 new enhancement

Support PAE on ia32

Reported by: Jakub Jermář Owned by: Martin Decky
Priority: minor Milestone:
Component: helenos/kernel/ia32 Version: mainline
Keywords: gsoc12, gsoc13, gsoc14, gsoc15, gsoc16, gsoc17, gsoc18 Cc:
Blocker for: Depends on: #3
See also:

Description (last modified by Jakub Jermář)

Add support for Physical Address Extension to our ia32 port so that more than 4G of physical memory can be addressed.

On all currently supported 32-bit platforms (arm32, ia32, mips32, ppc32), HelenOS assumes 32-bit physical addresses. This allows the system to make use of 4G of physical memory in total. Some of these architectures, however, provide extensions (e.g. PAE on ia32, LPAE on arm32) that make it possible to address more physical memory by using wider physical addresses (e.g. 36-bit or 40-bit).

There are actually two goals for this project. The first is to modify HelenOS to use a dedicated type for representing physical addresses instead of the current uintptr_t or void *, because the assumption that both virtual and physical addresses have the same amount of bits will no longer hold. The second goal is to implement the actual support for PAE in the form of PAE page table format and PAE feature detection and initialization.

What Gains and Benefits will this bring?
By having the PAE support on ia32, HelenOS will be able to utilize more of the installed memory. HelenOS will also become ready to support similar features on other architectures (think LPAE on arm32).
Required skills
Kernel programming skills are needed and the applicant should be strong in C and should have the ability to understand the HelenOS memory management subsystem quickly.
Possible mentors
HelenOS Core Team, Jakub Jermar

Change History (27)

comment:1 by Martin Decky, 15 years ago

Milestone: 0.5.0

comment:2 by Jiri Svoboda, 15 years ago

Component: kernel/ia32

comment:3 by Jakub Jermář, 13 years ago

Depends on: #3

comment:4 by Jakub Jermář, 13 years ago


comment:5 by Jakub Jermář, 12 years ago

Keywords: gsoc12 added

comment:6 by Jakub Jermář, 12 years ago

Keywords: needswork added

comment:7 by Jakub Jermář, 12 years ago

Description: modified (diff)
Keywords: needswork removed

comment:8 by Jakub Jermář, 12 years ago

Description: modified (diff)

comment:9 by Jakub Jermář, 12 years ago

Description: modified (diff)

comment:10 by Jakub Jermář, 12 years ago

Description: modified (diff)

comment:11 by Martin Decky, 12 years ago

Description: modified (diff)

comment:12 by Jakub Jermář, 11 years ago

Keywords: gsoc13 added

comment:13 by Vojtech Horky, 11 years ago

Description: modified (diff)

comment:14 by Vojtech Horky, 11 years ago

Description: modified (diff)

comment:15 by Martin Decky, 11 years ago

Description: modified (diff)

comment:16 by Martin Decky, 10 years ago

Keywords: gsoc14 added

comment:17 by Jakub Jermář, 10 years ago


comment:18 by Jakub Jermář, 9 years ago

Keywords: gsoc15 added

comment:19 by Jakub Jermář, 8 years ago

Keywords: gsoc16 added

comment:20 by Jakub Jermář, 8 years ago

Milestone: 0.6.1

comment:21 by Jakub Jermář, 7 years ago

Description: modified (diff)

comment:22 by Jakub Jermář, 6 years ago

Keywords: gsoc18 added

comment:23 by Jakub Jermář, 6 years ago

Description: modified (diff)

comment:24 by Jiří Zárevúcky, 6 years ago

Is this still something we are interested in? ia32 is very nearly extinct by now, arm's 64b variant is slowly entering mainstream as well, and I have personally never seen an arm32 board with more than 4GB RAM.

comment:25 by Martin Decky, 6 years ago

Despite the arguable obscurity I would still prefer to keep the ticket. It is an interesting opportunity to come up with a generic support for the case where the physical address space is larger than the virtual address space (or, even more generally, with a well-designed type-safe support for physical and virtual pointers). The priority is minimal, of course.

comment:26 by Jiri Svoboda, 6 years ago

Aren't there 32-bit Intel Atoms? While desktop/server processors are moving to 64-bit, 32-bit processors seem to be rather popular choice for embedded use, in general (AVR32, Leon is a 32-bit SPARC, etc.). ia32 seems like a good particular case to implement the general feature, which can be useful in other cases (e.g. >64 bit physical space).

comment:27 by Jiří Zárevúcky, 6 years ago

Atom CPUs have had 64b support since 2008 (though according to wiki, motherboard support is another story). Besides, 32b embedded boards with >32b physical address space sounds like something utterly cost-inefficient.

But I do agree that it's a good test case for improving kernel interfaces.

Note: See TracTickets for help on using tickets.