History log of /haiku/src/system/kernel/arch/ppc/arch_vm.cpp (Results 1 – 14 of 14)
Revision Date Author Comments
# 8271b4a8 16-Sep-2024 Michael Lotz <mmlr@mlotz.ch>

x86/arch_vm: Allow arch_vm_set_memory_type to override type.

We allow requesting an explicit memory type when calling
map_physical_memory but default to the uncached B_MTR_UC when not given.

When c

x86/arch_vm: Allow arch_vm_set_memory_type to override type.

We allow requesting an explicit memory type when calling
map_physical_memory but default to the uncached B_MTR_UC when not given.

When called without an explicitly requested memory type, allow
arch_vm_set_memory_type to modify and return an effective memory type.
When an overlapping range already exists, the effective memory type is
set to the one of the existing mapping. If there is an explicit memory
type request that conflicts with an existing range, or if multiple
overlaps with conflicting types would be produced, the mapping is
disallow (and a panic is triggered under KDEBUG).

This effectively detects and panics when conflicting aliases of physical
memory would be created. This is also useful on an MTRR based setup,
as such overlaps cannot be properly represented.

When using the page attribute table (PAT) to set the memory type on a
per page virtual memory mapping basis, this is needed to prevent
aliasing of the same physical memory with different types. As per the
specs, such aliasing is unsupported and may result in undefined
operations that lead to system failure.

The mechanism is extended to the general arch_vm_set_memory_type as such
aliasing prevention also seems to apply to other architectures (at least
on ARM, aliasing is also strongly discouraged).

Change-Id: I7aaf6ea8415e92e74cd1643b67793a6857619eea
Reviewed-on: https://review.haiku-os.org/c/haiku/+/8339
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

show more ...


# f290297b 21-Aug-2010 Andreas Färber <andreas.faerber@web.de>

ppc: Support other memory types

Let setting the memory type to B_MTR_UC succeed.

Add initial support for those memory types in the translation map,
pointed out by Ingo in ticket #5193.


git-svn-id

ppc: Support other memory types

Let setting the memory type to B_MTR_UC succeed.

Add initial support for those memory types in the translation map,
pointed out by Ingo in ticket #5193.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38292 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...


# 31bce167 20-Aug-2010 Andreas Färber <andreas.faerber@web.de>

ppc: Keep memory mappings set up by OpenFirmware

Revert r36886 and fix compilation of insert_virtual_range_to_keep().
The use of void* vs. addr_t matches the surrounding boot loader code
but should

ppc: Keep memory mappings set up by OpenFirmware

Revert r36886 and fix compilation of insert_virtual_range_to_keep().
The use of void* vs. addr_t matches the surrounding boot loader code
but should probably be revised in favour of addr_t.

create_area() in the kernel wrongly assumed a RAM-backed address range,
which was destined to fail since ranges below the kernel address space
were ignored anyway. Use vm_map_physical_memory() instead.

This fixes a hang once the frame buffer and other resources used by OF
get unmapped. Closes ticket #5193 again.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38291 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...


# 147133b7 25-May-2010 Ingo Weinhold <ingo_weinhold@gmx.de>

* First run through the kernel's private parts to use phys_{addr,size}_t
where appropriate.
* Typedef'ed page_num_t to phys_addr_t and used it in more places in
vm_page.{h,cpp}.


git-svn-id: fil

* First run through the kernel's private parts to use phys_{addr,size}_t
where appropriate.
* Typedef'ed page_num_t to phys_addr_t and used it in more places in
vm_page.{h,cpp}.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36937 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...


# e50cf876 02-Dec-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

* Moved the VM headers into subdirectory vm/.
* Renamed vm_cache.h/vm_address_space.h to VMCache.h/VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34449 a95241bf-73f2-0310-859d-

* Moved the VM headers into subdirectory vm/.
* Renamed vm_cache.h/vm_address_space.h to VMCache.h/VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34449 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...


# a99eb6b5 01-Dec-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

vm_area -> VMArea


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34423 a95241bf-73f2-0310-859d-f6bbb57e9c96


# b0db552c 01-Dec-2009 Ingo Weinhold <ingo_weinhold@gmx.de>

Renamed vm_address_space to VMAddressSpace.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34422 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 74785e79 07-Oct-2008 Ingo Weinhold <ingo_weinhold@gmx.de>

* Added "from" address space parameter to vm_swap_address_space()/
arch_vm_aspace_swap().
* The x86 implementation does now maintain a bit mask per
vm_translation_map_arch_info indicating on whic

* Added "from" address space parameter to vm_swap_address_space()/
arch_vm_aspace_swap().
* The x86 implementation does now maintain a bit mask per
vm_translation_map_arch_info indicating on which CPUs the address
space is active. This allows flush_tmap() to avoid ICI for user
address spaces when the team isn't currently running on any other CPU.
In this context ICI is relatively expensive, particularly since we map
most pages via vm_map_page() and therefore invoke flush_tmap() pretty
much for every single page.
This optimization speeds up a "hello world" compilation about 20% on
my machine (KDEBUG turned off, freshly booted), but interestingly it
has virtually no effect on the "-j2" haiku build time.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27912 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...


# 428a7df2 06-Oct-2007 Jérôme Duval <korli@users.berlios.de>

fix ppc kernel build


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22463 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 6c678c57 10-Jan-2006 Ingo Weinhold <ingo_weinhold@gmx.de>

* The exception vector offset is now also part of the iframe.
* Cloned iframe stack management from x86.
* Reimplemented arch_thread_{get,set}_current_thread(). The
thread structure is stored in SP

* The exception vector offset is now also part of the iframe.
* Cloned iframe stack management from x86.
* Reimplemented arch_thread_{get,set}_current_thread(). The
thread structure is stored in SPRG2. It is set to NULL in
arch_cpu_preboot_init(), now. A non-null current thread
causes all kinds of undesired behavior in early boot code.
* We establish the address space mappings we know from the
Open Firmware as areas. At least those in kernel address
space. The ones in userland address space are tougher.
Fortunately on my Mac mini there aren't any save the
boot_loader stack, which is not needed any longer anyway.
* Added stack trace support to the kernel debugger. Mostly
cloned and adjusted the x86 code. Some bits are still
missing, like stack traces for other threads.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15890 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...


# 51a3c450 13-Dec-2005 Axel Dörfler <axeld@pinc-software.de>

The short story: we now have MTRR support on Intel and AMD CPUs (the latter
has not yet been tested, though - I'll do this after this commit):
* Removed the arch_memory_type stuff from vm_area; since

The short story: we now have MTRR support on Intel and AMD CPUs (the latter
has not yet been tested, though - I'll do this after this commit):
* Removed the arch_memory_type stuff from vm_area; since there are only 8 memory
ranges on x86, it's simply overkill. The MTRR code now remembers the area ID
and finds the MTRR that way (it could also iterate over the existing MTRRs).
* Introduced some post_modules() init functions.
* If the other x86 CPUs out there don't differ a lot, MTRR functionality might
be put back into the kernel.
* x86_write_msr() was broken, it wrote the 64 bit number with the 32 bit words
switched - it took me some time (and lots of #GPs) to figure that one out.
* Removed the macro read_ebp() and introduced a function x86_read_ebp()
(it's not really a time critical call).
* Followed the Intel docs on how to change MTRRs (symmetrically on all CPUs
with caches turned off).
* Asking for memory types will automatically change the requested length to
a power of two - note that BeOS seems to behave in the same, although that's
not really very clean.
* fixed MTRRs are ignored for now - we should make sure at least, though,
that they are identical on all CPUs (or turn them off, even though I'd
prefer the BIOS stuff to be uncacheable, which we don't enforce yet, though).



git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15528 a95241bf-73f2-0310-859d-f6bbb57e9c96

show more ...


# 2ed21b85 13-Dec-2005 Axel Dörfler <axeld@pinc-software.de>

Some work in progress of the MTRR support. Shouldn't do any harm yet :-)


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15525 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 97ec781e 12-Dec-2005 Axel Dörfler <axeld@pinc-software.de>

Added (empty) memory type functions to the PPC port.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15521 a95241bf-73f2-0310-859d-f6bbb57e9c96


# 2d690920 13-Apr-2005 Axel Dörfler <axeld@pinc-software.de>

Renamed system/core to system/kernel.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12360 a95241bf-73f2-0310-859d-f6bbb57e9c96