History log of /haiku/src/add-ons/kernel/cpu/x86/amd.cpp
Revision Date Author Comments
# f0ccf102 26-Feb-2014 Julian Harnath <julian.harnath@rwth-aachen.de>

Fix AMD CPU selection in generic_x86 kernel add-on

* The AMD-part of the add-on is supposed to reject some very old
models. However, a bug in the selection code caused it to reject
anything with model-number smaller 9 regardless of model-family.
This caused MTRR setup to not happen on many AMD CPUs and Haiku
being very slow on these machines.

* Fixes #10571


# 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


# cdffef9f 24-May-2006 Axel Dörfler <axeld@pinc-software.de>

MTRR is no longer set on anything below AMD K6-2 model 9. This should fix bug #624.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17572 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


# 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


# f0ccf10243cc7d7ddfe8a52a5e298264bc899d56 26-Feb-2014 Julian Harnath <julian.harnath@rwth-aachen.de>

Fix AMD CPU selection in generic_x86 kernel add-on

* The AMD-part of the add-on is supposed to reject some very old
models. However, a bug in the selection code caused it to reject
anything with model-number smaller 9 regardless of model-family.
This caused MTRR setup to not happen on many AMD CPUs and Haiku
being very slow on these machines.

* Fixes #10571


# 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


# cdffef9f0190adbf77b8ca379299a4e7d76ceed9 24-May-2006 Axel Dörfler <axeld@pinc-software.de>

MTRR is no longer set on anything below AMD K6-2 model 9. This should fix bug #624.


git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17572 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


# 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