Fork us on GitHub Follow us on Google+ Follow us on Facebook Follow us on Twitter

Opened 10 years ago

Last modified 4 weeks 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.

Details
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).
Difficulty
High
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.
Documentation
Possible mentors
HelenOS Core Team, Jakub Jermar

Change History (27)

comment:1 Changed 10 years ago by Martin Decky

Milestone: 0.5.0

comment:2 Changed 10 years ago by Jiri Svoboda

Component: kernel/ia32

comment:3 Changed 8 years ago by Jakub Jermář

Depends on: #3

comment:4 Changed 8 years ago by Jakub Jermář

Milestone: 0.5.00.5.1

comment:5 Changed 7 years ago by Jakub Jermář

Keywords: gsoc12 added
Milestone: 0.5.00.5.1

comment:6 Changed 7 years ago by Jakub Jermář

Keywords: needswork added

comment:7 Changed 7 years ago by Jakub Jermář

Description: modified (diff)
Keywords: needswork removed

comment:8 Changed 7 years ago by Jakub Jermář

Description: modified (diff)

comment:9 Changed 7 years ago by Jakub Jermář

Description: modified (diff)

comment:10 Changed 7 years ago by Jakub Jermář

Description: modified (diff)

comment:11 Changed 7 years ago by Martin Decky

Description: modified (diff)

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

Keywords: gsoc13 added

comment:13 Changed 6 years ago by Vojtech Horky

Description: modified (diff)

comment:14 Changed 6 years ago by Vojtech Horky

Description: modified (diff)

comment:15 Changed 6 years ago by Martin Decky

Description: modified (diff)

comment:16 Changed 5 years ago by Martin Decky

Keywords: gsoc14 added

comment:17 Changed 4 years ago by Jakub Jermář

Milestone: 0.5.10.5.2

comment:18 Changed 4 years ago by Jakub Jermář

Keywords: gsoc15 added

comment:19 Changed 3 years ago by Jakub Jermář

Keywords: gsoc16 added

comment:20 Changed 3 years ago by Jakub Jermář

Milestone: 0.6.1

comment:21 Changed 21 months ago by Jakub Jermář

Description: modified (diff)

comment:22 Changed 10 months ago by Jakub Jermář

Keywords: gsoc18 added

comment:23 Changed 10 months ago by Jakub Jermář

Description: modified (diff)

comment:24 Changed 5 weeks ago by Jiří Zárevúcky

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 Changed 4 weeks ago by Martin Decky

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 Changed 4 weeks ago by Jiri Svoboda

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 Changed 4 weeks ago by Jiří Zárevúcky

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.