add-ons/kernel: add spaces between literals and identifiers

Due to introduction of user-defined suffixes C++11 requires that there
is a space between literal and identifier to avoid ambiguity.

This patch makes the whole kernel build successfully with C++11.

x86[_64]: Add support for CPUID sub-leaves

Some CPUID leaves may contain one or more sub-leaves accessed by setting
ECX to an appropriate value.

* 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

* 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

When clearing the MTRRs also set the default type to uncacheable. Otherwise on
systems where the default is set to a cachable type and MTRRs are used to define
the uncacheable areas, everything would become cacheable after clearing them.


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

Fix the length calculated in generic_get_mtrr(). The +1 would usually be added
to the mask and then shifted, but as we don't do the shifting at all, we need
to add a page size instead of just 1.


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

* Add more details to debug output.
* Change the TRACE macro to use varargs and add a prefix for easier grepping.
* Some line length cleanup.


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

Fix more operator precedence errors. These do not do what you'd expect at first
sight. The comparison operator takes precedence over the binary ones.


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

pulled over some stuff from newos:
at boot, per cpu, detect the cpu, pull down all the relevant cpuid bits and
save them into the per-cpu structure. Changed most of the code scattered here
and there that reads the cpuid to use a new api, x86_check_feature, which looks
at the saved bits.
Also changed the system_info stuff to read from these bits.
While i was at it, refreshed all the bits to be current.


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

Applied patch by Vasilis Kaoutsis: now checks for the MSR feature as well; obviously
some Pentium 200 MMX pretend to support MTRRs.
This should fix bug #553.


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

No longer call init_mtrrs() if there are no MTRRs, also made generic_init_mtrrs()
no longer try to access any MSRs when there are no MTRRs. Got it? :-)


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

This may fix Rudolf's MTRR problem - could you please try?


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

* Now calls get_current_cpuid() instead of get_cpuid() - that doesn't work on
SMP machines since we're already in a call_all_cpus() function (that also
needs to run synchronously). MTRR does now work on SMP machines again; ie.
SMP machines should boot fine again now.
* Fixed warning when compiled with tracing turned on.


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

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

Implemented VIA specific MTRR functionality - untested, though.


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

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

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

add-ons/kernel: add spaces between literals and identifiers

Due to introduction of user-defined suffixes C++11 requires that there
is a space between literal and identifier to avoid ambiguity.

This patch makes the whole kernel build successfully with C++11.

x86[_64]: Add support for CPUID sub-leaves

Some CPUID leaves may contain one or more sub-leaves accessed by setting
ECX to an appropriate value.

* 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

* 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

When clearing the MTRRs also set the default type to uncacheable. Otherwise on
systems where the default is set to a cachable type and MTRRs are used to define
the uncacheable areas, everything would become cacheable after clearing them.


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

Fix the length calculated in generic_get_mtrr(). The +1 would usually be added
to the mask and then shifted, but as we don't do the shifting at all, we need
to add a page size instead of just 1.


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

* Add more details to debug output.
* Change the TRACE macro to use varargs and add a prefix for easier grepping.
* Some line length cleanup.


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

Fix more operator precedence errors. These do not do what you'd expect at first
sight. The comparison operator takes precedence over the binary ones.


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

pulled over some stuff from newos:
at boot, per cpu, detect the cpu, pull down all the relevant cpuid bits and
save them into the per-cpu structure. Changed most of the code scattered here
and there that reads the cpuid to use a new api, x86_check_feature, which looks
at the saved bits.
Also changed the system_info stuff to read from these bits.
While i was at it, refreshed all the bits to be current.


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

Applied patch by Vasilis Kaoutsis: now checks for the MSR feature as well; obviously
some Pentium 200 MMX pretend to support MTRRs.
This should fix bug #553.


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

No longer call init_mtrrs() if there are no MTRRs, also made generic_init_mtrrs()
no longer try to access any MSRs when there are no MTRRs. Got it? :-)


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

This may fix Rudolf's MTRR problem - could you please try?


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

* Now calls get_current_cpuid() instead of get_cpuid() - that doesn't work on
SMP machines since we're already in a call_all_cpus() function (that also
needs to run synchronously). MTRR does now work on SMP machines again; ie.
SMP machines should boot fine again now.
* Fixed warning when compiled with tracing turned on.


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

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

Implemented VIA specific MTRR functionality - untested, though.


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

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

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