#
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
|