#
fa157509 |
|
10-Dec-2013 |
Pawel Dziepak <pdziepak@quarnos.org> |
kernel/cpu: Do not use get_system_info() to identify CPU
|
#
dac21d8b |
|
18-Feb-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* map_physical_memory() does now always set a memory type. If none is given (it needs to be or'ed to the address specification), "uncached" is assumed. * Set the memory type for the "BIOS" and "DMA" areas to write-back. Not sure, if that's correct, but that's what was effectively used on my machines before. * Changed x86_set_mtrrs() and the CPU module hook to also set the default memory type. * Rewrote the MTRR computation once more: - Now we know all used memory ranges, so we are free to extend used ranges into unused ones in order to simplify them for MTRR setup. - Leverage the subtractive properties of uncached and write-through ranges to simplify ranges of any other respectively write-back type. - Set the default memory type to write-back, so we don't need MTRRs for the RAM ranges. - If a new range intersects with an existing one, we no longer just fail. Instead we use the strictest requirements implied by the ranges. This fixes #5383. Overall the new algorithm should be sufficient with far less MTRRs than before (on my desktop machine 4 are used at maximum, while 8 didn't quite suffice before). A drawback of the current implementation is that it doesn't deal with the case of running out of MTRRs at all, which might result in some ranges having weaker caching/memory ordering properties than requested. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35515 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bb163c02 |
|
23-Nov-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Added a set_mtrrs() hook to x86_cpu_module_info, which is supposed to set all MTRRs at once. * Added a respective x86_set_mtrrs() kernel function. * x86 CPU module: - Implemented the new hook. - Prefixed most debug output with the CPU index. Otherwise it gets quite confusing with multiple CPUs. - generic_init_mtrrs(): No longer clear all MTRRs, if they are already enabled. This lets us benefit from the BIOS's setup until we install our own -- otherwise with caching disabled things are *really* slow. * arch_vm.cpp: Completely rewrote the MTRR handling as the old one was not only slow (O(2^n)), but also broken (resulting in incorrect setups (e.g. with cachable ranges larger than requested)), and not working by design for certain cases (subtractive setups intersecting ranges added later). Now we maintain an array with the successfully set ranges. When a new range is added, we recompute the complete MTRR setup as we need to. The new algorithm analyzing the ranges has linear complexity and also handles range base addresses with an alignment not matching the range size (e.g. a range at address 0x1000 with size 0x2000) and joining of adjacent/overlapping ranges of the same type. This fixes the slow graphics on my 4 GB machine (though unfortunately the 8 MTRRs aren't enough to fully cover the complete frame buffer (about 35 pixel lines remain uncachable), but that can't be helped without rounding up the frame buffer size, for which we don't have enough information). It might also fix #1823. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34197 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2058e6c1 |
|
16-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Refactored MTRR code a bit: there is now a generic base that is used by all CPU specific implementations as much as possible. AMD and Intel are now separated again, even though they are currently equivalent besides the CPU vendor detection. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15567 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
af018058 |
|
16-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Implemented VIA specific MTRR functionality - untested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15560 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f104fa77 |
|
13-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Did not compile with tracing turned off. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15529 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
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 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
|
#
2ed21b85 |
|
12-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
|
#
4f006133 |
|
12-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Added generic x86 CPU module. Contains (emtpy) modules for Intel/AMD/VIA models. Might be separated later, though, depending on how large they will get. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15522 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
fa157509258c9b494903e48aed66816897bb6cc6 |
|
10-Dec-2013 |
Pawel Dziepak <pdziepak@quarnos.org> |
kernel/cpu: Do not use get_system_info() to identify CPU
|
#
dac21d8bfe3fcb0ee34a4a0c866c2474bfb8b155 |
|
18-Feb-2010 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* map_physical_memory() does now always set a memory type. If none is given (it needs to be or'ed to the address specification), "uncached" is assumed. * Set the memory type for the "BIOS" and "DMA" areas to write-back. Not sure, if that's correct, but that's what was effectively used on my machines before. * Changed x86_set_mtrrs() and the CPU module hook to also set the default memory type. * Rewrote the MTRR computation once more: - Now we know all used memory ranges, so we are free to extend used ranges into unused ones in order to simplify them for MTRR setup. - Leverage the subtractive properties of uncached and write-through ranges to simplify ranges of any other respectively write-back type. - Set the default memory type to write-back, so we don't need MTRRs for the RAM ranges. - If a new range intersects with an existing one, we no longer just fail. Instead we use the strictest requirements implied by the ranges. This fixes #5383. Overall the new algorithm should be sufficient with far less MTRRs than before (on my desktop machine 4 are used at maximum, while 8 didn't quite suffice before). A drawback of the current implementation is that it doesn't deal with the case of running out of MTRRs at all, which might result in some ranges having weaker caching/memory ordering properties than requested. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@35515 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
bb163c0289ef6ea5d1d6162f0178273c8933a7c0 |
|
23-Nov-2009 |
Ingo Weinhold <ingo_weinhold@gmx.de> |
* Added a set_mtrrs() hook to x86_cpu_module_info, which is supposed to set all MTRRs at once. * Added a respective x86_set_mtrrs() kernel function. * x86 CPU module: - Implemented the new hook. - Prefixed most debug output with the CPU index. Otherwise it gets quite confusing with multiple CPUs. - generic_init_mtrrs(): No longer clear all MTRRs, if they are already enabled. This lets us benefit from the BIOS's setup until we install our own -- otherwise with caching disabled things are *really* slow. * arch_vm.cpp: Completely rewrote the MTRR handling as the old one was not only slow (O(2^n)), but also broken (resulting in incorrect setups (e.g. with cachable ranges larger than requested)), and not working by design for certain cases (subtractive setups intersecting ranges added later). Now we maintain an array with the successfully set ranges. When a new range is added, we recompute the complete MTRR setup as we need to. The new algorithm analyzing the ranges has linear complexity and also handles range base addresses with an alignment not matching the range size (e.g. a range at address 0x1000 with size 0x2000) and joining of adjacent/overlapping ranges of the same type. This fixes the slow graphics on my 4 GB machine (though unfortunately the 8 MTRRs aren't enough to fully cover the complete frame buffer (about 35 pixel lines remain uncachable), but that can't be helped without rounding up the frame buffer size, for which we don't have enough information). It might also fix #1823. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34197 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
2058e6c1d4c07696e8bb8cb59bbf96a27b5e1688 |
|
16-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Refactored MTRR code a bit: there is now a generic base that is used by all CPU specific implementations as much as possible. AMD and Intel are now separated again, even though they are currently equivalent besides the CPU vendor detection. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15567 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
af01805834bb089e56e79a5bef92cd52d569a4dd |
|
16-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Implemented VIA specific MTRR functionality - untested, though. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15560 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
f104fa77bdbb01bff97c22f04e831fad5724e3f1 |
|
13-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Did not compile with tracing turned off. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15529 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
51a3c450bebefa32a5636bc6078bdd648818da41 |
|
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 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
|
#
2ed21b85257d9d36d4d8a25c2a798a42add6e618 |
|
12-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
|
#
4f00613311d0bd6b70fa82ce19931c41f071ea4e |
|
12-Dec-2005 |
Axel Dörfler <axeld@pinc-software.de> |
Added generic x86 CPU module. Contains (emtpy) modules for Intel/AMD/VIA models. Might be separated later, though, depending on how large they will get. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15522 a95241bf-73f2-0310-859d-f6bbb57e9c96
|